2016년 1월 14일 목요일

구글 인터뷰 팁


오래전에 구글+에 올렸던 글을 옮겨왔다.

구글에 소프트웨어 엔지니어로 지원하려는 사람들을 위해 몇 가지 팁을 적어본다. 이 글은 구글의 공식적인 의견이 아니고 개인적인 경험을 바탕으로 대학 후배에게 얘기한다는 마음으로 적은 글이다. 누구에게나 적용하기 힘든 개인적인 경험도 있고 손발이 오글거리는 표현도 많이 있지만 그게 나의 솔직한 이야기이니 너그러이 이해해 주기를 바란다. 참고로 나는 구글에 입사하여 150회 정도의 엔지니어 후보자를 면접했고 채용위원회에서도 활동했다.


도전 - 구글 면접 자체로 배울 것이 있다

내가 구글에 입사하기 위해 도전할 때를 추억해보면 면접후의 나는 면접 보기전의 나와 다른 사람이었다. 면접 과정에서 한계에 부딪혔고 그 한계 너머의 세상을 경험했고 컴퓨터 공학 문제를 푸는 방법에는 더 높은 단계가 있다는 것을 깨달았다. 면접이 끝나고 나서 세상을 향해 자신감이 붙었다고 할까.

내가 구글에 지원할 때 합격하리라는 믿음은 없었다. 지방국립대를 (정말로) 간신히 졸업하고 대기업 근처에도 가보지 못해 이력서에 눈에 띄는 내용이 없었기 때문이었다. 한국에 구글 R&D센터가 들어오기 전이라 면접을 영어로 볼텐데 그럴 실력도 없었다. 영어점수가 없어 대기업 근처에도 못 갔고. 오히려 불가능해 보였기 때문에 도전을 했다. 반지하 월세방에서 어린 아이들 셋을 두고 구글에 면접을 보려고 회사에는 퇴사를 알렸다. 그러니 형편으로 봐도 무모한 도전이었다.

구글 면접을 어떻게 준비해야 하는지도 모른채 도전을 했고 레쥬메를 내고 합격통지를 받기까지 4개월동안 최선을 다했다. 마지막 면접을 보고 지하철 역으로 향하며 아내에게 전화를 걸었다. “이제 다 끝났어. 난 이제 떨어져도 아쉬운게 없어.” 정말 한 단계 성장했다는 느낌을 받았다. 하루종일 긴장하고 면접을 치러서 어지러웠지만 세상 어디에 떨어져도 다 먹어치울 수 있을 것 같은 느낌이 들었다.

소프트웨어 엔지니어라면 구글에 도전해 보기를 권한다. 떨어지더라도 짧은 시간에 많은 것을 배울 수 있는 기회다. 구글 면접에서 세 번이나 떨어진 어떤 사람은 구글의 면접은 현대의 소크라테스에게 가르침을 받는 시간이라고 말한다.

전화 인터뷰 팁 - 자신에게 가장 유리한 시간대로 고른다

일반적으로 본면접을 보기전에 전화로 기술 면접을 치른다. 전화상으로 45분 정도 기술 면접을 보는데 대면 면접과 비슷한 수준의 문제를 푼다. 전화를 들고 구글 닥스Google Docs에다가 코딩도 시킨다. 얼굴도 보지 않고 전화로 기술면접을 보는 것은 상당한 부담이다. 그리고 영어다. 따라서 전화 인터뷰 전에 준비를 잘 하는 것이 중요하다.

준비의 첫번째는 면접 시간이다. 면접시간을 조정하는 리쿠르터에게 자기가 원하는 시간을 정확히 알려주자. 하루 중 컨디션이 최상이 되는 시간대 그리고 다른 일 때문에 방해를 받지 않는 시간대를 골라야 한다. 구글의 면접관과 채용담당자가 지구 반대편에 살고 있을 수도 있어서 실수로 면접 시간이 면접 후보자에게는 새벽이 되는 경우도 있다. 바꿔줄 것을 반드시 요구해야 한다. 면접 과정은 후보자의 최상을 보려는 것이기 때문이다.

전화 인터뷰 팁 - 준비를 하면 좋은 것들

