소프트웨어 엔지니어 코딩 인터뷰 준비하기 (미국)

졸업을 앞두고 미국에 왔을 때 한국에 있을 당시 이력서를 넣고 전화 인터뷰를 본 덕분에 3개의 On Site인터뷰가 예정되어 있었다. 당시 나는 미국의 소프트웨어 엔지니어링 포지션이 어떤 인터뷰를 보는지 제대로 알지 못했고, 단순히 '코딩 할 줄 암'을 잘 어필하면 채용 될 줄 알았다. 그래서 당연히 Cracking the Coding Interview를 간간히 보고 슈도코드를 종이에 몇번 작성 해 보는 것으로 인터뷰 준비가 끝났다고 생각했다. 당시에는 어떤 이유에선지 3곳 모두 채용 확정이 되었지만, 이후에 다른 회사의 면접을 보며 슈도코드를 종이에 적당히 작성 해 보는 것이 결코 코딩 인터뷰 준비의 끝이 아님을 알게 되었다. 그래서 이번 포스트에서 미국 소프트웨어 엔지니어 포지션의 인터뷰가 어떻게 진행되는지 알아보고 그 중에서도 코딩 인터뷰를 준비하는 방법에 대한 이야기를 나눠보려고 한다.

들어가기전에

이 포스트는 내 회사의 의견 또는 채용 기준을 반영하지 않는다.

나는 인사 담당자가 아니며 여기에 적힌 정보는 경험을 기반으로 한다. 

이 포스트의 내용은 미국의 모든 소프트웨어 엔지니어 포지션의 인터뷰 방식을 대변하지 않는다. 회사마다 다른 평가 방식이 존재 할 수 있다.

여기에 나오는 사이트 및 상품들은 나와 이해관계가 없으며 그냥 내가 사용 했던 것들을 소개하는 것 뿐이다.

목표

• 소프트웨어 엔지니어 포지션의 인터뷰 구성

• 코딩 인터뷰의 종류
• 코딩 시험 (Coding Exam)
• 전화 코딩 인터뷰 (Phone Interview)
• 온사이트 코딩 인터뷰 (On-site Interview, aka Whiteboarding)

• 코딩 인터뷰 준비 방법
• 소프트웨어 엔지니어 역량
• 코딩 인터뷰 연습하기
• 또 다른 예 - 시스템 디자인

소프트웨어 엔지니어 포지션의 인터뷰 구성

 소프트웨어 엔지니어 포지션의 경우 가장 처음 리크루터와의 전화로 인터뷰가 시작된다. 우리가 어떤 회사에 이력서를 넣었고, 그 내용이 회사가 원하는 인력과 맞아서 리크루터가 전화하는 경우 또는 링크드인과 같은 구인구직 플랫폼으로 리크루터들이 직접 연락 해 오는 경우가 있다. 경로가 어떻든 인터뷰의 시작은 대게 리크루터와의 전화 통화에서 시작한다. 리크루터는 전화 통화를 통해 우리가 현재 회사 또는 학교에서 어떤 프로젝트를 했는지, 어떤 기술을 알고있는지 파악하고 그 정보를 토대로 회사에서 가장 잘 맞는 포지션에 맞춰주려 한다. 리크루터는 우리가 채용되도록 도와주는 사람이다. 

 리크루터와 전화를 마치면 몇 주 내로 전화 면접 일정에 대한 이메일이 온다. 이것은 해당 회사에 적절한 포지션이 있는 경우이고, 적절한 포지션이 없다면 이 단계에서 거절 될 수도 있다. 이 단계에서 엔지니어 또는 매니저와의 전화 면접 일정이 잡히거나 어떤 회사는 전화 면접 없이 바로 온사이트(On-Site)면접을 진행하기도 한다. 이후 전화 면접으로 넘어가면 HR 매니저 또는 팀원(엔지니어)과 전화로 인터뷰를 진행한다. 여기서부터가 우리의 기술적 역량이 평가되는 시작점이다. 자세한 내용은 아래에서 다루도록 하겠다. 

 전화 면접이 잘 성사되면 온사이트(On-Site) 인터뷰로 넘어간다. 온사이트 인터뷰는 보통 HR 매니저 + 팀 내의 엔지니어로 구성되지만 어떤 회사의 경우는 우리가 일 할 팀이 아닌 임의의 엔지니어, 임의의 매니저와 인터뷰를 하기도 한다(대표적으로 Google). 이렇게 해서 온사이트(On-Site) 인터뷰는 보통 3시간에서 5시간 사이로 진행되고 최소 2명의 사람들과 1:1로 면접을 본다. 각 면접 시간은 보통 30분~1시간 사이이고 중간에 휴식시간 및 점심시간이 주어진다. 이 모든것은 대체적인 것이며 각 회사의 인터뷰 진행 방식에 따라 차이가 있음을 유의하라. 보통 포지션의 급이 올라 갈 수록 매니저와의 면접이 더 많아진다고 한다.

