레벨로그란?

우아한테크코스에는 레벨 인터뷰가 존재한다. 일종의 모의 면접으로 한 레벨 동안 배운 내용을 인터뷰를 통해 점검하는 것이다. 6명의 팀으로 진행했는데, 레벨 로그를 토대로 1명의 인터뷰어를 3명의 크루 인터뷰이와 코치가 인터뷰하고, 2명이 옵저버(관찰자)로 참여한다. 역할은 돌아가면서 바뀐다.
나는 크루 리차드, 릭, 열음, 오찌, 클레이와 코치 브라운과 함께 했다.

인터뷰어 회고

레벨1 레벨로그는 키워드 중심으로 간략하게 작성했다. 레벨1동안 많은 걸 배웠지만 직접 로그로 쓰기 전 까지는 정확히 몰랐다. 그런데 인터뷰를 위해 로그를 쓰면서부터 한 번 정리할 수 있었다.
감사하게도 열음이 내 인터뷰 기록을 남겨줘서 복기가 쉬웠다.

인터뷰 요약 전문 
Q . TDD 하면서 도움을 받았던 경험, 불편했던 경험  
A . 체스미션 기물 종류별 움직임 에러 디버깅시 편리, 여러 케이스가 모여있는 경우에 원인을 찾기 편함, 비즈니스 로직 통합 개발 시 에러가 적었다  
중간에 설계가 바뀌어 테스트도 전부 고친 경험이 불편  

Q. 설계가 바뀔 수 있을때 변경범위를 줄이는 방법이 있나?  
A. TDD는 설계가 아닌 개발 방법론. 시작 전 구조를 어느정도 잡고 착수하면 변경을 줄일 수 있을 것 같다  
구현을 작은 단위로 하면 파급효과가 덜할 것 같다  

Q. 자바의 Checked exception / Unchecked exception 의 차이  
A. Checked exception은 try,catch 로 잡고 unchecked exception은 runtime에러가 나옴, 실패가 발생했을때 이어지는 상황에 따라 달리 써야한다. 그리고 이에 대한 처리는 개발자에 달림.  
복구나 대처가 상황이면 해결을, 복구 불가능한 상황이라면 다른 exception을 던지는 식으로 처리해왔다   

Q. 추상클래스는 객체를 생성할 수 없는데, 생성자는 가질 수 있다. 왜 이런 구조일까?  
A. 자식클래스에서 사용, 생성시 제약사항(검증)등을 걸 수 있으므로  

Q. 추상클래스 vs 인터페이스?  
A. 인터페이스는 input, output만 작성, 추상클래스는 이외에도 기본적인 메소드나 필드가 포함되어있음  
변경에 의한 파급효과 때문에 인터페이스를 먼저 시도하는 편  

Q. 구현체가 중복되어도 인터페이스를 선호한 이유가 있나?  
A. 메소드가 겹치는 경우가 이제까지 없어서 잘 모르겠다  

Q. 인터페이스로 썼는데 메소드를 추가한다면 가장 최적의 방법은?  
A. 만약 구현 내용이 같다면 디폴트 메서드로 추가하는 걸 미리 고려, 불가능하면 implement한 클래스에 전부 작성  

Q. 의존 관계의 정의, 주입법의 장점?  
A. A가 B를 사용할 때. 의존관계를 받는 클래스에서 무엇을 주입받을지 결정할 수 있다는 장점이 있다  

Q. 클린코드의 원칙, 가장 수정하고싶은 코드?  
A. 이름을 잘 짓기, 코드 줄 적게, 보드 서비스를 수정하고싶음. (메소드 배치 순서) 페어가 코드를 읽기 힘들어해서 1순위.  

Q. DI에 인터페이스만 들어갈 수 있나? 다른건?  
A. 다른 구현체도 들어갈 수 있음  

Q. 페어는 처음?, 첫페어랑 마지막페어랑 가장 크게 달라진 생각    
A. 우테코에 와서 처음. 좋은 코드를 짤 수 있음이 장점인 줄 알았는데 소통을 많이 하게 됨. 서로 생각하는 코드의 장점이나 단점을 얘기할 수 있어서 좋았다.  

Q. 레벨1에서 지식을 공유한 경험이 있나? 처음의 본인에게 가장 가르쳐주고싶은 철칙이 있다면?  
A. 계속 나보다 경험이 많은 페어들과 매칭되었다. 적극적으로 물어보는 태도를 당부할 것 같다.

그리고 리차드가 저녁에 피드백을 보내줬다😭 정말 너무 고마워서 눈물이 났다…

