미국 IT기업 인터뷰 준비하기
실제 FAANG 인터뷰 경험을 바탕으로 쓰는 미국 IT기업 인터뷰 개요
*경어를 생략하며 진행하는 점 양해 부탁드립니다.
개요
요즘에는 미국 테크 기업에 종사하는 한국인들이 많아지고, 또 입사와 관련된 정보들을 책이나 온라인에서 손쉽게 찾을 수 있다. 그래서 내가 같은 이야기를 하는 것이 큰 도움이 될까?라는 생각이 들지만, 내 실제 경험을 토대로 나만의 관점에서 이야기를 해보는 것도 어느 정도 의미가 있을 거란 마음에 글을 작성한다. 미국 IT회사에서 인터뷰 절차는 크게 레쥬메 스크리닝, 리크루터 통화, 스크리닝 인터뷰, 온사이트 인터뷰, 디브리핑 미팅, 그리고 오퍼 단계로 나뉜다. 그리고 인터뷰 형식은 보통 Behavioral, 코딩, 시스템 디자인, 그리고 스페셜 토픽으로 나뉜다.
레쥬메 스크리닝
개인적으로 가장 쉬우면서도 어려운 단계가 레쥬메 스크리닝이 아닌가 싶다. 가장 쉬운 이유는 그냥 준비해둔 레쥬메를 지인이나 온라인 사이트를 통해 지원하면 되기 때문이고, 가장 어려운 이유는 이전 경력이나 좋은 학력 / 포트폴리오 / 추천 없이는 이 단계에서 걸러지기가 쉽기 때문이다. 유명 IT회사들의 경우에는 하루에도 엄청난 수의 지원자들을 받기 때문에, 그만큼 많은 수의 지원자들이 여기서 걸러진다.
정확히 어떻게 회사들이 레쥬메 스크리닝 하는지는 모르지만, 경력이나 학벌, 프로젝트에 타깃 키워드들을 설정해서 그들에 매치되는 레쥬메들을 우선 뽑는 방식도 있는 걸로 알고 있다. 테크 업계의 경우, 학벌에 대한 허들은 비교적 낮아서, Top 20 학교가 아니더라도 gpa가 좋고, 흥미로운 프로젝트 경험이 있다면, 통과될 가능성이 있다. 이미 좋은 회사의 인턴 경력이 있다면 학벌은 중요하지 않다. 아마존 같은 경우, AI를 이용해서 자동으로 레쥬메 스크리닝을 했었는데, 학습 중에 편향적인 특성 (특정 인종, 성별에 우호적인 모습을 보임)을 가지게 되어서 자동 스크리닝을 중지하고 다시 리크루터들이 스크리닝을 한다고 한다.
만약 괜찮은 경력이나 실적이 없다면, 맨땅에 헤딩으로 온라인 지원하는 거보다 리퍼럴을 받는 것을 추천한다. 링크드인으로 지원할 회사에 다니고 있는 동문에게 정중히 메시지로 리퍼럴을 부탁하는 거도 한 방법이다 (동문이 아니더라도 일단 물어볼 가치는 충분하다). 물론 책임감을 느끼고 잘 모르는 사람을 추천해 줄 수 없다는 사람이 많겠지만, 또 어차피 인터뷰를 통과해야 입사가 정해지기 때문에, 리퍼 정도는 해줄 수 있다는 사람도 분명 있을 것이다 (피추천인 입사 시 받게 되는 리퍼럴 보너스는 덤). 영문 레쥬메를 작성하는 법은 이 사이트를 참조하길 바란다.
리크루터 통화
레쥬메 스크리닝을 통과했다면 리크루터가 연락이 와서 가벼운 자기소개 통화를 위한 날짜를 잡자고 할 것이다. 대개는 형식적인 통화로, 리크루터가 짤막한 회사 소개 및 지원한 직무에 대해 얘기하고, 지원자의 배경과 지원 동기를 듣고 다음 단계를 위한 일정을 논의한다. 통화 이후에는, 이메일로 리크루터가 스크리닝 인터뷰 스케줄을 위해 지원자가 희망하는 날짜들을 보내달라고 한다. 통상 ~4주 내로 인터뷰 날짜를 잡지만, 본인이 준비가 덜 됐다고 생각하면, 시간을 조금 더 달라고 해도 된다. 하지만 만약 지원한 직무 채용이 완료되면 지원 프로세스는 거기서 멈추게 될 것이다.
넷플릭스의 경우 이 리크루터와의 통화가 굉장히 중요한데, 만약 리크루터가 지원자가 지원한 직무나 넷플릭스의 문화와 맞지 않는다고 생각하면 다음 단계로 진행하지 않고 거기서 멈출 것이다. 넷플릭스 채용 과정은 다른 글에서 좀 더 상세하게 다루도록 하겠다.
테크니컬 스크리닝 인터뷰
스크리닝 인터뷰는 보통 전화통화로 진행하면서 인터뷰어가 보내준 링크를 통해 코딩을 한다. 대부분 테크 스크리닝은 지원자가 기본적인 테크니컬 소양을 갖추었는지를 시험하기 때문에, 리트코드 쉬움~중간 난이도의 문제가 하나에서 둘 정도 나올 것이다. 코딩 문제 외에도 기본적인 컴퓨터 이론 관련 질문도 할 수 있는데, 레딧 인터뷰에서 그런 질문을 받았었다. 만약 스크리닝 인터뷰를 통과한다면 리크루터가 온사이트 진행을 위한 간단한 통화를 요청하거나 바로 다음 인터뷰 스케줄을 잡기 위한 날짜들을 보내달라고 한다.
온사이트 인터뷰
대개의 경우, 온사이트 인터뷰가 회사 면접의 마지막 단계일 것이다. 코로나 이전 상황에선 본사로 지원자를 초청하여 인터뷰도 하고 밥도 먹이고, 회사 캠퍼스도 구경시켜주는 일정이다. 하지만 코로나 이후로는 원격으로 인터뷰를 진행하는 만큼 관광(?)은 일정에서 빠지고, 화상으로 인터뷰어들과 인터뷰를 진행하게 된다. 온사이트는 보통 4~6번의 인터뷰를 하게 되는데 인터뷰 종류도 코딩, 시스템 디자인, behavioral, special topic (예: ML) 등 다양하다. 코딩 문제 난이도도 스크리닝 때보다 어려우며, 지원자의 합격 / 불합격을 가르는 만큼 인터뷰 라운드 하나, 하나가 중요하다.
디브리핑
온사이트 인터뷰가 끝나면, 이제 인터뷰어, 리크루터, 그리고 특정 회사들은 (예: 아마존) Bar Raiser라고 불리는 역할을 가진 사람까지 포함해서 지원자의 인터뷰 퍼포먼스를 평가하고, 오퍼를 줄지 말지를 논의한다. 이후부터는 회사마다 다루는 방식이 조금씩 다른데, 아마존의 경우엔 지원자에 대한 의견이 반반으로 갈린다면 Bar Raiser가 각 인터뷰어에게 결정의 이유를 상세하게 듣고, 한쪽으로 의견이 통일되도록 미팅을 주도한다. 페이스북이나 구글 같은 경우에는, 디 브리핑 이후에도 하이어링 커미티 미팅이 존재하기 때문에, 의견이 반반이더라도 리크루터가 보기에 다음 미팅에 갈 만하다고 생각하면, 그대로 패킷을 진행하여 다음 단계에서 리뷰를 받는다. 하지만 애매한 지원자의 경우 하이어링 커미티에서 리젝을 받거나, 부족한 부분에 한해서 추가 인터뷰를 요구받는다. 또한 지원자의 레벨링 (직급) 논의도 여기서 벌어지는데, 시스템 디자인과 Behavioral 퍼포먼스에 따라서 지원자가 지원한 role 오퍼를 받을지 아니면 그보다 낮은 레벨로 받을지를 결정한다.
오퍼
마지막 오퍼 단계까지 온다면 9부 능선을 넘은 거라 봐도 무방하다. 이 단계에서는 리크루터가 지원자에게 합격 소식을 전해주면서 이 정도의 compensation을 받을 것이라 얘기해준다. 그때부터 협상이 시작되는데, 대개 다른 회사로부터 competitive 한 오퍼를 받아놓아야 제대로 된 협상을 할 수 있다. 필자도 제대로 된 협상을 해본 적이 없어서 정확한 설명을 못하지만, 인터넷에서 효과적으로 협상하는 방법을 쉽게 찾을 수 있다.
Behavioral 인터뷰
Behavioral 인터뷰는 지원자의 평소 가지고 있는 태도나 특정 상황에서의 대응 경험 등을 알아보면서 이 사람이 회사가 원하는 인재상에 부합하는지, 어떤 직급에 어울리는지를 평가하는 인터뷰이다. "We don't want a brilliant jerk" (우리는 뛰어난 바보를 원하지 않습니다). 어찌 보면 당연한 말 같지만, 그만큼 회사들이 중요하게 생각하는 요소이다. IT는 직원들 간의 긴밀한 대화와 협력이 필수적인 직종이다. 아무리 본인의 개발실력이 뛰어나더라도 협동심이 부족하거나 인성에 큰 문제가 있다면 많은 회사들이 외면할 것이다. 기본적인 인성이나 태도 외에도 회사들마다 고유하게 중요시 여기는 가치들이 있기 때문에 그에 맞춰서 인터뷰를 준비하는 것이 일반적이다.
예를 들어 아마존은 리더십 원칙이라고 해서 16개 정도의 원칙들이 존재하는데, 모든 인터뷰 라운드에서 2개의 리더십 원칙과 관련된 질문을 하고 그에 관련된 지원자의 경험을 듣는다. 만약 지원자의 대답이 충분하지 않거나 옆으로 샌다면, 추가적인 질문으로 그 리더십과 관련된 데이터를 모으는데, 그럼에도 합격점을 받지 못한다면, 아무리 코딩 문제를 잘 풀었다고 하더라도 오퍼를 받지 못하게 된다 (실제로 내가 참여한 인터뷰에서 그런 경우가 종종 있었다).
시니어 이상의 직급으로 인터뷰를 볼 경우, 자기가 주도적으로 어떤 임팩트를 남겼는지, 팀원들 간의 충돌이나 불화를 중재한 경험, 그리고 다른 팀원들의 성장에 어떠한 도움을 주었는지를 보다 더 중점적으로 본다.
코딩 인터뷰
어찌 보면 개발자로서 가장 기본적인 능력을 평가하는 인터뷰일 것이다. "코딩 인터뷰를 준비하려면 어떻게 해야 하지?"에 대한 가장 단순한 답변으로는 "Grind LC"가 될 수 있을 것이다. LC는 리트코드 사이트를 뜻하는 단어이다. 한마디로 리트코드에서 코딩 문제들을 미친 듯이 풀라는 소리이다. 그만큼 리트코드가 현재 코딩 인터뷰 방식에서 가지는 영향력은 절대적이다. 카테고리 별로 다양한 문제들이 난이도 별로 존재하고, 내가 쓴 코드를 준비되어 있는 테스트 케이스들을 통해 검증해 볼 수 있다. 돈을 내서 프리미엄 계정이 되면, 회사들이 어떤 문제들을 어느 빈도로 물어보는지도 알 수 있다. 코딩 인터뷰 준비를 위한 최고의 학원인 셈이다. 하지만 업계 종사자들은 리트코드 형식의 문제들을 좋아하지 않는다. 현업에 필요한 개발 능력과 동 떨어진 문제들이 대다수이기 때문이다. 그래서 요즘 들어서는 기업들이 보다 더 현실과 연관되고 밀접한 방향으로 코딩 테스트를 내려하고 있다. 대표적으로 넷플릭스, 스트라이프, 스퀘어, 레딧을 들 수 있다. 실용적인 코딩에도 종류가 여러 가지인데 문제를 인터뷰어와 함께 풀어나가는 interactive 세션, 코드를 주고 버그를 찾아내는 디버깅 세션 등 보다 실용적이고 현업에서 있을법한 상황을 만들어서 지원자를 평가한다.
코딩 인터뷰에서는 알고리즘과 자료구조가 필수 과목이다. 만약 이 두 과목에서 튼튼한 기초가 쌓여있다면, 리트코드를 유형별로 몇 문제만 풀어보아도 금방 인터뷰에서 좋은 성과를 낼 수 있을 것이다. 만약 이 두 과목을 제대로 배운 적이 없더라도, 유튜브나 인터넷, 그리고 책으로 독학이 가능하니 어느 정도 이론을 배우고 문제를 풀어보는 것도 좋은 방법이 될 것이다.
코딩 인터뷰에서 가장 중요한 것은 인터뷰어와의 충분한 커뮤니케이션이다. 문제를 받았을 때, 바로 코딩을 시작하는 것은, 나를 떨어뜨려 달라는 강력한 신호와도 같다. 코딩 인터뷰 문제가 현업과 맞지 않는 것은 차치하더라도, 해답을 만들어가는 과정이 현업에서 동료와 일하는 과정을 시뮬레이션해놓은 것이기 때문이다. 문제를 받으면 우선 자신이 문제를 올바르게 이해한 것이 맞는지 인터뷰어에게 확인을 받는 게 중요하다. 입력 값으로 A를 받았을 때 기대하는 출력 값은 B이다 같은 예시를 드는 것이 가장 효과적이다. 그 후에 만약 바로 최적화된 해답이 떠오르지 않는다면, 1분 정도의 생각할 시간을 달라고 얘기하는 게 좋다. 그동안 어떻게 문제를 접근해야 할지 생각하고 본인의 알고리즘을 우선 인터뷰어에게 얘기하라. 이런 알고리즘을 쓰면, 시간 복잡도는 이렇고, 공간 복잡도는 이런데 인터뷰어는 어떻게 생각하느냐 묻는다면, 인터뷰어가 본인 마음에 드는지 아니면 더 나은 해법이 있는지 알려줄 것이다. 만약 아무리 생각해도 좋은 해답이 생각나지 않는다면, 비효율적인 해답이라도 우선 얘기를 한 다음에 코드를 짠 후 점차 나은 방법으로 발전시켜나갈 것이라 얘기하는 게 좋다. 백지로 인터뷰를 끝내는 것보다 우선 코드라도 써놓는 것이 낫기 때문이다. 그리고 일단 코딩을 하기 시작하면, 긴장이 풀리고 머리가 잘 돌아가기 시작하면서 더 나은 방법이 떠오르기도 한다. 코딩을 끝냈을 때, 끝났다고 말하지 말고, 일단 작성은 완료했는데 자기가 짠 코드가 잘 돌아가는지 확인하기 위해서 몇 가지 테스트 케이스로 검증하겠다고 말해야 한다. 그 후 본인이 생각해 놓은 테스트 입력값 몇 가지를 이용해서 한 줄 한 줄 코드를 소리 내가며 검증하고 모든 입력값을 정상적으로 처리한다고 생각하면, 인터뷰어에게 확인을 받자. 만약 인터뷰어도 코드가 좋은 상태라고 생각한다면, 다음 문제로 넘어가거나 질문을 받는 타임으로 넘어갈 것이다. 항상 테스트 케이스에 에지 케이스도 넣는 걸 잊지 말자.
시스템 디자인 인터뷰
시스템 디자인 인터뷰는 경력을 가진 개발자들의 시스템 설계 역량을 평가하는 인터뷰이다. 보통 인터뷰 후보의 최종 레벨을 정할 때 Behavioral 인터뷰와 같이 중요하게 반영되는 인터뷰로써, 개발자가 시니어 이상 직급으로 오퍼를 줘도 될지 말지는 이 인터뷰에 달려있다. 주로 나오는 문제는 어떤 서비스를 디자인하라 같은 전반적인 시스템 설계 문제부터, 특정 모듈이나 컴포넌트 API를 디자인하라는 보다 로우 레벨 디자인 문제가 존재한다. 코딩 인터뷰처럼 충분한 준비가 필요한 인터뷰이며, 다양한 주제들에 대해 얘기할 준비가 되어있어야 하기 때문에, 자주 나오는 문제는 여러 번 공부하고 가는 것이 좋다. 온라인에 많은 자료들이 있는데 몇 가지를 추천해보자면:
1. 유튜브 채널:
- System Design Interview (아마존 시니어 개발자가 운영하는 채널. 모든 영상 추천)
- Gaurav (깊이는 얕지만 설명을 잘함)
2. 책:
- Design Data Intensive Applications (비단 인터뷰 공부용이 아니라 실무에도 엄청나게 도움이 되는 책으로 강력하게 추천)
- System Design Intervew (깊이는 조금 얕지만, 다양한 주제를 맛볼 수 있다.)
3. 웹사이트:
- System Design Primer (무료로 처음 입문하기 좋은 자료이다.)
- Grokking the System Design Interview (위에 System Design Interview 책과 비슷하다. 깊이는 얕지만, 다양한 주제를 섭렵하기에 좋다.)
- Grokking the Advanced System Design Interview (심화 버전이라기보다는, 시스템 디자인 인터뷰에 자주 등장하는 개념들을 심도 있게 다루는 콘텐츠이다.)
4. 기출문제:
- Leetcode Discussion section
- Blind (US ver) 앱에서도 후기들을 통해 문제를 알아볼 수 있다.
코딩 인터뷰와 마찬가지로 가장 중요하게 생각하는 것은 실전처럼 연습해 보는 것이다. 같이 인터뷰를 준비하는 아니면 준비했었던 친구가 있다면 mock interview를 해보면서 자기의 어느 부분이 부족한지 평가하며 보완해 나가는 것이 좋다. 가격이 좀 나가지만, 세션당 $100~150 정도를 지불하고 현업 전문가들에게 mock 인터뷰를 한 뒤 피드백을 받는 것도 괜찮은 투자가 될 수 있다.
스페셜 토픽 인터뷰
사실 스페셜 토픽 인터뷰!라고 정해져 있는 인터뷰는 없다. 다만 위에 정형화된 3개의 인터뷰 유형이 아닌 것들을 편리하게 한 부류로 묶기 위해서 스페셜 토픽이라고 써보았다. 보통 스페셜리스트를 뽑으려 할 때 추가되는 인터뷰들인데, 대표적으로 머신러닝 인터뷰가 있다. 머신러닝 인터뷰도 가지고 있는 머신러닝 지식을 평가하는 인터뷰가 유형별로 (NLP, Vision, RecSys, etc..) 있고, end-to-end로 머신러닝 시스템을 구축할 수 있는지 평가해보는 머신러닝 시스템 디자인 인터뷰가 있다.
강력하게 추천하는 준비 자료로는:
- https://stanford-cs329s.github.io/ (instructor Chip Huyen은 MLOps / Design에 확고한 전문성을 가지고 있다.)
- ML System Design Interview Guide (Pinterest ML엔지니어가 적어놓은 글)
마치며
본인의 부족한 경험을 토대로 작성한 정보 글이다 보니, 시중에 나온 인터뷰 준비 책이나, 온라인 자료들보다 빈약한 부분이 많은 것 같습니다. 하지만 이런 관점/경험에서 전달하는 정보도 있다는 걸 알아주셨으면 합니다. 워낙 빠르게 변화하는 분야다 보니 인터뷰 준비 방법도 계속해서 발전해나갈 거 같습니다. 부족한 부분이 많은 만큼 계속해서 이 글을 업데이트해 나가도록 하겠습니다. 읽어주셔서 감사합니다.
