코딩 인터뷰 – part 5

온사이트의 마지막 세션을 마칠때쯤엔 대략 오퍼의 여부를 스스로 예상할수 있다. 파트 2에서 설명했던것처럼 한개 정도 부족한 세션이 있었다해도 나머지 문제들을 풀었다면 오퍼가 희망적이다. 회사들은 보통 인터뷰 다음날 인터뷰어들이 모여 debriefing 시간을 갖는다. 여기에서 리뷰들이 오퍼쪽으로 결정되면 리쿠르터는 지체없이 연락을 해온다. 인터뷰 후 결과가 나오기까지는 마치 예전에 대입시험 결과를 기다리는 그런 초조함이 있다. 내 경험상 오퍼가 나올때에는 인터뷰후 빠르면 24시간, 늦어도 3일안에 오퍼 소식을 들을수 있었다. 혹시 연락이 오지 않고 시간만 흘러갈때는 점점 오퍼의 가능성이 낮아진다. 이 경우 며칠후에 공손하게 확인하면 결과를 가르쳐준다. 리젝시에 한가지 꼭 시도하면 좋은것은 인터뷰의 피드백을 달라는 요청이다. 일반적으로 회사는 정책상의 이유로 인터뷰의 피드백을 공유하지 않는다. 그러나 종종 피드백을 짧게라도 이야기해주는 곳이있다. 이 피드백에는 내 예상과 다른 평가들이 있을수 있기때문에 다음 인터뷰를 준비하는데 아주 유용하다. 내 경우 첫 인터뷰에 안되고나서 코딩때문이라 생각했는데, 의외로 시스템디자인에서 부족했다는 피드백을 받았다. 결과가 안좋을때는 배울것을 한가지라도 건지고 툭툭 털어내는게 좋다.

오퍼가 나오면 이제 시작되는 것은 연봉과 Title, Benefit (보험, 휴가)등에 관련된 협상(negotiation)이다. 미국에서 비지니스 관계의 모든 딜은 철저하게 협상을 통해 이루어진다. 예전에 차를 한대사러 딜러샵에 간적있다. 전날밤 미리 여러개의 웹사이트에서 해당 차량의 가격 정보를 풍부하게 수집하고 딜러와 데스크를 사이에 두고 앉았다. <갑>의 위치에 있다고 생각한 나는 편안하게 내가 생각한 적정 가격을 제시했다. 딜러는 웃음기 없는 얼굴로 이렇게 되물었다.

“왜 그 가격이 타당한지 나를 설득시켜봐”

잡마켓에서 오퍼 이후의 협상도 마찬가지다. 목표하는 연봉이 있을경우 그 액수를 뒷받침할수 있는 논리적 이유가 있어야 한다. 그중 가장 효과적인것은 역시 다른 회사에서 제시하는 경쟁 오퍼다. 한개의 오퍼만 가지고 테이블에 올라오면 설득시킬 무기가 없다. 리쿠르터와의 대화는 그래서 이렇게 요약된다.

“잘 해 줄께. 근데 얼마까지 알아봤어?”

리쿠르터는 타 회사의 오퍼가 있을경우 이를 상세하게 적어가고 곧 이보다 조금 많은 금액으로 오퍼한다. 이쯤되면 보통 지원자 입장에서는 연봉과 상관없이 가고싶은 회사가 한곳 이미 정해져있다. 그래서 다른 곳의 오퍼는 원하는 회사의 오퍼를 올리기 위한 수단으로 사용해야한다. 그런데 리쿠르터 역시 매일 이런 딜을 하는사람들이기 때문에 본인이 top에 있는지 아니면 오퍼를 올리기 위한 마중물인지를 파악하려고 노력한다. 그래서 지원자는 끝까지 포커페이스를 유지하며 왜 그 회사가 top choice인지 이유를 댈수있어야한다. 지원자에게 최고의 전략은 second choice에서 오퍼를 맥시멈으로 끌어올리고, top에서 이를 이기게끔 만드는것이다.

소프트웨어 회사의 오퍼는 보통 이렇게 구성되어 있다.

  • 베이스 연봉
  • 보너스
  • 주식 (RSU)
  • 사이닝 보너스

주식과 보너스 역시 시간이 얼마 지나면 현금화 할수있기때문에 이를 모두 합산한 Total Compensation을 기준으로 협상하는것이 좋다. 사이닝 보너스는 일회성 금액이라 융통성이 있기때문에 회사들은 경쟁 오퍼를 죽이기위해 활용할수 있다. 그래서 오퍼가 여러개 있을때 사이닝을 최대한 잘 받는것도 좋은 전략이된다.

