서론

우아한테크코스의 레벨인터뷰를 진행했다.
면접관의 역할인 인터뷰어, 면접자의 역할인 인터뷰이, 관찰자의 역할인 옵저버를 돌아가며 수행했다.

레벨 1 기간동안 학습한 내용에 대해 제대로 이해하고 있는지 알 수 있는 좋은 기회였다.

레벨인터뷰를 진행하며 학습했던 내용 및 받았던 피드백에 대해 정리해보려고한다.

레벨로그

레벨 1 동안 학습했던 내용을 상황과 키워드를 중심으로 정리해봤다.

자동차 경주

• 테스트를 작성할 수 있다? → Junit5, AssertJ 테스트
• 랜덤값을 테스트하는 방법? → 전략패턴
• 메소드가 최소한의 기능을 가진다? → 단위테스트

사다리타기

• 테스트를 먼저 작성했을 때 이점? → TDD로 설계 쌓기
• 객체와 메시지를 주고 받는다? → 원시값 포장
• final 키워드는 불변이다? → final과 불변

블랙잭

• Dealer와 Player는 정말 is-a 관계일까? → 상속과 조합
• 계층간 의존관계를 끊어주려면 어떻게할까? → DTO
• 운영체제별 개행 표현 → CRLF
• 파일의 마지막 라인에 공백이 없으면 GitHub에서 경고를 띄우는 이유? → POSIX

체스

• 동일한 행동을 하는 메소드를 묶어서 사용할 수 없을까? → 함수형 인터페이스
• 제한적인 시간 내에 개발을 해야한다면? → 시간 내로 빠르게 해결하는 방법과 리팩터링

위 내용 외적으로 다른 크루들의 경험을 공유받거나, 스스로 고민을 깊이 해보지 않은 내용들이 있다.

• Stream의 성능?
• 불변객체란?
• VO와 DTO의 차이는?
• 원시값 포장이란?
• 디자인 패턴에 대해 (전략패턴, 상태패턴, 커맨드 패턴 등)
• JCF
• 제네릭

레벨 인터뷰

인터뷰간 받았던 질문과 대답했던 부분, 피드백에 대한 내용을 하나씩 묶어서 확인해보려고한다.
아래는 인터뷰 진행과정을 문장을 다듬어서 표현한 내용들이다.
실제로는 답변 시 쓸데없는 소리를 많이 했다.

Q: Junit5와 AssertJ의 차이점?

A : Junit5는 문장의 흐름이 기대값을 먼저 추론 한 뒤 문장이 구성되고, 반대로 AssertJ는 문장의 흐름이 먼저 나온뒤 끝에 기대값이 나온다.
개인적으로 어떤 동작으로부터 어떤 결과값이 나온다라는 문장의 흐름이 읽기 쉬워 AssertJ를 주로 사용했다.

Q : 같이 개발하는 다른 팀원이 본인과 다른 것을 사용하면 어떻게 해결할 것인가?

A : 전체적인 레거시 코드가있다면 레거시를 따라가고, 회사의 컨벤션이 있다면 컨벤션을 따를 것 같다.
만약 이러한 부분이 없다면 다양한 상황에 대해 테스트를 작성해보고 어느 코드가 읽기 수월한지 비교해본 뒤 서로를 설득하는 시간을 가지고 조율할 것 같다.

Q: 메소드가 가지는 최소한의 기능의 기준은?

A : 메서드 명으로 수행하는 역할을 충분히 표현할 수 있고, 분기를 최소한으로 작성한다는 기준을 세우고 있다.

Q: TDD를 사용하면서 느낀 장점?

A : 객체지향에 대한 경계를 했다.
테스트를 먼저 작성하면서 해당 객체가 어떤 역할을 가지고, 어떤 책임을 가지고있는가? 에 대한 고민을 했다.
페어프로그래밍을 하면서도 페어와 항상 객체가 어떤 책임을 가져야하는지에 대한 경계를 했다.
이러한 경험을 통해 객체지향에 대한 생각이 깊어졌다는 장점이 있었다.

Q : 객체지향에 능숙한 엔지니어들끼리 협업을 해서 뭔가를 만들어야하는 상황에서는 TDD를 안해도될까?