전화는 스피커 폰 기능이 동작하는 지 확인하자. 헤드셋이 있으면 편하다. 적어도 1시간 동안은 방해받지 않도록 준비하는 것이 좋겠다. 면접 중에 전화가 끊기거나 누가 방해를 하면 곤란하니까.

연습장과 연필을 준비하자. 종종 종이에 계산을 하거나 메모를 할 일이 있다. 면접관의 이름을 메모하기도 한다. 가령 면접관이 처음 소개할 때 밝혔던 부서를 메모해 두었다가 나중에 관련된 질문을 할 수도 있겠다. 예를 들어, 검색팀에 계시다고 했는데 요즘 가장 어려운 문제는 무엇인가를 물어볼 수도 있다.

인터넷과 구글닥스가 잘 동작하는지 확인하자. 코딩을 구글 닥스에 시킨다. 인터넷 브라우저도 확인해 두는 것이 좋다. 면접 시간이 되기 전에 리쿠르터가 구글 닥스 링크를 보내준다. 면접 시간에 면접관도 해당 구글 닥스 문서에서 함께 작업을 진행한다.

문제 유형과 요령

코딩, 알고리듬, 시스템 설계 등을 주로 물어본다. 박사 졸업자의 경우는 졸업 논문에 대해서 묻기도 한다. 대체로 실제로 현업에서 발생하는 내용을 토대로 물어본다.

코딩은 보통 15분에서 20분 사이에 풀 수 있는 간단한 문제들이 많다. 구글 면접 문제로 잘 알려진 atoi함수 구현이나 문자열 뒤집기 등의 문제는 쉬운편이다. 물론 이런 잘 알려진 문제는 더 이상 묻지 않는다. 쉬운 코딩 문제를 내지만 대부분의 후보자들은 통과하지 못한다. 코딩은 누구나 하지만 제대로 코드를 작성하는 것은 쉽지 않다. 더욱이 인터넷도 없고 비주얼 스튜디오도 없이 칠판에 코드를 짜는 것이 상당히 부담스럽다. 평소에 칠판이나 종이에 연습을 많이 해두어야 한다.

코딩 문제가 나올때 바로 구현으로 들어가는 것은 좋지 않다. 먼저 요구사항을 제대로 밝히는 것이 중요하다. 나는 일부러 중요한 사항을 빠뜨리고 문제를 내기도 한다. 예를 들어, 입력 데이터의 타입이나 중요한 예외 케이스corner case등을 일부러 누락한다. 바로 구현으로 들어가면 반드시 나중에 문제가 생긴다. 요구사항을 점검하고 간단하게라도 어떤 식으로 구현할지 설명하는 것이 좋다. 그렇다고 여기에 너무 많은 시간을 쏟지는 말고.

구현이 끝나면 반드시 검증을 하자. 요구사항 분석시 사용한 예제나 예외 케이스를 가지고 코드를 한줄 한줄 진행하면서 논리적으로 잘못된 부분이나 문법의 오류를 스스로 찾도록 한다. 평소에 엔지니어들은 코드의 작성보다는 버그를 수정하고 코드를 향상시키는 데에 더 많은 시간과 노력을 쏟는다. 따라서, 면접과정에서도 스스로 버그를 찾고 코드를 향상시키는 노력을 보여주는 것이 좋을 것이다.

정리하면 (1) 요구사항 분석 -> (2) 구현 -> (3) 검증 및 향상의 3단계를 거치는 것이 좋겠다.

알고리듬은 주어진 컴퓨터공학 문제를 어떻게 풀지 물어본다. 주로 많은 데이터에서 주어진 값을 찾는 가장 빠른 방법을 물어본다. 처음에 간단하게 시작해서 데이터의 규모가 커진다거나 컴퓨터 시스템의 한계를 설정하는 방식으로 심화하기도 한다. 알고리듬 문제에서 중요한 것은 다양한 접근 방식의 장단점을 구체적으로 얘기할 수 있어야 한다. 예를 들어, 문제의 조건에 따라 퀵 정렬보다 병합 정렬이 더 효과적이라고 말할 수도 있는데 이때 왜 그런지 설명하는 것이 좋다. 입력 데이터가 메모리의 용량보다 커서 랜덤 액세스가 필요한 퀵 정렬이 비효율적이라든지 말이다. 계산 복잡도와 공간 복잡도를 공학적 표기법(대문자 O 표기법 등)으로 설명하는 것도 있지 말자. 알고리듬 문제에서 코딩 문제로 발전하기도 하니 미리 코딩 연습을 하는 것이 도움이 될 것이다.