최근엔 보통 Glassdoor의 정보를 활용해 오퍼가 괜찮은지 여부를 평가한다. 그런데 내 경험에 Glassdoor의 연봉 정보는 시장 가격보다 좀 많이 낮은편이다. 아마도 오래된 정보가 쌓여있어서 그런게 아닌가 생각된다. 시장의 가격보다 대략 30%정도 디스카운트 되어있다고 생각하는게 좋다. 이보다 좀 더 정확한 정보는 paysa.com에서 얻을수 있다. 예를들어 시애틀 마이크로소프트의 시니어 엔지니어 경우 glassdoor에선 175K이 평균인 반면, paysa에서는 221K가 시장 가격으로 올라와있다. 경쟁 오퍼가 있다면 이보다 조금 더 올리는것도 어렵지 않으니, “얼마까지 알아봤어?”의 시장 원리를 최대한 활용하는것이 좋다.

이렇게해서 이번 인터뷰 시리즈를 마무리한다. 결과적으로 나 자신도 뜻밖의 결과인 Niantic Lab.으로 다음 회사를 결정했다 (나이엔틱은 포켓몬고를 만드는 증강현실 게임회사). 다른 몇개의 대기업에서 받은 오퍼가 괜찮고 한두개 회사는 일의 종류, 환경, 팀도 너무 마음에 들어 포기해야 하는게 아까웠다. 나이엔틱의 인터뷰 경험은 다른 대기업들과는 많이 달랐다. 높고 화려한 대기업 오피스들 사이에 낮고 오래된 건물이 있고, 어두컴컴한 복도 한켠에 회사간판도 없는 오피스… 문을 열고 들어가니 주성치 영화에 조연처럼 생긴, 머리카락 몇올없는 중국 아저씨가 웃으며 나를 맞았다. 아주 작은 사무실에 다닥다닥 붙어앉아 일하는 사람들. 오피스가 그래서인지 다소 창백해 보였지만 다들 눈은 초롱초롱 빛났다. 작년의 포켓몬고 열풍에 서버를 어떻게 감당했는지 물었더니 중국아저씨는 <그땐 3-4시간씩 자면서 다 막아냈지 껄껄껄>… 이 바닥 초 절정 고수의 아우라를 풍겼다. 인터뷰를 마치고 나오며 팬시한 대기업에서 못느낀, <여기에서 일하고싶다> 라는 열망이 생겼으니, 나도 어지간히 스타트업을 좋아하는가보다.

https://twitter.com/sm_park

코딩 인터뷰 – part 4

예전에 구글에서 일하시는 한분이 본인은 시스템 디자인 인터뷰가 가장 어렵다고 이야기한적 있다. 코딩인터뷰의 경우 문제 set이 존재하기때문에 문제를 많이 풀어보면 되지만, 시스템 디자인은 질문을 예측하는것도 어렵고 정답이란것도 존재하지 않기때문이다. 구글에서 시스템 디자인 문제를 검색해봐도 결과에 정답은 나오지 않는다. 시스템 디자인은 대부분 스케일 문제를 다룬다. “수억명의 사람들이 너의 서비스를 사용한다면 너는 어떻게 이 문제를 해결할래?” 이런 질문에 경험에서 우러나오는 사골같은 답을 할수 있다면 얼마나 좋을까마는 사실 그런 시스템을 다 만들어본 엔지니어는 극히 소수일 것이다. 나 역시 시스템 분야로 PhD도 했고 수년간 같은 분야에서 다양한걸 만들었지만 여전히 이 질문은 어렵다. 그러나 디자인 인터뷰 역시 살아남는 방법은 있다. 그 방법이란 좀 싱겁지만…,

“공부를 많이하면 된다.”

우선 내가 그동안 받았던 디자인 질문들을 나열해보면 이렇다.

  • Queue 시스템을 디자인해라
  • Twitter를 디자인해봐라
  • TinyURL 디자인해봐라
  • Yahoo의 Stock Quote 시스템을 디자인해라
  • Elevator 시스템을 구현해봐라
  • Hadoop의 namenode를 새로 디자인해봐라
  • (AI 관련팀) 우리 시스템을 네가 디자인해봐라

4-5명과의 인터뷰중 시스템 디자인은 최소 한차례, 많게는 두세번 질문을 받게된다. 시스템 디자인에서 인터뷰어가 파악하고자 하는것은 크게 세가지로 볼수 있다:

  1. 커뮤니케이션을 잘 하는가?
  2. 문제를 정확히 알고있는가?
  3. 괜찮은 디자인을 할수있는가?

