brunch

You can make anything
by writing

C.S.Lewis

by 륜 Ian Apr 29. 2017

소프트웨어 개발자의 인터뷰 준비과정

Microsoft에서 이직을 결심하다 - 4

막무가내로 인터뷰 일정을 잡았다고는 해도, 준비까지 막무가내로 할 수는 없었다. 소프트웨어 개발자의 인터뷰는, 다른 분야와는 상이한 부분이 많다. 지금까지 해 온 일들에 대한 이야기를 나눈다던지, 특정 상황에서 어떤 식으로 대처해서 문제를 해결해 나갈 것인지 같은 소위 말하는 behavioural interview는 적은 비중을 차지하고, 대부분은 주어진 문제를 화이트보드에 적어나가는 방식으로 진행된다. 준비를 안 한 상태에서 본 첫 인터뷰에서 크게 데었기 때문에, 다시 같은 실수를 되풀이하고 싶지는 않았다. 책상 앞에 앉아서 간단하게 인터뷰 준비 계획을 세운 뒤 다음과 같은 방식으로 진행했다.

1. Cracking the coding interview를 재빠르게 훑으면서 전반적인 data structure 및 알고리즘에 대한 복습

미국에서 소프트웨어 개발 면접 관련 서적 중에 가장 유명한 것을 꼽으라면 역시 Cracking the coding interview일 것이다.

이렇게 유용합니다

구글을 포함한 수많은 대기업들에서 면접관으로 근무를 하고 현재는 Careercup의 CEO로 재직 중인 Gayle Mcdowell이라는 여성 개발자 분이 쓴 책인데, 전 에디션들은 PDF로 구글에서 쉽게 찾을 수 있는 데다가 알고리즘과 Data structure가 간단하게 잘 정리되어 있어 한번 훑어볼 가치가 있는 책이다. 다만 책에 실린 문제들은 책이 유명해지면서 면접관들이 가장 기피하는 문제들로 낙인찍혔기 때문에 혹시나 이 문제들이 실제로 출제되지는 않을까 하는 기대는 접는 것이 좋다. 전에 근무하던 회사에서 면접관으로 일할 당시 면접관들 지침서 같은 위키가 있었는데 거기에도 아예 대놓고 Cracking the coding interview에 나와있는 문제는 제시하지 말 것!이라고 쓰여있었다.

시간에 여유가 있다면 대학교에서 전공서적으로 사용되는 알고리즘 책을 꼼꼼하게 복습하는 것이 훨씬 도움이 되겠지만, 여유가 별로 없었던 나는 이 책을 재빨리 한번 훑는 것으로 대신했다. 실제 업무에서도 자주 쓰이는 List라던지 Hash Map/Dictionary 같은 경우는 특별할 것이 없었지만 그 외에 자주 사용되지 않는 Data structure와 알고리즘에 대한 부분은 꽤나 도움이 되었다. 조금 아쉬운 점이라면 요즘 들어 출제빈도가 높아진 듯한 Dynamic Progeramming에 대한 부분이 많지 않다는 것. DP는 가장 어려운 난이도의 문제들 중 하나기 때문에 더 기본적인 것들에 집중하다 보니 그렇게 된 듯하다.

2. Glassdoor나 Careercup에서 인터뷰를 보기로 한 회사들의 최근 2년간 기출문제들 풀어보기