코딩 인터뷰의 종류

코딩 인터뷰는 인터뷰가 진행되는 단계와 코딩 방식에 따라 코딩 시험, 전화 코딩 인터뷰, 온사이트 코딩 인터뷰로 나뉜다. 보통 리쿠르터와의 면접 이후 코딩 시험 또는 전화 인터뷰를 보고 온사이트 인터뷰로 넘어간다. 전화 인터뷰의 경우 코딩 인터뷰가 아닐 수도 있다. 회사에 따라 코딩 시험 + 전화 인터뷰를 모두 하는 회사도 있다. 온사이트 보통 인터뷰는 인성 + 코딩/시스템 디자인 인터뷰로 진행된다.

코딩 시험 (Coding Exam)

어떤 회사들은 전화 인터뷰 대신 코딩 시험으로 이를 대체하기도 한다. 내가 대학 졸업 후 들어갔던 첫번째 직장이 이런 방식이었고, 나는 CoderByte라는 곳에서 40분의 시간제한을 두고 코딩 시험을 치렀다. 코딩 시험이라고 해서 어디에 가서 제한된 환경에서 보는 것이 아니고, 집에서 노트북 또는 컴퓨터를 이용해 보는 것이다. 그럼 문제를 검색해서 복붙하면 솔루션을 복붙하면 되지 않을까? 보통 코딩 시험을 보면 딱 결과물만 전송되는 것이 아니라 40분동안 우리가 적는 코드의 내용이 녹화된다. 따라서 면접자는 코드 정확성 뿐만 아니라 그 과정까지 전부 볼 수 있다. 

전화 코딩 인터뷰 (Phone Interview)

전화 코딩 인터뷰의 경우 면접관이 여러분이 코딩을 할 수 있는 공유 문서(Shared Document)을 제공한다. 공유 문서는 보통 웹 상에 존재하며(대표적으로 Google Doc) 면접관과 면접자가 동시에 수정 할 수 있다. 면접관이 전화 통화가 시작되면 짧게 자기 소개를 하고, 코딩 문제로 넘어간다. 면접관이 코딩 문제를 말하면 면접자가 공유 문서에 코드를 적으며 된다. 보통 30분~1시간 30분 이내로 진행된다. 

온사이트 코딩 인터뷰 (On-site Interview, aka Whiteboarding)

코딩 시험 또는 전화 인터뷰를 성공적으로 마쳤다면 2-3주 이내에 리크루터로부터 온사이트 면접에 대한 이메일이 온다. 온사이트 면접은 경험상 최소 2시간~5시간사이로 진행된다. 대부분의 면접이 1:1 면접이며, 어떤 경우는 1: m면접으로 진행되는 경우도 있다. 이 m은 여러명의 면접관이 들어오는 경우이며 한국의 공채처럼 여러명의 면접자가 들어가는 면접은 거의 없다. 면접자는 보통 자기가 가장 잘 아는 프로그래밍 언어를 이용해 화이트보드에 손코딩을 한다. 회사에 따라 특정 언어를 사용해야 할 수도 있다. 예를들어 임베디드 시스템 쪽이면 C또는 C++로 프로그래밍, 웹 서비스 개발이면 Java로 프로그래밍 해 달라고 요구 할 수 있다.

