작년(2016년) 이맘때쯤에 연구를 하다 말고(ㅜㅜ) 구글 코리아에 지원을 했다가 떨어졌었다. 벌써 1년이나 지났다.
구글 채용 절차는 서류전형(온라인으로 CV 보내는 게 전부), 전화 일반면접(대화와
질의응답), 전화 코딩면접, 현장면접, 입사의 순서인데, 작년에 지원하던 당시에 나는 전화 코딩면접만 두
차례 겪어보고 떨어졌다. 기왕 떨어지더라도 현장면접까지는 가 봤어야 하는데, 내가 현장면접을 할 정도의 실력이 되지 못했다는 반증이니 달리 할 말이 없다.
ㅠㅠ 그래서 현장면접에서 어떻게 해야 하는지에 대해서는 한 마디도 쓸 수 없다. 나중에
혹시 또 지원하게 되면 + 현장면접까지 겪어볼 수 있게 된다면 그 때 추가하는 걸로…
비록 1년 전의 일이지만 그 당시의 경험을 따로 어딘가에 기록해 두지
않았기에, 여기에 기록하면서 앞으로 professional (우리말로
딱 표현하려니 잘 떠오르지 않는다)한 소프트웨어 엔지니어 또는 연구원이 되기 위해서 어떤 노력을 해야
할 지 생각을 정리해보려 한다.
일단 구글의 소프트웨어 엔지니어 채용 스타일은 굳이 쓰지 않더라도 잘 알려져 있고, 유튜브에는
구글 코리아가 올린 현장면접 예시 영상도 있다. [1] 게다가 최근 구글의 채용 스타일을 꽤 많은 IT 대기업들이 따라 하고 있다. LG전자 CTO의 소프트웨어 직군 면접의 일부도 그랬었던 기억이
있다.
*지원부터 전화면접까지의 과정 개요
나는 링크드인에서 구글 코리아 소프트웨어 엔지니어 지원 페이지에 CV를
보냈는데(링크드인 프로파일을 CV로 변환해서 첨부함), 서류 통과 후에 구글 재팬(?)에서 영어로 면접을 보자는 메일이
왔다. 그래서 전화상으로 대화를 하고 질의응답을 하는 면접은 구글 재팬에서 일하는 소프트웨어 엔지니어와
영어로 진행했다. 지원대상은 구글 코리아였는데 왜 구글 재팬에서 연락이 왔는지는 잘 모르겠다. 그냥 어느 branch에 가던지 상관 없이 회사 전체적인 입장에서
면접 가능한 엔지니어를 배정한 것인지, 아니면 일본 branch에서
실제로 관심이 있었는지는 알 수 없다.
전화상의 코딩이 아닌 일반면접 후에 전화 코딩면접을 할 때에는 다행히도 구글 코리아에서 한국인 소프트웨어 엔지니어가
전화를 걸어 와서 한국어로 편하게(?) 면접을 진행할 수 있었다.
전화 코딩면접은 두 번을 했는데, 사실 전화 코딩면접은 한 번만 하고
당락을 결정하는 게 일반적인 듯 하다. 내가 왜 전화 코딩면접을 두 번 했는지 정확한 이유는 사실 알
수 없다. 굳이 추측하자면, 내가 첫 번째 전화면접 후에
당락의 경계선 상에 놓이게 되면서 현역 엔지니어들이 보기에 ‘긴가 민가’ 해서(…) 한 번만 더 기회를 줘 보자고 생각했을 지도 모르겠다.
아니면 조금 더 부정적으로 보자면, 내가 비록 첫 번째 전화면접에서
망했지만(ㅠㅠ) 그럼에도 불구하고 혹시나 지원자가 애석하게도
문제가 잘못 걸려서 못했을 지도 모르니 다른 문제를 내서 한번 더 역량을 발휘할 기회를 줘 보자는 생각이었을 수도 있다. 결국 두 번째 전화면접 이후에 다시 구글 재팬에 있던 맨 처음 전화로 얘기했던 엔지니어로부터 탈락 통보를 이메일로
받았다.
전화 코딩면접 진행 과정은 잘 알려져 있듯이 사전에 이메일로 공유된 구글 문서를 켜고, 휴대폰으로 걸려오는 전화를 통해서 문제를 전달받고, 30분 동안
그 문제를 해결하는 코드를 구글 문서에 작성한다. 중간에 엔지니어와 계속 전화상으로 대화하면서 진행한다.
첫 번째 전화 코딩면접 때는 문제를 정확하게 이해하지 못하는 바람에 알고리즘 제시는 못했고, 어찌됐든 컴파일 에러나 로직 에러(스택오버플로우, 익셉션 따위) 없이 돌아가는 코드를 제출하기는 했다.
두 번째 전화 코딩면접 때는 문제를 제대로 이해했고 어떻게 해결하면 되는지 해결 방법도 개념상으로는 맞게 제시했지만, 막상 내가 짠 코드에 컴파일 에러뿐만 아니라 스택오버플로우 문제마저 있는 상태로 제출해 버렸다. ㅠㅠ
(문제가 무엇인지는 왠지 함부로 공유하면 안될 것 같아서 일부러 언급하지
않았다.)
위의 두 차례의 전화 코딩면접을 겪으면서 나의 어떤 부분이 부족했는지를 생각해 보았다.
*알고리즘과 코딩실력: 두 마리 토끼 모두 잡기
위에 언급했듯이 나의 첫 번째와 두 번째 코딩면접 결과를 보면
알고리즘 이해도와 코드의 완성도, 이 두 가지 측면에서 서로 다른 한계를 갖고 있었다. 알고리즘을 정확히 이해해서 문제 해결방법을 제대로 짚기도 해야 하지만, 결국
그걸 주어진 시간 안에 집중적으로 코딩해서 실제로 돌아가는 코드를 만들어내는 능력이 있는지도 같이 검증하는 것이 아닐까 싶다.
구글 입장에서도 이익을 극대화하려면 같은 소프트웨어 엔지니어라도 기본기가 있어서 재교육 비용이 가급적 적게 드는
인재를 원할 테니까 당연한 것일 수 있다. 면접 과정에서 프로그래밍 언어의 선택권이 지원자에게 있는
만큼, 그만큼 지원자 입장에서 가장 자신있는 프로그래밍 언어를 들고 왔을 테니 적어도 문제없이 코드를
짤 수 있어야 한다는 전제가 깔려 있을 것 같다.
*코딩면접 이전의 일반 전화면접의 중요성
이 부분은 이전 포스팅(http://skylit.tistory.com/189)에서도 썼지만, 채용에서 떨어진 후에 다시 생각하면서 반복해서 쓰게 되었다.
지금 다시 생각해 보면, 전화 코딩면접을 하기 전에 구글 재팬
소프트웨어 엔지니어와 나눴던 대화가 의외로 중요했으리라는 생각이 든다. 그 당시에 나 자신의 역량에
대해서 여러 분야별로 1~10점 사이의 점수를 매겨 보라는 질문을 받았는데, 그 때 멋모르고 Java 언어를 조금 높게(7점) 제시했더니 엔지니어가 살짝 당황하는 눈치였다. 그리고 이어서 들어오는 Java 언어의 자세한 속성들에 대한 질문에서 제대로 대답하지 못하고 실컷 털리고 보니 내가 점수를 뻥튀기한 셈이 되어 버렸다. ㅜㅜ
그리고 알고리즘은 내가 4점 또는 5점이라고
대답했던 것 같다. 이 경우는 비록 그 당시에 대답하던 당시에는 나의 가감없는 실제 실력을 그대로 보여주는
점수라고 할지라도, 차라리 그 전에 미리 알고리즘 개념을 복습을 좀 하고서 6점 정도가 된다고 자신 있게 이야기할 수 있어야 했다. 알다시피 구글은
알고리즘을 특히나 중요하게 생각하는데 이미 그 역량에서 내가 한 수 접고 들어간 것이다. ㅜㅜ
즉, 코딩이 아닌 일반 전화면접이고 그냥 대화를 나눈다는 식으로 안내가
오더라도 그 메일에 속지 말고(?) 전산학의 주요 분야를 충분히 복습해야 한다.
*트렌드보다는 기본기가 충실한 것이 더 중요하다.
IT분야의 큰 트렌드에 따라 시기별로 회사가 유난히 원하는 소프트웨어
엔지니어의 종류도 어느 정도 있게 마련이다. 가령 2000년대
중후반에는 정보검색 기술, 2010년대 초반에는 빅데이터, 수
년 전부터 지금까지는 IoT와 클라우드, 최근에는 인공지능
등…
그런데 구글은 일반 소프트웨어 엔지니어 채용 과정에 있어서는 그런 트렌드를 별로 고려하지 않는 듯한 느낌이 들었다. (트렌드에 적합한 실력 있는 인재는 그 회사를 인수하는 방법으로 충당하는 것일지도?)
내가 얼마나 지금의 트렌드에 적합한 인재인지에 대한 자기PR은 서류
전형에서 조금이나마 영향을 줄 수는 있을 지도 모른다. 하지만 전화 코딩면접에서는 정말 내가 학사인지
석사인지 박사인지는 전혀 중요하지 않았고, 내가 석/박사과정을
하면서 나름대로 확보했다고 생각되는 경쟁력에 대해서는 통화를 시작할 때 단 한번 물어보고 끝났다. 예를
들면,
첫 번째 전화 코딩면접 당시:
엔지니어: 지금 박사과정 하면서 어떤 연구를 하고 있죠?
나: 네, IoT 서비스
플랫폼을 개발하고 그 중에서도 무선 네트워킹을 서비스 종류별로 효율적으로 해주기 위해서 블라블라~~~ … (1분
뒤)
엔지니어: 네, 잘 알겠습니다. 자 그럼 문제를 내도록 하죠.
나: ……
두 번째 통화에서도:
엔지니어: 최근에 연구하면서 무엇을 개발했나요?
나: 네, 라즈베리파이와
일반 가전기기를 연동해서 스마트한 IoT 기기로 만들고 그들을 서로 연결해서 블라블라블라~~ (1분 뒤)
엔지니어: 그 과정에서 무엇이 가장 어려웠나요?
나: (오 의외로 다른 질문이!)
나: 네, IoT 기기들을 실제로 회의실, 휴게실 같은 공간에 설치하고 IoT 소프트웨어 플랫폼 올리고 우리만의 스마트 기기 코드를 짜서 올려서 돌아가게 만들 때 블라블라블라~~ (1분 뒤)
엔지니어: 네, 알겠습니다. 그럼 문제를 내겠습니다.
나: …… (ㅠㅠ)
결론적으로, 구글은 나의 석/박사
연구주제나 논문에 관심이 없다. ㅠㅠ 석/박사과정을
통해서 습득한 연구능력이 산업 현장에서 일어나는 문제를 제대로 정의해서 해결 방법을 체계적으로 제시하는 것으로 발현이 되는지를 코딩면접을 통해서
검사할 뿐이다. 즉, 내가 과거에 석/박사 연구를 얼마나 체계적으로 잘 수행했는지를 확인하는 대신, 그렇게
연구를 잘 했으니까 instant하게 주어지는 문제 상황에 대해서도 본인이 잘 대처하는지 증명해 보라는
식이다.
해외, 국내를 막론하고 차라리 다른 회사들이라면 나의 박사학위 연구
주제에 대해서 물어볼 만도 하고, 어느 학회나 저널에 냈는지에 관심을 가져 주거나 연구실에서
수행한 프로젝트가 회사가 필요로 하는 일과 얼마나 연관성이 높은지 정도를 생각해볼 만도 한데, 구글
소프트웨어 엔지니어는 그런 거 없다. 그냥 소프트웨어 엔지니어 개인이 기본기와 문제해결능력이 충분하면
어떤 문제를 던져 줘도 잘 해결할 것이라는 단 하나의 원리만 갖고서 채용하는 것처럼 느껴졌다.
물론 구글도 개발이 아닌 연구 부서가 없을 리가 없겠지만 잘 알려져 있지 않으니까… 적어도 구글이 생각하는 “소프트웨어 엔지니어” 범주에서는 학위를 별로 신경쓰지 않는 것만은 확실하다.
이것을 바꾸어 생각해 보면, 결국 내가 석/박사과정을 충실하게 보냈는지를 과거 기록에 의존하지 않고 검증하는 것과 같다.
모든 교수님들이 얘기하듯이 대학원에서 배우는 핵심은 문제 정의와 문제 해결 능력이고, 이것은 스펙만으로
일대일 대응으로 증명되지는 않는다. 즉, 문제해결능력이 뛰어난
석/박사가 논문을 잘 쓰고 프로젝트를 성공적으로 수행하는 것은 참이 되지만, 좋은 논문실적과 좋은 프로젝트 수행 실적이 개인의 문제해결능력을 역으로 증명해 준다고 볼 수는 없다는 것이다.
*결론: 어려운 문제를
대하는 태도의 문제
비록 전화 코딩면접에서 떨어졌지만, 내 입장에서는 꽤 중요하고 값진
경험이었다. 내가 알고리즘 설계와 코딩 실력이 어느 정도 되는지를 점검할 수 있는 기회였고, 한편으로는 말로 설명하는 나의 역량과 실제로 드러나는 나의 생산성 사이에 존재하는 괴리를 직접 확인할 수 있었다.
최근에 자꾸 연구과제 등 신경쓸 것이 많다는 핑계로 개인연구가 점점 미뤄져 가는 현실을 한탄하고 있지만, 정작 이러한 도전적인 상황에서 문제해결능력과 코딩면접 때와 같은 집중력으로 지금의 상황을 돌파해 내지 못하는
내 모습을 다시 확인할 수 있었다. ㅜㅜ 내가 박사학위를 내 손으로 내 실력으로 받기 위해서는 지금의
내 모습에서 한두 단계는 더 역량을 업그레이드해야 한다는 것도 다시 느끼게 되었다.
개인연구에서 제시하는 문제 상황을 시뮬레이션이나 실험 코드로 구현해서 측정하고 그걸 증명하는 과정에서 쉽게 코딩이
되지 않을 때가 자주 있는데, 사실 그 때 문제를 해결하는 것이 어쩌면 구글 전화 코딩면접을 하는 과정과
다를 바가 없는 것 아닐까? 어려움에 봉착했을 때, 귀찮아하면서
좀더 쉬운 과제 문서작업이나 연구실 허드렛일들(서버 관리 등)을
하며 의도적으로 회피했던 내 모습이 부끄럽다. 그럴 때 문제에 직면해서 해결 방법을 설계하고 그 방법을
집중해서 구현하면서 (비록 에러가 나거나 버그가 발생하더라도) 반복적으로
검증함으로써 점차 나만의 문제 해결 능력과 코딩 능력을 쌓아 가는 태도가 필요하다.
무턱대고 방향성 없이 하는 노력이 아니라, 나의 궁극적인 목표(박사학위)를 달성하는 과정에서 일어나는 온갖 문제들을 어떻게 해결할 지를 생각해 가면서 꾸준하게 집중적으로 노력하는 나 자신이 완성될 때까지는 힘들지만 매일매일 회피하지 말고 노력해야 하겠다.
<참고자료>
[1] https://www.youtube.com/watch?v=BF3FLDAzWxo