디자인 질문은 의도적으로 모호하게 주어진다. 예를들어 Queue 시스템을 디자인하라는 질문은 사실 밑도끝도 없다. <어떤 Application이 Queue를 사용하는가?>, <Queue에는 무엇이 들어가는가?>, <Producer/Consumer의 숫자는 몇개인가?> 등 디자인에 꼭 필요한 디테일이 빠져있다. 그래서 디자인 질문을 받았을때 처음 해야하는것은 <질문>이다. 여러번 충분한 질문을 통해서 인터뷰어가 생각하는 진짜 문제를 파악해내고 여기에서 Requirement를 알아내는것이 첫 단계에서 반드시 해야할 일이다. 이 과정에서 인터뷰어는 지원자의 커뮤니케이션 능력을 평가한다. 혹시 예전에 비슷한 시스템을 구현해본적이 있다고 질문을 생략한다면 이는 인터뷰가 망하는 길로 가는 지름길이다.

내가 받았던 디자인 질문중 특히 좋았던 것 한가지는 엘리베이터 시스템을 디자인하라는 것이었다. 무한하게 많은 수의 엘리베이터가 늘어서있다고 가정하고 사용자가 각 층에서 누르는 Up/Down 버튼에 맞추어 어떻게하면 최적의 서비스를 제공할수 있을까라는 질문이었다. 이 질문이 좋았던 이유는 엘리베이터라는 잘 알려진 문제가 그동안 생각하지 못했던 수많은 분산시스템의 컨셉을 드러내기 때문이다. 예를들어서,

  • Controller가 중앙에 한개 놓여있고 모든 엘리베이터가 통제에 따른다고 가정해보자. 그럼 Controller가 죽어버리면 엘리베이터의 Availability는 어떻게 될것인가?
  • 그럼 엘리베이터를 분산시스템으로 구현해보자. 엘리베이터 사이의 커뮤니케이션이 불안정할때 스케줄이 항상 정확할수 있을까? (CAPS theorem)
  • 엘리베이터는 사용자가 버튼을 누른 시간순으로 서비스를 제공한다. 그럼 엘리베이터의 시간은 모두에게 동일하게 흘러가는가? (Vector clock의 개념)

이러한 질문의 의도는 지원자가 시스템에서 발생하는 <문제> 혹은 <컨셉>을 다양하게 알고있는가를 파악하기 위한것이다. 가상의 문제에 대해 대화하면서 분산시스템의 클래식한 문제들 — vector clock, CAPS theorem, distributed consensus, quorum vote, data hashing등 — 을 연상해낼수 있는지를 보는것이다. 뛰어난 인터뷰어일수록 이런 질문을 던진다. 이런 문제에 답하기 위한 쉬운 방법은 없다. 아래에 달린 긴 리스트에서 보듯, 그저 다양하게 많이 아는 수밖에…

마지막으로 디자인 질문에서 파악하고자 하는것은 <괜찮은 디자인을 할수 있는가?> 여부이다. 복잡한 시스템에는 정답이 없다. 다만 괜찮은 답이 있을뿐이다. 여기에서 괜찮은 답이란 디자인의 각 단계에서 어떠한 선택을 해야할때 각 선택의 Trade-off 를 알고 있고, 자신의 선택을 논리적으로 방어할 수 있는 디자인이다. 즉 취할것은 취하고 버릴것은 버리되, 왜 그러한 선택을 하는지는 설명을 할 수 있어야 한다는 뜻이다. 예를들어 트위터를 디자인한다면,

  • Relational DB를 Shard해서 사용할것인가 아니면 Cassandra, Dynamo와 같은 분산 key-value DB를 사용할 것인가?
  • In-memory cache로 Redis 혹은 Memcached 를 사용할까?
  • Push model (모든 follower에게 tweet을 저장) 혹은 pull model (모든 following에게서 tweet을 읽음)을 사용할까?
  • Tweet의 아이디는 DB의 Sequential ID를 사용할까 아니면 snowflake와 같은 분산시스템을 따로 만들까?