시스템 설계에서는 구글에서 제공하는 서비스를 설계해 보라고 하기도 하고 상상의 제품을 만들어 보라고도 한다. 구글에서 하는 대부분의 작업은 모두 병렬처리 또는 분산 시스템에 대한 것이다. 따라서 분산 시스템에 대해서 공부해 두면 도움이 될 것이다. 구글 검색의 성공을 뒷받침했던 구글 파일 시스템GFS과 맵리듀스MapReduce에 대한 논문을 한번쯤 읽어보는 것도 좋겠다.

구글 파일 시스템에 대한 논문:
http://research.google.com/archive/gfs.html

대규모 병렬 처리 프레임워크 맵리듀스에 대한 논문:
http://research.google.com/archive/mapreduce.html

면접관들의 문제 출제 유형

면접관들의 면접유형에는 크게 두가지가 있다. 가능한 넓은 영역을 두드려서 후보자의 컴퓨터 공학 지식과 경험을 전반적으로 평가하는 진단 평가 유형과 좀 더 복잡한 공학 문제를 물어서 후보자의 지식과 경험을 깊이 평가하는 심화 평가 유형이다. 면접관들의 성향에 달려있기는 하지만 시스템 관리자, 웹마스터 등은 진단 평가를 사용하고 소프트웨어 엔지니어는 심화 평가 유형을 주로 사용한다. 때로는 한 면접 세션에서 진단 평가와 심화 평가가 동시에 이루어지기도 한다.

심화 평가라면 한 세션에 보통 두 문제 정도를 푼다. 45분 면접의 시작시 소개와 종료직전의 자유질문 시간을 빼면 한 문제당 15분에서 20분 정도를 사용한다고 생각하자. 이걸 반대로 생각하면 문제가 아무리 어려워 보여도 15분내에 풀 수 있는 간단한 문제이니 지레 겁먹지 않아도 된다는 얘기다. 물론 어려운 문제는 한 세션에서 한 문제만 푸는 경우도 있다.  

단순 지식을 묻는 문제가 아닌데 3문제까지 왔다면 둘 중 하나다. 평균을 크게 웃도는 실력을 가진 후보이거나 가망이 별로 없는 후보다. 나는 보통 처음에 쉬운 문제를 낸다. 몸풀기 문제인 것이다. 몸풀기를 마치면 본격적으로 어려운 문제를 낸다. 어려운 문제를 잘 푸는 경우 더 어려운 문제로 옮겨간다. 드문 실력자다. 개중에는 첫 번째 문제에서 헤매는 사람이 있다. 이때는 더 쉬운 문제를 내거나 분야를 바꿔서 문제를 낸다. 후보자의 가능성을 찾는 것이다. 하지만 대개 가망이 별로 없다.

때로는 처음부터 어려운 문제로 몰아치는 경우도 있다. 레쥬메를 읽을때 또는 면접 초기에 감이 오는 경우다. 이 친구 정말 실력자라는 느낌이 오면 어려운 문제를 내면서 후보자의 약점을 찾으려고 한다. 이렇게 하는 이유는 수준 높은 후보자를 그 수준에 맞는 잣대로 평가하려는 것도 있지만 면접관이 혹시 가질 수 있는 선입견을 스스로 견제하기 위해서다.

문제 풀이 과정이 중요하다

기술 면접에서 중요한 것은 정답을 만들어내는 것이 아니라 문제를 해결하는 방식이다. 실세계의 공학문제는 정답이 없는 경우가 많다. 실세계 시스템은 복잡하고 요구사항이 상충하기 때문이다. 따라서, 항상 상충점trade-off을 고민하는 것이 공학이다.

