실리콘밸리 전화 인터뷰 팁
Episode 7 - Phone Interview Tip
이번 Episode에선 온사이트 인터뷰 스토리를 이어가기 전에 그동안 전화 인터뷰에 대해서 정리를 하고 전화 인터뷰 노하우/팁을 공유해보자고 한다.
지금까지 8개의 회사와 전화 인터뷰를 진행해서 LinkedIn, Quora, Lyft, Airbnb, Netflix, Facebook 이렇게 총 6개의 회사들에서 온사이트를 받을 수 있었다.
물론 전화 인터뷰는 최종 면접인 온사이트 인터뷰를 보기 위한 1차 관문일 뿐이고 온사이트 인터뷰는 전화 인터뷰에 비해 훨씬 더 까다롭고 인터뷰를 하루 만에 4-6개 정도를 연달에 해내야 하기 때문에 비교가 안 될 정도로 힘들다.
전화 인터뷰는 인터뷰 과정 중 워밍업 정도라고 보면 되고 이제부터가 진짜 본 게임이다.
앞선 Episode 들에서 볼 수 있듯이 사실 전화 인터뷰 방식이나 문제들은 회사들마다 크게 다르지 않다.
대부분 알고리듬 문제 한, 두 개 정도가 나오고 주어진 시간 (보통 45분) 내로 optimal 한 솔루션으로 문제들을 풀어낼 수 있으면 웬만하면 통과를 할 수 있다.
이런 알고리듬 문제들은 수학 시험공부하듯이 많은 알고리즘 연습 문제를 풀어봐야 실력도 늘고 실전 인터뷰에 충분한 대비를 할 수 있다.
45분의 전화 인터뷰 시간 중에 소개 및 대화하는 시간을 빼면 보통 35분 정도의 시간 동안 문제를 이해하고 솔루션을 찾고 그 솔루션을 코딩으로 완성한 후 설명까지 해야 되기 때문에 충분한 연습이 없으면 시간 내에 문제를 푸는 것조차 쉽지가 않다.
거기다가 요즘엔 CoderPad 같이 코드를 직접 돌릴 수 있는 온라인 코딩 툴을 많이 쓰면서 Test Case까지 생각을 해야 한다.
따라서 짧은 시간에 정확한 이해와 코딩을 완성할 수 있는 능력이 무엇보다 중요하다.
그렇다면 연습은 어떻게 해야 할까?
가장 기본적으로 알고리즘 (Algorithm), 자료구조 (Data Structure)를 공부하는 것도 중요하지만 그 많은 내용을 다 찾아서 공부할 수도 없는 노릇이다.
사실 인터뷰를 준비하는 시점에선 이론을 공부하기보단 문제를 풀어보면서 이해를 하는 것이 좀 더 실용적인 방법이다.
특히 요즘엔 인터넷을 조금만 찾아보면 실제 회사들 인터뷰로 나왔던 실전 문제들을 쉽게 찾을 수 있다.
그중에 가장 많이 쓰는 웹사이트는 단연 LeetCode.
800개의 가까운 문제를 보유하고 있고 커뮤니티 내에서 사람들이 활동적으로 같이 문제도 풀고 의견을 교환하고 있어서 개인적으로 도움을 가장 많이 받은 웹사이트였다.
좀 더 솔직히 이야기를 하자면 내가 지금껏 전화 인터뷰를 보면서 받았던 대부분의 코딩 문제는 저 LeetCode에서 찾을 수 있는 문제였다.
LeetCode에 있는 문제들이 실제 회사 인터뷰에서 나왔던 문제들을 많이 모아 놔서 인터뷰어들이 매번 새로운 문제로 바꾸지 않는 한 비슷한 문제들이 많이 보일 수밖에 없다.
물론 LeetCode에 문제가 워낙 많아서 준비하는 기간 동안 개인적으론 2-3달의 긴 준비기간에도 200개 정도밖에 풀어보지 못했고 실제 인터뷰에선 미처 보지 못한 문제들에서 많이 나왔다.
하지만 다시 바꿔 말하면 LeetCode 문제만 잘 풀어봐도 전화 인터뷰는 웬만하면 통과할 수 있을 거라 생각한다.
물론 800개의 LeetCode를 정식으로 하나하나 다 풀어보려면 한 개당 20분만 잡아도 260시간이 넘게 걸린다.
인터뷰 준비를 하루에 2-3시간 정도 한다고 가정했을 때 문제만 풀어봐도 꼬박 3-4달이 걸리는 문제 양이다.
문제의 난이도가 Easy/Medium/Hard로 나눠져 있는데 Hard 문제들은 한 문제 푸는데 1시간이 넘게 걸리던 적이 있어서 실제로는 몇 배 더 걸릴 수도 있다.
때문에 현실적으로 800개 문제를 다 풀어본다는 건 쉽지 않을 것이다.
가장 좋은 건 벼락치기보다 평소에 조금씩 준비를 하는 것이다.
평소 하루에 한 문제씩, 하루에 20-30분씩만 투자를 한다면 코딩 문제들에 대한 감을 유지하면서 다양한 문제 해결 능력을 기를 수 있어 인터뷰를 준비한다고 나처럼 벼락치기로 2-3달 동안 고생을 할 필요가 없을 것이다.
Other Resources
Leetcode가 실전 인터뷰 문제를 연습할 수 있다면 GeeksForGeeks는 연습 문제 외에도 이론적인 부분을 자세하게 다루고 있어서 좀 더 깊게 공부하고 싶다면 GeeksForGeeks를 추천한다.
그 외에도 interviewing.io는 현재 실리콘 밸리에서 일하고 있는 엔지니어들과 실전 전화 인터뷰를 연습할 수 있도록 모의 인터뷰를 제공한다.
요즘 전화 인터뷰에서 많이 쓰는 CodePad나 HackRank, CodePair 같은 툴도 평소에 익숙해져 놓으면 실제 인터뷰에 많은 도움이 될 수 있다.
그렇다면 인터뷰의 평가 기준은 어떻게 되는 걸까?
사실 전화 인터뷰에 출제되는 문제나 평가는 대부분 전적으로 인터뷰어 즉 인터뷰를 하는 엔지니어에게 달려있다.
때문에 어떤 인터뷰어를 만나냐에 따라 인터뷰 결과가 정말 달라질 수도 있다.
어떻게 보면 복불복이라는 생각이 들 만큼 운도 중요하다.
터무니없이 어려운 문제를 전화 인터뷰로 내는 경우도 봤고 어떤 경우엔 어떻게 이런 걸로 지원자를 가려내려고 하나 생각이 들 정도로 쉬운 문제를 내는 경우도 봤다.
그래도 기본적으로 전화 인터뷰를 평가하는데 가장 중요한 것은 인터뷰 문제를 주어진 시간 내에 해결하는 것이다.
주어진 시간 내에 정답을 풀어내면 웬만하면 전화 인터뷰는 통과할 수 있다.
(그래서 솔직히 LeetCode에 나온 솔루션만 달달 외워도 내 생각엔 웬만한 전화 인터뷰는 충분히 통과 가능하다고 생각이 든다.)
하지만 그게 전부는 아니다.
나도 여러 회사에 제직 하면서 인터뷰어로써도 많은 인터뷰를 해왔는데 내가 생각하는 인터뷰 Best Practice를 모아봤다.
1. Do not jump into coding right away
: 대부분 많이 하는 실수이다. 빨리 문제를 풀려는 급한 마음에 문제를 듣자마자 바로 코딩을 시작을 하는 경우가 있는데 이는 웬만하면 피해야 한다. 대신에 문제를 듣고 생각을 먼저 하고 어떤 방법으로 문제 해결을 할 건지 또 그 이유는 무엇인지 먼저 설명을 하고 코딩을 시작하는 게 좋다. Communication도 인터뷰에서 중요한 요소 중에 하나인데 이를 통해 그 능력을 증명할 수 있다. 그리고 내가 생각하는 방법이 잘못된 방향이라면 이미 인터뷰어에게 피드백을 받을 수도 있기 때문에 서두르기보단 먼저 한번 생각을 하고 진행해 나가는 것이 좋다
2. Clarify your question
: 코딩을 하기 전 문제에 대해 확인 작업을 하는 것이다. 인터뷰 문제는 일부러 모든 조건을 먼저 주지 않고 vague 한 문제가 나오는 경우가 많다. 주로 일부러 이런 문제를 통해서 인터뷰이가 제대로 된 질문을 하는지 또 확실하지 않은 문제의 조건들을 스스로 확인하면서 진행을 하는지도 평가 항목이다.
3. Think out loud
: 전화 인터뷰는 전화 상으로 내 솔루션을 설명해야 하기 때문에 상당히 까다롭다. 개인적으로 내가 영어가 부족한 문제도 있겠지만 반대로 인터뷰어가 영어가 짧은 경우도 많이 있다. 따라서 코딩을 하면서 인터뷰어를 이해시키는 것도 중요한 부분인데 코딩을 하면서 중간중간에 설명을 하면 내가 어떤 생각으로 어떤 방향으로 문제를 해결해 나가는지 인터뷰어에게 명확하게 알려줄 수 있다. 만약 내가 잘못된 방향으로 가고 있다면 인터뷰어에게 힌트를 받을 수도 있다.
4. Don't miss edge cases
: 주로 input validation을 통해서 해결 가능한데 어떤 사람들은 알고리듬만 제대로 짜면 되지라고 말할 수도 있는 항목이지만 사실 가장 기본이 되면서 중요한 부분이다.
5. You should understand what you are doing/coding
: 단순히 솔루션을 암기를 해서 문제를 푸는 사람들을 가려낼 수 있다. 기본적으로 time & space complexity 정도는 알아야 하고 내가 쓴 알고리즘이 어떻게 작동되는지 이해하고 설명을 할 수 있어야 한다.
6. Debugging process
: 코딩은 과정이다. 한 번에 완벽한 코딩을 짤 수 있다면 모를까 대부분 trial & error 가 필요하다. 거기서 보게 되는 것이 debugging 능력이다. 내 코드에 버그가 있다면 그 버그를 얼마나 빨리 찾고 어떤 과정을 통해서 버그를 고칠 수 있는 지도 중요한 평가 요소이다.
7. Cover various test cases
: 마지막으로 솔루션을 완성했다면 솔루션이 맞는지 스스로 테스트를 통해 증명할 수 있어야 한다. 이때 다양한 test case들을 통해서 증명할 수 있는 것도 중요한 항목 중에 하나이다.
