코딩 인터뷰, System Design 인터뷰에서 면접관이 원하는 것

Blind에서 익명의 Amazon 재직자 분이 올리신 글인데, 이대로 재야에 파묻히긴 너무 아쉬운 양질의 글이라 내 블로그에 아카이빙 해 둔다.

문제 시 삭제하겠습니다.

코딩 인터뷰에서 - 인터뷰어가 원하는 것

1. Speak, speak, and speak.

• 면접관은 면접자가 혼자서 문제 푸는 것을 원하는 게 아니다. 왜 이 자료구조를 선택했는지, 왜 이 알고리즘으로 해결하려고 하는지 등 이유를 설명해야 한다. 지금 무엇을 하려고 하는지 쉬지 않고 설명해야 한다.
• 그 이유는 첫째 개발자는 보통 혼자 일하지 않는다. 동료와의 협업, 커뮤니케이션이 매우 중요하기 때문에 지금 무엇을 하려는지를 정확하게 전달하고 있는가는 매우 중요한 요소이다.
• 두번째는 면접자가 그냥 문제를 미리 외워서 푸는 것인지를 대화를 통해 알 수 있기 때문이다.

2. It’s a method, not code.

• 면접관이 점수를 매기는 것은 문제를 해결해가는 과정이다. 실제로 동작하는 코드를 원하는 것이 아니다. 그리고 완벽한 정답을 원하는 것도 아니다.

3. Boost brain power

• 문제를 해결하는 가장 효율적인 방법이 무엇인가를 생각해라. 이때가 가장 brain power가 필요한 시점이다.
• 예시) SNS의 친구 관계를 처리하는데 용이한 자료 구조는 Graph. 디렉토리 구조 처리에 용이한 자료 구조는 Stack. 정렬된 리스트의 빠른 탐색 알고리즘은 이진 탐색. 이렇게 문제를 풀 수 있는 가장 적합한 솔루션을 최대한 "생각" 하며 떠올려야 한다.

4. Practice, practice, and practice.

• 연습만이 답이다. 위의 문제를 풀면서 말하는 습관이나 brain power 부스팅 등은 처음에는 잘 되지 않는다. 누구나 처음에는 어렵다. 그러나 연습하면 반드시 는다.

코딩 인터뷰 - 어떻게 준비하나?

1. Fundamentals

• 컴공 전공자이거나 자료구조, 알고리즘 등을 한번 제대로 공부를 해본 사람이라면 기초는 이미 있다. 아래의 기초를 다시 공부하면서 정리한다. (1~2개월 소요)
  • Data structure : Stack, Queue, Linked List, Graph, Priority queue, Hash table, Trie
  • Algorithm : DFS, BFS, DisjointSet, MST, Quick sort, MRU, LRU, Binary search, Recursion, Sliding window
  • Paradigm : Greedy, Divide & Conquer, Backtracking, Dynamic Programming
  • ETC : brute force, In-place memory, big O-notation

2. Exercise

• 위 기초가 어느 정도 정리되면 다양한 패턴의 문제를 최소 200개 이상 풀어야 한다. 동일한 알고리즘으로 풀 수 있는 문제 200 문제를 말하는 것이 아니다.
• 문제는 leetcode, hackerrank 에서 풀 수 있다
• 문제 해결 과정을 템플릿화 해두면 습관화 할 수 있다. [문제 이해] -> [예시 확보] -> [해결방안 탐색] -> [코딩] -> [최적화] -> [테스트]
• 문제의 정답을 읽기 전에 반드시 본인의 해법으로 먼저 풀어야 한다. 실력 향상에 가장 중요한 부분이다.

시스템 디자인 인터뷰에서 - 인터뷰어가 원하는 것

1. Speak, speak, and speak

• 면접관은 system 디자인에 필요한 개념을 잘 이해하고 있는지를 본다. 왜 SQL이 아닌 NoSQL을 선택했는지, 무엇을 위해서 cache를 사용하는지 등을 쉬지 않고 설명해야 한다.

2. Keep it simple, stupid. (KISS)