리차드의 피드백
  • 테스트 코드의 유지보수 비용을 줄일 수 있는 방법에 대하여 답변 준비해보기
  • 경험해보지 못한 사례나 모르는 내용에 대한 질문을 받았을 때, 차분히 모름을 인정하되 현재 생각나는 추론과 이유를 제시하기
  • 인터뷰어로부터 같은 질문이 반복될 때 나의 답변 중 모순이 있었는지, 함정일지 판단해보기 (잠시 시간 두고 생각하기. 때론 빠른 인정이 나을 수도)
  • 다른 크루에게 도움을 준 경험에 대하여 답변 준비해보기
  • 페어 프로그래밍 또는 협업에 있어 내가 지키고자 하는 철칙에 대한 답변 준비해보기
  • 추상클래스 or 인터페이스 or 구현체 각각을 의존관계 주입할 때의 차이에 대한 답변 준비해보기
  • 추상 클래스 vs 인터페이스의 선택 기준 또는 추상 클래스가 더 유리한 상황에 대한 답변 준비해보기
    ( 저는 이펙 18번을 보고 다음과 같이 정리해봤어요. 1) 확실한 is-a관계이고, 2) 추상클래스 메서드에 결함이 없음이 확실하고, 3) 같은 패키지 내에서 관리되고, 4) 계층적 상속 없이 1단 상속만 사용한다면 추상클래스를 사용하는 게 맞다)

스스로 잘한 점

  • 거의 모든 질문에 알고 있는 지식을 아쉬움 없이 차근차근 말했다
  • 답변에 지식과 경험의 균형이 좋았다
  • 시선과 어조를 만족스럽게 관리했다

스스로 아쉬운 점

  • Checked/Unchecked Exception 질문에 답변하면서 모순 된 말을 했다
  • 모순된 말을 한 것을 처음에 인지하지 못하고 꼬리 질문에 당황했다
  • 경험이 없거나 생각해보지 않은 부분에 대해 조금 섣불리 단정적으로 대답했다

인터뷰이 & 옵저버 회고

레벨 인터뷰를 준비하면서 잘 대답하는 것만 걱정했다. 그런데 인터뷰이, 옵저버로 참여해 다른 크루들의 인터뷰를 들으면서 인터뷰어 때 만큼 많은 걸 배웠다.

  • 클레이 : 트러블 슈팅을 하며 제네릭에 대해 깊게 공부한 경험이 인상적이었다. 이 사람은 잘 모르는 문제를 발견하면 그냥 넘어가지 않고 꼼꼼히 파고들어 공부하는구나! 가 확실히 느껴졌다.
  • 리차드 : 개념 설명이 놀라울 정도로 완벽했다. 거기다 말하는 구성이 한 번 글을 써보신 것 처럼 탄탄해서, 대답의 구조를 저렇게 해야 듣기 쉽구나 했다.
  • 오찌 : 개념 질문에 대한 답변 만큼, 경험에 기반한 자기 주장이 탄탄하게 준비되어 있어서, 평소에 코드를 짜며 생각을 많이 한다는 것이 보였다. 엮인 개념들의 관계를 언급하는 부분이 특히 그랬다.
  • 열음 : 소프트스킬 관련해 다소 대답하기 어려운 질문에도 차분히 생각을 말하시는 모습에서 레벨1 동안 소프트스킬에 대해 많이 고민하셨음을 알 수 있었다. 개념 질문에 간결하지만 명확한 설명을 하셔서 알아듣기 쉬웠다.
  • 릭 : 질문에 대한 대답에서 단순히 대답의 부피를 불리기 위해 예시를 드는 것이 아니라, 경험을 통해 연관시켜 더 깊이있는 공부를 했음이 보였다. 확고한 페이스가 있는 점도 좋았다.

인터뷰를 들으면서 각자 확고하게 느껴지는 장점이 있었다. 면접에서 이런 장점을 보고 사람을 뽑는구나를 배울 수 있었다. 같은 데일리 조였던 오찌를 제외하고 거의 처음 보는 크루들이었는데도, 이 크루들이랑 같이 일하거나 공부하면 좋겠다고 진심으로 생각했다.

또, 열음이랑 리차드가 해 준 것 처럼, 다음 레벨 인터뷰 때는 나도 크루들을 위해 인터뷰 기록이나 더욱 상세한 피드백을 주고 싶다.

✏️ 종합 회고

작년까지는 모의 면접이라는 이름으로 진행했다고 들은데다 첫번째 순서로 인터뷰어를 하게 되어서 굉장히 긴장했다. 끝나고 다른 크루들과 코치 브라운이 잘했다며 칭찬해줬는데 순간 울컥할 정도였다. 단순히 면접 대비라 생각했는데, 인터뷰를 통해 내 학습 경향이나 화법에 대해 부족한 점을 성찰할 수 있어서 좋았다. 또, 다른 크루들의 인터뷰 모습을 보고, 함께 일하고 싶은 사람이란 저런 사람을 말하는 거구나를 배웠다. 해보기 전까지는 걱정이 컸는데, 다음 레벨 인터뷰가 기대된다. 그 때는 이번에 발견한 아쉬운 점을 보완해서 더 잘하고 싶다!