구글과 코딩테스트(왜 테크 회사들이 경험 많은 시니어 면접자들에게도 코딩 인터뷰를 시키나요)

번역글 출처: https://m.dcinside.com/board/github/31416

 

 

Matthew Lai, Research Engineer at DeepMind, coauthor of "AlphaGo" :

퍼포먼스를 예측할 때 면접자의 경험은 형편없는 지표이기 때문입니다. 저는 이제 경력 5년차이며, 알파고 프로젝트를 포함한 많은 첨단 머신러닝 프로젝트에 참가했습니다. 경력이 고작 2년뿐인데도 지금의 저보다 훨씬 유능한 사람을 저는 여러 명 보았습니다. 경력을 20년 넘게 쌓았는데도 제가 대학에 입학할 당시보다도 훨씬 실력없는 사람을 저는 수도 없이 봅니다.

저는 CTO라든지 기술 리드라든지 하는 멋진 직함을 가진 사람들을 많이 면접 보았습니다. 이 중 많은 사람들은 제가 기술적 질문을 하기 시작하자마자 헛소리를 하기 시작합니다. 이것은 답을 모르는 것과는 다릅니다. "저는 답을 모르겠는데요" 는 확신에 찬 상태로 틀린 답을 말하는 것보다 훨씬 더 낫기 때문입니다. 많은 "CTO", "기술 리드" 들은 "확신에 차 헛소리를 하는" 카테고리 안에 들어갑니다. 그것은 그들이 쌓은 경력의 종류가 어떤 것들이었는지 보여 줍니다. 그렇게 해도 상관없는 회사들만 평생 다닌 거겠죠. 단지 조금 틀린 것만이 아니라, 너무 완전히 틀려서 제가 그들이 헛소리를 한다고 확신할 정도로 틀리는 경우가 너무 많습니다. (저는 면접자가 대체 왜 그러는지 모르겠습니다. 면접관도 답을 잘 모를 테니 면접자가 하는 말을 그냥 믿을 거라 생각하는 걸까요?) 이 많은 사람들은 모두들 커리어에 대한 흥미로운 이야기와 경험담을 면접 때 들려줍니다 - 오직 기술적인 질문을 받을 때만을 빼고.

저는 CV가 별볼일 없고 관련된 경험이 없으면서도 높은 성숙함과, 기술적인 유능함과, 명료하고 논리적인 사고 과정 (물론 그들이 본 적 없는 기술적 문제들에 대한), 그리고 겸손함을 가진 면접자들도 여럿 보았습니다. 이런 분들에게는 strong hire 추천을 즐겁게 남기게 됩니다.

당신이라면 누구를 고용하시겠습니까?

고작 몇 시간을 써서 미래의 퍼포먼스를 예측할 수 있는 더 나은 방법이 있다면, 구글은 크게 관심이 있을 겁니다. 기술 면접은 항상 이랬던 것이 아닙니다. 그들은 많은 것들을 시도했고, 많은 실험을 했습니다. 아니요, 테이크 홈 과제는 인터뷰보다 낫지 않습니다. 과제를 그 후보자가 했는지 다른 누군가가 대신 한 건지 어떻게 알 수 있나요? 물론 완벽하지는 않습니다. 하지만 학점이나 학벌 따위를 보는 것보단 낫습니다. 그것들은 퍼포먼스와 별로 상관이 없습니다. 그리고 "경험"을 보는 것보다는 훨씬 더 낫습니다. 어떤 사람들은 헛소리로 다른 사람들을 속이는 데에 (대면으로나 CV상으로나) 다른 사람들보다 훨씬 뛰어나니까요.

기술적으로 완전히 답이 없는 사람들에게 "엔지니어링 매니저"라는 직함을 달아 주는 회사들이 얼마나 수도 없이 많은지 짐작하실 수 있으신가요? 이것이 구글이 그런 일을 피하는 방식입니다.

물론, 이 과정은 모두 거짓 양성을 최소화하는 데 최적화되어 있습니다. 그것은 어쩔 수 없습니다. 구글에 채용되고 나면 정말 터무니없는 일을 저지르지 않는 이상 해고되기 어렵기 때문입니다. 우리는 면접자들이 편안한 환경에서 면접을 볼 수 있게 많이 신경쓰지만, 뛰어난 엔지니어들도 기술적 면접에서 실수할 수 있으며, 운이 없어서 면접에서 떨어지는 경우는 확실하게 존재합니다. 그런 경우에는 반 년이나 일 년 안에 다시 면접을 볼 수 있으며, 구글은 그런 분들을 환영합니다. 하지만 구글 입장에서는, 유능하지 못한 사람을 실수로 채용했을 때, 해고하기도 무척 어렵거니와, "반 년이나 일 년 안에 다시 시도할" 수도 없습니다.

아니요, 코딩 인터뷰는 쓰지도 않을 알고리즘을 달달 외우고 있느냐를 측정하지 않습니다. 신택스에 대한 nitpicking도 아닙니다. 그런 회사에는 저도 가고 싶지 않습니다. 코딩 인터뷰는 문제를 푸는 것에 대한 면접자와 면접관 간의 토론입니다. 만약 그가 고전한다면, 우리는 그를 올바른 방향으로 이끌고, 그 과정에서 엣지 케이스나 퍼포먼스를 충분히 고려하는지, 코드의 퀄리티는 어떠한지, 테스팅은 충분히 하는지, 그런 것으로부터 궁극적으로는 문제를 해결하는 능력을 보는 겁니다. 우리는 경험 있는 면접자들에게는 대형 시스템을 설계함에 따른 성능, 스케일러빌리티 등도 물어봅니다.

아니요, 우리는 절대 AVL 트리나 레드블랙 트리의 구체적인 구현이라든가, A* 알고리즘 같은 것을 물어보지 않습니다. 그건 미친 짓입니다. 우리는 진짜로 기본적인 것들만 물어봅니다. 연결 리스트, 트리, 해시 테이블, 최소 하나의 nlogn 정렬 - 정렬 알고리즘을 물어볼 때 버블 소트를 짜는 면접자는 정말로 진짜 많습니다 - 기본적인 분할 정복, 재귀, 그리고 제일 중요한 건, 그를 기반으로 여지껏 본 적 없는 문제를 풀 수 있는 능력.

면접 문제는 꼭 실제 업무와 완전히 일치하는 부류일 필요는 없습니다. 단지 업무 능력을 얼마나 잘 예측할 수 있는지가 중요합니다. 예를 들어, SQL의 구문 사용법이라든가, 정규 표현식의 특정 문법이라든가, 이런 것들은 "실제 업무"와 관련이 깊을 수 있지만, 이런 것을 면접 질문으로 묻는다면 그거야말로 우스운 일일 겁니다. 그거야말로 인터넷에서 검색을 하면 바로 알 수 있으니까요. 당신에게 더 좋은 생각이 있다면, 구글은 면접자들에게 언제나 면접에 대한 피드백을 요청합니다. 그들은 귀가 있습니다. 하지만 아마 당신이 제안한 것들은 그들이 이미 시도해봤을 확률이 높습니다.