A : 객체지향에 익숙하다라는 것이 굉장히 주관적인 관점이라 섣불리 말하기에는 조심스럽지만 어떤 객체를 떠올렸을 때 책임도 명확하고 설계도 자연스럽게 나오는 상황이라면 TDD를 하지 않고 시간적인 이점을 챙겨갈 것 같다.

Q: 원시값 포장을 하면 객체와 메시지를 주고받을 수 있다?

Q : 원시값 포장의 예시를 말하자면 나이를 표현하기 위해 int age = 20이라는 변수로 나타냈을 때 변수 명으로는 의미를 가질 수 있지만 변수가 다른 인자로 넘겨지고, 다른 함수에서 사용 될 때는 어떤 의미를 가지는지 명확해지지 않는다.
이 때 이 나이라는 값을 객체로 표현함으로써 객체가 자신의 상태를 가지고 행동할 수 있는 주체적인 객체가 될 수 있다고 생각한다.
이러한 생각을 통해 원시값을 포장하면 객체가 메시지를 전달할 수 있다는 말을 했다.

Q: 원시값 포장과 VO의 차이점?

A: 원시값 포장은 어떤 값에 대한 의미를 주는 행위라고 생각을 했고, VO는 값 자체로만 존재하는 특징을 가지고 있어 불변해야하는 특징을 가지고있다.
때문에 원시값 포장을 하는 과정에서 VO가 생길 수 있다는 흐름으로부터 원시값 포장이라는 행위와, VO라는 결과물 사이의 관계에서 동등성을 판단하기에는 어려워보인다.

Q: 자바 언어를 강제하지 않는다면 어떤 언어를 선택할것인가?

A: 우테코에서 자바가 blue collar 언어라는 것을 듣고 자바라는 언어가 생산성을 목표로 두고 개발된 언어임을 알게되었다.
아직 다른 언어데 대한 학습이 많이 진행되지 않은 상태에서 현재의 지식으로는 생산성이 높은 자바를 선택할 것 같다.

Q: 실제로 생산성 측면에서 이점을 느낀 부분이 있는가?

A: 짧은 경험에 빗대어 이야기하자면 C, C++을 사용해봤을 때는 세세한 구현 로직을 손으로 구현해야하는 경우가 많았다.
자바에서 기본적으로 제공하는 API를 활용했을 때 세부 구현에 과도한 신경을 쓰지 않아도 되기 떄문에 생산성에서의 이점을 느꼈다.

Q: 자바 언어를 이용해 객체지향으로 프로그래밍을 하려고 노력했는데, 실제로 미션을 진행하는데 도움이 되었는가?

A: 개인적으로 코드를 작성할 때 읽기 수월한 코드를 작성하는 것에 의의를 두고있다.
객체지향이 이러한 부분에 있어서 많은 도움을 줬다.
예를 들면 단일 책임원칙을 신경 썼을 때 객체의 책임이 명확해지면서 읽기 수월한 코드를 작성하는데 많은 도움이 된 경험이 있다.

Q: 함수형 인터페이스는 가독성이 낮은가?

A: 함수형 인터페이스를 처음 사용해봤기 때문에 익숙한 상태가 아니다.
문법이 생소하게 느껴지는 탓에 가독성이 좋아지는 부분은 체감되지 않았다.

함수형 인터페이스를 사용하게된 계기는 함수를 작성 할 때 공통된 행위를 함수를 봤는데 공통된 로직을 하나의 메소드로 분리하듯 함수도 분리할 수 없을까? 라는 의문을 가지게 되었다.
서적을 찾아보고 주변 크루들에게도 물어보면서 함수형 인터페이스를 사용하면 동작을 파라미터화 시킬 수 있다는 개념을 처음 알게되었다.
함수형 인터페이스를 사용해서 중복을 제거하는데는 도움이 되었으나 아직 문법이 익숙하지 않아 가독성 측면에서는 크게 향상되었다는 느낌을 받지 못했다.

피드백

인터뷰이, 인터뷰어, 옵저버를 하면서 도움이 될 만한 피드백들을 모았다.

학습

• 모르는것을 모른다고 말하는 솔직함이 좋았다.

정말 모르는것이 나왔을 때 모른다고 말하는 연습을 할 수 있었다.

• 자신의 주관이 생기고 있는 사람인 것 같아 좋았다.

스스로를 객관화하면서 느끼고 있던 부분을 다른 사람에게도 전달할 수 있어서 가장 기분 좋은 피드백이였다.