코딩 질문이 한가지 질문에 optimal 알고리즘을 구현하기위한 것이라면 시스템 디자인은 시스템의 각 파트를 해결하기위해 제각각 여러개의 알고리즘을 끌어와서 큰 스케일에서 동작하는 그림을 보여주는 것이다. 그러므로 좋은 답을하기 위한 핵심은 얼마나 많이 그러한 알고리즘을 알고 있는가의 여부이다. 예를들어,

  • 어떻게 분산된 컴퓨터에 데이터를 나눌 것인가 —> Consistent hashing
  • 분산 컴퓨터들은 어떻게 자신이 담당할 문제의 영역을 선택할까? —> Paxos algorithm or zookeeper
  • 데이터가 복제되어있을때 어떻게 consistency를 보장할까? —> Quorum vote
  • 분산 컴퓨터가 어떻게 ID를 고유하게 만들까? —> Twitter’s snowflake
  • 데이터 통신의 보안은? —> PKI encyprtion

아래는 내가 그동안 공부했던것들중 인터뷰에서 가장 유용했던 자료들이다. 꼭 인터뷰가 아니더라도 최신의 시스템을 이해하는데 좋은 자료들이라고 생각해 여기에 공유한다. 가장 중요한 자료에는 별점 5개를 붙여놓았다.

[Designing Data-Intensive Applications]
시스템 디자인 준비하기에 가장 좋은 책. 아래의 레퍼런스 대부분 내용을 책 한권에 다 요약해 놨다. https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321

[Distributed Systems]

[Distributed Key-Value Database]

[Sharding]

[Caching]

[Search]

[Distributed Consensus]

[Concurrency]

[Distributed Queue]

[그외]

코딩 인터뷰 – part 3

예전에 한 스타트업과 인터뷰를 한적이 있다. 첫 시간에 두명의 엔지니어가 함께 들어왔는데 한시간 내내 코딩이나 시스템디자인이 아닌 behavioral 인터뷰를 했다. 과거 직장동료와 충돌이 있었는지, 그런 상황에서 어떻게 문제를 해결했는지등 일반적인 질문이었다. 코딩 인터뷰를 기대했던 나는 약간 당황했고 답은 횡설수설이었다. 그리고 한시간을 마치자마자 리쿠르터가 들어와 나는 그 회사와 cultural fit이 맞지 않으니 집에가라는 결과를 받았다. 태연한척 걸어나왔지만 ‘내 인성이 그리 엉망진창이란 말인가?’ 모욕감이 며칠간 내내 머리를 맴돌았다. 최근에서야 깨달은것은 behavioal 인터뷰 역시 준비가 필요하다는 사실이다. (참고로 나는 그 스타트업이 잘될거라고 생각하지 않는다. 엔지니어를 인성만으로 거르는건 축구선수를 외모 보고 발탁하는것과 같다.)

테크 회사들의 개발자 인터뷰는 크게 1) 코딩, 2) 시스템 디자인, 3) behavioral 세가지 파트로 나눌수 있다. 코딩인터뷰의 경우 주어지는 문제에따라 최적의 알고리즘이 이미 알려져있기때문에 pass/fail 여부를 쉽게 가늠할수 있는반면 behavioral과 시스템 디자인은 정확하게 어디까지가 pass이고 fail인지를 나누는것이 쉽지 않다. 지원자 입장에서는 최대한 ‘잘’ 준비하는수밖에 없다. behavioral의 경우 회사에서 알고자하는것은 크게 두가지로 볼수있다:

1. 커뮤니케이션을 효과적으로 하는가
2. 이 녀석은 혹시 jerk (고문관)가 아닐까?

과거에 아무리 대단한 프로젝트를 많이했어도 몇분안에 그 경험의 핵심을 전달하는것은 코딩과 별개인 커뮤니케이션 능력이다. 영어에 native가 아닌 사람들에게는 특별히 준비가 필요한 영역이다. ‘jerk test’의 경우 가장 중요한것은 인터뷰 과정에서 이상 행동을 하지 않는것이다. 듣기로는 테크 인터뷰를 하면서 인터뷰어와 싸우려드는 사람들이 의외로 많다고한다. 혹시라도 자신에게 파이터 본능이 있다면 인터뷰 당일만큼은 날카로운 발톱을 최대한 숨기는것이 좋다.

