6년차 개발자 해외취업 도전기 – 3. 아마존, 첫번째 시도

그렇게 “해외취업을 해야지~” 하면서 이력서를 올려놓으면 뭐가 올까? 놀랍게도 왔다. 그것도 무려 아마존에서! 자기는 리크루터인데 이번에 시애틀 오피스에서 한국 개발자들을 채용하기 위해 서울에서 4일간의 리크루팅 이벤트를 연다며, 시애틀에서 일하는 것에 관심이 있으면 이력서를 보내달라고 했다.

리크루팅 이벤트란 리크루터들과 인터뷰어들로 이루어진 채용 그룹이 현지에 직접 방문해서 채용을 진행하는 행사이다. 보통 호텔이나 컨퍼런스 홀 같은 곳을 대관해서 진행되며, 일반적으로 인터뷰는 본사에서 진행되지만 현실적으로 모든 지원자들을 비행기와 호텔을 제공하며 미국으로 부르기가 힘드므로 이런 채용 팀을 세계 곳곳에 파견해서 개발자들을 끌어모으고 있는 것이다. 같은 이유로 북미쪽 기업과 인터뷰할 수 있는 기회가 많지 않은 한국 개발자들에겐 꽤나 좋은 기회다. 이런 식으로 채용을 진행하는 회사는 현재로서는 아마존밖에 없는 것으로 알고 있다.

며칠이 지나자 답장이 왔다.

리크루터 : 이력서 잘 받았어. 근데 너 졸업이 2015년이던데? 정말 5년 경력 있는거 맞아?
나 : 그건 내가 병특을 하느라… 블라블라블라 4년 몇개월 정도 되는 거 같은데.
리크루터 : ㅈㅅ. 우리는 5년 이상만 받음

그렇게 아마존 인터뷰의 기회가 물건너 가…지는 않았고, 이 상황을 아마존 다니시는 지인분께 공유를 드리니까 “안녕, 나는 이 지원자를 몇 년 전부터 봐 왔는데 어쩌고저쩌고… 5년이 그렇게 중요한 건 아닌 거 같아.” 라고 친절하게 리크루터에게 메일을 써 주셨다. 리크루터 입장에서는 실제 경력 기간이 그렇게 많이 부족한 것도 아니고, 내부의 레퍼런스가 있으니 괜찮다고 판단을 했는지 다행히 다음 단계로 넘어갈 수 있었다.

첫 번째 단계는 코딩 테스트였다. 메일로 주어지는 LeetCode나 HackerRank같은 problem solving 사이트에 접속해서, 1시간 정도 주어진 문제를 풀고 작성한 코드를 설명하는 짧은 글을 작성하고 시간/공간 복잡도 분석을 하면 된다. 주말에 날 잡고 일찍 일어나 밥을 먹은 후, 노트북을 들고 카페로 내려가서 엄청 긴장하고 메일 링크를 클릭했는데 Leetcode 기준으로 easy~medium정도 난이도로 그렇게 어려운 문제들은 아니었다. 그래프 상에서 breadth-first search하는 코드를 작성했던 것 같다.

두 번째는 폰 인터뷰. 리크루터와 전화통화 약속을 잡고 – 시애틀과는 17시간의 시차가 있어 시간 잡는 것이 쉽지 않다. – 전화상으로 리크루터가 물어보는 질문에 대답을 하면 된다. 최대 30분정도로 간단한 이력서에 관한 질문과 코딩 테스트에서 작성한 코드에 대한 질문, 데이터 구조와 알고리즘에 관한 문제를 물어본다. 역시 대학교 수준의 알고리즘/자료구조에 대한 지식이 있으면 쉽게 대답할 수 있는 부분이다. 코딩 인터뷰 준비하는 사람들이 만들어놓은 Big-O-cheatsheet 라는 주요 자료구조와 알고리즘들을 정리해놓은 암기책같은 것이 있는데, 이 시트에 나오는 내용만 알고 있어도 통과하기 힘들지 않을 것같다. 그리고 약간의 응용이 필요한 문제도 나오는데, 예를 들면 이런 것이다.

