스톡홀름에서의 인터뷰
Spotify data engineer 인터뷰 후기
앞서 글에서 언급했던 것처럼 링크드인에 이력서를 영어로 올려두니 여러 기업에서 연락이 왔는데 그중에는 유명한 음악 서비스인 Spotify도 있었다. 예전에 추천 관련 논문 서치 하면서 봤던 기억도 있고, Apache Spark를 잘 활용하고 있는 것으로 나름 유명한 기업인지라 궁금한 마음에 답장으로 이력서를 첨부해 보내고 리크루터와 전화 약속을 잡았다.
한국에는 잘 알려져 있지는 않지만 Spotify는 8천만 명에 가까운 구독자를 가지고 있는, 미국/유럽을 비롯한 서구권에서 꽤나 유명한 음악 스트리밍 서비스이다. 쉽게 말하자면 서양의 벅스뮤직이나 멜론이랄까. 최근에 미국 지역에서는 애플 뮤직에 따라 잡혔다는 이야기도 있지만 아직 유럽권에서는 Spotify가 우세한 듯하다.
정해진 시간이 되자 스카이프로 전화가 왔다. 런던 오피스에 있다는 이 리크루터는 간략하게 회사를 소개하고 현재 오픈되어 있는 포지션들에 대해 안내해주었다. 나는 data engineer와 machine learning engineer, 두 개의 포지션에 지원했는데 전화 인터뷰를 잡고 나니 내가 data engineer로 면접을 보게 된다는 사실을 알게 되었다. 아무래도 관련 경험이나 학위가 없어서였던듯 싶다.
Spotify는 크게 2곳, 스웨덴의 스톡홀름(본사)과 미국 뉴욕에 오피스가 있다. 내가 지원한 data engineer는 양쪽 오피스에서 모두 뽑고 있는 포지션이었기 때문에 사실 미국에 가고 싶은 맘이 더 컸지만 아쉽게도 비자 문제 때문에 스톡홀름에서만 채용을 한다고 했다. 아쉬운 마음을 뒤로하고 다음 전화 인터뷰 일정을 잡았다.
전화 인터뷰는 구글 행아웃으로 진행되었다. 난이도가 어렵진 않았는데 유럽 특유의 독특한 영어 발음 때문에 꽤나 고생했다. 화상으로 CS 지식 관련 단답형 객관식 질문들을 20분 정도 물어보고 Collabedit으로 간단한 파이썬 코딩 문제 (피보나치수열이었던 것 같다) 하나와 map-reduce 문제 하나가 나왔다. 어떤 데이터가 주어졌을 때 이 데이터에서 다른 데이터를 추출하는 SQL 쿼리를 작성하게 하고, 그 쿼리를 map-reduce를 써서 구현한다면 어떻게 되겠는가? 하는 문제였다. 쿼리 자체가 간단한 group by 쿼리여서 그다지 어려운 문제는 아니었다.
폰 인터뷰를 잘 통과해서 온사이트에 초대받게 되었다. 회사에서 왕복 항공권과 호텔 3일 숙박을 지원해준다니까 와이프가 "그럼 나도 갈래!"라고 해서 졸지에 면접 겸 스웨덴 여행을 떠나게 됐다. 사실 합격해서 가게 된다면 가서 생활이 어떨지 와이프도 당연히 가봐야 하니까. 인천-스톡홀름은 직항이 없어서 네덜란드 암스테르담을 경유해서 15시간의 여정 끝에 스톡홀름에 도착해서 하루를 쉰 후 다음날 인터뷰를 하러 갔다.
Spotify의 온사이트는 코딩 인터뷰, 시스템 디자인 인터뷰, 컬처 인터뷰, 케이스 인터뷰의 4개 세션으로 이루어진다. 여느 회사들처럼 회의실에서 대기하고 있으면 인터뷰어가 와서 인터뷰를 하고 나간다. Spotify의 회의실은 마이클 잭슨이나 아델, 아리아나 그란데처럼 유명한 아티스트들의 이름을 가지고 있다. 재미있는 점은 회의실 이름에 따라 인테리어가 다르다는 점이다. 우연인지 의도한 것인지 매시간 회의실이 바뀌어서 다른 회의실들을 구경하는 깨알 같은 재미가 있었다.
첫 시간은 코딩 인터뷰. 두 개의 문제가 나왔다.
Queue의 interface를 설계해보고, 이 인터페이스를 어떻게 테스트할 것인지 테스트 코드를 작성하라.
텍스트 파일을 읽어서 stdout에 출력하는데, 내용이 같은 라인이 두 번 출력되지 않게 하려면?
1번은 기초적인 문제여서 어렵지 않게 풀 수 있었고 2번 역시 파이썬으로 set을 써서 중복을 검사하도록 작성했는데, 여기서 더 발전된 문제가 나왔다.
인터뷰어 : 파일 크기가 커서 메모리에 다 읽어 들일 수 없다면 어떻게 하겠는가?
나 : 파일의 내용을 줄 별로 해시해서 set에 라인 넘버와 함께 저장해두었다가 (hash table인 셈이다), hash collision이 발생하면 라인 넘버를 꺼내서 검사하면 어떨까?
인터뷰어 : 만약에 파일의 모든 라인이 같은 내용이면 어떻게 되는가?
나 : (끙...) 그럼 O(n^2)이 되겠지. 그럼 Hbase 같은 distributed hashtable에 내용들을 다 저장해놓고 중복체크를 하면 어떨까?
인터뷰어 : 그럼 네트워크를 사용해야 해서 엄청 느릴 텐데?
이러다가 주어진 시간을 다 소모해서 세션이 끝났다. 주어진 질문에 대답을 못 하고 시간이 끝나니 왠지 찝찝했다. 지금 생각해보면 그냥 map-reduce 같은 거 써서 소팅하면 됐을 텐데 너무 어렵게 생각했던 것 같다.
아름다운 스톡홀름의 풍경이 보이는 Spotify 오피스.두 번째 시간은 시스템 디자인 인터뷰였다. 문제는 간단했다. 유저들의 재생 기록 데이터가 (user id, track id, duration, timestamp)와 같은 포맷으로 주어질 때 Spotify에서 재생 횟수 top 10 차트를 제공하려면 어떻게 해야 하는가?
Data pipeline 쪽 경험이 있다면 그리 어려운 질문은 아니다. 우선 데이터를 우리가 필요한 형태로 바꾸고 (필요없는 필드와 의미없는 데이터를 잘라내야 한다) distributed storage에 저장하면 되는데, 숫자 계산이 매우 중요하다. 하루에 얼마만큼의 play event가 발생하는지, unique 한 track 수는 어떻게 되는지에 따라 한 시스템에 저장할 수 있는 record의 양이 정해지고, 그에 따라 partition key가 달라지기 때문이다. 인터뷰를 시작할 때는 1 miilion records/day라고 가정했는데, 이걸 계산하고 나니까 1 biliion으로 바꾸면 어떻게 되냐?라는 추가 질문이 들어왔다. 특히 나는 모든 데이터를 time-range based partitioning으로 in-memory storage에 저장할 것이라고 가정했기 때문에 데이터가 늘어나면 이 서비스만을 위해 1000대의 physical machine + replica가 필요한 상황이 되어버렸다.
내가 좀 헤매고 있으니 인터뷰어가 partitioning scheme을 바꾸는 건 어떻겠냐는 조언을 해주었다. 옳다구나 하고 partition key를 track id로 바꾸니 많은 문제가 해결되었다. play 횟수만으로 top 10을 재는 것이기 때문에 (track id, play 수)와 같은 데이터가 분산된 환경에 저장되어 있다고 하더라도 각각의 머신 별로 재생 횟수 top 10에 해당하는 것만 max heap 형태로 메모리에 들고 있으면서 나머지는 디스크에 저장하면 엄청나게 많은 머신을 절약할 수 있다. 물론 이 방법에도 단점은 있었다. track id로 hash partitionioning 하는 건 장점도 있지만 단점도 있다. 특정 shard에 인기가 많은 트랙이 몰리면 해당 partition에 부하가 집중되게 되기 때문이다. 그럼 어떻게 할까? 그냥 replica를 만들어서 부하를 분산하면 된다. 여기까지 하니까 주어진 시간이 끝났다.
두 번째 시간이 끝나고 여기서 일하는 직원들과 같이 점심을 먹었다. 다른 회사들은 보통 점심시간 동안이라도 인터뷰와 관련 없는 사람들과 짝을 지어주는데, 여기서는 특이하게 점심 멤버들이 전부 오늘 보게 될/이미 본 인터뷰어들이었다. 하필 점심 메뉴도 뻑뻑한 스웨덴식 미트볼이었던 덕분에 추가 인터뷰를 보는 기분으로 소화 안 되는 점심을 꼭꼭 씹어 넘겼다.
점심 메뉴였던 스웨덴 전통식 미트볼, 매쉬드 포테이토, 감자와 고지 베리.세 번째 시간인 케이스 인터뷰는 조금 특이했다. 과거 Spotify에서 실제로 발생했던 문제 상황을 나에게 주고 그 당시 시스템 구조를 나에게 설명해준 다음, 이 문제를 디버깅한다면 어떻게 접근할 것인지 설명해보라고 했다.
나 : 음 이건 technical 한 원인과 non-technical 한 원인이 있을 수 있을 거 같다.
인터뷰어 : 네가 맘에 드는 걸로 추적해봐.
나 : 난 엔지니어니까 테크니컬 하게 가볼게. 이 대시보드를 만드는 배치 작업에 최근 커밋된 사항이 있어?
인터뷰어 : 몇 개월간은 없었어.
나 : 그럼 배치 쿼리 문제는 아니겠군. raw data 사이즈의 추이를 보면 어떨까?
인터뷰어 : raw data 사이즈를 어떻게 볼 건데?
나 : plaintext면 wc 쓰면 될 거 같은데, orc나 parquet이면 블라블라...
이런 대화를 한 시간 동안 이어가다 보니 결국 원인을 찾지 못한 채로 인터뷰가 끝이 났다. 근본적인 이유는 허탈할 정도로 간단했다. 실제 일을 하다 보면 사소한 실수나 가정의 오류에서 문제가 비롯되는 경우가 많은데 그런 케이스였다. 원인을 찾아내는 것 자체보다 문제를 해결하는 과정에서 내 추론 과정을 들여다보고 싶었던 것이 아닐까 한다.
마지막 시간은 컬처 인터뷰였다. 대략 이런 질문들을 받았다.
동료들과 어떻게 같이 일하는가?
어떻게 작업을 할당하고 작업자를 정하는가?
너는 팀에 어떻게 공헌하는가?
팀원들이 서로 코드 스타일이 안 맞으면 어떻게 하는가?
코드 스타일을 맞추기 위해 어떤 도구를 사용하는가?
개인적으로 열정을 가지고 있는 일이 있는가?
읽으시는 분들이 나의 답변이 굳이 궁금하진 않을 것 같다. 모범답안 정도로 적당히 대답하고 궁금한 것이 있냐고 해서 이런저런 것들을 물어보았다. 인상 깊었던 것은 Spotify에서는 모두가 하고 싶은 일을 할 수 있도록 장려한다는 이야기였다. 예를 들어서 10년간 서버를 개발하던 사람이 어느 날 안드로이드를 개발하고 싶다고 하면 보통은 안 된다고 할 텐데 여기서는 하게 해 준다고.
Spotify는 다양성(diversity)을 엄청나게 존중하는 회사라고 한다. 국적으로도 그렇고 - 내 인터뷰어들도 대부분 스웨덴 사람이 아닌 브라질, 아이슬란드, 네덜란드 등등 세계 여러 나라들에서 온 사람들이었다 - 하고 싶은 일을 하게 해주는 것도 이런 의도의 일부이고, 이런 노력들이 결국 회사에 도움이 될 거라 믿는다고. 어쨌거나 나도 외국에 나가서 일하게 되면 외국인의 입장에 서게 될 텐데 문화적 다양성을 존중해주는 회사 분위기에 많은 호감을 느꼈다. 스웨덴의 인구는 의외로 천만명밖에 되지 않고, 결국 인재들을 다른 나라에서 끌어와야 하는 입장이다 보니 전략적으로 이런 부분들을 강조하는 것 같기도 하다.
인터뷰를 마치고 회사를 구경했다. Spotify의 분위기는 구글과 비슷한 느낌의 자유분방 분위기의 오픈 오피스였고 점심과 간식을 무료로 제공하며, 특이하게도 CEO의 이름이 붙은 게이밍 룸도 있었다. 음악 서비스를 하는 회사답게 곳곳마다 독특한 인테리어들이 시선을 사로잡았다.
그렇게 반나절 간의 힘겨운 면접을 마치고 며칠간 스톡홀름을 구경했다.
와이프는 유럽 여행을 나보다 훨씬 많이 다녀본 사람인데도 불구하고 그 매력에 흠뻑 빠질 정도로 (와이프 말로는 유럽 중의 유럽이라고) 스톡홀름은 매력적이고 아름다우면서 한가한 도시였다. 아이슬란드에서도 느꼈지만 정말 북유럽 사람들은 키 크고 예쁘고 잘생겼는데 친절하기까지 하다. 다들 영어를 잘하는 지라 스웨덴어를 못하는 우리가 돌아다니는 데에도 전혀 지장이 없었다. 와이프는 스톡홀름의 길거리를 걸으며 감탄을 멈추지 않았다. 거리에 한 번, 사람에 한 번. 그러다가 문득 핸드폰을 들어 친구에게 "우리 다음 여행은 스톡홀름으로 오자"고 카톡을 보내다가. 나는 수상 버스를 타러 갔는데 매표소 직원이 연예인처럼 예뻐서 깜짝 놀랐다. (그렇습니다. 저희는 얼빠들입니다.)
너무 아름다웠던 스톡홀름의 여름.그렇게 한국으로 돌아간 지 일주일 정도 지나서 오퍼를 받았다.