Behavior인터뷰의 방법은 회사마다 다르다. 어떤 회사들은 코딩인터뷰 중간에 인성과 관련된 질문을 넣기도 하고, 다른 회사들은 점심 시간이나 하이어링 매니저와의 세션 전부를 인성과 관련된 질문으로 채워 넣는다. 다음은 내가 받았던 Behavioral 혹은 프로젝트 경험과 관련된 질문들이다.

  • 지금까지 해결한 기술적인 문제중 아주 어려웠던 것은 어떤것이 있는가? 어떻게 그 문제를 해결했는가?
  • 지금 회사를 왜 떠나려고 하는가? 왜 우리 회사를 선택했는가?
  • 프로젝트가 내가 원하지 않는 방향으로 진행되는 것을 경험한적이 있는가? 어떻게 대응했는가?
  • 프로젝트가 기술외의 문제 (사내 정치등)로 영향을 받은적이 있는가?
  • 팀을 리드해본 경험이 있는가?
  • 내가 담당하는 영역이 아닌 다른 사람, 부서의 문제를 해결한 경험이 있는가?
  • 직장동료와 충돌을 경험한적이 있는가? 그런 상황에서 어떻게 문제를 해결했는가?
  • 고객과 회사의 이해가 충돌하는 상황을 경험한적이 있는가? 나는 어떤 선택을 했는가?

이와같은 질문을 받았을때 그 자리에서 즉흥적으로 답을 만들어내는것은 생각보다 쉽지 않다. 과거의 경험을 바탕으로 최대한 긍정적인 면을 어필할수 있는 답을 미리 준비하는것이 필요하다. (To be continued…)

코딩 인터뷰 – part 2

온사이트 인터뷰

스크리닝에서 일단 지원자가 사람이라는게 판가름나면 그 다음은 <쓸모>있는 사람인지를 판단하는 온사이트 단계로 넘어가게된다. 폰스크린 마치고 짧게는 1시간 안에, 길게는 2-3일내로 온사이트 초청 이메일을 받게된다. 이때부터 리쿠르터가 지원자를 대하는 태도가 조금 달라지는걸 느낄수 있는데 미래의 동료가 될 가능성이 높기때문에 이메일과 전화통화에서 좀더 지원자를 배려해준다. 즉 이제 <사람 취급> 받는다는 뜻이다.

폰스크리닝이 예선전이었다면 온사이트는 이제 본선이다. 월드컵 예선에서 미얀마, 필리핀같은 array문제를 풀었다면 이제 본선에선 독일, 브라질같은 dynamic programming, graph search 문제도 만나게 된다. 더 쓰기전에 우선 내 경험을 좀 더 이야기하려고 한다. 나는 내 자신이 한번도 알고리즘에 소질이 있다고 생각한적이 없다. <알알못>같은 사람이다. 학부 시절에 알고리즘 수업에서는 C를 받았었고, 대학원 수업에서도 C를 받았다. 참고로 대학원 수업에서 B를 못받는건 교수에게 진상짓하는것과 같다. 박사학위를 했지만 시스템쪽 전공이라 알고리즘과는 관계가없고, 지난 몇년간 스타트업에서 일하며 제대로 코딩 인터뷰를 해본적도 없다.

내가 코딩 인터뷰를 돌파하기 위한 방법은 그래서 한가지였다. 멋있는 말로 하면 <photographic memory 능력을 사용하자> 이고, 쉽게 말하면 <답을 외우자>가 내 전략이었다. 코딩 인터뷰에는 분명히 문제 set이 존재한다. 어떤 경우엔 문제가 토씨하나 틀리지않고 그대로 나올때가있고, 응용이지만 결국 같은 알고리즘을 원하는 문제를 만날때도 있다. 코딩 인터뷰의 set을 공부하는 가장 좋은곳은 leetcode.com 이다. 이곳에서 Frequency 순으로 정렬해서 가능하면 많이 문제를 풀어보는것이 좋다. 나는 지난 3개월간 160개 정도의 문제를 풀었고 같은 문제가 나왔을때 한번도 실수 안할정도로 답의 코드 패턴을 외웠다.

사실은 인터뷰의 set을 푸는 그 과정이 쉬운것은 아니다. 한 문제를 풀어보려고 2시간 이상 씩씩대가며 모니터를 쳐다볼때도 많았다. 나는 내가 좀 지능이 모자라서 그런가 생각했는데, 최근 공부를 시작한 나보다 훨씬 똑똑한 동네 친구 역시 나처럼 2시간씩 씩씩대고 있다는 하소연을 들었다. 그런데 한가지 흥미로운 사실은, 공부를 시작할무렵 문제를 보면서 느낀, 마치 벽을 앞에두고 선듯한 막막함이 지금은 거의 사라졌다는 사실이다. 지금은 비슷한 문제를 보면 예전에 외웠던 알고리즘의 패턴이 자연스럽게 생각난다. 같은 문제에 대해 예전에는 두뇌가 불편해 했다면, 지금은 두뇌가 자연스럽게 받아들인다고 할까? 160개의 문제와 답의 알고리즘 패턴을 외우는 과정에서, 두뇌가 좀 더 알고리즘 문제에 적응되었기 때문일것이다. 그래서 <답을 달달 외우면 그게 실력이냐?> 누가 묻는다면, <하다보면 실력이 돼> 라고 답할수 있을것 같다.

