개발 이력서는 프로젝트 단위로 쓰다 보니 팀이 한 일과 본인이 한 일이 한 덩어리로 붙어 버립니다. 무엇을 만들었다는 문장은 남는데 왜 그 방식을 골랐고 어디서 막혔는지는 지면에서 사라집니다. 진단은 이력서를 경험의 시장 경쟁력과 표현·전달 두 갈래로 나눠 각 7개씩 14개 항목을 봅니다. 점수를 매기는 대신 이미 적혀 있는 문장을 근거로, 어느 대목이 약하게 읽히고 어떻게 고치면 전달되는지를 알려드려요. 아래에서 직무를 고르면 그 직무 이력서를 14개 항목으로 진단한 예시를 볼 수 있습니다.
SW 개발 이력서는 쓴 기술 목록이 서로 비슷해서 그것만으로는 구분되지 않습니다. 백엔드 개발자는 어떤 규모의 트래픽과 데이터를 다뤘는지, 프론트엔드 개발자는 화면을 만든 것 외에 성능과 접근성을 어디까지 챙겼는지 적어 두면 읽는 쪽이 범위를 가늠할 수 있습니다. 모바일 개발자는 출시와 운영을 몇 번 겪었는지, DevOps·SRE는 어떤 장애를 어떻게 줄였는지가 드러나야 합니다. 임베디드 개발자는 펌웨어가 들어간 하드웨어와 양산 여부를, 시스템 SW 개발자는 직접 다룬 운영체제 층과 추적한 장애를 밝혀 두면 좋습니다. QA 엔지니어는 테스트 도구보다 품질 기준을 세운 이야기가, 보안 엔지니어는 진단과 대응을 실제로 맡은 범위가 필요합니다. 풀스택 개발자는 다룬 영역을 나열하기보다 한 서비스를 끝까지 책임진 사례를 앞에 두는 편이 낫습니다.
직무를 고르면 그 직무 이력서를 14개 항목으로 진단한 예시를 볼 수 있어요.