• 인터뷰는 면접자는 어쨌든 1시간 동안 면접관과 대화하는 자리이다. 중요한 부분이 아닌데 장황하게 설명하여 인터뷰가 너무 산으로 가면 지루하다고 느껴진다. 큰 그림을 설명하고 작은 부분으로 좁혀 나가야 한다. 좁혀 나갈 때도 모든 것을 다 설명하는 게 아니라 가장 중요한 기능 logic에 대해서 자세하게 설명한다.
• English
  • 코딩 테스트보다 영어가 좀 더 중요하다. 사실 코딩 테스트는 어떤 특정 알고리즘을 사용하면 문제가 풀리는 경우가 많다. 그런데 시스템 디자인은 다양한 방식으로 아키텍쳐 구성이 가능하기 때문에 다양한 질문을 받을 가능성이 높다. 예를 들어 LB 알고리즘으로 least connection을 선택하였다면 왜 round robin이 아닌 least connection을 선택했는지 답변을 해야 한다. 그 때마다 테크 영어로 답변을 해야 하는데 테크 답변은 익숙하지 않은 경우가 많다.
  • 영어에 익숙해 지려면 영어 테크 유튜브와 친숙해져야 한다. 나는 운전을 하거나 집안일을 할 때 freeCodeCamp, sudoCODE, Clement 채널을 background 로 틀어 놓고 테크 영어 단어나 표현에 친숙해지려고 노력했다.

시스템 디자인 인터뷰 - 어떻게 준비하나?

1. Fundamentals

• system design의 기본 개념들을 이해하고 있어야 한다. 잘 알고 있는 거라면 정리하는 계기로 삼고, 잘 모르는 거라면 제대로 짚고 넘어가자.
• https://github.com/donnemartin/system-design-primer
• Latency, Throughput, Availability, Consistency, LB, Cache, CDN, Proxy, Database, Replica, Security

2. Exercise

• 위 기초가 어느 정도 정리되면 Youtube나 Blog를 참고하여 공부한다. 구글, 페이스북 출신의 Clement의 채널을 많이 봤고 educative 구독하면서 샘플 디자인을 공부하면 좋다.
• 문제 해결 과정을 템플릿화 해서 연습해야 한다.
  1. Requirements clarification
  2. Scale estimation
  3. System interface definition (APIs)
  4. Defining data model (w/ database)
  5. High-level design
  6. Detailed design
  7. Identifying and resolving bottlenecks

내 생각은...

• 경험상 (1)이 매우 중요하다. 말 하지 않고 혼자 문제를 풀어 결과 알고리즘만 설명해 주면, 면접관이 기다리는 동안 "어색한 정적"만 흐르기도 하고, 결과를 한번에 면접관이 이해하기도 힘들고, 혹여 요구사항을 제대로 파악하지 못해 잘못 풀었을 경우 치명적인 감점 요인이 된다. 면접에서의 소통 능력은 평가에 굉장히 큰 영향을 끼친다.
• 아키텍처쪽은 최신 기술과 이의 적절한 활용, 그리고 큰 그림을 그릴 수 있는 능력도 중요하지만, 그것을 서술할 수 있는 기본 용어들에 대해 익숙해지는 것 또한 크게 중요하다는 점에 큰 공감을 했다. 영어 테크 유튜브 귀찮아서 안 봤는데... 이젠 열심히 봐야 할까... 😂
  • 그래도 평상시에 테크 블로그들 보면서 꾸준히 내용 소화해가며 정리해보고 있는데, 이것도 큰 도움이 됐던 것 같다. Amazon 테크 블로그는 물론이고, 국내에서도 카카오/네이버 테크 블로그에 너무나 좋은 내용들이 많다.
• 문제 해결 과정을 7단계로 템플릿화 해놓은 것 너무 멋지다. 마치 시스템 아키텍처에서의 육하원칙 같은 느낌이다. 앞으로 아키텍처 분석 포스팅을 하게 된다면 저 부분에 대해서 심도깊게 생각을 하면서 쓰도록 노력해야겠다.