코딩 인터뷰 준비 방법

어떤 회사는 코딩 인터뷰에서 딱 면접자의 문제 해결 역량만을 보기도 하고, 또 다른 회사는 면접자의 다양한 측면을 보기도 한다. 여러가지 코딩 인터뷰 준비 방법이 있겠지만 지금부터는 내가 사용했던 방법을 소개 해 보도록 하겠다.

소프트웨어 엔지니어링 역량

문제 해결 역량 - 자료구조/알고리즘/시스템 설계

코딩 인터뷰를 통해 피력하고자 하는 가장 첫번째 역량은 문제 해결 역량이다. 어떤 문제가 주어졌을 때 면접자인 내가 어떻게 문제를 접근하는가? 어떻게 문제를 이해하는가? 어떻게 문제를 해결하는가? 어떻게 문제가 해결되었음을 확인하는가? 해당 문제를 해결하는데 다른 방법을 제시하는가? 각 방법의 장점과 단점을 알고 있는가? 등을 통해 면접관에게 나의 문제 해결 역량을 보여준다. 이 때 문제는 보통 자료구조/알고리즘 문제 또는 시스템 디자인 문제이다. 자료구조/알고리즘 문제의 경우 내가 적절한 자료구조와 알고리즘을 활용해 문제를 해결 할 수 있는지, 성능을 예측 할 수 있는지(Big-O notation), 개선 할 수 있는지, 내 구현의 장단점을 알고 있는지 등을 보여준다. 또 코딩을 할때 변수나 함수 이름을 어떻게 쓰는지, 모듈화 된 코딩을 하는지도 보여줘야 한다. 시스템 디자인의 경우, 시스템을 요구사항에 맞게 디자인 할 수 있는지, Scalable, Extensible, Fault Tolerant 시스템을 디자인 할 수 있는지 등을 보여줘야 한다.

이 과정에서 면접관은 대게 면접자인 내가 Idiomatic Syntax를 사용 할 것이라고 예상한다. Idiomatic Syntax란 사용하는 언어의 문법이라는 뜻이다. 즉, Idiomatix Syntax가 요구되는 경우 슈도 코드(psudo code)로 코드를 작성하는 것을 지양해야한다. 물론 세미콜론이나 꺽쇠괄호를 빼먹었다는 점이 당락을 좌우하는 경우는 거의 없을 것이다. 하지만 예를들어 자바가 가장 자신있는 언어일 경우 배열의 길이는 length, 문자열의 길이는 length()로 가져온다는 사실 정도는 알고 있고 써 먹을 수 있어야 한다는 것이다.

커뮤니케이션 역량

코딩 인터뷰에서는 문제 해결 능력을 우선으로 보는 것이 당연하지만 나는 코딩 인터뷰를 통해 인성 또는 커뮤니케이션 역량을 함께 보여주려 한다. 문제를 해결하는 도중 막히는 경우 어떻게 대처하는지, 요구사항이 두리뭉실 한 경우 적절한 질문을 통해 요구사항을 파악하는지, 면접관이 주는 힌트를 어떻게 받아들이는지등을 보여준다. 또 이런 교류(Intercation)을 통해 '나랑 일하는게 참 괜찮을 것 같다'는 인상을 주려고 노력한다. 개인적으로 커뮤니케이션 역량은 문제 해결 역량만큼이나 중요하다고 생각한다. 아무리 코딩을 잘 해도 팀에 잘 융화(team fit이라고 부른다) 될 수 없다고 판단되는 경우 해당 면접자를 탈락 시킬 수 있다는 말을 다수의 매니저에게서 종종 듣기 때문이다.

코딩 인터뷰 연습하기

첫번째로 자료구조와 알고리즘을 복습해라. 자료구조와 알고리즘은 기본이다. 자료구조와 알고리즘을 가지고 문제를 풀어야하는데 자료구조와 알고리즘을 모른고 코딩 문제를 푼다는 것은 말이 안된다. 어떤 자료구조와 알고리즘을 복습해야 하는지는 소프트웨어 엔지니어가 되는 법의 자료구조와 알고리즘 섹션을 참고하라.

 어떤 코딩 인터뷰이든 한 가지 명심해야 할 사항이 있다. 코딩 인터뷰 준비는 1-2일내에 끝낼 수 있는 것이 아니다. 인터뷰를 준비하는데 위해 적어도 2주의 시간을 소비해라. '1주일에 한번 5시간동안 코딩 인터뷰 준비' 이런식으로 한번에 몰아서 하려 하지 말고 매일매일 1-2시간씩 코딩 인터뷰를 준비 하는 것이 좋다. 

 코딩 문제를 외우려고 하지 마라. 세상의 모든 코딩 문제를 외울 수 있는 것을 불가능 할 뿐만 아니라 우리가 외운 코딩 문제가 인터뷰에 나올 확률은 매우 작다. 또한 우리가 외운 코딩 문제를 아주 빠르게 잘 풀어내면 면접과는 그 문제를 비틀어 다른 문제를 해결하도록 유도 할 수도 있다. 그러므로 우리의 목표는 실제로 '문제 해결력이 있는 사람'이어야지 문제은행에서 문제와 답을 외워 면접을 '통과'하고자 하는 사람이면 안된다는 것이다. 이건 면접 때만이 문제가 아니라 이렇게 입사하면 일 하면서 실력이 드러나 최악의 경우 해고 될 수 있다. 

 지금부터는 그래서 실제로 어떻게 인터뷰를 준비해야 하는지에 대해 설명하도록 하겠다. 여기서부터는 여러분이 어느정도 자료구조와 알고리즘을 알고 있음을 가정한다. 이제부터 실제로 On-Site 코딩 인터뷰를 대비하는 법에 대해 소개 해 보도록 하겠다. 간략하게 말해 코딩 인터뷰 준비는 다음과 같이 진행된다.

• 요구사항 이해
• 입력/출력값을 스스로 도출하기
• Brute Force로 구현하기 (생략 가능)
• 최적의 성능을 가진 코드 구현 및 설명하기
• 테스팅
• 성능 분석 (Time and Space Complexity)
• IDE에 솔루션을 옮겨 적어 코딩/컴파일 후 제대로 풀었는지 확인하기

화이트보드 준비하기

화이트보드를 사는 이유는 인터뷰 준비 환경을 실제 인터뷰 환경과 준비 환경을 최대한 비슷하게 하기 위해서이다. 화이트보드에 적는게 익숙하지 않는 경우 화이트보드에 적는것 마저 시간이 들 수 있다. 제약된 공간에 뭘 적어야되는지 얼마나 적어야 되는지 화이트보드가 있으면 이를 시뮬레이션하기 쉽다. 나같은 경우 스티커 형식의 화이트보드를 샀다. (쿠팡 스티커 화이트보드 또는 아마존에서 산 화이트보드) 화이트보드가 여의치 않다면 큰 종이라도 사서 벽에 붙여라. 그것마저도 여의치 않다면 A4용지를 준비하라. 코딩 시험이나 전화 코딩 인터뷰를 준비하는게 아니라면 컴퓨터를 사용하지 마라. 전화 코딩 인터뷰를 준비하는 경우 웹으로 인터뷰 환경을 최대한 비슷하게 만들어 주는 사이트들이 있다. (예: CodeInterview) 이런 사이트의 도움을 받는 것도 나쁘지 않다고 생각한다.

코딩 문제를 확보하기

LeetCode또는 HackerRank와 같은 사이트나 Cracking the Coding Interview와 같은 책을 통해 코딩 문제를 확보한다. 이 때 일정량의 Easy를 풀고 Easy를 10-15분 내로 풀 수 있는 경우 Medium -> Hard로 넘어 갈 것이다. 처음부터 어려운걸 하려 하지 말고 쉬운 것 부터 차근차근 하자. 

요구사항 이해하기

