더 개발자 인터뷰 가이드 - 채용 (1)

개발자 인터뷰 개요

• 단순히 코딩 실력만 보는 것이 아니다!
• 실제로 문제를 잘 풀어도 떨어질 수 있다.
• 면접을 볼 때, 지원자의 기술적인 역량만 보지는 않는다.
• 그 사람이 문제를 잘 푼다고 해도, 실제로 떨어질 수 있다. 이러한 경우는 대다수가 소프트 스킬이 부족했기 때문이다.

채용

• 면접관의 입장에서, 채용을 바라볼 것이다.
• 면접관에게 절대로 거짓말을 하면 안된다, 따라서 평상시에 준비를 하고 이와 같은 행동을 해왔어야 한다.
• 이번 채용을 통해서 배운다라는 생각을 하면 좋다.
• 우리를 채용하고 싶기 때문에, 물어보는 것이고 우리를 떨어뜨리려고 당혹 시키려고 질문하는 것이 아니다.

고전적인 채용 절차

1. 채용 공고
2. 이력서 접수 및 검토
3. 개발자 비대면 면접
4. 개발자 대면 면접
5. 임원 면접

이력서 접수 및 검토의 문제

• 사실 여부 판단이 어렵다.
• 지원자의 기술적인 실력을 가늠하기 어렵다.
• 단편적인 정보들로 인해 편견을 가지기 쉽다.
• 개발자가 검토할 서류가 너무 많다.
• 이력서로 개발자를 필터링하는 것은, 너무 어렵다.

비대면 면접의 문제

• 지원자 당 한시간 정도를 소비하기 때문에 비용이 크다.
  • 제한된 시간 이내에 충분히 파악하기 힘들다.
• 단답형 또는 서술형 답변의 기준을 정해둘 필요가 있다.
  • 주관에 따라서 상대방이 충분하게 답을 했다고 생각했을 수도 있고 충분하게 답변하지 않다고 생각할 수 있다.
  • 따라서 기준이 있어야한다.
• 지원자의 실력을 가늠하기 충분하지 않다.

대면 면접의 문제

• 지원자를 파악하기 좋은 채용 절차이지만, 비용이 크다.
• 지원자가 부족할 수도 있어서 도중에 면접을 중단하는 경우가 있을 수도 있지만, 원칙적으로는 끝까지 봐야한다.
• 지나치게 문제 풀이에만 집중하는 경향이 있다.

임원 면접의 문제

• 사내 문화와 잘 어우러 질지, 잘 적응할 수 있는지를 물어본다.
• 과연 임원 면접이 필요한가?

변하고 있는 채용 절차

1. 채용 공고
2. 이력서 접수 및 리쿠루팅
3. 비대면 면접
4. 대면 면접

이력서 접수 및 리크루팅

• 적극적인 채용 비중 증가
• 잠재적인 지원자에게 리크루터가 직접 연락

비대면 면접 강화

• 대면 면접 이전에 미리 기본적인 코딩 능력을 테스트
• 인력 비용을 최소화 할 수 있는 형태로 운영
• 단점도 있지만 이전의 비대면 면접에 비하면 보자 비중이 높아짐
• 비대면 면접에서 실제로 코딩 문제를 풀어야 한다.
  • codility
  • 모든 과정이 녹화가 된다. 따라서 코드를 작성하는 과정을 따라갈 수 있다.
• 따라서 이력서 접수 이전에도 코딩 테스트 준비를 꾸준하게 해야한다.

대면 면접 강화

• 개발자 뿐만 아니라, 매니저 트랙의 직원도 면접관으로 참여
• 코딩 스킬 뿐 아니라 커뮤니케이션 또는 비기술적인 역량 검증
• 문제를 푸는 것 뿐 아니라 “어떻게” 푸는지를 중요하게 보기 시작한다.
• 기술적인 능력 이외에도 같이 일을 해나갈 수 있는지를 검토 해야 한다.

대면 면접 구성

• 45분 면접 15분 휴식
• 5분까지 아이스 브레이킹
  • 이전 경력을 보면서 이전 회사에서는 어떤 일을 해왔는지..
  • 어떤 프로그래밍 언어에 자신이 있는지..
  • 그 언어를 왜 좋아하는지?…
  • 지원자의 긴장을 풀어주는 것이 목적이다.
