시작하기 전에
레벨2 레벨 인터뷰는 포비의 조에 당첨 되었다.
포비와 레벨 인터뷰라니.. 처음에는 조금 무서웠으나, 진행할 때는 너무 좋았다!! 계속 질문하지 않으시고, 인터뷰어의 질문을 토대로 추가 질문을 하셨다.
크루들의 긴장을 풀어주려고 하시는 모습이 너무 스윗하셨다!
조를 나누지는 않고 전체가 오전, 오후를 모두 함께 했다.
함께 레벨 인터뷰를 진행한 크루는 애쉬, 민트, 베베, 로이, 저문, 달리, 여우 였다.
그리고 나는 마지막 순서였다(거의 밤을 새고 와서 죽을 것 같았다..ㅎㅎ).
레벨2의 레벨 인터뷰는 레벨1 때와 다르게 레벨로그를 공유하지 않고 진행되었다. 즉, 어떤 질문을 받을지 모르는 상황에서 인터뷰를 진행했다.
질문
레벨 인터뷰를 하면서 받았던 질문에 대해 정리하였다.
질문과 꼬리질문들을 구분하여 작성하였다.
인터뷰어: 애쉬, 민트, 달리 (+ 포비)
레이어드 아키텍처
- 이번 미션에서 레이어드 아키텍처를 사용했는지?
- 레이어드 아키텍처가 뭔지 설명해줄 수 있는지?
- 어떤 이유로 레이어드 아키텍처를 사용해야 할까요?
- 레이어드 아키텍처를 사용하면서 단점이 있다고 느꼈는지?
- 계층을 구성할 때 어떤 레벨로 구성했는지?
- 도메인 코드가 영속성 계층에 영향을 받는 문제에 대해서 어떻게 생각하는지? 어떻게 해결할 수 있는지 말해줄 수 있나요?
- service 레이어에서 특정 DB에 의존하지 않기 위해 repository 계층을 둔 것으로 이해했습니다. 그러나 DAO를 인터페이스로 두면 특정 DB에 의존하지 않을 것 같은데 굳이 repository 계층을 둘 필요가 있는지?
- entity를 domain으로 조립해주는 것은 repository의 역할이 아니라 mapper의 역할로 볼 수 있지 않나요? 이에 대해 어떻게 생각하시는지?
엔티티와 도메인
- DB 테이블과 매핑하는 객체와 비지니스 로직을 구현하는 객체를 분리했는지, 하나로 가져갔는지?
- 두 객체 사이의 데이터 변환을 어디서 하는지?
- Controller 와 데이터 교환을 위해서도 DTO와 같은 새로운 객체를 사용했을텐데, 그럼 하나의 기능 개발을 하기 위해 비슷한 성격의 객체가 3개가 나올 수 있겠네요. 그 사이에 발생하는 중복은 어떻게 관리했는지?
- DB 테이블과 매핑되는 객체랑 도메인 객체가 1:1 로 매핑되는지? 없다면 예시를 들어줄 수 있는지?
- 모두 1:1로 매핑되었다면, 도메인과 엔티티 객체의 어떤 차이가 있었는지? 둘의 차이가 있어서 구분한건지, 아니면 단순히 DB용 객체와 비지니스 로직을 가지는 객체를 분리하기 위해 구분하신건지?
- DB에서는 왜 ID로 연관관계를 매핑한다고 생각하시는지?
웹 서버와 웹 어플리케이션 서버
- 웹 서버와 웹 어플리케이션 서버의 차이를 알고 있는지?
- 웹 어플리케이션 서버는 웹 서버의 역할을 다 하고 있는 것 같은데, 왜 분리해서 사용할까요?
- 웹 어플리케이션을 여러개 둔다면 어떨까요? 여러개 둔다면 한 개를 두는 것에 비해 어떤 이점이 있을까요?
- 서버가 n개로 확장될 때 주의해야할 점이 있을지?
- 스프링 부트 기반으로 개발을 하면, 정적인 자원과 동적인 자원을 같이 가지고 있을겁니다. 배포할 때 웹서버와 웹 어플리케이션 서버를 분리하면 어렵지 않을까요? 이 문제는 어떻게 해결하면 좋을까요?
구현
- 미션을 하다보면, 하나의 기능을 수행하기 위해 여러가지 역할을 담당해야할 때가 있습니다. 예를 들면, (지하철 미션) 하나의 구간을 추가하기 위해 기존 구간을 조회하거나, 기존 구간을 삭제하고 새로운 구간을 추가해야하는 경우가 있을겁니다. 이럴 경우 API 하나에 너무 많은 역할이 들어간다고 생각하는데, 이 경우 하나의 API로 구현해야할까요, 아니면 모두 나눠서 구현해야할까요?
@Transactional
- 만약 @Transactional 를 붙인 메서드 안에서 중간에 쿼리가 실행되면서 RuntimeException이 터지면 자동으로 rollback이 된다고 생각하시나요? 무조건적으로?
테스트
- 테스트 더블에 대해서 설명해주실 수 있는지?
- 테스트 더블의 종류에 대해서 설명해주실 수 있는지?
- stub과 mock의 차이에 대해 설명해주실 수 있는지?
- 테스트에서 mock 객체를 사용하셨는지? 어떤상황에서 사용했는지? 왜 사용했는지?
- 컨트롤러 테스트 진행했는지? 컨트롤러 테스트에서는 mock객체 사용했는지, 아니면 실제 객체를 사용해서 했는지? 그 이유는 무엇인지?
- 스프링 부트 테스트에서 실제 객체를 사용하기 위해 어떤 옵션을 넣어줘야하는지?
- 왜 random port를 사용했는지?
피드백
옵저버: 베베, 저문, 여우 (+ 포비)
부족한 점이 한 바가지.. 하지만 오히려 좋아.. 원래 단점 알기가 더 어려운 것이다.. 감사하게 생각해야지!!
좋았던 점
- 전반적으로 준수한 설명을 한다.
- 예시와 함께 설명과 생각을 붙여주는 점이 좋았다.
- 자신이 엔티티와 도메인을 나누고 중복되는 부분을 굳이 나누지 않은 이유를 설명한게 좋았다.
- 자신이 설계한 구조에 대해서 명확한 주관을 가지고 있다.
- 차분하게 설명을 이어가는 모습이 좋았다.
- 자세가 굉장히 안정적이다.
- 이해 못한 질문을 면접관에게 차분하게 다시 물어본다.
부족한 점
- 학습은 잘한 것 같은데 기술적인 이해를 기반으로 한 표현이 부족한게 아쉽다.
- 짧게라도 근거를 말해주면 좋을 것 같다.
- 짧은 답변으로 꼬리 질문을 유도하는 것은 좋지만, 필요에 따라 길게 대답하는 경우도 좋아보인다.
- 레이어드 아키텍쳐를 사용하는데 해당 아키텍쳐에 대해서 더 깊이있게 공부하면 좋을 것 같다.
- 스프링을 사용하는 만큼 스프링만의 배포 방식에 대해서 자세히 공부해 보는 것도 좋을 것 같다.
- db와 스프링의 사이에서 조율하는 무언가에 대해 더 학습하는게 좋을 것 같다(트랜잭션 격리 수준과 롤백, 예외).
- 전반적으로 지식의 뎁스가 너무 얕은 것 같다. 면접관이 어느 분야의 질문을 해도 깊이있는 대답이 돌아오지 않는다.
- 프로젝트에 적용할 구조를 설계할 때 어떤 근거로 결정했는지, 또 다른 대안이 있는지 고민을 많이 하지 못한 느낌이 듭니다.
- 꼬리질문을 내기 쉽게 답변을 합니다.
- 목소리가 조금 더 커도 좋을 것 같다.
- 모르는 부분에 대해서는 말이 길어지는 모습이 보였다.
- 중간중간 생각할 때 뜸을 들이는 주기가 너무 잦다.
- 면접관과 눈을 마주치면 좋을 것 같다.
- 모르는 주제에 대해서 질문이 나왔을 때 자신감이 엄청 떨어져보인다.(목소리부터 작아짐) 그리고 떨어진 페이스가 계속 이어진다.
- 모르는 부분에 대해서는 그냥 모른다고 하는게 더 좋을 수 있다.
- 긴 고민 끝에 항상 '제가 생각하기로는' 이라는 고정된 문장으로 시작하는 습관이 있다.
포비의 말
개인 피드백
- 목소리 톤을 올릴 수 있는 만큼 최대한 올려봅시다(+ 크기). 자신감 있게!
- 만약 공부를 많이 했음에도 답변하는게 어려웠다면, 공부 방법을 바꿔보면 좋을 것 같습니다. 경험 위주로 교육과정이 설계되어있기 때문에 이론적으로만 공부한다면 꼬리 질문에 답변하기 어려울 것 입니다. 공부 방법을 검토해보면 좋을 것 같습니다. 이론+경험으로 공부해보면 좋을 것 같습니다!
QnA
Q1. 포비가 생각하기에 이론과 실기의 비율을 나눈다면?
- 딱 잘라 말할 수 없겠지만, 경험을 충분히 하다보면 스프링 사용법이나 요구사항에 대해 무언가를 참고하지 않고 만들 수 있다는 느낌이 들 것이다.
- 새로운 용어들이 등장하면 일정기간동안 책을 보면서 학습했던 것 같다. - 경험-이론-경험-이론 이런식으로 공부하는 게 좋다.
- 책도 처음부터 끝까지 보기보다는 필요할 때 찾아보고 깊게 공부하는 방법도 있다.
- 너무 미션에만 몰입하지 말자.
- 이론적인 학습은 소홀히 하지 말자.
Q2. 실제 회사 면접에서 경험에 대해 설명할 때 어떻게 설명할 수 있을까요?
- 실제 면접에서 (미션 같은) 경험에 대한 예시를 잘 설명할 수 있도록 연습을 많이 해야 합니다.
- 요구사항에 대해서 설명하고, 어떻게 구현했고, 어떤 어려움이 있었다. 이를 해결하기 위해 어떤 방법을 사용했다. 이런 식으로 풀어서 설명할 수 있어야 한다. 즉, 예시를 들 때 구체적으로 설명해서 상대가 이해할 수 있어야 한다.
Q3. 추상화 되어있는 기술을 사용하다보면, 왜 이 기술을 사용해야하는지 설명하기 힘든데, 어떻게 하면 좋을까요? (모두 경험해볼 수 없기 때문에)
- 이점이나 단점, 불편한 점에 대해 계속 고민해야 한다.
- 기술의 등장 배경에 대해 생각해보자.
- 장점이나 단점에 대해 잘 모르겠으면 나만의 이유를 찾자!!
- why 를 생각하는게 가장 중요하다.
Q4. 잘 하는 개발자의 역량이 뭔지..?
- 기술을 얼마나 잘 사용하느냐도 있겠지만, 문제 상황에 맞는 기술을 잘 사용하는 개발자가 잘 하는 개발자라고 생각한다.
- 적절한 상황에 적절한 해결책을 제시할 수 있어야 한다. 적절한 해결책을 찾아가는 자세가 중요하다!
모두에게 전하는 말
가장 빠르게 성장하는 사람은 피드백을 잘 수용해서 성장하는 사람이다.
레벨 인터뷰가 끝이 아니다. 이건 하나의 과정이다! 오늘 잘 했고, 못 했고는 중요한 것이 아니다. 이 과정에서 무엇을 경험하고 느꼈는지를 정리하는 것이 중요하다.
이 경험 속에서 부족한 부분을 깨달았다면 보완하면 되고, 잘 했다면 계속 잘 해나가면 된다.
당일에 회고 하는 것이 가장 좋다. 가장 빠르게 성장하는 사람은 피드백을 잘 수용해서 성장하는 사람이다.
회고는 귀찮고 어렵지만, 많이 할수록 더 성장할 수 있다. 하지만 그 속에서 제발 자책은 하지말자. 내 자신을 연민으로 바라보자.. 앞으로 잘하면 된다는 마음을 가지자!
생각
포비가 말씀하신대로 레벨 인터뷰를 하고 바로 회고를 작성할까 생각했지만, 멘탈이 살짝 바사삭이라 잠시 미뤄두고 오늘 작성하게 되었다. 쉬면서 레벨2도 돌아보고 레벨 인터뷰 피드백에서도 곱씹어 봤던 것 같다. 그 때의 감정을 생각하면.. 음.. 착잡했던 것 같다. 꼭 첫 단추를 잘못 끼운 것 같은 느낌이 들었다. 시간을 되돌릴 수 있으면 좋겠으나, 그럴 리 만무하기에 레벨3에서 차근차근 다시 시작해봐야 겠다.
레벨2를 하면서, 공부 방법이나 방향성에 대해서 갈피를 못 잡았었다. 흐린 눈 하고 있었는데, 역시 레벨 인터뷰에서 내가 부족하다는 것이 여실히 들어났다.
레벨 인터뷰 결과가 이런 것이 컨디션이 안 좋았던 이유도 있었으나, 평소에 충분히 학습했다면 이 정도로 개판은 아니었을 것 같다.
이제 회피를 그만하고 직면해야겠다는 생각을 했다. 크루들의 피드백을 들으면서 부끄럽고 속상했던 것도 사실이지만, 정신이 확 들어서 고마운 마음이 더 컸다.
단순히 미션을 기간 안에 해내는 것이 우테코가 지향하는 바도 아니고, 나의 목표도 아니다. 그 동안은 이 점을 잊고 산 것 같다.
그런 의미에서 레벨 인터뷰는 너무나 의미있었고, 부끄러운 나 자신과 대면할 수 있는 좋은 시간이었다. 포비는 자책하지 말라고 하셨지만, 나에겐 자책할 시간이 약간 필요하다. 조금만 자책하고 정신 차리겠습니다 ㅎㅎ
글을 마무리 하면서, 레벨 인터뷰를 함께한 크루들과 포비에게 다시 한 번 감사함을 전합니다! 💕