이제 Easy에서 본인이 30분 내로 풀 수 있을 만한 문제를 골라보자. 그 문제를 화이트보드에 옮겨적어라. 그리고 문제의 의미를 파악하라. 문제의 의미를 파악하기 위해 왼편에 입력값과 출력값을 적어보자. 

입력/출력값 스스로 도출하기

[나의 실제 연습 과정]

가장 간단한 입력값을 적고 무슨 출력이 나와야 정답인지 스스로 도출 해 보라. 가장 간단한 입력값을 적었으면 조금 복잡한 입력값을 적고 무슨 출력이 나와야 정답인지 스스로 도출 해 보라. 가장 간단한 입력/출력의 경우 어떻게 코딩해야 할 지 생각 해 보라. 그리고 이 도출 과정을 말로 설명하라. 다시 한번 강조하겠다. 본인이 입력과 출력을 도출한 과정을 면접관에게 말하듯 말로 설명하라. 이것이 바로 화이트보드를 사서 연습을 하는 이유이다.

Brute Force 방법으로 구현하기

입력과 출력의 관계를 확인했으나 좋은 성능의 솔루션이 떠오르지 않는다면 Brute Force 방법을 먼저 적어라. Brute Force 솔루션이란 성능이 가장 안좋은, 대부분 다중 루프나 재귀함수로 작성된 솔루션이다. 이런 솔루션을 적는게 의미가 있을까? 의미가 없으면 어떻게 할 것인가..? 가만히 있을것인가? 일단 뭐라도 적고 말을 하는게 좋다. 어차피 가만히 있어봤자 아무것도 떠오르지 않으니 가장 성능이 안좋은 것에서 시작해 개선 할 점을 찾아나가는 것이 한 방법이 될 수 있다. 그리고 가장 안좋은 성능이라도 일단 코딩을 하면 면접관이 평가할 거리가 생긴다. 5분-10분 내로 빠르게 Brute Force 솔루션을 작성하라. 작성하면서 어떤 자료구조와 알고리즘을 이용해 성능을 어떻게 개선 할 것인지 계속해서 생각하라. 그리고, 현재 코딩을 하는 과정을 면접관에게 말 하듯 말로 설명하라. 등을 돌리고 코딩만 막 하지 말라는 것이다. 한 줄 쓰면 왜 그 줄을 썼는지, 의도가 뭔지, 한 줄 쓸 때마다 다시 돌아서 면접관이 있다고 상상하고 이를 설명하라. 막히면 이 부분이 어떻게 해야 할 지 아직 잘 모르겠다 라고 말하라. 이런 경우 어떤(경험상 많은) 면접관들은 여러분이 계속 진행 할 수 있도록 힌트를 주기도 한다. 또 어떤 경우는 일부러 질문을 유도하기위해 요구사항을 애매하게 하는 경우가 있다. 요구사항이 잘 이해되지 않는 경우 반드시 질문해야한다. 요구사항을 이해하지 못하면 코딩을 시작조자 할 수 없기 때문이다.

주의! 코딩은 본인이 선택한 프로그래밍 언어의 문법에 맞게 작성하라.

최적의 성능을 가진 코드 구현 및 설명하기

 Brute Force솔루션을 풀며 개선된 솔루션을 생각 해 냈다면 이제 실제 솔루션을 넘어가도록 한다. 또 때로는 바로 최적의 솔루션이 생각 날 때가 있다(이런경우 Brute Force는 말로만 설명해도 된다). 이 때 바로 넘어가지 말고 무엇을 코딩 할 것인지 1, 2, 3과 같은 Bullet Point를 이용해 간략하게 과정을 적어 면접관에게 설명한다. 이는 도중에 면접 시간이 지나버릴 경우 처음에 뭘 하려고 했는지 이미 설명 할 기회가 없을 수 있기 때문이기도 하고 대략적인 과정을 설명하면 나중에 코드를 설명할 때 더 쉽기 때문이다. 예를들어서 '이 부분의 코드는 1번을 구현한 코드이다.' 이런식으로 설명 할 수 있다. 이 모든 과정에서 여러분은 쉼없이 말하고 있어야 한다. 계속해서 여러분의 생각 과정을 설명하고 있어야 한다. 과정은 3-5줄/1분이내 정도로 아주 간략하게 적어라. 과정을 적다가 면접이 끝나버리면 안되니 말이다.