아폴로 착륙선의 다리를 설계할 때도 상충점에 대한 고민을 했다고 한다. 다리를 세개로 하면 무게를 줄일 수 있지만 안전하지 않았고 다섯개로 하면 가장 안전하지만 너무 무거워졌기 때문에 다리를 네개로 정했다고 한다. 이걸 비공학도들에게 얘기하면 당연히 다리 네개가 제일 좋은 것 아니냐고 핀잔을 듣는다. 하지만 공학도들은 사람들이 당연하게 생각하는 문제의 원리를 풀어내야 한다. 

컴퓨터공학도 마찬가지다. 혹 틀린 답을 도출할지라도 답이 나오는 과정에서 요구사항의 우선순위가 무엇이었는지, 가능한 옵션들은 어떤 것들이 있었는지, 어떤 상충점을 고려했는지, 결과를 어떻게 검증할 수 있는지 얘기할 수 있어야 한다. 문제 풀이 과정과 검증 방법을 아는 사람이 문제를 정말로 풀 수 있는 사람이다. 결국 문제풀이 과정이 정답보다 중요하다.

따라서, 기술 면접에서 문제 풀이 과정을 보여주는 것이 중요하다. 

반복iteration과 대화interaction다

문제를 풀 때 쉬운 풀이 방법으로부터 차근차근 반복하면서 향상시키는 것이 좋다. 코드를 작성하는 경우라면 알고리듬은 비효율적이지만 구현하기 쉬운 방법으로 빨리 코드를 완성하고 개선해 나가는 것이 좋다. 아무리 좋은 알고리듬을 썼더라도 코드를 완성하지 못했다면 인정을 받기는 힘들다. 많은 후보자들이 최적의 구현방법을 고민하는 데 시간을 너무 많이 쓰고 정작 코드를 완성하지 못한다.

머리로 생각하는 것과 실제로 구현하는 것에는 간극이 있다. 이 간극은 실제로 코드를 쓸 때 드러난다. 따라서 우아하지(?) 않더라도 동작하는 코드를 작성하고 문제를 발견한 다음에 반복적으로 향상하는 것이 전략이다. 물론, 초절정 고수는 일필휘지로 단방에 최고의 코드를 써내리는 경우도 있지만...

면접관과 대화를 하면서 문제를 푸는 것도 중요하다. 면접관을 동료라고 생각하고 문제풀이를 짝 프로그래밍pair programming으로 생각하자. 면접관의 질문을 확인하고 부족한 부분을 점검하고 코드를 어떻게 작성할지 대강의 플로우flow를 얘기하자. 코드를 작성하면서 본인이 어떻게 생각하고 있는지 말로 표현하면서 써내려 가는 것이 좋다. 때로 잘 못된 방향으로 가는 경우 면접관이 가이드를 해 줄 수도 있다.

통역관을 요청할 수 있다

영어에 정말 자신이 없으면 통역관을 요청할 수 있다. 보통은 엔지니어가 통역을 한다. 컴퓨터공학 용어나 기술 설명은 비엔지니어가 통역하기는 힘들기 때문에.

참고로 나는 영어를 잘 못했지만 일부러 통역없이 면접을 봤다. 비엔지니어가 통역을 하리라고 생각했고(당시에는 실제로도 그랬다) 대면 면접에서 부족하더라도 중간에 끼는 사람 없이 정면으로 부딪히겠다는 각오를 했기 때문이다. 결과를 놓고 보면 나는 이런 배포 때문에 득을 보았다. 하지만 다른 사람에게 적용되는 방식은 아니라고 본다.

엔지니어는 영어 능력 테스트가 아니니 자신이 없으면 통역관을 요청하자.

면접관들이 잘 묻지 않는 질문

“앞으로 10년후 자신에 대해서 이야기보세요.”나 “구글에서 어떤 일을 하고 싶으세요?” 같은 질문은 잘 하지 않는다. 후보자들은 열이면 열명 모두 알흠다운 답변을 한다. 이런 질문을 통해 후보자의 진면목을 알 수도 없고 변별력도 없다는 뜻이다. 혹시 이런 질문이 나오면 그건 분위기 조성용이라고 보자.

