구글 인터뷰 후기

거의 1년만의 글인데, 근황에 대한 이야기를 쓸까 잠깐 생각했다가 어차피 요즘에는 페이스북에 근황 이야기는 많이 풀어놓고 있으니 별 필요가 없겠다는 생각이 들었다. 그리고 그 외의 근황을 생각해내서 적으려니 이건 뭐 오늘의 일기가 되겠다 싶어서 기각. 그럼 뭘 적을까, 하다가 벌써 반년 넘게 지나버린(...) 2013년 9월에 있었던 구글 온사이트 인터뷰 이야기라도 적어보면 어떨까 하는 생각이 들었다. 구글의 인터뷰는 어떤어떤 과정을 통해 이루어진다, 같은 이야기보다는 온사이트에 나왔던 문제와 내가 받았던 인상을 단편적으로 남겨본다. 혹시 구글에 인터뷰 볼 생각을 하고 있는 사람에게 참고가 된다면 좋겠고, 아니면 구글에서는 이런 인터뷰 질문이 나오는구나, 하고 넘어가시면 되겠다.

- 개요

온사이트 인터뷰는 (당연하지만) 구글 본사에서 이루어졌고 총 다섯 명과 인터뷰를 했으며, 각 인터뷰는 50여분 내외로 이루어졌으며 한 시간은 넘지 않았다. 나는 Python Engineer로 분류되어 인터뷰를 치러야 했다. Python에 대해 그리 깊게 알지도 못하는데!

구글에서 일하는 엔지니어 분들하고 얘기를 하면서 많이 들었던 말은, '운이 많이 작용한다'라는 것이었다. 그렇게 들었을 때에는 단순히 까다로운 알고리즘을 들고 나온다던가, 이상한(?) 사람이 인터뷰어로 등장한다던가 하는 것이라 생각했는데, 확실히 운이 많이 작용한다는 말이 맞는 듯 하다. 내 인터뷰의 경우 내가 영어도 잘 못하고(...) 무엇보다 Python 지식이 충분치 않았기 때문에 인터뷰가 잘 되기를 기대하는 것 자체가 무리이긴 했지만, 데이터 구조와 알고리즘을 잘 꿰고 있으면서 자기 분야의 지식(내 경우엔 Python)을 충실히 쌓은 상태라면 얼마든지 '잘 될 수도' 있다는 생각이 들었다. 그런 생각이 든 건 첫 라운드부터였다.

- Round 1

당연히 일반적인 알고리듬 문제가 나오리라 예상했던 첫 라운드에서는 굉장히 의외의 문제가 나왔다. 그것은 바로 Pivot Table 계산 알고리듬. 엑셀에 정통한 사람들은 당연히 Pivot Table 기능을 알겠지만, 아무리 프로그래머라고 하더라도 모든 비즈니스 어플리케이션에 정통할리가 없고 엑셀을 많이 쓰지 않는 사람의 경우에는 Pivot Table 자체를 모를 수도 있다. 인터뷰어가 스프레드시트가 그려진 종이를 들고 와서 Pivot Table을 아냐고 물어보길래 그렇다고 했더니 이거 설명할 1분을 절약했다며 좋아했다(...)

여튼 첫 질문은, 여러 컬럼이 있는 데이터가 있을 때 이를 컬럼별로 Grouping해서 count하는 로직을 어떻게 만드느냐였다. 처음에는 문제 자체에 당황해서 버벅거렸지만 이내 평정을 찾고, dictionary를 만들고 키를 컬럼명_indexnum 키 이름으로 만들어서 특정 컬럼 항목의 count를 계산하는 간단한 방법을 제시했다. 그리고 Grouping이 컬럼A, 컬럼B로 연속해서 이어질 경우, 컬럼A_0_컬럼B_0 같이 sub-level의 count를 먼저 계산한 다음 상위로 summarize 해서 계산하는 방법을 제시했다. 코딩을 요구하기에 간단한 python 코드도 구현해 보이면서, 최적화가 필요하다면 컬럼에 존재하는 값을 별도의 테이블에 인덱싱하고, 실제 count에 사용할 composite key는 테이블에 인덱싱 된 숫자값을 조합한 key를 사용하면 좀 더 효율적으로 계산할 수 있을 것이라고 대답했다.