테스팅

코드를 다 작성하고 난 후에는 반드시 임의의 입력값과 출력값을 이용해 본인의 코드를 검토하라. 이 과정에서 면접관에게 '만약 입력값으로 x, y, z를 넣으면 함수 a에서 ~한 과정을 거쳐 ~값이 도출되고 이 값을 이용해 함수 b는 ~를 하면 결국엔 답인 k가 나온다.'이렇게 설명하듯 실제로 말로 한다. 이때 몸을 화이트보드와 정면으로 마주하지 않고 약간 비스듬히 해 면접관을 바라보면 더 좋다. (인형같은 것을 앉혀놓고 하면 좀 낫다.) 

성능 분석 (Time and Space Complexity)

테스팅을 통해 본인의 코드가 의도한 대로 작동한다는 것을 확인했으면 시간복잡도(Time Complexity)와 공간 복잡도(Space Complexity)를 분석하라. 어떤 부분에서 시간이 오래걸리는지, 어떤 부분에서 메모리를 많이 소모하는지 말로 설명하라. 만약 버그가 있다면 고쳐라. 버그가 있다면 보통 면접관이 말해주기도 한다. 버그는 있을 수 있는 일이니 사소한 버그가 하나 있다고 해서 주눅들지 말자.

IDE에 솔루션을 옮겨 적어 코딩/컴파일 후 제대로 풀었는지 확인하기

위의 모든 과정일 끝났으면 화이트보드에 작성한 코드르 그대로 LeetCode/HackerRank/등등 여러분이 문제를 가져왔던 사이트로 돌아가 그대로 옮겨적는다. 옮겨 적은후, 

1) 문법이 맞는지, 

2) 실행 결과가 맞는지, 

3) 성능이 적절한지 판단한다.

 위 3개 중에서 틀린 곳이 있다면 그 부분을 개선하고 공부한다.

또 다른 예 - 시스템 디자인

 디자인 문제도 마찬가지이다.

 디자인 문제의 경우 나는 요구사항을 확실하게 하기 위해 질문을 한다. 시스템 디자인의 경우 큰 시스템 예를들어 위처럼 인스타그램을 디자인하라와 같은 문제의 경우 인스타그램에 기능이 너무 많기 때문에 어떤 기능을 구체적으로 디자인 할 것인지 정확히 알고 시작해야 하기 때문이다. 예를들어 위에서는 feed와 follow기능만 구현하도록 한다고 정했다. 어떤 기능을 구할 지 알았다면 소수가 사용하는 시스템을 위해 먼저 설계를 한다. 예를들어 위에서는 왼편 아래에 3명을 위한 인스타그램을 설계한다고 써 놨다. 3명을 위한 인스타그램이라면 데이터베이스 하나에 Tiny Instagram이라는 서버한개를 놓고 유저의 핸드폰에서 Polling하는 방식으로 구현하도록 디자인 했다. 유저가 3명밖에 없으므로 폴링이 서버에 부하를 일으키지 않을 거라 가정한다. 또 Relational 데이터베이스에 User, Feed, Follower, Following과 같은 테이블을 만들고 그 관계가 어떻게 되는지 정의했다. 이렇게 하고나서 다시 가정을 해본다. 이제 수천, 수만명의 유저가 생긴다면 어디에서 문제가 발생 할 것인가? 첫번째로 polling하는 방식에서, 또 데이터베이스의 사이즈, 탐색 등에서 문제가 발생 할 것이다. 코드의 사이즈가 커지면 유지보수도 힘들어질 것이다. 팀원들의 수도 늘어날 것이고 여러명이 하나의 Monolithic 코드를 유지하는데 많은 시간과 노력이 소요 될 것이다. 따라서 Scalable디자인에선 이러한 점들을 고려해 microservices, in-memory database, caching, pub-sub등등을 활용하여 이런 문제를 고치는 디자인을 한다. 내가 이 방법을 좋아하는 이유는 작은 문제 해결을 위한 디자인에서 부하가 늘면 어디서 고장이 날지 잘 보이고, 이를 해결하기 위해 어떤 기술/디자인을 사용할지 설명하는게 면접관을 설득하기 편해서이다. 시스템 디자인 면접의 경우 정답이 없고 완벽한 디자인이 없기 때문에 본인이 고려하는 디자인과, 이 방법 말고 다른 어떤 디자인 방법이 존재하는지, 장단점이 뭔지에 대해 설명 하는 것이 좋다. 지금 위에서 이 포스트의 독자를 위해 설명 한 것 처럼 면접 당시에 면접관에게 설명하도록 해야 한다. 