• 15분까지 소프트 스킬 검증
  • 소프트 스킬과 관련된 질문을 한다.
  • 지원자의 과거 행동이나 현재 면접에 임하는 자세가 우리 팀 또는 회사가 중요하게 여기는 가치에 부합하는가?, 적합한가를 보는 것이 소프트 스킬을 보는 단계이다.
• 40분까지 하드 스킬 및 소프트 스킬 검증
  • 문제를 푸는 것도 중요하지만, 풀어가는 과정도 중요하다.
  • 보다 자세한 문제 풀이 프레임워크에 대해서는 하드 스킬 파트에서 확인
  • 주제만 코딩 퀴즈일 뿐, 실제로 동료와 업무를 하는 과정과 비슷하다고 생각하는 것이 좋다.
  • 실제로 동료와 업무를 하는 과정과 비슷하다고 생각하는 것이 좋다.
    • 만약 게시판을 동료와 같이 구현하는데, 동료가 코딩 부터 뚝딱뚝딱 해서, 완성했네요! 하면 어떻겠는가?.. 따라서 구현하기 전에 궁금하고 물어봐야할 것을 같이 검토를 해야한다.
  • 하드 스킬을 검증하는 것 처럼 보이지만, 사실 소프트 스킬을 같이 검토하는 단계이다.
• 45분까지 질문 받기
  • 간략하게 질문을 받을 수 있다.
  • 지원자가 이 회사의 잠재적인 고객이자 동료가 될 수도 있다는 생각으로 대할 것이다.
  • 지원자에게는 면접관의 이미지가 곧 그 회사를 대표하는 이미지라는 생각으로 임할 것.

이력서 검토 가이드

• 경력 및 이력이 채용 공고의 필수 자격 요건에 준하는지 확인.

• 이력서에 기술 및 경험을 구체적으로 서술하고 있는지 확인.

  • 업무에 충실하게 임했다면 해당 하는 업무를 통해서 어떠한 성과가 있었으며, 어떠한 기술을 사용하고 있고, 팀에서 어떤 역할을 맡았는지를 구체적으로 기술할 수 있다. 하지만 성실하게 임하지 못했던 개발자라면 구체적으로 임할 수 없다.

• 회사 또는 팁에서 추구하는 중요한 가치가 드러나는지 확인.

  • 이러한 이력서가 정말 좋은 이력서이다.

• 주의할 사항

  • 무의식 또는 의식적인 편견에 주의할 것.
  • 이력서에 적힌 기술, 경험 및 가치관 이외의 사항은 무시할 것.

면접 가이드

• 지원자의 면접 경험

  • 일관된 면접 기법이나 방식을 사용할 것.
  • 편안하고 일상적인 억양으로 말할 것.
  • 본론에 집중할 것.
  • 지원자의 역량에 집중할 것.
  • 직무와 관련있는 질문만 할 것.
  • 눈을 마주하고 이야기 할 것.
  • 주의깊게 듣고 지원자의 말이 끝날때까지 기다릴 것.
  • 이해하지 못한 것을 이해한 척 하지 말고 다시 확인할 것.

지원자 평가 방법

• 지원자를 평가할 때는 다양한 시각으로 기술적인 역량과 경험을 검토해야한다.

• 지원자의 기술적인 역량이나 경험을 바탕으로 판단할 것

• 평가 기준으로 여기지 말아야 할 것.

  • 태도 (적극적, 소극적, 악수하는 방법, 바디 랭귀지 등)
  • 외모 (복장, 스타일, 헤어, 문신 등)
  • 행동 (말하는 스타일, 속도, 억양 등)

• 중요하게 여겨야 할 핵심 역량

  • 판단력
  • 적응력
  • 결과를 만들어내는 노력
  • 협업
  • 영향력
  • 고객 중심

• 다양한 시각을 가진 면접 팀을 구성할 것

  • 개발자와 매니저.
  • 다양한 경력의 개발자.
  • 여러 팀의 개발자.

피드백 공유

객관적이고, 공정한 피드백을 공유

• 모든 면접관의 면접이 끝나기 전에 서로의 피드백을 공유하지 않는다.
• 피드백을 면접팀과 공유하며, 객관적인 평가를 내렸는지 점검한다.
• 어떤 지원자에게 대해 강한 반응이나 가정을 기반으로 결정을 내린 경우 대화로 풀어야 한다.

참고 문헌

• 더 개발자, 인터뷰 가이드