Glassdoor는 한국의 JobKorea와 비슷하게 직원들이 남긴 기업 후기를 볼 수 있는 사이트로 단순히 면접 관련된 부분뿐만 아니라, 회사의 복지정책과 근무환경 등에 대해 객관적인 정보와 주관적인 직원들의 평가를 볼 수 있는 곳이다. 테크 회사들의 인터뷰 난이도를 측정할 때 종종 이 사이트의 정보가 사용되기도 하는데 그에 의하면 Google과 Amazon, 그리고 AirBnB의 면접이 가장 어려운 축에 속한다고 한다 (실제로 신빙성이 있는지는 모르겠다). 또 가끔씩 한국 뉴스 기사에 등장하는 미국에서 가장 일하기 좋은 회사 50선 같은 류의 순위 보고서의 출처가 되기도 한다. Glassdoor의 면접 후기 부분을 살펴보면 몇몇 친절한 (그리고 회사와의 NDA를 무시한..?) 지원자들이 면접 도중에 출제된 문제를 공유하는 글들이 있는데 그런 문제들은 가능한 전부 다 풀어보았다.

Careercup은 면접 출제 문제들만을 모아놓은 사이트로 테크 회사들의 기출문제를 찾기에는 가장 좋은 소스 중 하나가 아닌가 싶다. 구글이나 아마존 같은 유명한 회사들은 상당한 규모의 기출문제은행이 형성되어 있고 문제의 종류도 다양하다. 이 곳에는 문제 수가 너무 많았기 때문에 전부 다 풀어볼 수는 없었고, 최근 2년 사이에 올라온 문제들만 집중적으로 풀어보았다.

이 방법에는 사실 두 가지 큰 문제가 있다. 첫째로, 문제의 불명확함이다. 기출문제들은 지원자들이 면접을 보고 온 뒤에 올리기 때문에 몇몇 중요한 디테일을 기억하지 못하는 경우가 종종 있다. 그런 문제들은 읽어도 정확한 문제의 목적을 알기가 어렵고 고로 어떻게 접근해야 할지도 알 수가 없다. 둘째로, 예시 답안의 부제다. 보통 지원자들이 기출문제를 올리면, 다른 사람들이 문제를 풀어본 다음에 자신의 접근방법을 댓글로 공유하는데, 대부분의 경우에 그 방법들이 얼마나 효율적인지, 또 문제 출제자의 의도와 일치하는지 알 방법이 없다. 즉, 누가 악의적으로 트롤링을 해서 잘못된 해답을 제시한다면, 무의식적으로, 혹은 의식적으로 문제에 대해 완전히 잘못된 정보를 갖고 있게 될 수 있다.

3. Leetcode에서 가장 면접에서 등장할 확률이 높은 문제들 풀어보기

최근 들어 가장 핫한 면접 준비 사이트들 중 하나인 Leetcode는, 보유한 문제가 그렇게 많지는 않지만 (500-600문제) 적중률이 높고, 제공하는 콘솔 윈도에 본인이 작성한 코드를 넣은 후 다른 사람들이 작성한 코드들과의 퍼포먼스를 비교해 볼 수 있는 기능을 제공한다는 점에서 상당히 유용한 사이트이다. 또한 프리미엄 멤버로 가입하면, 각 문제가 제출되는 빈도를 확인할 수 있는데 면접들을 다 보고 난 뒤에 실제로 이 정보가 어느 정도 맞다는 사실에 좀 놀랐다.

나는 첫째로 Bit Manipulation을 제외한 다른 문제 유형들은 각 유형 당 최소 5문제 이상을 풀어보았고, 그 후에는 난이도 순으로 정렬한 후, 쉬운 문제들부터 시간이 허용하는 한에서 가능한 많은 문제를 풀어보았다. 최종적으로는 약 50문제 정도를 푼 상태에서 폰 인터뷰들을 진행하기 시작했고, 모든 인터뷰를 마칠 때쯤에는 200문제 정도를 풀어볼 수 있었다. Leetcode도 사이트에서 자체적으로 해답을 제시하지는 않지만 다른 사용자들이 공유하는 답들의 질이 굉장히 높았고 설명 또한 자세했기 때문에 크게 문제가 되지는 않았다. 또 내가 작성한 코드의 성능을 시험해 볼 수 있다는 점도 매력적이었다. 다만, 이 부분에 있어서는 내가 작성한 코드가 모든 사용자들의 코드 대비 40% 이상의 속도가 나온다면 (100%가 가장 빠른 코드라고 가정했을 때), 이 이상의 성능 차이는 big O에서 상수값으로서의 차이에 불과하다고 생각했기 때문에 더 이상 성능 향상을 위해 시간을 투자하지는 않았다. 개인적으로 Leetcode가 가장 도움이 많이 되었던 것 같다.

4. Object Oriented Programming/Design에 대한 글 들을 찾아서 읽어보고 몇몇 유명한 문제들을 직접 풀어보기

불행하게도, 지금까지도 Object Oriented Programming/Design문제들은 어떤 식으로 준비해야 하는지 알 수가 없다. 코딩 문제들은 위와 같은 방법으로 충분히 준비할 수가 있지만 정해진 답변도 없고, 문제의 출제 범위도 무궁무진한 OOP/OOD문제들은 단기간에 족집게 과외하듯이 준비할 수 있는 성격의 것이 아니라 직접 개발자로서의 근무하면서 실무경험을 쌓아야 하는 부분인 듯하다.

그렇다고 아무 준비도 안 하고 면접에 임할 수는 없었기 때문에 나름의 방법이라고 생각해낸 것이: OOP/OOD가 무엇인지 다시 한번 명확하게 이해를 하고, 관련된 유명한 디자인 패턴들을 복습하고, 실제로 유명한 문제들 (Uber 같은 차량 공유 앱 디자인, 주차장 디자인, 자판기 디자인 등등)을 직접 종이에 풀어보는 것이었다.

유튜브나 구글을 뒤지면 면접 준비를 위한 OOP/OOD 복습에 대한 글 들을 쉽게 찾아볼 수 있다. 최우선 적으로 그런 글들을 읽어보면서 OOP/OOD의 목적에 대한 올바른 이해를 갖기 위해 노력했다. 그 후에는 위키피디아에서 Design Pattern을 검색하면 나오는 패턴들 중 가장 유명한 것들 위주로 읽어보았다. 그리고 마지막으로 인터넷을 찾아봐서 나온 유명한 OOP/OOD문제 들을 직접 종이에 풀어보았다. OOP/OOD문제들은 두리뭉실한 부분이 많기 때문에 한번 예시 답안을 훑어보고 넘어가는 경우가 많은데 나는 직접 풀어보는 것을 강력하게 추천하고 싶다. 직접 종이에 적어보면, 그렇게 호락호락하지 않다는 것을 알 수 있다. OOP/OOD 문제들은 시간이 제한된 인터뷰에서 막힘없이, 그리고 끊임없이 새로운 아이디어를 제시하고 다양한 관점에서 문제에 접근하는 것이 중요하기 때문에 미리 이런 연습을 해보는 것이 정말 중요한 것 같다.

5. 면접 전날 각 회사가 추구하는 가치에 대해서 한번 읽어보기

대기업들(특히 아마존)은 지원자가 자기 회사에서 추구한 가치들에 얼마나 부합하는지 확인해보려는 경향이 있다. 그 과정은 직접적으로 회사의 가치에 대한 이야기를 나누는 것만이 아니라 인터뷰 도중 지원자가 보여주는 태도와 접근방법으로부터 도출해 내는 것도 포함한다. 모든 테크니컬 인터뷰를 완벽하게 해낸다면 상관없겠지만, 어정쩡한 상태라면 이런 부분이 당락을 결정할 수 있기 때문에 인터뷰 전날 30분 정도라도 투자해서 회사가 추구하는 가장 중요한 가치들이 어떤 것들이 있는지 살펴보는 것이 좋다. 나 역시 면접 전날 밤에 회사들의 홈페이지에 들어가서 이런 가치들에 대한 부분들을 훑어보고 면접에 임했고, 실제로 면접 도중에 내가 이런 가치들에 대해 인지하고 있다는 것을 끊임없이 어필하려고 노력했다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari