백 수 현, Suhyun Baik Back-End Lead at ZET Team - Dable [email protected]
목차
이 글은 서비스를 만드는 IT 회사에 이력서를 제출하기 전 한번 더 점검하면 좋을 사항들에 대해 짚어보는 글입니다.
경력직으로 지원했는데 깃(Git)이나 기술 블로그 주소가 없는 경우가 있습니다. 채용담당자는 깃이나 기술 블로그가 있는 이력서를 보는데 시간을 더 할애하기 때문에 이러한 이력서들은 페이퍼 스크리닝 과정에서 탈락할 가능성이 높습니다. 회사 업무로 개발한 코드를 공개할 수 없으므로, 본인의 코딩 스타일과 철학을 잘 보여줄 수 있는 토이 프로젝트를 만들고 그 주소를 주는 게 좋습니다.
기술 블로그도 반드시 있어야 합니다. 이력서는 보통 1장, 최대 2장으로 몇년의 경력 사항을 최대한 압축해서 적기 때문에 이때까지 했던 경험들을 풀어내기에는 부족합니다. 특히 라이브 상태의 서비스를 개발 및 운영해본 개발자라면 많은 장애상황을 맞닥트리고 해결한 경험이 많을텐데 그런 긴 이야기들을 이력서에서 다 표현하기 힘들 것입니다. 이런 경험들은 기술 블로그에 자세히 쓰면 됩니다.
기술 블로그는 있는데 최근에 쓴 글이 2~3년 전인 경우가 있습니다. 이럴 경우에는 지원자에게 따로 연락해서 최근에 쓴 글이 없는지 묻는 과정을 추가로 거치기도 합니다. 2~3년은 긴 시간입니다. 예전 글만 있는 기술 블로그만 봐서는 해당 개발자가 최근에 어떤 스타일로 개발을 하는지, 어떤 부분에 관심을 갖고 있고 있는지 알기 힘듭니다.
경력이 없는 신입이라면 기술 튜토리얼 (예: 장고(Django) 설치하고 프로젝트 세팅하는 방법, 도커(Docker) 파일 작성하고 도커 컨테이너 띄우는 방법)만 있어도 괜찮습니다. 경력직일 경우에는 그렇지 않습니다. 개발하면서 어떤 문제점을 맞닥트렸고 어떤 방법으로 해결했는지에 대한 글이 많으면 많을수록 좋습니다. 기술 조직은 경력직에게 문제에 대한 해결능력을 기대하기 때문입니다. 반드시 기술 분야일 필요는 없습니다. 협업이나 매니징과 관련된 글도 괜찮습니다. 최근에 협업을 또는 매니징을 하면서 어떤 문제점이 발생했고 해당 문제점을 해결하기 위해 어떤 방법을 시도했고, 결과가 어떠했는지에 대한 글이 있으면 좋습니다.
본인이 이때까지 했던 일들을 전부 나열식으로 적어서 이력서가 4~5장을 넘어가는 경우가 있습니다. 아래는 인터넷에 공개되어 있는 한 이력서를 각색해본 것입니다.