brunch

You can make anything
by writing

C.S.Lewis

아마존 인터뷰에 떨어지다

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


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


이력서를 보내고 며칠이 지나자 답장이 왔다.

리크루터 : 이력서 잘 받았어. 근데 너 졸업이 2015년이던데? 정말 5년 경력 있는 거 맞아?

나 : 그건 내가 병특을 하느라… 블라블라블라 4년 몇 개월 정도 되는 거 같은데.

리크루터 : 미안. 우리는 5년 이상만 받아.


이렇게 기회가 물 건너 가는 걸까? 다행히 아마존 다니시는 지인분께 부탁을 드리니 리크루터에게 메일을 써 주셨다. 리크루터 입장에서는 실제 경력 기간이 그렇게 많이 부족한 것도 아니고 직원의 레퍼런스가 있으니 괜찮다고 판단을 했는지 다행히 다음 단계로 넘어갈 수 있었다.


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


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


“Binary search의 시간 복잡도는? Quicksort는?”

“영어사전에서 원하는 단어를 찾는 데에 걸리는 시간을 big-O notation으로 나타내면?”

“A로 시작하는 단어와 B로 시작하는 단어에 몇 개의 페이지가 있는지 찾는데 걸리는 시간은?”


이번 단계도 통과해서 아마존 직원들과 대면으로 진행되는 온사이트(onsite) 인터뷰에 초대받게 되었다. 온사이트 인터뷰는 이태원에 있는 그랜드 하얏트 호텔에서 진행되었다. 온사이트 인터뷰는 한 세션 50분, 쉬는 시간 10분으로 총 4 세션이 진행된다. 호텔에 도착하면 지원자마다 테이블과 화이트보드가 있는 방을 하나씩 배정해주고, 반나절동안 인터뷰어들이 순서대로 방에 들어와서 인터뷰를 보고 다시 나간다. 


이런 느낌으로 화이트보드에 그림을 그리며 내 생각을 설명해야 한다.


온사이트에서 나오는 문제들은 크게 세 가지로 분류할 수 있다.


1. 코딩 인터뷰 : 어떤 문제를 주고, 그 문제를 해결하는 코드를 손으로 작성하는 인터뷰이다. 인터뷰 시간이 제한이 있고 손으로 작성한다는 점을 감안해서 보통 많이 복잡한 문제가 나오진 않는다. 이 부류의 문제는 프로그래머라면 친숙할 것 같아서 많은 설명은 하지 않아도 될 것 같다.


2. 시스템 디자인 인터뷰 : 이 인터뷰는 조금 생소할 텐데, 쉽게 말해서 서비스 시스템을 설계하는 문제다.


“URL 단축 서비스를 설계하라.”

“유명한 서비스 (트위터나 우버 같은)를 개발하려고 한다. 어떻게 해야 하나?”

“페이스북처럼 친구의 게시물을 시간 순으로 보기 위한 시스템을 만들어라.”


각각의 문제에는 제약사항들이 있다. 예를 들면 url shortener 같은 경우에는 "하루에 몇 개의 url이 생성되는지?", "한번 생성된 url은 얼마나 지나야 expire 되는지?", "중복 url은 어떻게 처리할 것인지?" 같은 고려사항들이 있을 것이다. 이런 제약조건(constraint)에 따라 설계해야 하는 시스템의 구조가 달라질 수 있기 때문에 처음부터 이런 숫자들에 대한 가정을 정확히 하지 않고 풀기 시작한다면 함정에 빠지기 쉽다. 자세한 내용은 구글에 system design interview를 검색해보면 많은 자료들이 나온다.


3. Leadership Principles : 아마존의 인터뷰를 다른 회사들의 인터뷰와 다르게 해주는 가장 큰 요인은 Amazon Leadership Principle의 존재일 것이다. 


아마존 인터뷰의 핵심, leadership principles.


한국어로 하면 “아마존 직원들이 따라야 하는 14가지 룰” 정도가 되겠다. 한국의 대기업들의 ‘인재상’ 비슷한 것이라고 볼 수 있는데, 지원자들이 인터뷰에서 하는 대답들은 모두 이 원칙들에 따라서 채점되며, 아마존 내부에서 내려지는 비즈니스적인 결정들도 모두 이 principle들에 의해 이루어진다고 하니 어찌 보면 이 항목들이 아마존 그 자체라고도 할 수 있겠다. 이 질문에는 내가 과거에 어떤 문제가 생겼을 때 이런 룰들에 부합하게 행동했다는 사실을 증명해야 한다. 예를 들면,


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


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


여튼 그렇게 4시간의 온사이트를 마치고, 호텔 건물을 나오자마자 불합격 통지를 받았다. 



아쉬운 부분에 대한 피드백을 받고 싶어 리크루터에게 메일을 보냈지만 답장은 받지 못했고, 내가 대략 짐작해본 이유는 다음과 같다.  


첫 시간 인터뷰가 bar raiser였던 것 같은데, 내가 이 인터뷰어의 인도식 악센트에 익숙지 않아 자꾸 재차 질문을 하며 위축되었고 결국 인터뷰 질문들에 대해 좋은 답변을 하지 못했다. 첫 세션이 이렇게 되니 나비효과로 다음 인터뷰도 다다음 인터뷰도 위축되어서 바보 같은 실수를 계속하게 되었다. Bar raiser라는 것은 아마존 인터뷰의 특징적인 제도인데, 4 세션의 인터뷰 중에 한 세션은 다른 인터뷰어보다 까다로운 (아마조니언들이 하는 표현으로 'raising bar') 인터뷰어를 배정하는 것이다. 주변에 면접 보신 분들 말을 들어보니 다들 한 시간은 조금 공격적으로 짧게 말하고, 표정이 밝지 않은 인터뷰어가 한 명씩 있었다고 하니 나의 bar raiser도 이 사람이었던 것 같다. 하필 첫 시간에 이런 인터뷰어가 배정된 것이 어떻게 보면 불운이겠지만, 뭐 이것도 내 실력이니 어쩔 수 없다.


코딩 인터뷰 준비와 시스템 인터뷰 준비를 제대로 하지 않았다. 손으로 코딩하는 것이 키보드로 코딩하는 것과는 다르다는 걸 빨리 깨닫고 미리 준비했어야 하는데, 실제 투자한 시간이 너무 적다 보니 당연히 쉬운 문제도 쉽지 않게 해결할 수밖에 없었다. 어려워서 풀지 못한 문제는 없었다.  


Leadership principle의 중요도를 너무 과소평가했다. 실력이 중요하지 이게 중요하겠어?라는 안이한 생각을 했는데, 거의 매 시간 이에 대한 질문이 나왔던 것 같다. 그렇다고 코딩 문제를 잘 푼 것도 아니고... 준비가 안 되었으니 당연히 주어진 질문에 간단한 대답밖에 할 수 없었고 내가 준비가 되어있다는 인상을 주는 데에 실패한 것 같다.  


세상 모든 일에 연습은 필수다. 인터뷰도 마찬가지다.


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

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari