📄
서로 성장하는 기술 면접 만들기
우리는 왜 채용을 하는가
- 조직은 항상 바쁘고 일손은 항상 부족
- 그러나 수 개월을 채용에 할애하더라도 ‘좋은 사람'을 구하기는 어려웠음
- 이후 회고를 하며 서로가 생각하는 방향이 달랐다는 것을 알게 됨
- 이 과정에서 지금까지 진행했던 기술 면접이 무언가 잘못되었다는 것을 알게 됨
- 몇 가지 질문을 준비해 팀원 & 상위 리드와 수시로 이야기를 나눔
- 힘들지는 않은지? 힘들다면 어떤 부분에서 힘이 드는 것 같은지?
- 협업 시 어디에서 병목이 생기는 것 같은지?
- 스스로가 부족하다고 느끼는 부분이 있는지? 그리고 어떤 것에 자극을 받는지?
- 우리가 단기적으로 집중해야 하는 일(로드맵)이 있는지?
- 어디에서 사람을 데려올 수 있을 것 같은지?
- 나누었던 이야기
- 우리 회사에서 2년 정도 일했을 때 이룰 수 있는 성장은?
- 대규모 데이터 처리 경험
- 시각화, 최적화, 다국어 등을 프로덕트를 만들며 경험할 수 있음
- 비즈니스를 이해해 실제 엔지니어링에 반영해보는 경험
- 디자인 시스템 구축
- 함께 하고 싶은 사람
- 빠르게 성장하는 사람(좋은 자극을 주는 사람)
- 기록을 잘 남기거나 정리를 잘 하는 사람
- 레거시와 호환되게끔 코드를 잘 짜는 사람
- 시각화 혹은 UI/UX에 관심이 많은 사람
무엇을, 어떻게 확인할 것인가
- 기존 기술 면접 방법
- 하나의 회의실에서 2~3시간 진행
- 1시간은 경험 및 기술 질문
- 1시간 반은 과제 및 알고리즘을 구현하는 코딩 테스트
- 기존 기술 면접 방법의 문제점
- 큰 회사들을 답습했을 뿐 근거가 없음
- 지원자와 공감하거나 이야기를 나눌 시간이 없고, 되려 지원자에게 압박을 줄 수 있음
- 지원자의 역량을 제대로 파악할 수 없음
- 기술 질문 문답 → 그냥 외워버릴 수 있음
- 과제 구현 → 규모와 난이도 조정, 합불 판단이 매우 어렵고 애매함
- 알고리즘 → 현업과 거리가 있음
- 무엇을 확인할 것인가?
- 도메인 지식
- 우리 회사가 무슨 일을 하는지 알고 있는 사람인가?
- 문제를 파악하고 이를 해결하기 위해 기술을 사용할 줄 아는 사람인가?
- 직무 능력
- 직무에 필요한 기초적인 지식을 갖고 있는가?
- 레거시를 이해하고 리팩터링과 마이그레이션을 할 수 있는가?
- 근거와 의도를 갖고 코드를 작성하는가?
- 상황을 얼마나 구체화할 수 있는가?
- 서로간의 기분을 상하게 하지 않으며 함께 일을 할 수 있는가?
- 성장 가능성
- 성장하는 것에 얼마나 많은 관심을 갖고 있는가?
- 본인만의 성장을 위한 패턴이나 루틴이 있는가?
- ‘면접'이 무엇인지 정의하고, 이에 맞는 기술 면접 방식을 고민하는 것도 방법
- 하나, 면접은 아래와 같은 행위이다
- 같이 일을 했을 때 서로에게 도움이 될 수 있는지를 확인
→ 기술, 업무, 문화
- 같은 개발자로서 이야기를 나누는 기회
→ 관심사, 엔지니어링 관점과 중요도, 장애나 문제 해결 방법/경험 등
- 좋은 인상 및 감정을 남기기 위한 마케팅 기회
- 둘, 면접은 주관적 행위이다
- 다만 합리적으로 설명할 수 있는 주관을 추구
- 면접이 잘못되었을 가능성을 항상 열어두고 피드백을 받음
→ 면접 후 연락할 수 있는 수단을 제공해 피드백을 받는 방식
- 셋, 면접은 아래의 기조로 진행한다
- 면접을 통해 서로의 성장에 도움이 될 수 있도록 함
- 구체적인 상황이나 문제를 제시한 뒤, 이를 해결하는 과정을 봄
- 모르는 것은 알아가면 됨
면접 구체화하기 w/ 질문과 코딩 테스트
- 질문과 답변을 사용하라
- 아이스 브레이킹
- 이력서와 직무 능력 검증을 위해 어쩔 수 없이 많은 질문을 하게 됨
- 다만 지원자가 긴장한 경우 모든 역량을 확인할 수 없을 가능성이 있음
- 경험이나 관심사를 묻는 등 편안한 분위기를 먼저 만드는 것이 좋음
- 직무 능력 검증은 간단한 질문으로 시작해 핵심으로 들어가게끔
- 간단한 질문이더라도 지원자가 해당 분야에 얼마나 조예가 깊은지에 따라 다른 답변이 나옴
- 지원자의 역량을 판단하기에 좋은 방법
- 상황을 제시하고 이에 관한 답을 듣는 질문도 좋음
- 지원자의 경험과 문제 정의, 파악, 해결 방식을 알 수 있음
- 지원자가 ‘모른다'고 말했을 때는 항상 정답에 가까운 개념을 설명해줄 것
- 모르거나, 잘못된 답변을 했을 때 우리가 생각했던 정답을 말해줘야 함
- 이에 대한 지원자의 생각을 듣거나, 또 다른 역량을 파악할 수도 있게 됨
- 코딩(과제) 테스트
- 어떤 사고방식으로 문제를 해결하는지 & 협업하기 좋을지 파악하는 데 도움
- 글쓴이는 실제로 사용중인 컴포넌트를 1시간 내 구현하는 과제를 냄
- 이후 피드백을 받으며 개선
- 인터페이스를 정해놓고 그 안의 동작을 유추하며 과제를 수행
- 컴포넌트의 구현 단계를 몇 개의 스텝으로 나누어 작업하도록 함
- 검색과 질문은 자유롭게
- 코드를 작성하거나 검색하는 화면을 실시간으로 공유
코딩 테스트에 담은 생각
- 요구 사항을 기존 레거시에 반영하는 것은 어렵지만, 중요한 능력 중 하나
- 실제 대부분의 업무가 이러한 일
- 그러나 정답은 없고, 따라서 ‘작성한 이유'를 물어봐야 함
- 코딩(과제) 테스트는 이러한 것들을 모두 반영하는 방법임
- 코딩 테스트 방법
- 실제 프로덕트의 컴포넌트 중, 보기엔 간단하지만 내부는 복잡한 컴포넌트가 과제
- 기본적인 형태부터 스텝을 거치며 확장하게끔 테스트를 설계
- 최종 구현체를 어렵게 설정하여 시간이 절대 남지 않도록 하는 것에도 집중
- 진행 과정 조건
- 스텝은 순서대로 진행하며, 다음 스텝의 내용은 확인 불가
- 각 스텝의 설명문에 영상, 구현체 링크, 요구 및 고려사항과 힌트를 제공
- 모든 컴포넌트는 직접 구현
- 지정된 폴더 내에서만 작업 가능
- e.g. 테이블 컴포넌트 구현 테스트 시
- 기본적인 테이블 구현
- column 기준 정렬 기능 추가
- 많은 rows/colums를 쉽게 조회할 수 있도록 개선
- 검색 기능 추가
- 각 스텝마다 이렇게 구성한 이유를 물어가보며 아래의 기준을 통해 역량 검증이 가능
- 전체 스텝 중 어느 정도까지 왔는지?
- 작성한 코드에 의도가 있었고, 그것이 타당했는지?
- 개선이 필요한 부분을 짚었을 때 대안을 생각해낼 수 있는지?
- 코딩 테스트 이후
- 지원자에게 면접 후 하루 동안 보며 마저 풀어볼 수 있도록 하면 좋음
- 끝까지 구현 후 메일을 이용해서라도 코드 리뷰를 요청받도록 하는 것도 방법
- 글쓴이는 코드에 대해 좋은 점, 아쉬운 점, 고려가 필요한 점을 정리해 답장을 보내기도 한다 함
기술 면접이 끝나고 난 뒤
- 지원자에게 기술 면접 경험을 묻는 설문지 배부
- 피드백을 통해 면접 과정에서 잘못된 것 혹은 개선점을 반영할 수 있게 됨
- 지원자에 관한 정보를 아카이빙하고 총평과 태그를 남겨야 함
- 질문, 답변 내용, 코딩 테스트 결과물, 면접관의 피드백, ...
- 지원자가 합격해 입사 시 이 내용을 기반으로 조직에서 어떤 부분을 채워나가면 좋을지 의논
- 기술 면접은 리드 등 특정 인물의 전유물이 아님
- 충원의 필요성, 함께 하고 싶은 사람 등 서로의 생각이 모두 다르며
- 검증 과정 역시 특정 인물만 참여하게 되면 빈약하지거나 잘못될 수 있음
- 팀원 모두가 한 번씩은 면접을 진행해보는 것도 하나의 방법
