약 100명의 임직원을 가진 B2B IT 솔루션 기업의 웹 F/E 개발자 채용 회고록

Created by DALL.E

내가 현재 속한 조직은 IT 기업의 기술연구소이다. 주된 업무는 다른 개발 팀이 웹 기반 제품 개발을 빠르게 개발할 수 있도록 공통 패키지를 만들어 배포하고, 기술적인 문제를 해결하는 것이다. 회사가 본격적으로 웹 제품을 출시하며, 현장 이슈 대응과 차기 버전 개발 일이 꽤 많아지기 시작했다.

결국, 연구소에서 팀원 충원의 결정을 내렸고, 팀에서 시니어 엔지니어를 맡고 있는 나에게 개발자 채용 과정의 대부분 위임되었다.

처음에는 HR 부서에서 사람인에 공고를 올렸지만, 수일이 지나도록 지원자가 없자, 개발자 전용 채용 플랫폼으로 바꿔달라고 제안했다. 그러자 하루에만 수십명이 지원했다. 나는 1주일 동안 약 150장 가량의 서류를 검토했다.

개발자 전용 채용 플랫폼을 쓰는 것이 시간을 아낄 수 있다.

채용 과정은 서류 전형 > 과제 전형 > 면접 > 처우 협의 > 최종 입사 이렇게 진행되었다.

1. 서류 전형

지원자의 이력서를 정말 꼼꼼하게 읽고자 노력했었다. 하지만 서류가 쌓일 수록 물리적인 한계가 있었다. 한 사람당 모든 첨부 URL을 읽고, 깊은 검토까지 진행하기에는 나도 실제 개발 업무가 있는 상황이라, 한 지원자마다 5분 정도로 보기로 했다. 그렇다고 서류 검토 업무를 다른 직원들과 함께 하기는 어려웠다. 내가 시니어로 있는 팀에 같이 일할 주니어 급의 개발자를 뽑는 것이기에, 내 관점에 맞는 지원자를 색출하는 것이 매우 중요했기 때문이다.

좋은 지원자 서류

서류를 보다보면, 빠르게 결정을 내려줄 이력서가 정말 좋다. 예를 들면, 자신이 한 프로젝트 이름보다는 실제 기능을 적은 것 말이다. 예를 들면, 단순한 소셜 네트워크 서비스 “너와 나”를 이력서 적고자 한다고 가정하자. 이력서에 이것을 그냥 프로젝트 이름 뿐인 “너와 나"를 읽으면 직관적으로 이해가 힘들다.

읽는 사람 관점에서 직관적으로 이해하기 쉬운 맥락을 적는 것이 좋다. 이 경우는 “비슷한 관심사를 가진 사람들을 매칭해주는 서비스, 너와 나"라고 직관적인 기능을 명시했었다면 좋았을 것이다.

진행한 프로젝트가 일반적으로 모두가 아는 범용 서비스라면 서비스 이름을 바로 명시해도 좋을 것 같다.

그래서 서류를 누르자마자 직관적으로 정보가 보이는 서류가 제일 좋았다. 지원자 분들도 자신의 이력서를 정리하느라 고생한 것은 충분히 이해하지만, 채용을 고려하는 사람들은 서류를 정말 많이 확인해야 한다.

많은 개발자들이 사용성과 사용자 중심을 생각한다고 80%이상이 이력서에 적어둔다. 서류 전형에서 서류를 읽는 경험도 생각해줬으면 좋겠다.

그리고 서류를 읽는 사람 관점에서 용어를 적는 것이 중요하다. 보통의 이력서에서는 자신의 맥락 속에서 사용되는 용어가 많이 보이게된다. 누구나 아는 용어는 괜찮지만, 자신의 경험 속에서만 특수하게 사용하는 도메인 용어들도 있다. 그런 용어를 이력서에 그대로 사용하면, 직관적으로는 파악하기 어렵다.

다른 사람에게 자신의 이력서를 보여주고, 직관적으로 이해가 되는지 피드백을 받아보자.

객관적으로 좋은 지표

긍정적으로 봤던 것 중 하나는, 특정 목표를 가지고 노력한 경험이나 리딩 경험을 좋게 평가했다. 그것으로 예를 들면 학점, 자격증, 프로젝트 리딩 경험들이다.

아쉬운 이력서들

대부분 서류 전형에서 광탈로 처리하는 이력서들이 있는데, 바로 이런 이력서들이다.

• B/E, F/E, DevOps 기술 스택 키워드 수집가
• 깨져버린 URL (404 Not Found)
• 지원 동기가 누락된 이력서들 (모든 회사에 지원 가능한 형식)

나는 엔지니어링을 더 중요시하는 사람을 뽑고자 했기 때문에, 하나를 제대로 전문성 있게 공부한 지원자를 좋게 평가했다.

개발자 블로그

블로그는 있으면 반드시 눌러본다. 없으면 있는지 찾기까지 한다. 거기서 단순하게 기술 노트만 정리한 지원자는 특별하게 평가하지 않았다. 좋게 평가되는 블로그는, 회고록을 쓴 블로그 였다. 개발자라는 직업을 어떻게 생각하고, 어떤 경험을 하며 무엇을 느꼈는지, 경험담을 더 중요시하게 읽고자 했다.

나는 글을 잘 쓰는 개발자를 좋은 개발자라고 생각한다.

회사와 적합하지 않은 지원자

서류 전형에서는 다양한 색의 지원자 서류들을 보게된다. 회사마다 개발자들이 가지고 있는 색깔이 있다. 능력이 많이 뛰어나지만, 회사 문화와 지나치게 맞지 않는 서류도 보였다. 그런 경우는 서류 과정에서 많은 고민을 할 수 밖에 없다.

회사와 지원자의 적합도는 크게 2가지로 확인하였다.

• 기술 적합도
• 문화 적합도

기술 적합도는 회사가 오래된 회사일 수록 내부적으로 레거시 기술이 많을 수 밖에 없다. 수십년 전 개발 초기에 설계된 모듈들은 옛날 기술이 많이 사용될 수 있고, 개발 환경이나 같이 사용하는 소프트웨어들도 꽤나 구버전이거나 현대적으로는 불편한 요소가 많을 수 있다. 지원자가 너무 최신 기술 스펙 위주로 어필한다면, 기술적으로 열려있는지를 확인이 필요하게 된다.

문화 적합도는 채용하려는 팀의 분위기나 팀 분위기에 너무 문제가 되지 않을지 정도만 확인한다. 가령, 입사하게 될 팀에서 큰 갈등이 우려되거나 다른 팀 간에 소통에 큰 문제가 없을지 정도이다.

이러한 적합도는 서류 뿐만 아니라, 면접 전형에서도 다시 확인한다.

이런 관점으로 서류 전형을 마무리하고, 과제 전형을 시작했다. 이렇게 통과한 지원자들은 1주일 동안 작은 요구사항을 구현하는 과제 전형을 하게 되었다.

2. 과제 전형

과제 전형은 여러 목적으로 평가할 수 있는 전형이다. 지원자의 회사 관심도를 확인할 수 있으며, 프로그래밍 수준을 평가할 수 있다.

많은 지원자들이 과제를 제출하지 않고 잠수를 타는 경우가 많다. 과제를 모두 완수하지 못하고, 제출만 하더라도 과제 전형 합격의 여지가 있다.

과제 전형의 주 관점은 아무런 의존성 없이 순수한 환경에서 자바스크립트 프로그래밍을 하는 것이다. 여기서 순수한 환경이라 하면, Node.js를 활용한 개발 환경 구축이나 TypeScript 등의 환경이 없고, React, JQuery 같은 외부 라이브러리 사용 없이 진행하는 환경을 의미한다.

과제에서 보고자 했던 것은 지원자가 자바스크립트를 얼마나 잘 이해하고, 브라우저 동작 환경을 신경쓰며 프로그래밍이 가능한 사람인지를 주된 관점으로 보았다. React를 사용하게 되면 DOM 제어 부분을 React 내부 엔진의 도움을 많이 받게된다. 나는 지원자가 순수한 환경에서 얼만큼 최적화가 가능한지 확인하고 싶었다.

많은 서류 합격자들이 과제를 제출해주었고, 나는 DevTools의 Performance 탭에서 CPU 성능을 제한하여 과제 동작을 테스트했다. 지원자 별로 특이한 코딩 패턴이 많았다. 단순한 과제에 과하게 설계한 지원자, 왜 React 쓰면 안되는지 묻는 지원자 등 지원자 입장에서의 다양한 관점을 보게 되었다.

만약, 다음 번에도 과제 전형을 한다면 과제 설명 하단에 부가적인 설명과 구체적인 과제 구현 목표를 명시해야겠다고 생각한다.

제일 중요하게 평가한 것은 과제의 완성도이다. 치명적인 버그가 없다면 대부분 합격이었다. 코드를 어떻게 모듈화 했고, 네이밍을 어떻게 했는지는 크게 신경쓰지 않았다. 회사에 근무하게 되면 회사 가이드라인에 맞게 코딩을 해나가면 되기 때문이다.

두 번째로 중요하게 본 관점은 성능 최적화 관점이었다. 과제에서 60fps를 유지하기 위해 신경써서 프로그래밍 해달라고 명시했었다. 좋은 컴퓨팅 환경에서 구동시키면 60fps이 잘 나와 최적화가 잘 되었다고 생각할 수 있다. 실제 사용자의 실행 환경은 저사양 사무 노트북일 수도 있고, 구형 스마트폰의 웹 브라우저일 수도 있다. 이 관점을 너무 신경쓰지 않고 제출된 결과에 큰 감점이 주어졌다.

세 번째는 보안 관점이었다. 대부분의 과제 제출자는 innerHTML 같은, html 문자열을 통해 DOM 처리를 구성하였는데, 이를 쓴 제출자는 대부분 과제 전형에서 탈락했다. 불필요한 DOM 생성이나 참조를 일으키는 요인이 많은 경우도 나쁘게 평가했다.

그렇게 하여 과제 전형 합격자가 결정되고, 면접 전형을 준비하게 되었다.

3. 면접 전형

면접 전형은 과제를 본인이 직접 해결한 것인지와 지원자와 회사가 좋은 관계로 일할 수 있을지를 보았다. 이를 위해 지원자마다 최대 30분 정도로 빠르게 평가하기로 했다. 시간을 많이 투자하기엔 면접관들의 업무 시간도 생각해야하고, 깊게 평가할만큼 중요한 위치는 아니었다.

사전 면접관 회의

면접관은 3명이 들어가기로 협의하였다. 나와, 같은 팀 디자이너 1명, 미들급 개발자 1명이다. 서로 하기로 하면 안되는 질문들을 정리하고, 지원자 서류를 통해 어떤 질문들을 할지 서로 합의하였다. 여러 명이 들어가는 자리에서 면접관끼리 어떤 질문을 할지 예상이 힘들다면 면접관끼리 당황스러운 상황이 발생할 수 있기 때문에 미리 결정하였다.

가능한 사적인 질문들은 제외했다. 다만, 지원자의 공백기간이 긴 경우는 그 기간동안 어떤 활동을 했는지 짧게 들어볼 필요는 있다고 판단했다.

과제 전형 질문

온라인 과제의 경우는 지원자가 스스로 풀지 않을 경우가 상당히 있을 것이라 생각된다. 많은 주위 사람의 도움이 있을 수도 있고, AI를 활용한 도움을 얻을 수도 있다. 그렇기에 실제 지원자가 작성한 코드 관점에서 왜 이렇게 작성하였는지를 물어보았다.

그리고 추가적으로 작성한 과제 코드를 더 개선할 방법이 없었는지도 물어보았다. 과제 이후에 혹시나 아쉽웠던 포인트나 더 개선할 포인트를 생각하는 개발자라면 좋은 개발자라고 평가할 수 있기 때문이다.

기술 질문

기술 질문에는 쉬운 것과 어려운 질문들이 있다. 어려운 질문은 대답을 못해도 괜찮다. 쉬운 질문들은 가능하면 대답할 수 있어야 한다. 물론 모두 정확하고 올바르게 대답한다면 크게 부각되겠지만, 기술적으로 완벽하더라도 소프트스킬 부분에서 결점이 발견된다면 그게 아쉽게 될 수도 있다.

어려운 질문들은 지원자가 경험하기 힘든 깊은 것들이 있으며, 쉬운 것들은 공부를 하다보면 한번 씩 들어본 것들 위주로 질문했다.

자신이 이력서에 사용한 단어들을 충분히 설명이 가능한지, 다른 사람들에게 잘 설명하는지를 위주로 평가했다.

문화 적합도 질문

대면 면접을 하게 되면 지원자에게 받는 전반적인 느낌을 통해 오는 성향을 조금이나마 알 수 있다. 물론, 함께 오랫동안 근무를 하지 않으면 깊게는 알 수 없을 것이다. 만약 고집이 너무 강한 지원자인 경우, 협업에 어려움이 있을 수 있다.

근무 여건 질문

근무 여건은 여러 가지가 있다. 출퇴근 거리와 희망 연봉, 원하는 근무 문화 등을 물어본다. 근무 여건이 크게 맞지 않는 경우는 잠재적으로 장기 근무 가능성이 낮다고 볼 수 있다.

함께 오랫동안 일할 정규직 직원을 뽑는 자리에서 근무 여건에서 불편한 요소들이 보이면 채용에 주저함이 생긴다. 예를 들어 줄 수 있는 적정 연봉은 책정되어 있는데, 지원자가 큰 연봉을 말한다면 그것도 고려할 것들이 많다.

모든 조건에 100점인 지원자도 없고, 회사도 없다.

처우 협의와 채용

모든 면접 전형이 마무리 되면 채용 인원 확정과 채용 우선 순위를 정한다. 몇 명을 뽑을 지, 최종 합격과 후순위 채용자와 불합격자를 정한다. 그리고 최종 합격자와의 처우 협의를 통해 입사 여부를 결정하는데, 입사 거부를 할 수도 있다.

최종 입사는 정말 출근하는 날까지 알 수가 없다.

그렇기 때문에 정말로 불합격이 된 지원자가 아니라면, 합격 결과 연락이 늦을 수도 있다. 너무 만족스러운 지원자거나 불합격이 확실한 지원자는 소식이 빠르겠지만, 연락이 늦는다면 후순위를 고려해봐도 좋겠다.

마치며

내가 처음으로 웹 F/E 개발자 채용 과정에 관여하며 얻은 과정과 생각했던 관점들을 정리해보았다. 처음으로 지원자 서류를 검토하고, 과제 전형을 통해 평가해보고, 면접 전형에서 어떤 것들을 질문해야 할지 많이 고민해보았다.

이러한 내용이 개발자를 준비하는 취준생과 개발자를 채용하고자 하는 관계자들에게 좋은 자료로 참고가 되었으면 한다.