... 이렇게까지 대답할 수 있었던 것은, 내가 다차원 데이터베이스(MDB)에 백그라운드가 있어서였다. 나는 Pivot Table이 실제로 어떻게 구현되어 있는지는 정확히 모르지만, MDB나 Pivot Table이나 aggregation을 빠르게 수행하기 위한 목적은 동일하고, 위에 적은 내용은 초창기의 MDB가 설계된 방식이기도 하다.

어쨌든 여기까지 얘기하고 보니 인터뷰어도 이런 엔지니어가 올지 예상 못한 듯(...) 다른 쪽으로 질문을 돌리기 시작했다. count가 아니라 value - sum, average, min, max 등을 구해야 할 때에는 어떻게 할거냐? : average를 제외하고는 count와 동일하지만, average의 경우 컬럼의 특성을 고려해야 한다. 예를 들어 날짜 컬럼의 경우 년-분기-월-일의 hierarchy에 따라 데이터를 조회하는 경우가 많은데, 이 경우 날짜의 각 부분요소를 별도의 컬럼으로 처리해 인덱싱하거나, 혹은 snowflake schema로 인덱싱할 수도 있다. 이 경우 processing power / storage의 tradeoff다. aggregation을 미리 해서 데이터를 저장해 두면 데이터가 마구 증가하는데 이건 어떻게 할거냐? : aggregation granularity를 적절히 지정하여, 쿼리가 빈번한 항목에 대해서 aggregation을 미리 해두면서 나머지는 cache에 맡길 수도 있겠다.

이런 식의 문답을 주고받으며 한 시간을 채우고 인터뷰가 끝났다. (바깥에 다음 인터뷰어가 와서 기다리고 있었다;;;) 인터뷰어가 딱히 준비해 온 질문에만 집중해서 인터뷰를 진행하는 것이 아니라, 지원자의 역량에 따라 유연하게 인터뷰를 진행한다는 인상을 받았다.

- Round 2

2 라운드에서는 약간 일반적인 질문이 나왔다. 트리에서 Preorder, Inorder, Postorder 방식으로 노드를 처리할 때 next node를 알아내는 알고리듬을 작성해 보라는 것이었다. 이는 그때 지겹게 풀어보던 알고리듬 책에서 이미 나왔던 문제였으므로(...) 어렵잖게 풀 수 있었다. 중간에 약간 착각한 부분이 있어 화이트보드에 작성하던 코드를 지우고 다시 작성했는데, 이 때 인터뷰어 표정이 좀 좋지 않았던 것이 기억난다. 가급적이면 한 번에 깔끔한 코드를 적어내는 것이 좋겠지만... 나는 일단 코드를 적어나가다가 뭔가 생각이 나면 기존 코드를 뒤엎고 다시 쓰는 편을 선호하는 사람이라 아직도 화이트보드 코딩에 적응을 못 하고 있다. 반성해야겠다.

코드를 neat하게 작성하는 방법에 대한 질문도 있었는데, 기억이 희미해서 이 부분은 적질 못하겠다. 전반적으로 무난하게 지나가긴 했다.

- Round 3

여기서부터 본격적으로 헤매기 시작했다. 생각나는대로 질문을 적자면:

- 자바에 비해 파이썬의 장점은? (저 파이썬도 깊게 모르고 자바는 잘 모르는데요...)

- 파이썬에서 바꾸고 싶은 부분이 있다면?

- ABCD / DCBA처럼 reverse된 string이 서로 동일한 string이라고 간주하고, 일정한 배열에 든 string의 unique count를 구하려면?

- 두 서버가 통신하면서 object를 주고 받아야 하는데, 어떻게 시스템을 설계하겠는가?

답을 어디부터 시작해야 할지 모르겠어서 헤매기 시작했다. 한국말로 얘기하라면 어떻게든 썰을 풀었겠지만, 뭔가 말을 생각해내는 것도 어려운 상황에 영어로 옮기기까지 하려니 그야말로 제 정신이 아니었다. Dynamic Language의 장점과 언어 자체의 간결함에 대해 몇 마디 주절거린 것 같긴 한데, 제대로 된 내용은 아니었다. 파이썬에서 바꾸고 싶은 부분에 대한 질문은, 문득 django model을 사용할 때 필드의 타입을 미리 체크해서 해당 객체의 프로퍼티에 값을 할당하는 시점에 잘못된 값을 넣으면 타입 예외를 일으키도록 하는 기능(말하자면 ad-hoc type checking logic)이 있었으면, 하는 생각이 퍼뜩 들어서 그걸 더듬더듬 이야기했다. 근데 나중에 생각해보니 그냥 __getattr__, __setattr__로 어떻게든 할 수 있는 부분이라는 것을 깨닫고 절망했다(...)

