미국 회사 인턴십 면접 후기 (2)

12월 초에 내가 정말 가고 싶던 회사에서 최종 개발자 인턴십 면접을 봤다. 정말 운이 좋게 합격할 수 있었다. 

NDA를 사인했기 때문에 정확히 면접에서 무엇을 물어봤는지는 공유할 수 없다.

하지만 나는 어떻게 준비했고, 면접을 통과하기 위해 어떤 부분이 중요한 것 같다는 개인적인 생각을 공유하고 싶다.

 

M사 같은 경우 개발자 인턴 리크루팅 프로세스는 총 3단계가 있다.

 

1) Resume Screening (레쥬메 스크리닝)

2) Phone Interview (1차 45분 Technical 인터뷰)

3) Virtual On-site interview  (2차 45분 Technical 인터뷰) 

 

Resume Screening 

개인적으로 제일 통과하기 힘든 부분이 1단계라고 생각한다. 특히나 미래에 비자 스폰서를 해줘야 하는 유학생들을 

회사 입장에서는 굳이 뽑을 필요가 없기 때문에 "난 비자 스폰서를 받을 만큼 실력이 있어!" 다는 걸 1장짜리 이력서에서 보여줘야한다. 

수많은 회사를 지원하면서 난 대부분 레쥬메 스크리닝 단계에서 불합격을 받았다. 그러므로 이 단계에서는 꼭 해당 회사 직원의

referral를 받는 게 좋다. 한국 사회에서는 아는 사람을 취직 시켰다고 하면 고발 당하겠지만 미국에서는 너무나 당연한 시스템이다. 

아예 모르는 사람을 인터뷰하는 것 보다, 직원이 자기 이름을 걸고 추천하는 사람에게 우선순위로 인터뷰 기회를 준다.

물론 레퍼럴을 받았다고 무조건 뽑히는 건 아니다. 요즘엔 Referral을 거의 모든 사람이 받아서 거의 무의미 하다는 말도 들었고, 실제로 레퍼럴을 받았지만 레쥬메에서 통과하지 못한 회사도 있다. 또한, 레쥬메를 통과한 후에는 모두 공평하게 인터뷰를 보고 채용할만한 사람인지 체크를 한다. 하지만 M사 같은 경우 레퍼럴을 통해 지원했고, 지원하고 2일 만에 첫 인터뷰를 보자는 메일이 왔다. 그러므로 M사 같은 경우 레퍼럴이 굉장히 큰 도움이 된 것 같다. 

 

큰 회사의 리쿠르터들은 수 천명, 수 만명의 지원자들의 레쥬메를 읽어야 하므로 어떤 회사에서는 AI를 이용해서 키워드 추출을 하고 Job description과 얼마나 매칭이 되는지 체크한다고 한다. 매칭이 안 된다면 실제 사람이 읽어보지도 않고 불합격한다고 한다.

그래서 나 같은 경우엔 진짜 가고 싶은 회사에는 Job description에 맞게 레쥬메에 키워드들을 바꿨다. 또, 실제로 리크루터들이 레쥬메를 읽더라도 몇 초안에 면접을 볼만한 지원자인지 판단한다고 들었다. 그렇기 때문에 나처럼 경력이 없는 학생들이 인턴을 지원할 때는 예전 인턴십에서는 무엇을 했고, 개인 프로젝트는 무엇을 했는지 이해하기 쉽게 레쥬메에 나타내야 한다. 나 같은 경우 8월에 개강 하자마자 학교 커리어센터에 가서 레쥬메 작성에 도움을 많이 받았었다. 

 

Phone Interview & Virtual Onsite Interview

이 단계는 바로 코딩 인터뷰 단계이다. 인턴이 아니라 풀타임으로 지원을 했다면 최종 인터뷰인 On-site 인터뷰는 실제로 오피스에 가서 

여러 명의 엔지니어를 만나서 4~5번의 인터뷰를 진행한다고 들었다. 하지만 인턴십 같은 경우 1차 면접과 최종 면접의 포멧이 완전히 같았다. 똑같이 45분 동안 엔지니어 앞에서 코딩 문제를 풀어야 한다. 총 45분이지만 처음 5분은 서로 자기소개를 하고 마지막 5분은 QA 시간이다. 따라서, 총 두 문제를 풀어야 하기 때문에 약 15분안에 한 문제씩 풀어야한다. 이렇게 45분의 면접을 두 번 통과해야 최종 합격을 할 수 있다.

사실 이건 많이 푼 것도 아니다. 500-600문제 푸는 친구들도 많다.

코딩 문제 난이도는 회사, 그리고 인터뷰마다 조금씩 다르지만 대부분 알고리즘과 자료구조를

잘 알고 있는 학생이라면 충분히 풀 수 있는 문제들이 주어진다.

문제는 나는 알고리즘을 잘하는 학생이 아니었기 때문에, 미국을 오기 전부터 Leetcode를 풀기 시작했다.

