Topic Edit: 구글, 아마존 등 면접 후기

This topic has [20] replies, 0 voices, and was last updated 3 years ago by adf.

Now Editing “구글, 아마존 등 면접 후기”

Name *

Password *

Topic Title (Maximum Length 80)

몇달 전 구글, 아마존, 등 7개 IT회사에 면접을 봤습니다. 스타트업 1개 빼고 모두 오퍼를 받았습니다. 경력은 중소기업에서 4년입니다. 인터뷰 준비할 때, 여러 사람들에게 도움을 구했었습니다. 대부분의 조언은, 네가 충분히 깔끔한 코드를 짤 수 있고, API 정의 등 일 하는 방법이 깔끔하며, 생각하는 과정을 인터뷰어에게 잘 전할 수 있으면 충분히 붙을 수 있다, 였습니다. 그런데 이건 짬이 쌓여야 알 수 있는거고, 대부분의 지원자들은 "그래서 진도를 어디까지 나가야 하는건데", "시험범위가 어디고 공부를 어디서 해야 하는건데"가 더 중요하게 느껴지기 마련입니다. 저도 그랬구요. 그래서 그쪽으로 정리를 해 보려고 합니다.

1. 구글은 폰스크린부터 온사이트까지, 한 세션당 딱 한 문제씩만 풀었습니다. 딱 leetcode medium정도 되는 문제였고, 몇몇 후속 질문이 hard 정도 난이도였습니다. 잘 하는 사람은 두세문제 푼다는데, 저는 그냥 한 문제씩만 풀기에도 시간이 빠듯했습니다. 한 세션은 정말 가까스로 구현을 했구요. 그래도 오퍼를 받은걸 보니 두세개씩 푼다는 이야기가 늘 맞는건 아닌가봅니다. 문자열 뒤집기 등 터무니없이 쉬운 문제가 아니고 적당히 짜여져 있는 문제라면 한시간동안 토론까지 다 끝마치는게 꽤 빠듯하긴 하지요. 문제가 적당히 어렵다면 너무 조급하지 않아도 될 것 같습니다.

2. 아마존은 구글보단 쉬운 문제가 나왔습니다. 좀 leetcode easy에서 쉬운 medium 정도? 어렵진 않은 로직을 귀찮게 구현해야 하는 문제가 많았습니다. linkedlist 노드 처리같은거요. 전체적으로 behavioral interview가 훨씬 중요해보였습니다. 리더십 원칙에 푹 절여진 아마존-맨이 아닌 이상 뽑지 않겠다는 의지가 엿보였습니다. 인터넷에 찾아보면 질문 정말 많이 있거든요. 충분한 시간을 들여서, 모든 질문에 겹치지 않는 예시로 완벽하게 대답할 수 있게 준비해야 합니다. 대학교 경험까지 들먹이는 좀 사소하고 미미한 경험으로 약간 민망한 답변을 하는게 한 프로젝트로 울궈먹는 것 보다 낫습니다. 중간에 bar raiser로 보이는 인터뷰가 하나 있었는데... 문제가 어렵다기보단 인터뷰어가 매우 빠르게 끝까지 몰아붙이더군요. 스피드 퀴즈 하나? 왜 말을 끊지? 하는 약간 재수없는 느낌... 차라리 어려운걸 물어보지... 근데 이건 인터뷰마다 다른 것 같아요.

3. 가끔 인터뷰어가 빡대가리라서 자기 문제 자기가 제대로 풀어보지도 않은 상태로 나온다거나, 제가 푼 문제를 이해를 못하는 경우가 있었습니다. 아무리 말해도 끝까지 못 알아먹을 것 같으면, 싸우지 마시고 그런가보다 하면서 정답 물어보고 걔가 답 알려주면 음~ 브릴리언트! 하면서 내가 풀려고 의도했던게 그 방향이었다고 잘 우겨보십시오. 납득도 못 시켰는데 싸우기까지 했다면 그 회사 오퍼는 날아간거라고 하네요.

4. 시스템 디자인은 많이 알려진 문제들이 나왔습니다. 회사 이름은 말씀을 못 드리지만 분산 key-value store 만들기가 두번, tinyurl 짜기 한번, 트위터 만들기 한번... 아무 인터뷰 플랫폼에나 가서 하나 딱 찍으면 나올 법한 그런 문제들이요.

5. 트리, 그래프, 서치 알고리즘 등 단골 문제들은 꼭 나왔습니다. 특히 Geeksforgeeks의 온갖 트리 종류 정리해놓은게 매우 도움되었습니다. 콕 찝어 그 문제가 그대로 나온다기보단, 대충 여러 꼼수들과 개념들을 다 익혀놓은 상황에서, 적당한 필요조건에 맞는 트리를 디자인해봅시다, 하는 느낌... 엄청 어렵고 복잡한걸 외워야 한다기보단, 기본적인걸 아주 잘 알고 그걸 응용할 수 있는 사람을 원하는 것 같았어요. 예를 들면 balanced tree 만드는 알고리즘을 외워서 쌩으로 구현하라고 시키진 않았습니다. 이런 알고리즘이 있다, 는걸 알면 되는 정도. 구현하기 좀 고통스러운거, 예를 들면 tree rotation, 임의 node deletion같은 것도 문제 풀이중에 구현해야 하는 상황이었는데 그냥 있다고 가정합시다... 하고 넘어갔습니다. 다만 tree의 전형적인 성질을 가지고 특정 목적의 tree를 구현해봐라, 예를 들면 segment tree 비스름한 add, delete, range query까지 되는 뭔가를 구현해봐라, 하면 할 수 있어야 했습니다. 이런 문제만 한 세개 나왔어요. 그래프 서치같은건 매번 나왔구요... DFS BFS이런건 그냥 탬플릿처럼 짤 수 있어야 편합니다.

