저는 지난 2014년 겨울~2015년 봄 동안 미국에서 소프트웨어 엔지니어 포지션으로 잡서치 기간을 가졌습니다. 그리고 마운틴뷰의 구글 본사에서 2015년 가을부터 일하게 되었습니다. 구직을 준비하는 과정에서 여러 선배분들의 조언과 블로그 글에서 큰 도움을 받아서 저도 조금이나마 다른분들께 도움이 될까 하는 마음으로 글을 씁니다. 아마 다른 글들과 중복되는 부분도 많을 것 같습니다. 어디까지나 개인적인 후기이니 참고만 해주세요.
배경
구직 당시에 저는 미국에서 소프트웨어 공학 박사과정 5년차였고, 2015년 5월 졸업을 예정에 두고 있었습니다. 대략 박사 3년차 정도부터 이미 졸업 후에는 미국 IT업계에서 소프트웨어 엔지니어로 일해야겠다고 마음을 먹고 있었습니다.
잡서치 스케쥴
잡서치 기간에 뭘 했는지 대략 정리해보면,
- 2014/08: 코딩 인터뷰 공부 시작 (알고리즘/데이터구조 공부, 문제풀이 등)
- 2014/11: 레쥬메 준비
- 2014/11하순: 리크루터 혹은 회사 다니고 있는 지인들에게 연락 해보기 시작
- 2014/12중순-2015/01중순: 실제 가장 많이 어플라이 한 기간
- 2015/02하순-2015/03초순: 온사이트 인터뷰 기간
- 2015/03중순경: 여러 회사에서 최종 합격 여부 통보 받음
- 2015/03/20: 최종 결정해서 각 회사에 알림
이정도가 됩니다. 어떤 경로로든 입사 지원을 처음 하고 나서 기술 인터뷰까지 가는 데 기간이 몇달씩 걸리기도 하기 때문에 미리 컨택할 수록 좋은 것 같습니다. 지원을 좀 일찍 했다고 인터뷰를 반드시 빨리 해야한다거나 하지는 않고, 인터뷰 일정은 지원자 상황에 회사가 많이 맞춰주는 편입니다. 경험상 “아직 인터뷰 준비를 좀 더 하고 싶으니 기다려달라” 하면 기다려주고, “다른회사 리크루팅 프로세스가 이미 많이 진행됐는데 최대한 expedite 해달라” 하면 어떻게든 해주기도 합니다. 최종 오퍼가 오고 나서는 어느정도 기간 안에 결정을 내려서 알려줘야 합니다. 이 기간을 잘 맞추려면 온사이트 인터뷰들을 최대한 몰아서 (대략 2주정도 범위?) 하는게 좋습니다. 온사이트 일정을 잘 조율하려면 최대한 일찍 원하는 회사들의 리크루팅 프로세스가 시작되도록 해야 합니다. 또 다른 이슈로는 인터뷰를 보는 순서가 있는데, 이왕이면 가고 싶은 회사 인터뷰를 뒤로 미루는게 앞쪽에서 인터뷰 연습도 할 겸 좋을거라고 생각을 했습니다. 그런데 준비하다보면 이 일정이 꼭 마음대로 되지가 않습니다. 제 경우는 막상 가고 싶은 회사들 리크루팅 프로세스가 먼저 시작되어 버려서 제일 가고 싶었던 구글에서 처음으로 인터뷰를 하게 되었습니다.
2월말 ~ 3월초까지 온사이트 인터뷰들을 봤는데, 이 시기가 그 해에 바로 H1-B 비자를 지원해볼 수 있는 최후의 마지노선이었던 것 같습니다. 보통 온사이트 한 이후로 최소 1~2주는 지나야 합격 여부를 알게 되고, 제가 오퍼 받은 회사들은 모두 H1-B 지원을 하려면 3월 20일까지 최종 결정을 해서 알려달라고 했습니다. 좀 더 규모가 작은 다른 회사들은 더 일찍부터 시작해야 되는 경우도 있었습니다. 참고로 저는 조금 일찍 구직을 시작한 편인데요, F1 OPT 도 있긴 하지만 H1-B 지원도 같이 하고 싶었기 때문입니다. OPT 나 다른 work authorization 이 있어서 무리해서 H1-B 를 지원하지 않아도 된다면 더 늦게 구직을 해도 될 것 같습니다. 다만, 저의 경우 잡서치가 빨리 끝났기 때문에 박사 졸업/디펜스 준비에 올인할 수 있어서 좋았습니다. 졸업 이후에 구직을 하게 되면 미래가 불확실해져서 불안할 수 있고, OPT 규정상 최대 unemployed 기간이 정해져있어서 문제가 될 수 있는 점도 참고하세요.
입사 지원
지원 회사
지원한 회사들은 미국내 유명 소프트웨어 기업들 위주로 지원했고 (대부분 Bay Area / Seattle), 모두 15군데 지원했습니다. 총 9곳에서 연락을 받았고, 이들 중 구글, F사, P사 에서 공식 오퍼 레터를 받았습니다. 연락 온 6개의 다른 회사들 중 한 곳은 프로세스 도중 전화면접에서 떨어졌습니다. 2곳에서는 이미 제가 최종 결정을 내린 후에 연락이 와서 프로세스를 진행시키지 않았습니다. G,F,P사 오퍼 레터를 받을 당시 프로세스가 진행중이던 나머지 3개의 회사에는 프로세스를 중지해달라고 요청했습니다. 지원한지 2달 이상 걸려서 연락 오는 경우도 있었습니다. 다시 한 번 말씀드리지만 미리미리 지원하는 것이 좋습니다.
이력서 (Resume / CV)
저는 연구 포지션도 아닌 순수 소프트웨어 엔지니어링 포지션에만 관심이 있어서, 레쥬메에서 연구 관련된 내용은 많이 쳐내고 1장으로 어떻게든 압축을 해 냈습니다. 레쥬메 내용은 가능하면 테크니컬 스킬을 강조할 수 있는 방향으로 가닥을 잡고, 이 샘플을 많이 참고하여 작성했습니다. 저는 커버레터 작성은 딱 A사 한 군데만 했고, 나머지 회사들은 커버레터 없이 지원했습니다.
지원 방법
지원하는 방법은 다양합니다. 경험적으로 가장 확률이 높은건 내부 지인의 추천을 통해서 지원하는 방법입니다. 처음 연락이 오기까지의 허들이 높은 편이고, 일단 연락이 오고 나면 그 때부터는 꽤 빨리빨리 진행이 되었습니다. 제 경우 특이하게도 오퍼 받은 3군데 회사에 지원한 방법이 다 다릅니다 (G: 내부인 추천, F: 리크루터에게 직접 이메일, P: 학교에서 Tech Talk 할 때 레쥬메 제출). 상황에 따라 다양한 방법으로 지원하시면 됩니다. O사의 경우, 학교의 취업 사이트를 통해서 간단히 지원했는데, 아무 소식 없다가 한달 반정도 후에 갑자기 온사이트 인터뷰를 하자는 연락이 왔습니다.
코딩 인터뷰 준비
제 경우는 박사 3년차부터 졸업 후에는 software industry 에서 일하겠다고 마음을 먹은 상태여서 비교적 일찍 준비를 시작할 수 있었습니다. 2014년 가을학기 시작하면서 부터 코딩 인터뷰 준비를 했고, 이에 관해 좀 자세히 설명해보려 합니다. 그에 앞서, 대부분의 소프트웨어 회사에서 사용하는 화이트보드 코딩 인터뷰가 왜 어려운지에 대한 제 의견을 먼저 공유합니다.
코딩 인터뷰가 어려운 이유
- 코드 편집이 어렵습니다. 일반적인 에디터 환경이라면, 있는 코드 중간에 새 코드를 끼워넣거나 copy & paste 해서 고치는 경우가 흔합니다. 하지만 화이트보드에서는 이런 단순한 편집도 굉장히 귀찮고 까다로워 집니다.
- IDE 지원이 없습니다. 화이트보드 코딩을 하면 IDE 의 도움을 받을 수 없게 됩니다. Syntax highlighting, refactoring, compiler, debugger 등의 지원이 갑자기 없어지면 엄청 불편해집니다.
- 설명을 병행하면서 코딩해야 합니다. 코딩 인터뷰중에는 내가 어떤 생각을 통해서 이런 코드를 짜고 있는지, 자신의 thought process 를 명확히 밝히면서 코딩을 해줘야 합니다. 그런데 코딩을 하면서 말로 (잘 안되는 영어로…) 설명을 병행하면 코딩에 온전히 집중하기가 어렵습니다. 평소에 그냥 혼자서 코딩하면 쉽게 금방 할 것을 버벅이면서 잘 못하게 되거나 실수를 하는 경우가 생깁니다.
폰 인터뷰는 보통 온라인 코드 에디터를 사용하게 되기 때문에 1번 문제는 없지만, 2, 3번 문제는 동일합니다.
본격적인 코딩 인터뷰 준비
저는 위에서 언급한 코딩 인터뷰의 특수성을 염두에 두고 준비를 했습니다. 졸업 준비와 병행하며 해야 했기 때문에 그냥 짬짬이 시간을 내서 특히 주말에 많이 준비했습니다. 프로그래밍 언어를 하나 딱 정해두고 준비하는게 좋은데, 저는 박사과정 내내 주력으로 사용한 Java 를 선택했습니다. 우선 dynamic programming, tree algorithms, dfs/bfs 등을 가볍게 리뷰한 후, 다음의 3가지를 중점적으로 준비했습니다.
LeetCode 의 장점은 일단 자체 코드 에디터(IDE 기능들은 없고 syntax highlight만 되는)가 있어서 폰 인터뷰와 비슷한 환경을 제공한다는 점입니다. 그리고 작성한 코드를 제출하면 자동으로 채점을 해주기 때문에 많은 도움이 됩니다. 이런 온라인 코드 채점 시스템에 익숙하지 않은 분들을 위해 간단히 설명하면, 단순히 답만 맞으면 되는게 아니라 지정된 시간/메모리 제한 내에서 답을 출력해야만 accept 가 됩니다. 여기서 IDE 의 도움 없이 코딩해서 최대한 에러 체크를 머릿속으로 해보고 최소한의 submit 횟수로 accept 받는 것을 연습하면 큰 도움이 됩니다. 문제가 생각보다 많아서 이게 기간이 꽤 걸리는데, 저는 폰 인터뷰 시작하기 전까지 모든 문제를 한 번씩 다 풀어봤습니다. 스스로 풀어보고 난 후에 궁금하다면 문제 페이지에서 discussion 으로 들어가면 다른 사람들이 올려둔 솔루션들이 많이 있으니 참고하실 수 있습니다.
CTCI 는 주요 알고리즘/데이터구조 등이 잘 정리되어 있어서 리뷰하는데 많은 도움이 됩니다. CTCI 에 나오는 연습문제들은 LeetCode 와 좀 다른 방식으로 풀었는데, 문제를 가지고 적당히 시끄러운 카페에 가서 종이에 손으로 코딩하면서 풀었습니다. 그리고 단순히 종이에 손코딩을 한 것이 아니라, 입으로 계속 중얼중얼 설명을 하면서 풀었습니다. 위에서 나열한 코딩 인터뷰의 어려운 점들을 극복하는 연습으로써 이렇게 했고, 저에게는 이 연습이 실제 인터뷰 때 굉장히 큰 도움이 되어습니다. 코드 편집을 할 수 없으니 좀 더 알고리즘의 큰 그림을 먼저 생각하여 skeleton 을 짜고, 그 이후에 skeleton 에서 적당히 method 이름만 적고 넘어간 부분들을 따로 구현해주는 식으로 연습을 했습니다. 더 좋은 방법은 실제 화이트보드 앞에서 mock interview 를 하는 방법일텐데, 저는 여건상 mock interview 는 해보지 못했습니다. 같이 취업 준비하는 동료가 있으면 많이 도움이 될 것 같네요.
TopCoder Arena 문제들도 풀었는데, 이 것은 앞의 2가지와 달리 어려운 코딩 문제를 풀기 위해서가 아니었습니다. 머릿속으로 생각한 것을 코드로 correct 하게 구현해낼 수 있는 코딩 감각을 유지하기 위해서 일종의 매일 하는 운동에 가까웠습니다. 매일 250-300pt 레벨 문제를 2개씩 풀었습니다. 이 것은 코딩 감각 유지가 목적이었기 때문에, 제가 늘 쓰던 Eclipse IDE 에다가 EclipseCoder 라는 TopCoder 플러그인을 깔아서 빨리빨리 코딩하는 방식으로 연습했습니다. 이 연습의 장점은 자주 쓰게 되는 collections 라이브러리나 string manipulation 등에 익숙해진다는 점입니다. 저도 TopCoder Arena 는 이번에 처음 해보았는데요, 사용방법은 검색해보시면 많이 나옵니다.
LeetCode 와 CTCI 는 시작할 때부터 쭉 병행했습니다. 제가 LeetCode / CTCI 문제들을 풀면서 가장 신경썼던 부분은 절대로 먼저 답을 확인하지 않는다 라는 원칙입니다. 어차피 실제 면접을 보면 모르는 문제가 나올 것이고, 새로운 문제를 만났을 때 풀어내는 능력을 길러야 한다고 생각했기 때문입니다. 혹시라도 아는 문제가 나오면 솔직하게 면접관에게 얘기하고 다른 문제를 받는 것이 더 낫다는 조언을 많이 들었고, 저도 동의합니다. 그래서 준비할 때에는 정말 며칠씩 고민해도 문제가 명확하게 풀리는 않는 경우를 제외하고는 늘 먼저 스스로 풀어본 후에 궁금하면 다른 사람들 코드나 책의 솔루션을 참고했습니다.
참고로 저는 careercup.com glassdoor.com 사이트 등은 너무 정리가 안 되어있고 저도 시간도 부족해서 그냥 포기하고 거의 안 봤습니다. 그리고 회사별 인터뷰 특징은 여기저기 검색해보면 많이 나오고 CTCI 책에도 좀 나와있으니 미리 알고 가면 약간은 도움이 됩니다. 그렇지만 결정적으로 크게 영향을 미치지는 않는 것 같습니다.
실제 인터뷰 팁
마지막으로 실제로 인터뷰 하면서 경험으로 체득한 팁을 몇 가지 공유합니다.
폰 인터뷰
폰 인터뷰가 온사이트 인터뷰보다 쉬울거라고 지레짐작했는데, 오히려 저는 폰 인터뷰가 훨씬 어려웠습니다. 물론 문제의 난이도 자체는 온사이트보다 약간 쉬운 편인데, 면접관과 같은 공간에서 진행하는게 아니기 때문에 어려운 점들이 있었습니다. 얼굴 표정이나 몸짓등이 전달이 안 되고, 그림을 그려가면서 설명하기도 어려우며, 통화 품질이 떨어지는 경우도 생길 수 있습니다. 그래서 폰 인터뷰 때는 다음과 같은 것들을 좀 주의하면 좋습니다.
- 열심히 말로 설명할 것. 온사이트 인터뷰와는 달리 면접관은 지원자가 생각을 하고 있는지 아닌지 조차도 얼굴을 볼 수 없으니 알기가 힘듭니다. 그렇기 때문에 온사이트 때보다도 더 말을 많이 한다는 생각으로 (think aloud) 면접을 진행해야 합니다.
- 키보드로 타이핑을 해야하기 때문에 블루투스 이어셋 등을 마련해두는 것은 필수입니다. 컴퓨터용과 폰용 2가지 다 있으면 더 좋습니다. 제 경우 한 면접관이 Skype 로 연락하기로 했는데 실제로는 전화로 연락을 해왔습니다. 다행히 휴대폰용 블루투스 이어셋도 준비되어 있어서 큰 문제 없이 면접을 진행할 수 있었습니다.
- 지원할 때 냈던 레쥬메나, 자주 사용하는 라이브러리 문서등은 미리 띄워놓으면 좀 도움이 됩니다. 듀얼 모니터라면 더 좋습니다.
온사이트 인터뷰
온사이트 인터뷰 에서는 다음과 같은 부분들을 유념하면서 인터뷰에 임했습니다.
- 처음 문제를 듣고난 뒤에는 문제를 제대로 이해했는지 여러가지 질문을 하며 확인하는 과정이 필수입니다. 이 과정에서 문제에 ambiguous 한 부분이 있다면 파고들어서 미리 clarify 해두어야 합니다. 이것 또한 면접의 중요한 요소입니다.
- 문제를 확실히 이해했으면, 곧바로 코딩으로 들어가기 전에 먼저 어떤식으로 문제를 풀 것인지 면접관에게 구두로 설명합니다. 다양한 high-level 아이디어들을 최대한 떠올려보고 그 중 가장 적절한 방법을 설명합니다. 설명하는 도중에 문제점이 발견되거나 더 좋은 방법이 떠오르면 최대한 일찍 방향을 선회하면 됩니다.
- 코딩을 시작해도 되겠는지 물어본 뒤 코딩을 시작합니다. 면접관이 코딩을 시작하라고 먼저 말해주기도 합니다. 간단한 테스트 케이스 몇가지를 미리 정해두고 시작하는 것도 좋습니다.
- 화이트보드 공간이 모자랄 수 있으니 최대한 왼쪽 위 구석에서 시작합니다. 더블 스페이스 느낌으로 라인 사이사이에 공간을 좀 비워두면 나중에 혹시 코드를 끼워넣어야 할 때 편합니다.
- 생각보다 시간이 잘 가기 때문에 조금 빨리 코딩하는게 좋습니다. 중간에 인터뷰어가 질문을 하거나 힌트를 주면 반드시 잘 되새겨보고 문제점이 무엇인지 파악해야 합니다. 해당 문제에 대해서는 면접관이 훨씬 더 경험이 풍부하고 잘 알고 있다는 사실을 기억합시다.
- 코딩이 끝났으면 바로 끝났다고 얘기하기 보다는, 테스트 케이스를 머릿속으로 수동으로 코드에 넣고 돌려봅니다. 이 과정에서 계산 결과, 조건식 등을 대충 넘어가지 말고, 실제로 계산 다 해보고, 조건식 양쪽 다 evaluate 해서 원하는 대로 결과 나오는지 체크해 봅니다. 저는 이거 하면서 면접중에 버그 몇개 잡았습니다 :p
- 면접에 임하는 태도도 중요한 요소임을 기억해야 합니다. 면접관이 ‘이 사람과 동료로서 같이 일하고 싶은가?’ 라는 질문에 그렇다 라고 대답할 수 있도록 노력해야 합니다. 너무 거만해서도 곤란하고 반대로 너무 shy 해서도 곤란하겠죠. 새로운 아이디어를 들었을 때, 재빨리 각 아이디어의 장단점을 파악하고 기존의 아이디어를 defend 하거나 새로운 아이디어 쪽으로 선회하는 유동적인 자세도 중요한 것 같습니다.
- 마지막으로.. 가능하면 면접을 즐기세요 🙂 물론 저도 긴장은 많이 되었지만, 주어진 문제를 가지고 이 분야의 expert 와 즐겁게 토론한다는 마인드로 임했더니 배우는 점도 많았고 실제 면접에도 더 도움이 되었던 것 같습니다.
정리
이것 저것 생각나는 것 위주로 나열해 보았는데, 가장 중요한 포인트를 한 가지 뽑으라면 일찍 준비하기 시작하라는 것입니다. 뭐든 그렇지만 잡서치도 일찍 시작해야 정보도 많이 모이고 자기 상황에 맞게 계획을 세워서 모자란 부분을 중점적으로 잘 준비할 수 있게 되는 것 같습니다. 혹시 더 궁금하신 부분은 댓글로 물어보시면 제가 답변할 수 있는 한도 내에서 최대한 알려드리겠습니다.
마지막으로 제가 도움 받았던 다른 글들 링크 걸어둡니다.
PS. 어째 다 써놓고 보니 논문같은 형식으로 써버렸네요^^;;