다시 온사이트 이야기로 돌아가보자. 온사이트는 보통 4-6명의 인터뷰어와 1시간씩 돌아가며 문제를 푼다. 폰스크리닝과 확연한 차이점은 두뇌가 5시간 이상을 버틸 체력이 필요하다는 사실이다. 코딩을 격투기라고 생각하면 매 시간마다 새로운 도전자가 씨익 웃으며 링위로 올라온다는 뜻이다. 쉬는 시간도 주어지지 않고 <다음 인터뷰어를 소개하지~> 이렇게 계속해서 상대방만 턴을 바꾸게된다. 나는 3주간 10개의 온사이트를 집중해서 보았다. 처음 온사이트는 숨막히는 피곤함 뿐이었는데, 후반기로 갈수록 체력이 붙어 여유롭게 6시간을 버텨낼수 있었다. 특히 오퍼가 이미 나왔다면 <허허 어디 문제한번 봅세~> 이런 여유로움도 누릴수 있다.

폰스크리닝과 마찬가지로 매 시간마다 인터뷰어는 <너는 뭐했슴?> <우리팀에 질문있슴?> 이렇게 묻는다. 가능하다면 앞 부분의 이런 인트로는 짧게 하고, 문제를 푸는 시간을 최대한 길게 갖는것이 좋다. 4-5명과의 온사이트중 최소한 1명은 디자인 인터뷰를 담당한다. 시니어 레벨의 경우 2명 이상과 디자인 세션을 하는 경우도 있다. 또 점심식사를 겸해서 behavioral interview를 하는게 일반적이다 그래서 코딩은 온사이트에서 3회 정도 한다고 보면 일반적이다.

인트로가 끝나면 <자 오늘 내가 준비한 문제는…>, 이렇게 멘트를 날리며 인터뷰어는 문제를 화이트보드에 적는다. 이때 문제에 따라 몇가지 다른 시나리오가 생긴다.

  • 아는 문제: 경험상 절반의 문제는 leetcode 문제 set에서 그대로 나왔다. 이때 필요한 것은 출중한 연기력이다. 태연하게 ‘나는 저 문제를 모른다. 나는 저 문제를 모른다’ 머리속으로 되뇌인다음 1) 막막한 표정, 2) brute-force는 이렇게 하면 될건데 , 3) 아 이렇게 하면 더 빨리 되겠구나!, 이렇게 단계별로 연기해가며 차분하게 외운 코드를 화이트보드에 적으면 된다
  • 응용 문제: 경험상 1/4 정도의 문제는 이미 외우고있는 문제를 약간만 응용해서 답을 찾는 타입이다. 예를들어 graph search 문제는 무궁무진하게 응용이 가능한데, 몇개의 문제를 풀어봤으면 대략 문제 설명을 듣고나서 이건 graph 문제구나 라는 느낌이온다. 이 경우엔 연기가 필요없다. 자연스럽게 내가 아는 지식을 꺼내서 문제에 적용하는 것이기 때문에, 코딩만 실수없이 잘 마무리하면 된다.
  • 모르는 문제: 이런 경우가 없으면 좋겠지만 어떤 인터뷰어는 너무 부지런해서 공개안된 문제를 내곤한다. 경험상 1/4 정도의 문제는 처음 접해보는 것이었다. 이 경우 우선은 알고리즘 패러다임 (dynamic programming, graph, binary search, divide&conquor..) 혹은 자료구조 (priority queue, binary search tree, …) 중에서 하나라도 써볼수 있는게 있나 생각해야 한다. 그리고 최대한 막막하고 힘든 표정을 지으며 인터뷰어의 힌트를 유도해야 한다. 힌트를 얻고도 도저히 안되겠다 싶을때는 시간을 잘 고려해 brute-force라도 코드를 정확하게 끝까지 써내야 한다. 한 세션의 결과는 [pass, neutral, fail] 세가지중 하나인데, pass가 글렀으면 neutral로 승점 1점이라도 건져야한다.