6. leetcode문제 많이 풀어본게 도움이 되었습니다. 면접대비용 몇 가지 연습 방법을 추천드립니다.
(0) 난이도 상관없이 아무 문제나 하나 찍습니다.
(1) 문제 보고 near optimal한 알고리즘 디자인까지 5-10분 안에 마칩니다. big O가 나와야겠지요.
(2) 골격부터, API부터 선언해놓습니다.
(3) 시간 딱 정해놓고 최대한 빨리 예쁘게 구현합니다. 30분?
(4) run 해서 컴파일 에러만 잡습니다.
(5) 테스트케이스를 만들고, 머리속으로 테스트케이스를 돌려봅니다. 10분
(6) submit합니다. submit했을 때 무조건 첫번째에 통과하는 것을 목표로 합니다.

(7) 답을 보고 optimal인지, big O가 맞는지 확인하고, 내 답은 어떤가 반성합니다.
(8) 추천수 제일 많은 코드 보고 내 코드가 얼마나 엉망인지, 
어떤 알고리즘과 데이터 구조에 어떤 전형적인 예쁜 꼼수들이 사용되는지 보고 반성합니다.

(9) 면접관과 할 이야기를 상상해봅니다. 문제 스케일이 엄청 커지면 어떻게 될거라든가, 조건이 이렇게 바뀌면 이렇게 될거라든가, 등등...

요렇게 하루에 두세문제씩 풀었습니다. 열문제씩 풀려고 했는데... 전업이 아닌 이상 어렵더군요.
많은 문제를 풀어서 답을 외우기보단, 아무 문제나 찍었을 때 언제든 시간 내에 제대로 풀 수 있는 상태에 도달하는게 중요해보입니다.
너무 많은 문제를 풀어서 답을 외우는 지경이 되는건 시간낭비, 문제 낭비로 보입니다.
인터뷰 세션을 하나 망친 경험이 있었는데, 풀어본 문제가 아주 어설프게 기억나는 경우였습니다. 차라리 모르는 문제였으면 풀 수 있지 않았을까, 하는 생각이 들더군요. 가물가물 기억나는 힌트 하나에 stuck해서 더이상 풀 수가 없었어요.

7. 잘 알려진 것 처럼 커뮤니케이션이 중요합니다. 문제 정의 잘 해야 하고요. 난 지금 이런 생각을 하고 있는데 알고리즘상으로는 이런게 걱정되는데 이렇게 풀면 풀릴 것 같은데 대충 time complexity가 이럴 것 같은데 이렇게 짜면 구현이 어려울 것 같으니 일단 같은 complexity의 이런 모양을 구현해놓고 improve를 시도해보는게 좋을 것 같은데 니 생각은 어때? 같은... 사실 일상생활에서 이런걸 해볼 일이 없죠. 이런걸 안해보셨다면 또박또박 중얼중얼 할 수 있도록 연습하십시오.

8. 잘 알려진 것 처럼 시간 안배가 중요합니다. 인터뷰어가 시간 안배를 해줄 정도면 이미 늦었다는 뜻입니다. 안되는게 있으면 너무 집착하지 말고 대충 API만 해놓고 넘어가든가, time, space complexity가 엉망이라도 일단 포기하고 넘어가는게 좋습니다. 문제 풀이에 대한 내 사고 과정 하나하나로부터 시작해서 큰 그림을 그리고 그 큰 그림 아래서 내가 이렇게 좌르륵 구현하고 있다, 는걸 보여줘야지 디테일에 집착하다가 거기서 끝나면 꽝입니다.

9. 왜인지 모르겠는데 밑도끝도 없이 hashtable/dictionary 짜봐, 라고 던져준 인터뷰가 무려 세번이나...

이런 인터뷰 잘 본다고 좋은 개발자가 되는건 아니라고 생각합니다. 써놓고 보니 시험 공부만 딸딸 하고 SAT문제은행 딸딸 외우고 공부해서 대학 가려는 전형적인 아시아인 같아 보여서 자괴감이 들긴 하는데 ㅠㅠ 뭐 저는 다른거 잘 못하니까 이런거라도 잘 해야 한다는 생각에... 어느 정도 통하더군요. 외우지 않고 잘 이해했다는 전제 하에요.

잘 하는 사람은 언젠가 자기가 꿈꾸던 좋은 회사에 입사할 수 있을거라고 생각합니다. 다만 좀 더 빠르고 덜 고통스럽게 갈 수 있다면 더 좋겠지요. 그런 마음에서 제 경험과 팁을 공유해봅니다. 도움이 되었으면 합니다.

I agree to the terms of service