릿코드는 한국 학생들은 잘 알고있는 백준과 비슷한 사이트이다. 해당 사이트에서 실제 기업들이 사용한 알고리즘 문제들을 풀 수 있다. 

미국에 오기 전에 약 150문제 정도를 풀었고 학교에 다니면서도 매일 몇 문제씩 풀어서 지금은 약 270문제를 풀었다. 실제 수업 쉬는 시간에도 동기들이 릿코드 문제를 푸는 걸 많이 본다. 그만큼 미국에서 개발자로 취직, 이직하려면 거의 필수로 사용하는 사이트이다. 

 

M사 같은 경우 문제 난이도는 대부분 미디엄 문제 2개 (가끔 하드나 이지) 가 나온다고 생각하면 된다.

나는 처음에 그냥 무식하게 많이 풀면 실력이 늘겠지 생각했는데 그렇지 않아서 고민하다 Grokking the Coding Interview 라는 강의를 사용했다. 이 사이트는 알고리즘 문제 해결에 사용할 수 있는 패턴들을 알려준다. (sliding window, two pointers, bitwise XOR 등..)

나처럼 알고리즘 문제를 많이 풀지 않았던 사람이라면 이 사이트를 굉장히 추천한다.  이 사이트를 사용하기 전에는 문제를 봐도 어떻게 문제를 접근해야 하는지 막막했는데 패턴이 보이기 시작했고, 이제 대부분 문제를 읽으면 바로

아 이건 투 포인터 문제구나! 이건 DP 문제구나! 알 수 있게 됐다. 

 

하지만 미국 IT회사의 코딩 인터뷰의 핵심은 문제를 풀 수 있냐가 아닌 것 같다.

아 물론 문제를 최종적으로 잘 풀긴 해야 한다.  하지만 개인적으로 더 중요한 건 커뮤니케이션 스킬인 것 같다.

막말로 만약 알고리즘 해결 실력만을 보고 싶은 거라면 실제 엔지니어와 1대1로 인터뷰가 아닌

그냥 알고리즘을 혼자 푸는 OA (online assessment 코딩 테스트) 를 줄 것이다. (실제로 1,2단계가 OA인 회사들이 많다) 

따라서, 코딩 인터뷰에서는 내가 어떻게 해당 문제를 해결할 것인지 정확하게 인터뷰어와 소통하는 게 중요하다.

이 사람과 과연 일을 같이하고 싶은가? 를 본다고 생각한다. 아무리 코딩 실력이 좋아도 입을 꾹 닫고 아무 소통을 하지 않는다면

같이 일하고 싶지 않을 것이다. 그래서 코딩 인터뷰에서는 최대한 많이 말해야 한다. 거의 TMI 수준으로 말해야 한다고 생각한다. 

 

코딩 인터뷰에서 주어지는 알고리즘 문제들은 실제 회사에서 하는 일과는 굉장히 다르다. 실제 회사에 가서 Binary tree를 invert 하거나 Linked list의 cycle을 찾는 프로그램을 짜진 않을 것이다. 하지만 처음 보는 문제를 보고 중요한 질문을 하고, 다른 엔지니어와 같이 소통을 하면서 문제를 풀어야 하는 것은 같다.  그래서 나는 면접을 볼때 중요하게 6단계로 나눠서 문제를 풀었다

 

1) 문제에 대해 질문하기

2) Brute Force로 어떻게 풀어야 하는지 설명 -> 시간,공간복잡도 설명. 너무 느리기 때문에 다른 해결책을 생각

3) 어떻게 더 효율적으로 풀 수 있는지 설명 -> 시간, 공간 복잡도 설명 

4) 수도 코드 작성 

5) 실제 코드 작성  

6) 테스트 케이스 생각해서 잘 돌아가는지 시뮬레이션해서 보여주기 

 

문제에 대해 질문하기 

실제로 백준이나 릿코드처럼 명확하게 문제가 주어지는 게 아니라 인터뷰어가 말로 문제를 내거나 Input output 을 안알려줄 수 있다.

그러므로 질문을 해서 문제를 더 정확하게 만들어야 한다. 또한, 이러한 질문을 통해 내가 이 문제를 진짜 잘 이해한 건지 인터뷰어와 확인을 할 수 있다. 

 

예를 들어, 유명한 Two Sum 문제를 생각해보자. 릿코드엔 해당 문제가 이렇게 설명되어 있다. 

Given an array of integers nums and an integer target, 
return indices of the two numbers such that they add up to target.

You may assume that each input would have exactly one solution, 
and you may not use the same element twice.
You can return the answer in any order.

인터뷰에 똑같은 문제가 주어진다면 

"배열에서 sum이 target 이 되는 두 숫자의 index를 구해라" 라고 디테일을 모두 생략하고 물어볼 수 있다.

또한, 백준이나 릿코드처럼 input output 예시를 아예 주지 않을 수도 있다. test case를 생각해내는 것도 중요한 스킬이라고 생각한다.

따라서 질문을 최대한 많이 해서 문제를 더 정확히 이해해야 한다. 예를 들어 

"배열은 이미 정렬되어서 주어지는 건가요?"

"배열에는 중복되는 숫자가 없나요?" 같은 질문을 해서 모호하거나 헷갈렸던 부분을 다 없애야 한다. 

 

Brute Force로 어떻게 풀어야 하는지 설명 

이 단계는 처음 보는 문제여서 바로 푸는 방법이 생각이 안 날 때 사용한 방법이다. 

일단 브루트 포스를 통해 무식하게 짜는 방법이라도 인터뷰어에게 설명했다. 당연히 인터뷰어는 이런 방식으로 문제를 해결하는걸

원하지 않는다. Two sum 문제같은 경우 이중 for loop을 사용해 모든 pair의 sum을 체크하는 것이다. 하지만 브루트 포스로 해결하면서 문제를 풀다보면 어떤 부분에서 bottleneck이 발생하는지 알 수 있다.  또한, 최악의 경우엔 브루트 포스로라도 문제를 풀어서 느리지만, 문제를 최소한 그래도 풀 수 있다는걸 보여주는 게 좋은 것 같다. 처음 보는 문제가 어렵다고 아예 풀지 못하고 면접이 끝난다면 합격 확률은 0이 될 것이다. 

 

어떻게 더 효율적이게 풀 수 있는지 설명

당연히 인터뷰어가 원하는 건 optimal 하게 문제를 푸는 방법이다. 따라서, 브루트 포스 접근 방식이 아닌 다른 알고리즘을

생각해야 한다. 하지만 바로 코딩을 하는 게 아니라 이 문제를 이런 게 필요하니 해당 알고리즘을 사용하면 더 효과적으로 풀 수 있다고 말로 일단 설명하고, 수도 코드를 작성했다. 수도 코드를 빨리 작성한 뒤에 테스트 케이스 1-2개를 만들어서 실제로 아웃풋이 제대로 나오는지 보여주고 제일 마지막으로 코딩을 했다. 그래서 한 문제당 15분을 써도 실제로 코딩을 하는 시간은 5-6분밖에 되지 않았던 것 같다. 

수도 코드를 잘 작성하고 이미 테스트케이스를 한번 시뮬레이션해 본 상태라면 코드는 쉽게 짤 수 있다. 

 

1-6단계에서 막히는 부분이 높은 확률로 있을 수 있다. 그건 너무나 당연한 거다. 하지만 당황하지 않고 질문을 하거나 인터뷰어에게 내 생각을 계속 얘기해야 한다. 만약 optimal 한 해결책이 생각이 안나더라도 정확히 어떤 부분이 이해가 안가는지, 무엇 때문에 막히는지 설명하면 인터뷰어가 힌트를 줄 수도 있다. 문제가 안 풀린다고 포기하지 않고 계속해서 면접관과 소통하는 게 중요하다. 

미국에 도착하고 바로 산 화이트 보드

영어가 어려운 유학생들이 인터뷰를 보면 코딩을 하는 것보다 앞에서 설명했던 커뮤니케이션 부분이 어려울 것이라고 생각한다. 알고리즘 문제도 풀기 바쁜데 영어로 그걸 동시에 설명하는 게 어려웠다. 그래서 나는 미국에 오자마자 대형 화이트 보드를 구매해서 혼자 문제를 풀 때도 마치 앞에 누가 있는 것처럼 혼잣말을 하면서 문제를 풀었다. 그리고 같이 인턴십을 찾는 동기들 몇 명을 찾아서 매주 모의 면접을 봤다. 1학기 동안 거의 모의 면접을 20번은 본 것 같다. 그래서 실제 면접을 볼 때 크게 떨리거나 하지 않아서 굉장히 큰 도움이 됐다. 커뮤니케이션 부분은 혼자 연습하기엔 한계가 있으니, 같이 연습할 수 있는 친구를 구하면 좋은 것 같다. 또 모의 면접을 하면 면접관 역할을 하게 되는데, 이게 많이 도움이 됐다. 면접관 입장에서 면접을 보면 어떤 식으로 얘기를 하고 문제를 풀어야 더 좋게 보이는지 더 정확하게 느끼게 되는 것 같다. 

 

글을 쓰고 보니 꼭 엄청 잘아는 사람처럼 이렇게 글을 썻지만 나는 아직도 많이 부족하다. 사실 내가 아직 어떻게 합격 했는지, 합격한건 맞는지 믿기지 않는다.  M사와 핀테크 회사 두 군데 빼고는 많은 면접에서 불합격을 받았다.

사실 면접은 결국에 운이 엄청나게 크게 작용한다고 생각한다. 그날 내 컨디션, 어떤 면접관을 만나는지,

또 어떤 문제를 받냐는 정말 랜덤하기 때문에 운이 따라줘야 면접에 통과할 수 있다.

그러므로 합격한 건 정말 운이 많이 따랐다고 생각한다. 

커뮤니케이션 부분, 알고리즘 해결 능력도 아직 한참 부족하므로 2022년에도 더 공부해야 한다.