엔지니어 면접에서 미국에 주유소가 몇개 있느니 골프공의 홈은 몇개 있으니 같은 질문은 묻지 않는다. 이런 질문은 전문 용어(?)로 돈오 질문Aha questions이다. 번뜩하는 재치를 평가할 수는 있겠지만 좋은 엔지니어인지를 드러내는 평가로 보기는 힘들다. 좋은 엔지니어는 오랜 시간 점진적인 노력을 통해 만들어진다. 돈오보다는 점수의 질문이 좋다.

연락이 오지 않으면 적극적으로 문의하자

구글의 채용 시스템은 완벽하지 않다. 전세계에서 일주일에 수만명의 후보가 지원하기 때문에 간혹 채용절차의 중간에서 누락되거나 실수로 문제가 발생하는 경우가 종종 있다. 지원하는 사람은 리쿠르터 한 사람과 1:1로 연락한다고 생각하지만 리쿠르터는 엄청난 숫자의 후보자를 다룬다.

이런 경우도 있었다. 내가 추천했던 어떤 후보자는 처음 지원했을 때 쓰던 이메일 주소가 아닌 다른 이메일 주소로 리쿠르터에게 연락을 취했다가 응답을 받지 못하고 단단히 화를 낸 적이 있다. 그는 그의 이름과 내용으로 해당 리쿠르터가 충분히 응대를 하기를 기대했던 것이다. 그런데 리쿠르터의 시스템은 이메일 주소를 기준으로 관리가 되었기 때문에 확인이 어려웠던 것이다. 이건 드문 경우인데 이외에도 중간에 문제가 발생할 수가 있다.

궁금하거나 문제가 있을 때 무한정 기다리지 말고 적극적으로 물어보자. 물어보는 것은 흠이 아니다.   

면접관들이 싫어하는 말

@ 나를 뭘로 보고 코딩을 시키나요? 코딩에서 손 뗀지 오래되었어요.
소프트웨어 엔지니어로 지원하는 경력자가 이런 얘기를 하는 경우가 있다. 자신은 소프트웨어 아키텍트로 코더들을 관리하는 역할을 오래 해왔다면서. 이런 말이 엔지니어인 나의 자존심을 건드린다. 코딩을 하급 노동이나 잡일로 취급한다는 인상을 받기 때문이다. 그렇다면 소프트웨어 엔지니어 직책에는 어울리지 않다. 더 나아가 소프트웨어 기업에서 일하기에는 부적합하다고 생각한다.

작가가 글쓰기를 잡일로 보고 연설가를 말하는 것을 잡일로 보고 육상선수가 달리기를 잡일로 볼까. 소프트웨어 제품을 움직이는 것은 소프트웨어 코드다. 기획도 중요하고 설계도 중요하다. 그러나 제대로된 코딩없이는 죽은 자식 불알 만지기일 뿐. 

@ 구글 제품들은 최고입니다.
고마운 얘기다. 그런데 면접관들은 구글 제품의 문제점에 대해 더 관심이 있다. 구글이 나아가는 방향이 어떻게 잘못되었는지 논리적으로 설득할 수 있는 사람에게 관심이 있다. 앞 문장에서 논리라는 단어에 밑줄을 긋자.

가끔 면접관들이 혹시 구글 제품의 문제점에 대해서 묻는다면 지적할 내용에 대해서 미리 생각해두는 것도 좋겠다. 

@ 학교에서 배우지 않은 내용입니다.
차라리 그냥 모른다고 얘기하는 것이 나을 것이다. 학교 망신은 주지 않을테니까. 기술 면접에서 물어보는 내용은 소프트웨어 엔지니어의 기본 소양이라고 본다. 배우지 않아서 모르겠습니다라는 말은 실제로 그럴지라도 가슴에만 담아두자.

@ 제가 인터뷰 잘 보았나요?
물어봐도 면접관들이 말해주기는 힘들다. 

땡큐 인사를 따로 보낼 필요는 없다

가끔 면접관의 이메일 주소를 알려달라는 경우가 있다. 나중에 땡큐 인사를 보내기 위해서. 솔직히 나는 별로다. 나는 면접관으로서 합격과 불합격을 좌우할 수 있다. 이건 후보자에게는 생사여탈로 비춰질 수 있기 때문에 상당한 부담이다. 후보자에게 내 연락처를 준다는 것, 그리고 땡큐 인사를 받는다는 것은 객관적 결과에 혹시 영향이 있을 수 있으므로 달갑지 않다.

땡큐 메일은 가능한 한 보지 않으려고 한다. 나도 사람인지라 다른 후보자들과 공평하게 평가해야 하는 순간에 흔들릴 수 있기 때문이다.

자기 소개는 짧게

자기소개에 에너지를 쏟지 말자. 면접관들은 후보자의 레쥬메를 읽고 들어온다. 후보자의 자기소개가 크게 필요하지 않다. 진짜 궁금하면 구체적인 사항을 물어본다. 3문장 정도로 요약하여 나는 현재 무슨일을 하고 주로 어떤 분야에서 일을 했는지 이야기하면 된다. 자랑할 만한 것이 있으면 키워드와 숫자로 주의를 끌도록 한다. 예를 들어, 나는 1970년대에 데니스 리치와 함께 유닉스를 만든 켄 톰슨입니다. 팍. 끝.

마지막 팁

내가 구글에 지원했을 때 이런걸 알려주는 사람이 주위에 없었다. 레쥬메를 어떻게 쓰는지도 몰랐으니까. 막막하게 준비하던 그때의 답답함을 나는 잘 안다. 그래서 이 글을 적었다.

나의 마지막 인터뷰 팁은, 팁은 팁일뿐 규칙이 아니라는 것이다. 조금씩 세상을 알게 될수록 세상이 교과서대로 움직이는 것이 아니라는 것을 깨닫는다. 나는 오랜 시간 경험했던 것을 바탕으로 조언을 하지만 여러분이 부딪힐 세상은 내가 경험한 세상과는 다르다. 내가 틀릴 수 있다.

나는 자기소개는 짧게 하라고 조언했지만 내가 구글에 지원할 때는 자기소개를 정말 열심히 준비했다. 파워포인트의 품질이 맘에 들지 않아 생전 처음 맥북을 구입해서 애플 키노트 프로그램으로 자기소개 프리젠테이션 자료를 만들었다. 친한 직장 동료에게 돈까스를 사며 식당에서 영어로 자기소개 프리젠테이션도 했다. 그러나 실제 면접에서는 자기소개를 할 시간이 주어지지 않았다. 그런데 외국에서 온 한 면접관이 서울의 교통체증 때문에 면접시간에 빠듯하게 도착했다. 미리 내 레주메를 확인하지 못해 당황해하는 것을 눈치채고 인터뷰 시간에서 딱 5분만 주면 내 소개를 하겠다고 했다. 나는 내 인생 최고의 프로젝트 3가지에 대해 이야기했다. 각 프로젝트마다 무슨 프로젝트였으며 문제점이 무엇이었으며 어떻게 해결했는지 3단계로 적었다. 마지막에 진짜 최고의 프로젝트는 가족이라며 세 아이와 아내를 팔았다. 3+1. 팍. 끝.

5분의 자기소개가 내 입사에 어떤 영향을 미쳤는지 지금도 알지 못한다. 그렇지만 결론은 구글에 입사했다. 내가 강조하고 싶은 것은 다른 사람들의 조언을 완전히 무시해야 할 때도 있다는 것이다. 세상은 교과서대로 움직이지 않고 내 조언도 그저 조언일뿐 당신이 경험할 세상은 나도 잘 모르기 때문이다. 그 배의 선장은 당신이다. (아... 오그라든다.)

면접관으로서 새로운 것을 배우게 되는 면접이 있다. 면접관을 한단계 성숙하게 만드는 후보자가 있다. 문제는 면접관이 내지만 후보자가 동료로서 문제풀이 여행을 함께 떠나는 면접이 있다. 나는 면접관으로서 이런 면접을 기다린다.

구글 인터뷰 팁은 이 정도다.