기술 면접 면접관으로 처음 들어가는 주니어를 위한 팁
신입 프로그래머로 입사했을 때는 내가 기술 면접의 면접관으로 들어가는 것이 먼 미래의 일이라고 생각했는데, 어느덧 정신을 차리고 보니 이미 면접관으로 다섯 번도 넘게 들어가고 난 후였다.
인터넷에 면접 지원자 입장에서의 팁, 후기들은 많다. 그런데 면접관을 위한 팁, 특히 기술 면접에 처음 들어가는 주니어를 위한 팁은 찾기가 힘들어서 글을 쓰게 되었다. 처음 면접관으로 들어가게 되면 면접 지원자만큼이나 긴장이 될 수도 있는데, 조금이나마 도움이 되었으면 좋겠다.
1. 지원자의 이력서를 토대로 구체적인 개발 경험 묻기
지원자의 이력서를 기반으로 어떤 경험을 했는지 구체적으로 확인할 수 있다. 어떤 서비스를 어떻게 설계했고, 어떤 장애를 겪어보았고 어떻게 대처했는지, 어떤 프레임워크/라이브러리/DBMS를 왜 선택했는지 질문하자.
예를 들어 아래와 같이 질문할 수 있다.
- 이력서에 A 서비스 설계 및 개발이라고 되어있는데, A 서비스의 아키텍처 설명 부탁드린다. 옆에 화이트보드를 사용하셔도 좋다.
- (아키텍처를 보고) 피크 상황에서는 B 부분이 병목이 될 것 같은데 문제가 없었는지?
- (아키텍처를 보고) redis는 단순 캐시 레이어로만 사용한 것인지? cluster, sentinel 사용 경험이 있는지?
- (아키텍처를 보고) MongoDB를 사용하셨는데, MySQL 대비 어떤 이점이 있어서 선택하셨는지?
- A 서비스를 운영하면서 더 많은 부하를 견디기 위해 따로 최적화한 부분이 있는지?
지원자가 어떤 서비스를 처음부터 구축한 경험이 없고 유지보수 경험만 있다면, 유지보수한 서비스를 만약 처음부터 다시 설계한다면 어떤 식으로 설계하겠냐고 질문을 할 수도 있다.
혹은 “특정 조건을 만족하는 어떤 서비스를 만들어야 한다고 했을 때 어떻게 설계를 하겠냐”는 식으로 질문을 할 수도 있는데, 이때 실제 입사했을 때 맡을 수 있는 업무와 은근슬쩍(?) 엮어서 질문하는 것도 가능하다. 단 이런 형태의 질문을 할 때는 적절한 조건도 미리 가늠해두자. 면접자가 "동접 n이라 잡고 초당 API 콜 수가 m개라는 가정 하에..."하며 스스로 기준을 세울 수도 있겠지만, 면접관이 어느 정도 리드해줘야 다른 면접관도 머릿속에서 그림을 그리고 적절한 질문을 할 수 있다.
2. 지원자의 수준에 맞는 질문 하기
주니어 지원자에게 시니어에게 물어볼법한 질문을 하게 되거나, 시니어에게 너무 기초적인 질문을 하게 되면 서로에게 시간 낭비이다.
특히 전자의 경우가 한 면접 내에서 여러번 반복되어 지원자가 대답을 하지 못할 경우, 지원자는 심리적 압박을 강하게 받아 더욱 긴장하게 될 가능성이 크다. 경력 and/or 면접 경험이 적으면 당연히 적절한 난이도의 질문에 대해 감이 안 잡힐 수 있다. 이는 주변 시니어 프로그래머 등에게 조언을 구해서 정리하면 좋다.
그런데 지원자의 수준을 어떻게 규정할 수 있을까? 토익 900점 이상 같은 조건을 만들 수도 없는 노릇인데 말이다. 그래서 면접에 들어가기 전 면접관들끼리 지원자에게 기대하는 수준이 구체적으로 어떤 것인지 충분히 대화하고 동기화를 하는 것이 중요하다고 생각한다. 서로가 생각하는 "n년차 서버 프로그래머라면 당연히 이 정도는 되어야지"가 천차만별일 수 있다. 누군가는 n년차 프로그래머가 주력으로 golang을 썼다면 당연히 goroutine의 동작 원리를 설명할 수 있어야한다고 생각하는데 다른 면접관은 경력 n년 이하면 모를 수도 있다고 여길 수도 있다. 여기에는 정답이 없다.
개인적으로는 이 문제를 해결해보려고 지원자 페르소나를 만들었다. 예를 들어, 주력 프로그래밍 언어와 프레임워크가 A, B 이고 경력이 n년차인 주니어 프로그래머라면 충분히 습득했을 지식들과, 알 수도 있지만 모를 수도 있는(모른다고 해서 역량이 부족하다고 볼 수는 없을) 주제들을 분리하여 정리하는 것이다. 팀장님을 비롯하여 다른 팀분들께도 공유를 해서 피드백을 받았고, 이로써 적어도 팀 내에서는 특정 연차의 지원자에 대한 기대 수준이 맞춰진 것 같아 개인적으로는 만족하고 있다. 이렇게 한번 기준을 세우면 자연스럽게 n + @ 년차 지원자에게도 어떤 질문을 하면 좋을지 감을 잡기가 훨씬 수월해지는 것도 덤이다.
3. 지원자의 성향을 파악하고, 최대한 많은 가능성을 이끌어내기
자신이 잘 모르는 내용에 대해 질문을 받았을 때의 반응은 정말 극과 극으로 갈리는 것 같다. 최대한 자기가 아는 것, 혹은 들어라도 본 것을 짜내서 어떻게든 대답을 하려는 사람이 있는 반면, 어느 정도 알고 있으면서도 확신이 없어 조심스럽게 “잘 모르겠습니다”하고 대답을 끝내버리는 지원자도 있다. 속으면 안된다. 사실 알고 있는데, 본인이 생각하기에 완벽하게 알고 있지 않다고 생각해서 모른다고 대답한 것일 가능성이 있다. 이때 웃으면서 부드럽게 자세한 설명이 아니어도 좋으니 혹시 관련해서 들어본 키워드 같은 것이라도 있는지 물어보자. 질문 안 했으면 참 아까웠겠다 싶을 정도로 대답을 해낼 수도 있다.
만약 “정말 잘 모르겠다”고 하면 추측을 해보라고 하고, 잠시 생각해봐도 좋다고 하자. 예를 들어 가비지 컬렉션에 대해 질문했다고 가정하자. 지원자가 자신없어하며 “잘 모르겠다”고 대답한다. 그러면 다른 토픽으로 넘어가는 게 아니라, 가비지 컬렉션이 어떻게 동작할지 추측해보라고 유도해보자. 레퍼런스 카운팅을 몰라도 “사용되는 부분이 몇 군데나 있는지 기억해놓고... 이 부분들이 다 사라지면 지워도 된다고 판단할 수 있지 않을까요?” 하고 추론을 해내는 지원자가 있을 수 있다. 자신이 잘 모르는 주제라도 추측을 하게 함으로써 지원자의 잠재력을 확인할 수 있다.
4. 발전하고자하는 의지를 다방면에서 확인하기 (신입~주니어 면접)
신입~주니어 개발자를 채용하고자 할 때 주도적으로 학습, 발전하고자 하는 의지를 확인하기 위해 업무 외 개발 경험에 대해 물을 때가 많다. 이때 최대한 다방면에서 확인하면 좋다. 예를 들어 "토이프로젝트 진행하시는 것 있나요?" 라고 물었을 때 "업무 때문에 바빠서.. 없네요"하며 멋쩍게 대답하는 지원자가 있다고 가정하자. 이 지원자는 토이프로젝트라고는 한번도 해본적 없지만 기술 컨퍼런스에 연사로 참여한 경험은 있을 수 있다. 혹은 프로그래밍 관련 서적은 거의 안 읽지만 꾸준히 오픈소스 라이브러리에 기여하는 커미터일 수 있다.
"토이프로젝트 진행하시는 것 있나요?" 라고 물었을 때 지원자가 귀신같이 질문 의도를 파악하고 "따로 진행하는 것은 없지만 기술 블로그에 주 1회 정도 글을 쓰고 있으며, 종종 컨퍼런스도 참여하는 편입니다" 라고 대답할 수도 있겠지만... 그런 케이스는 드물 거라고 생각한다.
의지를 실천하는 수단은 개인마다 다를 수 있다. 평소에 업무 외에도 관심있는 기술 주제가 있는지, 혹시 최근에 읽은 기술 관련 서적/블로그 글 등이 있는지, 따로 온라인으로 강의를 듣는 것이 있는지 등등 다양한 측면에서 확인하면 좋다.