지난 10회의 온사이트에서 나온 25개 문제를 카테고리로 나누면 다음과 같다:

  • Binary Search Tree or Binary Tree: 8회
  • Graph Search Problem: 3회
  • Dynamic Programming: 2회
  • Advanced(응용) Sorting: 3회
  • Hybrid Data Structure: 2회
  • Greedy Algorithm: 4회
  • String, sliding-window problem: 2회
  • Binary Search 응용: 1회

대부분 문제들은 leetcode의 medium difficulty 수준이라고 생각하면 되고, 종종 hard difficulty 문제가 나오는 경우도 있다. 내 경우 dynamic programming 문제중 하나는 아주 어려운것이었는데 마침 그 문제의 답을 며칠전 외운 상태였다. 그리고 그 인터뷰가 첫 오퍼였으니 어쩌면 인터뷰엔 운도 많은 작용을 한다.

코딩과 디자인 인터뷰 (다음 블로그 주제)를 4명과 했을경우 경험상 오퍼의 여부는 이렇게 가늠할수 있다:

  • 4명 PASS: 당연히 오퍼
  • 3명 PASS, 1명 Neutral: 오퍼
  • 3명 PASS, 1명 Fail: 리젝
  • 2명 PASS, 2명 Neutral: 리젝

즉, 한명에게라도 Fail수준의 인터뷰를 했으면 오퍼는 나오지 않았다. 그리고 2명이상 Neutral일 경우에도 오퍼는 나오지 않았다.

끝으로 코딩 인터뷰에 적합한 알고리즘 교과서는 Skiena의 Algorithm Design Manual을 추천한다. Cormen의 Introduction to Algorithm보다 쉬우면서 인터뷰에 충분한 내용은 모두 담고있다. 그리고 인터뷰 경험이 부족한 사람에겐 가상(mock) 인터뷰를 할수 있는 pramp.com 도 아주 유용했다. 코딩 인터뷰의 pressure를 훈련하기에는 mock 인터뷰만큼 좋은것이 없다.

(To be continued…)

코딩 인터뷰 – part 1

지난 두달간 무려 15개의 회사와 코딩 인터뷰를 했다. 혹 비슷한 과정을 겪게될 분들을 위해 그동안의 경험을 지극히 주관적인 관점에서 정리해보려고 한다.

미국의 소프트웨어 개발자 채용 과정은 사실 공정한 편이다. 채용 프로세스중 몇몇 역할을 우선 소개하자면,
  1. 리쿠르터: LinkedIn등을 통해 지원자와 처음 연락하는 것부터 오퍼의 마지막 단계까지 끌어주는 역할을 한다. 오퍼의 여부를 결정하는 사람은 아니지만, 오퍼에서 연봉등을 하이어링 매니저와 조율하기 때문에 중요한 역할을한다. LinkedIn으로 귀찮게 연락한다고 가볍게 여겨선 안된다.
  2. 하이어링매니저: 포지션을 오픈하고 채용 후에 보통 매니저 역할을 수행하게되는 사람이다. 곧 미래의 보스라고 생각하면 된다. 이 사람의 의견이 채용에 있어 가장 중요하므로 지원자 입장에선 높이 우러러보는 자세가 필요하다.
  3. 같은팀 개미 개발자: 오퍼를 받았을때 같은 팀에서 일하게될 개미 개발자들이다. 여기서 개미는 Principal 보다 낮은 직급으로 주로 코딩 인터뷰를 담당하는, 일개미 같은 개발자들을 말한다.
  4. 같은팀 왕고 개발자: 같은 팀에서 Principal 엔지니어 이상의 직급으로, 칠판에 그림만 그리고도 월급을 쓸어가는 사람들을 말한다. 참고로 대기업에서 Principal들은 보통 연봉이 30만불을 훌쩍 넘긴다. 이들의 역할은 주로 그림 그리는 것인만큼 인터뷰 역시 칠판에 그림 그리는 시스템 디자인을 주로 담당한다.
  5. 다른팀 왕고 개발자: 원래 아마존에서 시작했던 Bar-raiser 시스템이 여러 회사에 퍼지면서 다른팀의 왕고 개발자가 인터뷰에 들어올때가 있다. 이들은 보통 어려운 문제를 던져놓고 심드렁하게 앉아있는 경우가 많다. 지원한 팀에대해 질문을 하면 자기 팀이 아니라 당황해 하기때문에, 맘에 안들면 타이밍을 봐서 한번 물어보는것도 괜찮다.
