이전 글의 '기조 설계하기'에서 기술 면접을 설계할 때 사용할 사고방식을 정했다. 기조에 맞는 기술 면접 방식이 무엇일지 고민을 많이 했다. 이야기도 나누고, 문제 해결 과정도 확인하기 위해서는 하나의 방법만 사용할 수 없었다. 그래서 고민 끝에 '질문과 답변', '코딩 테스트'를 섞어서 구성하기로 했다.
질문과 답변
많은 면접 진행자들은 이력서에 써있는 내용이 물경험, 물경력인지 확인하고 싶어한다. 그래서 많은 질문을 해서 얼마나 아는지 확인하려고 한다. 하지만, 지원자의 입장에서는 되려 긴장하여 말할 수 있던 것도 말할 수 없게 된다. 그래서 '질문과 답변'을 사용하는 첫 번째 이유는 '아이스 브레이킹'에 있다.
지원하시는 분도 긴장하지만, 사실 면접을 보는 사람도 긴장한다. 모르는 사람을 만나 이야기를 나누는 것은 언제나 힘든 일이기 때문이다. 그런데 오히려 서로 긴장을 했기 때문에 동질감을 느낄 수 있지 않을까. 편안한 분위기를 만들고 조심스럽게 경험이나 관심사를 물어본다면, 딱딱한 질문으로는 얻을 수 없는 뒷이야기를 들을 수 있을 것 같았다.
직무 능력을 검증하는 것도 중요하다. 현실 세계에서 해결해야하는 문제는 절대 한 번에 구체적으로 해결되지 않는다. 그러면 스스로 해결 가능한 문제를 도출하기 위해 생각해야한다. 이를 위해서 직무 관련된 질문은 간단하게 시작해서 점점 핵심으로 들어가게끔 구성을 해보았다. 예를 들어 아래와 같은 질문들을 사용할 수 있을 것이다.
- HTML
<button>태그의type이라는 속성은 기본값이 무엇일까요?
→ 그 이유는 무엇일까요? - React의 state update는 동기(synchronous) 동작인가요, 비동기(asynchronous) 동작인가요?
→ 그렇게 했을 때의 장점은 무엇인가요?
간단한 질문들로 시작했지만 그 뒤에 이어지는 질문들은 '얼마나 해보았는지?'를 알기에 좋다. 첫 질문을 예로 들면, <form> 안에 있는 <button>을 클릭했더니 form이 submit되는 걸 한 번이라도 본 사람이라면, <button>에 type을 꼭 써야 하는 이유를 알 것이다.
이와 동시에 '상황을 제시하고 이에 관한 답을 듣는 질문' 역시 큰 도움이 된다. 예를 들어, 다른 파트의 팀원과 협업을 하다가 문제가 발생했는데 그 문제가 무엇인지는 모르는 상황이라고 가정한다. 지원자에게 이 문제를 어떻게 정의, 파악, 해결할 것인지 물어보자. 본인의 경험을 투영해 이야기를 할 것이다.
끝으로, '질문과 답변' 과정에서 하나 특이한 것을 넣었다. '모른다고 말하면 정답에 가까운 개념을 설명하는 것'이다. 항상 면접을 볼 때 '모르는 것'을 알기는 쉬워도, 그것이 정확히 무엇이고 어떻게 찾아야하는지 알기가 어려웠던 것 같다. 모르는 것은 알아가면 된다. 모른다고 하거나 잘못된 답변을 했을 때 우리가 생각하는 정답을 꼭 말해주기로 했다.
코딩 테스트
앞서 말했듯, 작업자는 새로운 것을 만드는 것만큼 기존에 짜여진 코드를 파악하며 작업하는 것도 많다. 이 사람이 기존 코드에 있는 문제를 마주쳤을 때 어떤 사고방식을 가지고 문제를 해결하는지 확인하는 것이 '협업하기 좋은 사람'을 찾는 것에 도움이 될 것이라고 생각했다. 물론, '질문과 답변' 단계에서 이야기한 내용을 명확하게 이해하고 있는지도 궁금했고.
먼저, 과제 형식의 코딩 테스트를 진행하기로 했다. 우리 프로덕트에서 실제로 사용중인 컴포넌트를 1시간 내에 구현하는 과제를 만들었는데, 몇 가지 조건을 추가하였다. 작업이 모두 완료되면 코드 리뷰를 진행하며, 코드를 작성한 이유를 묻고 더 나은 방법은 없는지 질문하기로 했다.
- 인터페이스를 정해놓고 그 안의 동작을 유추하며 과제를 수행한다.
- 컴포넌트의 구현 단계를 6개의 스텝으로 나누어, 순서대로 작업하도록 하였다.
- 검색 및 질문을 자유롭게 할 수 있다.
- 면접자는 코드를 작성하거나 검색하는 화면을 실시간으로 공유해야한다.
사실 코딩 테스트를 설계하면서 고민한 내용이 정말 많았다. 하지만 막상 글로 옮겨보니 양이 너무 많아서, 다음 글로 분리해서 자세하게 이야기를 해보려고 한다.