디자인 문제의 경우 정답이 없지만 다른사람의 디자인을 보는것이 공부가 되기 때문에 인터넷에 xxx system design하고 검색해서 다른사람의 디자인을 보고 배우도록 하자. 

끝

 다시 말하지만 인터뷰 과정은 회사마다 다르기 때문에 내가 이 포스트에서 설명한 모든것이 정답이고 진리는 아니다. 첫번째 회사는 온사이트 인터뷰 때 내가 프로젝트 했던 것들에 대해 구체적으로 어떻게 구현했는지, 어떤 문제가 있었는지에 대해 주로 물어봤다. 네트워크 모듈을 만드는 회사의 면접을 봤을 때는 리눅스 커널의 yield point에 대해 질문 받았다. 다른 회사에서는 실제 코드를 분석하고 해당 코드에 기능을 더하는 면접을 봤다. 또 다른 면접에서는 주차장 시스템을 디자인하는 면접을 봤다. 대기업과의 면접에서는 보통 위처럼 자료구조/알고리즘/시스템디자인 위주의 면접을 봤다. 어디서 들은 바로는 실제로 프로젝트를 주고 며칠내로 구현해와라 하는 면접을 보기도 한다고 한다. 이전 회사에서 어떤 면접관은 '노트북을 주고 이런 문제가 발생했으니 디버깅 해 보시오' 하는 문제를 내기도 했다. 따라서 회사가 개발하는 분야나 원하는 인재에 따라 인터뷰 방식이 다를 수 있음을 유의하도록 하자. 화이트보드 코딩 인터뷰 방식은 현재 널리 사용되는 방식이지만 나와 같은 면접자들이 매우 힘들어 하는 방식이기도 하다.

 나의 경우 2주간 주중에는 1-2시간 씩, 주말에는 최대 5시간까지 화이트보드를 이용해 인터뷰 준비를 했다. 나머지 시간에는 자료구조, 알고리즘, 운영체제, 네트워크등 기본적인 컴퓨터 공학 이론을 복습하고 아래의 책과 사이트를 읽었다. 처음 읽는 책도 있었고 이미 몇번 읽어봐서 빨리 넘어가는 책도 있었다. 갓 대학을 졸업한 엔지니어에게는 보통 시스템 디자인 문제를 묻지 않으므로 자료구조/알고리즘, 기본 컴퓨터 공학 이론, 본인이 했던 프로젝트 위주로 준비하는 것이 도움이 될 것 같다.

 끝으로 내가 인터뷰를 준비하던 당시 도움 받았던 책과 사이트에 대해 소개하고 마치도록 하겠다. 

• LeetCode (대부분 무료이고 자료구조 알고리즘 뿐만 아니라 운영체제, 시스템 디자인 문제들도 있어서 좋다. 또 대기업의 경우 필터가 있어 해당 기업에서 자주 나오는 질문 위주로 공부 할 수 있다(유료).)
• Cracking the Coding Interview (자료구조/알고리즘 복습)
• Interview Cake
• The Algorithm Design Manual - (코세라에 강의도 있다)
• Design Pattern
• Reactive Microservices Architecture
• Designing Distributed System
• Free O'Reilly Books