채용 프로세스의 첫 단계는 리쿠르터와의 짧은 통화다. 내 레주메가 하이어링매니저 혹은 리쿠르터의 눈에 들었을땐 이메일로 전화 약속을 잡게된다. 통화시엔 레주메를 기준으로 과거의 경력을 짧게 소개하고, 왜 그 포지션에 지원하게 되었는지 설명한다. 하이어링매니저가 시켜서 전화를 걸어온 경우엔 거의 100% 전화 인터뷰를 잡자고 이야기하고, 혹 리쿠르터가 단독으로 연락을 해온경우 하이어링매니저의 레주메 심사를 더 통과해야 한다. 리쿠르터와의 통화는 거의 같은 패턴을 반복하므로 몇번 같은 통화를 하고나면 나중엔 유머사이트 보거나 애들 밥먹이면서 이야기하는 경지에 이르게된다. 혹 첫단계에서 현재 회사의 연봉을 묻는 리쿠르터가 있는데, 이 경우 어차피 오퍼 단계에서 필요한 정보이므로 알려주는것도 나쁘지 않다.

전화 인터뷰

리쿠르터와의 통화이후 며칠안에 전화 인터뷰가 잡힌다. 흔히 이것을 Phone Screening 이라 부르는데, 해석하자면 전화기 너머 상대가 스크리닝 (차양막, 모기장) 당해야 하는 벌레인가 아니면 온사이트 불러도 되는 인간인지를 판가름하는 지원자 입장에선 기분나쁜 단계다. 폰스크리닝의 상대로는 흔히 개미 개발자들이 출현하고, 혹 시니어 포지션으로 지원했을때는 그에 걸맞는 시니어 개미가 전화해 예우를 갖춰준다. 보통은 짧게 자신의 팀 소개를 먼저 하고, 그 다음엔 “너는 뭐했슴?” 묻는다. 여기서 주의할점은 이 질문의 역할은 지원자의 긴장을 풀어주기 위한것이지, 지원자의 화려한 전적을 듣고싶어 하는것이 아니라는점이다. 신바람나서 과거의 무용담을 끝도없이 늘어놓으면 나중에 시간이 부족해 “I’m sorry, I’m sorry…” 를 반복하다가 전화를 끊게되는 참담함을 겪을수 있으니 소개는 적당한것이 좋다. 또 인터뷰어는 흔히 “우리 팀에 질문 있슴?” 이렇게 묻는데, 코딩 문제 끝나고 나중에 묻겠다고 이야기하는게 낫다. 어차리 이런 잡담은 당락에 영향을 미치지 않고 오직 코딩 테스트가 결과를 결정하기 때문이다.

여러번 인터뷰후 한가지 파악한것은 폰스크리닝용 문제 타입이 있다는 사실이다. 우선 스크리닝 역할은 ‘멋진’ 인간인지를 판가름하는게 아니라 상대가 그저 인간인지를 알아내는데 있기 때문에 어려운 문제를 내선 곤란하다. 그리고 전화와 코딩 사이트의 텍스트 에디터로만 문제를 설명하는 한계때문에 문제 자체가 짧고 이해하기 쉬워야 한다. 아래는 실제로 폰스크리닝에서 받았던 질문들 혹은 같은 유형의 예제이다.

폰스크리닝 단계에서 주로 맞닥뜨리는 코딩문제의 패턴을 보면…
  • Array위에서 한개 이상의 variable을 가지고 놀수 있는가? (maximum-subarray, move-zeroes와 같은 문제)
  • LinkedList, Stack, Queue등을 이해하고 갖고 놀수 있는가?
  • 다양한 엣지 케이스를 잡아낼수 있는가? (Integer overflow, negative numbers 등등). 사실 이건 함정을 파놓고 기다리는 아주 짜증나는 타입의 질문인데 시애틀 M사 출신의 개발자들이 특히 많이 물었다.
  • HashMap이나 Set을 제대로 사용할줄 아는가? 두개 이상의 Map을 차분하게 사용해야 해결할수 있는 문제들이 많았다.
실용적인 질문을 한다고 알려진 몇몇 회사의 경우 (시애틀 A사, 캘리포니아 사과회사등), 코딩에 더해서 몇가지 시스템 지식문제를 내는 경우도 있었다. 예를들어
  • web browser로 google.com에 접속했을때 운영체제, 네트워크에서 벌어지는 모든 일들을 설명해봐
  • 프로그램이 execution될때 무슨 일이 일어나는지 Stack과 heap과 관련해서 설명해봐
  • virtual memory 설명해봐
  • Java가 C에 비해서 왜 느린지 설명해봐

(To be continued…)