Skip to content

jchun.dev

해외취업 후기 6. 면접 후기 (2) 온라인 인터뷰

careers6 min read

Table of Content

  1. 프롤로그 - 우리는 왜 떠나는가
  2. 어떤 나라로 갈까? - 미국
  3. 어떤 나라로 갈까? - 미국 외 지역
  4. 해외 기업들의 엔지니어 채용 과정
  5. 면접 후기 (1) 이력서 준비와 지원
  6. 면접 후기 (2) 온라인 인터뷰
  7. 면접 후기 (3) 온사이트 인터뷰
  8. 면접 후기 (4) 오퍼 협상
  9. 마치며 - 우리는 왜 떠났는가

여섯 번째 글부터는, 첫 리크루터 콜부터 최종 면접에 이르기까지의 개인적인 준비 과정과 경험담을 세 편 정도로 나누 조금 더 자세히 이야기 해보겠습니다. 지원하시는 회사, 직군, 지원 시점, 지원하시는 분의 경력에 따라 면접의 형태와 질문들은 조금씩 달라질 것입니다. 따라서 제 준비 과정과 경험이 해외 취업을 준비하시는 다른 분들께도 완전히 똑같이 적용될 수는 없겠지만, 전체적인 준비와 면접 과정에 대해 사례를 보면서 감을 잡는다는 느낌으로 가볍게 읽어주시면 감사드리겠습니다.

(제가 면접을 본 각 회사들과의 기밀유지서약 이슈로 인해 회사의 정확한 이름과 자세한 면접 문제들은 공개하지 않습니다. 양해 부탁드립니다.)

01
화기애애한 면접 과정(?) 출처: Unsplash

코딩, 얼마나 연습해야 할까?

FANG 등의 글로벌 기업뿐만 아니라, 많은 테크 회사들의 개발자 면접에서 자료구조와 알고리즘 관련 코딩 문제를 묻는 것은 이제 매우 흔한 일이 되었습니다. 말 그대로 주어진 문제를 시간/공간(메모리) 차원에서 가장 효율적으로 해결할 수 있는 알고리즘을 코드로 작성하는 형태의 문제입니다. ACM-ICPC, TopCoder, Codeforces 등의 Competitive Programming 을 경험해보신 분들이라면 비교적 익숙하실 것이며, 해당 대회/플랫폼을 경험해보신 적이 없는 분이더라도 LeetCodeHackerRank 등의 서비스를 통해 알고리즘과 자료구조 관련 문제들을 쉽게 연습해보실 수 있습니다.

대학교 학부 과정에서 전산학/컴퓨터공학을 전공하셨고 학부 수준의 자료구조/알고리즘의 내용들을 확실히 기억하고 계신다면 금방 익숙하게 문제들을 풀 수 있게 됩니다. 그런데 따로 대학 수준의 알고리즘을 공부해본 적이 없거나 공부한 지 한참 되어서 내용이 기억나지 않으면 어떻게 해야 할까요? 저도 면접 준비를 하면서 대학 시절 배웠던 내용들이 가물가물해서 처음부터 다시 공부를 해야 했는데요, 제가 준비한 과정을 돌이켜보면 다음과 같은 세 단계로 준비를 해나갔던 것 같습니다.

1. 책으로 기본 개념 잡기

문제를 풀기 위한 기초 지식부터 하나하나 쌓아가야 하는 입장이라면, 먼저 좋은 책으로 기본적인 개념을 확실하게 잡을 필요가 있습니다. 개인적으로 아래 두 책을 알고리즘을 공부할 때 유용하게 활용했습니다.

알고리즘 뿐만 아니라 전반적인 면접 과정에 대해 미리 살펴보고 싶으신 경우, [Cracking the Coding Interview] 책이 시중에서 가장 유명한 편입니다. (번역본도 있습니다)

2. LeetCode / HackerRank 등의 플랫폼으로 연습하기

알고리즘에 대한 기본 개념을 잡은 후, 본격적으로 코딩 면접을 연습하려면 직접 문제들을 풀어보는 것이 가장 확실한 방법일 것입니다. 두 사이트는 각각 처음 인터뷰를 준비하시는 분들을 위한 문제 set들을 아래와 같이 준비해놓았으므로, 해당 문제들부터 접근해보시면 수월하게 시작하실 수 있습니다.

두 세트를 끝내신 후에는 문제 풀이가 익숙해지실 때까지 꾸준히 많은 문제들을 풀어보면서 연습을 하시면 되는데요, 인터넷을 찾아보시면 300문제를 풀고 입사했니, 450문제는 풀어야 하니 하는 후기들이 많습니다만, 개인적으로 얼마나 많은 문제를 풀었는지보다는 어느 정도 수준의 문제까지 풀수 있는지 가 중요하다고 생각합니다. 저는 45분(면접 한 세션) 정도의 시간 안에 LeetCode 기준 대부분의 Medium ~ 정답률이 높은(비교적 쉬운) Hard를 자신 있게 풀 수 있는 정도까지 문제 풀이를 연습했습니다.

3. 실전 연습하기

LeetCode 등을 통해 문제풀이가 충분히 연습되셨다면, 실전과 비슷한 환경에서 리허설을 해 볼 때입니다. LeetCode와 실제 면접 환경의 다른 점을 꼽아보라면 아래와 같은 것들이 있습니다.

  • 컴파일과 실행이 가능한 IDE 환경이 아닌 Syntax Highlighting만 되는 편집기, 혹은 그냥 Google Docs나 화이트보드 위에서 코딩을 해야 할 때도 있습니다.
  • 컴퓨터에서 실행만 되면 그만인 코드가 아닌, 사람이 읽었을 때 명확하게 코드의 의미를 이해할 수 있는 명료하고 깔끔한 코드를 짜는 것이 더 좋습니다.
  • 혼자 문제를 푸는 것이 아닌 면접관과 함께 진행하는 면접이므로, 논리를 전개하는 과정을 말로 설명해가며(Thinking out Loud) 문제를 풀어나가는 연습이 필요합니다.

혼자서 연습하기 어려운 부분들도 있으므로, 같이 면접을 준비하시는 분들과, 혹은 모의 면접 서비스 등을 통해 실제와 최대한 비슷한 환경에서 면접 연습을 진행해보시는 것을 추천드립니다. 스터디그룹이나 지인과 함께 준비하는 형태가 아닌 혼자서 이직을 준비하시는 경우, Pramp 등의 서비스를 통해 익명의 다른 유저들과 p2p로 면접 연습을 하실 수 있습니다.

다음 단락부터는 제 개인적인 면접 경험을 사례별로 소개해보겠습니다.

시애틀 A사 - Online Assessment

A사의 경우 리테일 서비스(aka 닷컴)를 담당하는 부서들은 면접관들이 한국으로 출장을 와서 hiring event를 여는 경우도 있는 반면, 클라우드 서비스를 담당하는 부서들은 지원자가 직접 지원을 해서 면접을 보는 전형적인 채용 절차를 아직 많이 진행하는 듯합니다. 두 경우 다 공통적으로 온라인 면접(online screening)을 한 번 혹은 두 번 진행하는데요. 첫 번째 면접은 지원자가 원하는 때 사이트에 접속해서 진행하는 Online Assessment 형태로 이루어집니다.

Online Assessment는 TOEIC/IELTS 등 영어 시험의 CBT와 비슷한 형태라고 생각하시면 될 것 같습니다. 2문제의 알고리즘 문제를 90분 정도에 걸쳐서 푸는 Part 1과, 해당 문제를 푼 알고리즘의 시간복잡도와 공간복잡도에 대한 설명을 15-20분 정도 안에 서술하는 Part 2로 나뉘며, 파트 중간에 쉬는 시간을 가질 수 있지만 한 파트 안에서는 쉬는 시간 없이 연속으로 면접(시험?)을 치러야 합니다. 면접관의 개입 없이 자동화된 시스템에서 진행되는 테스트이므로, 지원자가 원하는 시간에 면접을 진행할 수 있습니다. 두 파트의 테스트가 끝나면 O/X로 답하는 수십문항 정도의 가벼운 직무적성평가(나는 압박 속에서 성과를 내려고 노력한다! 같은 질문들) 같은 것도 있는데요, 해당 부분에 대해서는 아는 바가 없어 자세한 설명은 생략하겠습니다.

문제는 크게 어렵지 않은 편이고, 테스트를 진행하는 웹사이트 환경에서 코드를 직접 실행하고 테스트 케이스(예시 입출력)의 통과 여부들도 확인할 수 있었습니다. 문제 또한 LeetCode 등의 사이트에서 볼 수 있는 문제들과 흡사하게 나오기 때문에 비교적 가벼운 마음으로 면접을 볼 수 있었습니다. 면접 결과 혹은 전반적인 채용 스케줄에 따라 면접관과 직접 화상으로 면접을 보는 세션을 한 번 더 갖기도 하고 바로 onsite로 넘어가기도 하는 것 같습니다. 저는 면접 후 onsite로 바로 넘어가서 화상 면접 세션은 진행하지 않았습니다.

런던 B사, 싱가포르 C사 - 화상 코딩 인터뷰

글로벌 기업 B사의 런던 오피스와 Pre-IPO 스타트업 C사의 싱가포르 본사에서도 인터뷰를 진행했는데요, 면접관과 화상으로 면접을 진행할 때는 대화가 가능한 화상 전화 연결과 별도로 coderpad.io 등과 같이 제가 코딩하는 과정을 실시간으로 공유받을 수 있는 세션을 통해 면접을 진행하게 됩니다. 45분 정도의 세션에서 대부분(30-40분)의 시간은 코딩을 진행하고 마지막 5-10분 정도 가벼운 질의응답을 주고받게 됩니다.

문제 자체는 크게 어렵지 않았으나 한 회사는 단순히 문제를 올바르게 푸는 것을 넘어 솔루션을 얼마나 더 최적화할 수 있을지를 깊게 파고드는 질문이 들어와서 인상적이었습니다. 예를 들어, 똑같이 시간복잡도가 O(n)인 솔루션을 제안했더라도 메모리를 읽어들이는 횟수를 줄이거나, 불필요한 오버헤드를 없애서 지금의 코드보다 조금이라도 더 효율적인 로직을 작성할 수 있을지 물어보는 식이었습니다.

처음 몇 번의 면접을 본 후에 피드백을 받고서야 알게 된 것이 있는데요, 문제를 푸는 좋은 코드를 작성하는 것뿐만 아니라 제가 작성한 코드가 올바르게 돌아간다는 것을 입증하는 테스트를 작성해가며 일종의 TDD(Test Driven Development)를 하는 것이 도움이 되었습니다. 당연한 입출력 케이스뿐만 아니라 처리해두지 않으면 코드가 오류를 낼 edge-case input들(divide by 0 등), 복잡한 입출력 등 다양한 경우를 미리 테스트 케이스로 커버해두고, 해당 테스트 케이스를 커버할 수 있도록 코드를 작성해나가는 형태로 인터뷰를 진행해봅시다.

암스테르담 D사 - SRE(Site Reliability Engineering) 면접

암스테르담에 본사가 있는 D사를 포함한 몇몇 회사에는 일반적인 소프트웨어 엔지니어(SWE; Software Engineer) 가 아닌 사이트 신뢰성 엔지니어(SRE; Site Reliability Engineer) 포지션으로 면접을 진행하기도 했습니다. SRE는 일반적인 소프트웨어 엔지니어링과 더불어 서비스의 백엔드를 글로벌 규모로 확장하기 위한 대규모 인프라 운영/자동화 등의 기술을 추가로 연구/개발하는 직군인데요, 이로 인해서 시스템, 특히 리눅스 인터널에 대한 질문을 알고리즘 면접과 별도로 준비해야 했습니다.

이전 직장에서 서버를 운영하는 일을 했음에도 리눅스 인터널에는 깊은 지식이 없어서 개인적으로 고생을 했는데요, 운영체제, 시스템 프로그래밍, 네트워크 등의 기초적인 지식 뿐 아니라 실제로 리눅스 커널의 특정 기능(process scheduler, virtual file system 등)이 어떻게 작동하는지, 리눅스 서버와 프로세스를 모니터링하고 디버깅하기 위한 툴(strace, top 등)을 어떻게 활용하는지까지 넓고 깊은 카테고리에 대한 질문을 받게 됩니다 (예시로 든 키워드가 면접에 나오진 않았으며, 공부했던 키워드 중 일부를 예로 든 것입니다). 실제로 리눅스 시스템을 운영해본 경험이 적다면 준비하는데 많은 어려움을 겪게 될 것이며, 저도 실제로 많이 준비를 하고도 면접에서 잘 하지는 못했습니다. ㅠㅠ

리눅스 시스템 지식에 대한 인터뷰는 알고리즘 인터뷰와 달리 여러 형태로 진행됩니다.

  • 물론 일반적인 질의응답 형태로 인터뷰를 진행하는 것이 가장 흔하구요,
  • '우리가 운영하는 서버에 이러이러한 장애가 나타나고 있어, 어떻게 문제의 증상과 원인을 파악하고 해결할까? 원하는 정보를 얻으려면 서버에 접속해서 어떤 명령어를 입력해야 할까?' 에서 시작하는 일종의 모의 트러블슈팅 형태의 질문도 받은 적이 있습니다.
  • 한 회사는 실제로 장애를 인위적으로 만들어낸 서버의 접속 주소를 던져주고(!) 해당 서버에 접속해서 시간 내에 문제의 원인을 파악해서 직접 해결하는 형태의 인터뷰를 진행하기도 했습니다.
02
지원자는(은) 눈앞이 깜깜해졌다! 출처: Unsplash

부끄러운 이야기들

잘 진행되어서 온사이트 면접과 오퍼까지 이어진 인터뷰도 있었지만, 물론 모든 면접이 예상한 대로 잘 진행될 리는 없습니다. 조금 부끄럽지만, 어처구니없는 실수를 해서 광탈! 했던 면접들도 소개해 보겠습니다.

  • 비영리 재단 E사: 프로젝트 리드급 이상의 직군을 의미하는 'Staff' Software Engineer를 일반적인 '스태프'의 의미로 잘못 알아듣고 지원을 했다가 얼떨결에 면접까지 갔었습니다.

    "어 그런데... resume를 쭉 보니 프로젝트 리드 경험은 비교적 적으신데 왜 Staff Level로 지원을 하셨나요?"

    "음, Staff면 그냥 일반적인 엔지니어 포지션 아닌가요?"

    "아뇨, 저희는 10명 이상의 팀을 수 년 이상 리드해오셨던 분을 찾고 있는데요?"

    "...?"

  • 스타트업 F사: 당연히 알고리즘 문제를 물어볼 줄 알았는데 갑작스럽게 fit에 대한 질문들이 들어와 당황해서 허둥대며 면접을 봤습니다. 제대로 대답도 못하고 횡설수설한 면접은 다음 대답과 함께 화려하게 망했습니다.

    "그러면 팀에 들어와서 엔지니어로 더 성장하면 어떤 것을 하고 싶으신가요?"

    "네? 어... 같이 일하던 동료들과 함께 창업을 해서 제 비즈니스를 만들어보고 싶은데요."

    "음... 그러니까... 회사에 입사한 다음 저희 동료들을 데리고 나가시겠다구요?"

    "네?"

  • 글로벌 기업 G사: 준비가 덜 되어서 당황했던 앞의 경우들과 반대로, 몇 번의 면접을 통과하고 나서 자신감이 너무 차올라 있었다가 무례한 대답을 했던 사례도 있었습니다.

    "이걸로 인터뷰는 마무리합시다. Python으로 코드를 대부분 짜셨는데 Python이 주로 쓰는 언어신가요?"

    "아니요, Go를 주로 쓰구요, 사실 Python은 싫어해요. 면접 볼때는 쉽게 코딩할 수 있어서 쓰는 거구요."

    "어... 미안한데요, 저희 팀의 백엔드 코드베이스 대부분이 Python이에요. Python을 싫어하신다구요?"

    "!"

당장 생각나는 사례들만 이 정도라면, 제가 모르고 있는 실수까지 세면 헤아리기 힘들 만큼 많은 실수들을 면접 때 했을 것 같습니다. 저처럼 바보같은 실수를 하는 경우를 줄이기 위해서, 이 글을 보시는 취업/이직준비생 여러분들은 면접을 볼 때마다 피드백을 요청해서 다음 면접에 도움이 되는 조언들을 얻으시길 바랍니다!

[7. 면접 후기 (3) 온사이트 인터뷰]로 이어집니다.