• 실제 적용은 해보지 못했으나 학습만 해봤던 내용은 아주 간단한 예시라도 만들어 보는 방식으로 학습을 해보는 것을 추천한다.

책으로만 익힌 지식보다는 경험을 예시로 드는 것이 상대방을 설득하기 좋다.
면접관은 딱딱한 지식을 보고 채용하기보다는 풍부한 경험을 보고 채용하고 싶어할 것이라는 생각이 들었다.

• 디자인패턴을 이용할 때 자신만의 명확한 주관을 가지도록 노력해보자.

전략패턴을 사용한다면 왜 사용해야하고 자바 뿐만 아니라 다른 언어에서도 통용될 수 있는 개념으로 이해해두는 것이 중요하다.
ex) 전략패턴은 Client Context Stragey로 구성되어있으며 자바에서는 Stragey를 구현하는 방식으로 Inteface를 이용한다...

말하기

• 잘 모르는 내용을 설명할 때 말이 길어진다.

설명할 때 질문의 의도를 명확히 파악하고 문장을 길게 이어가지 않도록 주의하자.
밥먹다가 문장의 단일 책임원칙 이라는 말이 생각났다...😂

• 답변을 할 때 시선이 분산된다.

질문자에게 시선을 집중하여 대화하고있다는 느낌을 줄 수 있도록 의식하자.

• 겸손한 표현보다는 적극적인 표현이 좋다. (제가 못하지만 → 제 생각은)

짧은 시간동안 나를 표현해야하는 만큼 자신감 있는 모습으로 깊은 인상을 심어주는것이 중요해보인다.

• 확장성, 성능 등에 대한 이야기를 할 때는 대략적으로라도 참고가 될만한 수치를 활용할 수 있어야한다.

프로그래밍에서 항상 고려되는 성능문제를 이야기할 때는 jvm, 메모리, 성능 차이에 대한 수치 등을 근거로 들 수 있어야한다.

공통 피드백

• 기술적으로 어려운 문제를 만났을 때 어떤 생각을 가지고 어떻게 해결할 지를 고민해보는 것이 중요하다.
  개발자는 단순히 프로그래밍을 하는 사람이 아니라 문제를 해결하는 사람이다.

위에서 이야기했듯이 경험을 들려달라는 질문이 많을 수 있다.
이럴 때 효과적으로 설명할 수 있는 STAR 메소드 인터뷰라는 방식이 존재한다.

• Situation: 장면을 설정하고 예제에 필요한 세부 정보를 제공합니다.
• Task: 그 상황에서 자신의 책임이 무엇이었는지 설명합니다.
• Action: 이 문제를 해결하기 위해 어떤 조치를 취했는지 정확히 설명합니다.
• Result: 어떤 결과를 달성했는지 공유합니다.

Situation: Set the scene and give the necessary details of your example.
Task: Describe what your responsibility was in that situation.
Action: Explain exactly what steps you took to address it.
Result: Share what outcomes your actions achieved.
참고자료

• 자신이 DB를 설계했다면 그 자리에서 간단한 ERD 정도는 그려볼 수 있어야한다.

결론

면접을 실제로 할 기회가 많이 없었는데 이번 레벨인터뷰를 통해 스스로 잘 성장하고 있음을 확인할 수 있는 시간이였다.

스스로 부족함이 많다고 생각했는 데 이번에 정확히 어떤 부분에서 부족함이 있었는지 알게되어 학습 방향성을 잡을 수 있었다.
인터뷰이를 했을 때 보다 옵저버를 하면서 다른 사람들이 받는 질문을 들었을 때 내가 이 부분을 모른다는 생각이 드는 부분도 많았다.

많은 키워드를 혼자서 소화하는 것 보다는 다양한 사람들의 경험을 들으면서 같이 성장하는 과정이 더욱 효율적인 것 같다.

레벨 2부터는 매 단계별로 학습한 내용에 대해 면접을 진행해보는 방식으로 스터디를 진행할 수도 있겠다는 생각이 들었다.

근데 스터디 안하는 스터디 유지하고싶은데... 매 단계가 끝날 때 마다 스터디 안하고있는 불특정 다수를 모아볼까도 싶다.
만약 한다면 페어와 학습로그 말하기의 심화버전이 될 것 같다.