“Binary search의 시간 복잡도는? Quicksort는?”
“영어사전에서 원하는 단어를 찾는 데에 걸리는 시간을 big-O notation으로 나타내면?”
“A로 시작하는 단어와 B로 시작하는 단어에 몇 개의 페이지가 있는 지 찾는데 걸리는 시간은?”

여튼 폰 인터뷰도 통과해서, 마지막으로 현재 아마존에서 일하고 있는 직원들과 대면으로 진행되는 온사이트 인터뷰에 초대받게 되었다. 온사이트 인터뷰는 이태원에 있는 그랜드 하얏트 호텔에서 진행되었다. 필요하다면 교통비와 호텔 숙박도 제공해준다고 하던데 나는 어차피 경기도권에 살고 있어서 굳이 신청하지 않았고 당일 택시를 타고 택시비만 청구했다.

온사이트 인터뷰는 한 세션 50분, 쉬는 시간 10분으로 총 4세션이 진행된다. 보통 길어봐야 2시간 정도로 인터뷰가 끝나는 국내 회사들과는 다른 부분이라 적응하기가 쉽지 않다. 온사이트 인터뷰가 잡힌 시점에서 보통 회사마다 인터뷰 이렇게 준비하세요~ 하는 문서를 보내주긴 하지만 일단 인터뷰에서 나오는 질문은 대략 이렇다.

  • 코딩 인터뷰 : 어떤 문제를 주고, 그 문제를 해결하는 코드를 손으로 작성하는 인터뷰이다. 인터뷰 시간이 제한이 있고 손으로 작성한다는 점을 감안해서 보통 많이 복잡한 문제가 나오진 않는다. 이 부류의 문제는 프로그래머라면 친숙할 것 같아서 많은 설명은 하지 않아도 될 것 같다.
  • 시스템 디자인 인터뷰 : 이 인터뷰는 조금 생소할 수 있는데, 예를 들면 이런 문제들이다.
    “URL 단축 서비스를 설계해봐라.”
    “유명한 서비스 (트위터나 우버 같은) 를 개발하려고 한다. 어떻게 해야 하나?”
    “페이스북처럼 친구의 게시물을 시간 순으로 보기 위한 시스템을 만들어라.”

    각각의 문제에는 제약사항들이 있다. 예를 들면 url shortener 같은 경우에는,

    – 하루에 몇 개의 url이 생성되는지?
    – 한번 생성된 url은 얼마나 지나야 expire 되는지?
    – 중복 url은 어떻게 처리할 것인지?

    이런 제약조건(constraint)에 따라 설계해야하는 시스템의 구조가 달라질 수 있기 때문에 처음부터 이런 숫자들에 대한 가정을 정확히 하지 않고 풀기 시작한다면 함정에 빠지기 쉽다. 자세한 내용은 구글에 system design interview를 검색해보면 엄청나게 많은 자료들이 나온다.

  • Leadership Principles : 아마존의 인터뷰를 다른 회사들의 인터뷰와 다르게 해주는 가장 큰 요인은 Amazon Leadership Principle의 존재일 것이다. 한국어로 하면 “아마존 직원들이 따라야 하는 13가지 규칙” 정도가 되겠다. 한국의 모 대기업의 ‘인재상’ 비슷한 것이라고 볼 수 있는데, 별로 중요한 것 같지 않아 보이지만 내가 인터뷰에서 하는 대답들은 모두 이 원칙들에 따라서 채점되고 또 아마존 내부에서 내려지는 결정들은 다 이 principle에 근거한다고 하니 어찌 보면 이 항목들이 아마존 그 자체라고도 할 수 있겠다. 여튼 내가 과거에 어떤 문제가 생겼을 때 이런 principle에 부합하게 행동함으로써 이 규칙들을 따를 준비가 되어 있는가? 라는 사실을 증명해야 한다. 예를 들면 이런 질문이다.

    “보스가 내가 동의하지 않는 명령을 내린 적이 있는가? 그 때 어떻게 행동했는가?”

    이 질문은 ‘disagree and commit’에 대한 질문이다. 모범 답안은 “설득해보려고 노력했지만 안되어서 어쩔 수 없이 따랐다. 하지만 후에 상사의 말이 맞음을 알게 되었다.” 정도가 되겠다. 당연하지만 “받아들일 수가 없어서 그 업무에서 손을 떼기로 했다.” “팀을 옮겼다.” “명령을 거부했다” 와 같은 답변은 좋은 점수를 받기 힘들 것이다. 답변을 하면서 이 항목 뿐만 아니라 다른 항목에 대해서도 어필할 수 있다면 더 좋은 점수를 받을 수 있을 것이다. 막상 가서 영어로 이야기하려면 도저히 생각이 나지 않기 때문에 회사생활하며 있었던 에피소드들을 미리 정리해두는 것이 좋다. 이 유형의 질문에 대해 얼마 전에 개발자 해외 취업 그룹에서 100점 만점에 150점 주고싶은 글이 있어 링크를 남겨둔다.

    그렇게 4시간의 온사이트 후, 호텔 건물을 나오자마자 불합격 통지를 받았다… 아쉬운 부분에 대한 피드백을 받고 싶어 리크루터에게 메일을 보냈지만 답장은 받지 못했고, 내가 대략 짐작해본 이유는 다음과 같다.

 

  • 첫 시간 인터뷰가 아마 bar raiser였던 것 같은데, 내가 이 인터뷰어의 인도식 악센트에 익숙치 않아 자꾸 재차 질문을 하며 위축되었고 결국 인터뷰 질문들에 대해 좋은 답변을 하지 못했다. 첫 세션이 이렇게 되니 나비효과로 다음 인터뷰도 다다음 인터뷰도 위축되어서 바보같은 실수를 계속 하게 되었다. Bar raiser라는 것은 아마존의 인터뷰 관습같은 것이라 할 수 있는데, 4시간 인터뷰 중에 한 시간은 다른 인터뷰어보다 까다로운 인터뷰어를 일부러 배정하는 것이다. 주변에 면접보신 분들 말을 들어보니 다들 한 시간은 조금 공격적으로 짧게 말하고, 표정이 밝지 않은 인터뷰어가 한 명씩 있었다고 하니 나의 bar raiser도 이 사람이었던 것 같다. 하필 첫 시간에 이런 인터뷰어가 배정된 것이 어떻게 보면 불운이겠지만, 뭐 이것도 내 실력이니 어쩔 수 없다.
  • 코딩 인터뷰 준비를 너무 안 했다. 손으로 코딩하는 것이 키보드로 코딩하는 것과는 다르다는 걸 빨리 깨닫고 미리 준비했어야 하는데, 실제 투자한 시간이 너무 적다 보니 당연히 쉬운 문제도 쉽지 않게 해결할 수밖에 없었다. 어려워서 풀지 못한 문제는 없었다.
  • 시스템 디자인 인터뷰도 잘 대답하지 못했다. 이런 면접에 익숙하지 않았는데 준비도 별로 안했다.
  • Leadership principle의 중요도를 너무 과소평가했다. 4시간에 2개정도 물어보겠거니 하고 안이하게 생각했는데, 거의 매 시간 LP에 대한 질문이 나왔던 것 같다. 준비가 안 되었으니 당연히 주어진 질문에 간단한 대답밖에 할 수 없었고 내가 준비가 되어있다는 인상을 주는 데에 실패한 것 같다.

결국 준비를 너무 안하고 면접에 들어간 것이 문제라고 하겠다. 면접 준비를 특별히 오래 해 본 경험이 별로 없으니 한국 회사들과 비슷하겠거니 하고 지원했던 것이 실패 요인이었다. 다음 글에는 이 실패를 경험삼아 어떻게 인터뷰 대비를 하기 시작했는지에 대해 써보려고 한다.