최근 우리 팀에서 신규 채용을 하고 있다. 나에게는 당연히 이력서를 검토하는 역할이 맡겨졌고 함께 일할 동료를 고르는 것이니만큼 꼼꼼하게 살펴보려고 한다. 그런데 처음부터 끝까지 모든 이력서를 꼼꼼하게 보기에는 지원자가 적잖다. 이러다가는 다른 업무를 못할 것 같다.
개발자인 나는 이 과정을 조금 효율적으로 리팩토링 해보기로 한다. Early return 조건을 추가하기로 한다. 다시 말해 "안 되는 이유"를 찾기 시작한다. 불가로 판정이 난 이력서는 검토 과정을 종료한다. 이 과정을 거치고도 남아있는 이력서는 확보한 시간만큼 더 정성을 들여 살펴볼 것이다.
나를 포함한 많은 이들의 이력서에는 이처럼 "안 되는 이유"가 꽤 남아있을 것이다. 그런 것만 고쳐도 중간은 될 거라 생각한다. 그렇다면 무엇을 조심하면 될까? 사실 어쩌면 여기저기서 수차례 들어봤을 내용일 테지만, 한 번 더 강조해도 될 것 같아서 굳이 내 블로그에 글로 옮겨본다.
다른 분들의 기준은 잘 모르겠다. 하지만 내가 아래에 나열한 것과 어느 정도는 교집합이 있으리라 생각한다.
주의: 너무나도 당연한 관련 분야 경력 등은 "사소한" 항목을 다루는 이 글에서 생략되어 있습니다.
용어 및 오타
잘못된 용어를 사용하거나 오타가 발견되는 경우 아무래도 안 좋은 첫인상으로 남을 수밖에 없다. 사람이기에 실수는 할 수 있으므로 어느 정도는 물론 이해가 된다. 하지만 어딘가에서는 Typescript라고 쓰고 또 어딘가에서는 TypeScript라고 쓰고, jQuery 대신 Jquery 라고 계속 사용하고 있다면 실수보다는 부주의로 보게 된다.
중요한 서류를 작성하면서 자신이 매일 쓰는 프로그래밍 언어와 도구의 이름을 정확하게 사용했는지 다시 한번 점검할 정도의 세심함이 없다는 뜻으로 보일 수 있다. 어떤 분들에게는 아무런 문제가 되지 않을지도 모르지만, 성격이 까다로운 또 어떤 사람들에게는(예를 들면 나 같은...) 그 사소한 부분이 불편하게 느껴지기도 한다.
용어를 잘못된 방법으로 사용하는 것도 문제가 된다. 예를 들어, Vanilla JavaScript를 "라이브러리"라고 칭한다면 모니터 너머의 누군가는 몹시 불편하게 느낄지도 모른다.
정보의 양
현재 우리 팀에서는 경력직을 채용하고 있다. 신입도 아니고 경력직을 뽑는데, 어떤 분들의 이력서에는 기재된 업무 이력이 너무 없다. 프론트엔드 개발자라는 업무의 특성상 설령 회사에서 작업한 게 비공개 프로젝트이더라도 다른 정보는 충분히 남길 수 있다. 개인 프로젝트도 좋고, 예전에 작업했던 웹 사이트도 좋고, 오픈소스 라이브러리도 좋으며 하다 못해 블로그 글도 좋다. 하지만 정말 너무 내용이 없는 경우가 많다.
어떤 프로젝트에서 작업을 했는지 구체적으로 어떤 역할을 했는지 너무 길어지지 않는 선에서 적어주는 편이 좋다.
우리는 요구 사항에 기재한 경력 년수보다 약간 부족하더라도 실력이 충분하다면 채용할 의사가 있지만, 아무리 뛰어난 실력을 가지고 있어도 그게 서류에서 드러나지 않는다면 다음 기회를 얻기 어려울 것이다.
깨진 링크
포트폴리오 웹 사이트를 링크한 이력서가 있다. 당연히 클릭해 본다. 링크가 깨져있다. 워낙 이 업계에서는 사라지는 웹 사이트가 많으니까 한 개 정도는 충분히 발생할 수 있는 일이다. 그런데 링크 몇 개가 더 깨져있다면, 그건 아마도 지원자가 이력서를 보내기 전에 확인을 안 했을 공산이 크다. 적어도 채용 담당자는 그렇게 볼 것이다.
커밋 로그
이력서에서 GitHub 주소를 발견하면 당연히 들어가 본다. 이런저런 저장소가 보인다. 가장 최근에 업데이트한 저장소에 들어가 본다. 아마 그 저장소에 있는 코드가 지원자의 가장 발전한 형태의 코드일 테니까. 저장소에 들어가서 제일 먼저 하는 일이 뭘까?
내 경우에는 히스토리를 살펴본다. 최종 결과에 해당하는 전체 코드를 보는 것보다 "무엇을 어떻게 변경했나"를 보는 편이 지원자의 코딩 습관을 더 정확하게 알 수 있기 때문이다. 변경 자체에 충분한 근거와 의도가 있기를 바라면서 히스토리를 열어보는데... 상당히 많은 지원자들은 개인 프로젝트의 경우 히스토리 관리를 전혀 하지 않는다는 사실을 깨달았다.
main 또는 master 브랜치의 커밋 로그에는 온갖 의미 없는 커밋 메시지가 가득했다. "임시 저장"이라거나 "Fix bugs", "update", "." 같은 있으나 마나 한 메시지도 심심찮게 보였다. 커밋 메시지에 더 자세한 정보도 없었고, PR도 없었다. 사실, 포트폴리오용으로 만든 것 같은 팀 프로젝트도 사정은 크게 다르지 않다.
좋은 커밋 메시지를 작성하는 방법에 대해서는 온라인에 여러 글이 있으니 검색해서 읽어보기를 권한다. 때로는 특정한 포맷을 강조하는 경우도 있는데, 개인적으로는 형식보다는 의미에 집중하는 편이 더 나을 거라 생각한다. 형식만 지킨 "Update: abc.js" 라는 메시지보다는 "버튼을 클릭했을 때 대화창이 나타나지 않는 문제를 수정"과 같이 형식은 따로 없더라도 의미가 충분한 메시지가 훨씬 더 좋다고 생각한다.
경력 공백
서류에서 가장 잘 보이는 것 중 하나가 바로 경력 공백이다. 근무 기간 사이, 마지막 근무일로부터 지금까지의 경력에 빈 틈이 있다면 이를 설명할 내용도 포함해 두는 것이 좋다. 모르긴 몰라도 많은 분들에게는 충분히 이해받을만한 사정이 있었을 거라 생각한다. 하지만 서류에 적어두지 않으면 서류를 통해서 만나는 사람은 그 사정을 알 수가 없다.
스킬의 중요도
우리팀에서 "프론트엔드 개발자"를 채용하고 있다. 그런데 이력서에 적혀있는 프로젝트 이력의 "사용 기술" 항목이 예를 들어 "Java, Spring, MySQL, React"과 같이 적혀있다. 아마 당시에는 Java를 주력으로 사용했기 때문에 그와 같이 적었을 수 있다. 하지만, 현재 자신이 지원하는 직군이 "프론트엔드 개발자"인 것을 인지했다면 해당 직군에 필요한 기술을 강조할 필요가 있지 않았을까. 그렇지 않으면 "아, Java가 메인이고 곁다리로 React도 조금 하신 것 같다"고 이해하게 된다. 프론트엔드 개발자 채용에 그리 이롭지는 않을 것이다.
스킬 점수
자신의 기술을 단순히 나열하는 걸 넘어 상, 중, 하 혹은 1~10점 척도의 점수로 매기는 건 반드시 빼는 게 좋을 것이다. 다른 항목과 달리 몹시 단호하게 말할 수 있는 이유는, 지금까지 내가 얘기를 나누어보거나 온라인에서 글이나 영상으로 접한 그 어떤 개발자도 스킬 점수에 긍정적인 경우를 못 봤기 때문이다.
"상"이라고 적어두면 면접관의 괜한 도전 의식을 불러일으킬 수 있다. "중"은 애매하다. "하"는 자신감이 없어보이고 오히려 약점이 될 수 있다. 그러니까 스킬 이름 옆에 어떤 점수를 적어내든 좋은 결과는 없을 거라는 뜻이다.
혹시 이력서 옆에 스킬 점수가 적혀있다면 반드시, 꼭, 빼도록 하자.
마치며
지금까지 이력서를 작성하면서 조심해야 할 내용을 살펴보았다. 물론 이 글에 작성된 기준은 어디까지나 개인의 판단일 뿐, 모두가 같은 기준을 가지고 있지는 않을 것이다. 어쩌면 몇몇 기준은 성격이 까다로운 사람(다시 한 번, 나 같은...)들만 불편하게 여기는 것일 수도 있다. 하지만 조심해서 나쁠 게 있을까. 큰 노력이 필요한 것도 아니니 위험 요소를 제거한다는 마음으로 이력서를 제출하기 전에 한 번만 위의 체크리스트를 확인해보자.
사실, 이 글을 작성한 목적은 따로 있다. 본문에도 듬성듬성 언급되었지만 현재 우리팀에서 경력 프론트엔드 개발자 채용을 진행하고 있다. 연봉이나 복지는 내 재량이 아니라서 내가 해줄 수 있는 게 없지만, 적어도 업무 환경만은 편하고 발전적으로 만들어보려고 노력하고 있다. 함께 일하고 싶은 분인 있다면 아래 링크를 통해 지원할 수 있으니 많은 관심 부탁드린다.