세 번째 질문은 갑자기 공황상태에 빠져서 뇌가 안 돌아가는 상황에 봉착. 인터뷰 끝나고 딱 나오는데 해시를 사용한 해결방법이 떠오르고 좀 있다가는 double linked list를 사용한 해결 방법이 떠올랐다. Aftermath (...)

마지막 질문 또한 대체 뭔 대답을 원하는지 모르겠어서 망함. JSON / SOAP 등을 얘기하고 https가 어쩌고 저쩌고 중언부언하다 끝나버렸다.

- Round 4

요약: 그냥 망함(...) 

질문은 이거 하나였다: 영화 데이터베이스가 있는데, 이 데이터베이스에 있는 항목들에 대한 번역 작업을 하기 위한 시스템을 구축하려 한다. 어떻게 하겠는가?

그냥 열린 질문(...) 처음에는 아예 질문 자체를 잘못 이해한데다가, 이야기를 하면 할 수록 데이터 입력 시스템에 대한 기획을 이야기하라는 것인지, 데이터 흐름을 설계하라는 것인지 갈피를 잡지 못하고 헤맸다. 사실 이 라운드에서는 내가 영어에 익숙지 못한 것이 가장 아쉬웠었다. 질문의 요지를 얼른 파악했으면 이야기를 좀 더 수월하게 끌고 나갈 수 있었을 터인데...

번역 데이터 입력 시스템에 대한 이야기를 할 때 구글 스프레드시트를 활용하면 어떻겠냐는 의견을 냈는데, 이 부분에 대해서 추가 질문이 계속 이어졌다. 하지만 역시 질문을 알아듣지 못해 계속 헤매는 사태가...

- Round 5

어째서인지 망함(...)

문제가 두 개였는데 하나는 생각이 안 나고(이건 풀었음) 다른 하나는 Knapsack problem이었다. 이 날 인터뷰 끝나고 나서 LA에 가기로 했었는데, LA로 자동차를 몰고 가다가 알고리듬이 생각이 나더라(...) 여튼 그 자리에서 풀지 못 해 망했다는 결론은 동일하다.

- 총평

3 라운드부터 멘탈 관리에 실패하고 아는 문제인데 왜 풀지를 못 하니 으허헝... 상태가 반복되었다. (4라운드 제외) 물론 인터뷰어가 제시한 질문에 대한 답을 했더라도, 그것만으로 좋은 점수가 나오는 구조는 분명 아닌 듯 하다. 일단 답을 했다면, 틀린 답이든 옳은 답이든 계속해서 심화된 질문을 던지고, 그에 대한 반응을 계속해서 살펴보면서 주관적인 점수를 매기는 방식에 가깝지 않나 싶다.

또한, 내게 할당된 인터뷰어가 다들 그런 사람들이었는지는 몰라도, 커뮤니케이션에서 굉장히 인내심을 가지고 무척 친절히 대해준다는 인상을 받았다. 다른 회사의 인터뷰에서는 의사소통에서 오는 스트레스가 너무 커서 인터뷰 문제에 집중을 못 하는 사태가 자주 벌어졌는데, 구글에서만큼은 그 스트레스가 확실히 적었다. 그냥 망했다고밖에 할 수 없는 4 라운드에서조차도, 인터뷰어의 인내심에 고마움을 느낄 정도였다.

준비된 질문이 계속 나오는 것이 아니라, 뭔가 답을 내놓으면 그에 따른 질문이 계속 이어지는 방식이라 무척 힘들게 느껴지기는 했지만, 내가 겪은 여러 인터뷰 중 손에 꼽을 수 있을 정도로 재미있는 인터뷰였다. 이런 인터뷰라면 몇 번이라도 하겠다 싶을 정도로.

- 결과

결과는, 떨어졌다. 

어느 정도 예상은 하고 있었지만 덕분에 몇 달간 정신적 공황 상태를 겪어야 했다(...)

이상.