좋은 이력서란 무엇일까?
Interviewer eXperience?
이력서를 작성하며 학습한 내용이다.
읽기 좋은 글 쓰기
인지 부하를 줄여라.
- 문장은 간결하게 목록으로 구성한다.
- 글씨 크기와 공백으로 적절히 디자인한다.
- 필요하지 않은 내용은 걷어낸다.
이해하기 쉬운 용어를 써라.
- 지원할 회사와 직무에서 쓰지 않는 용어는 순화한다. (e.g. EMR → 병원 업무용 데스크탑 앱)
- 부족하면 적절한 위치에 설명을 덧붙인다. (e.g. 용어를 처음 사용할 때: 접수·진료·결제 등을 처리하는 병원 업무용 데스크탑 앱)
관련된 내용은 한 곳에 모아라.
- 무언가를 이해하는 데 필요한 내용을 한 곳에서 함께 보지 못해 스크롤을 반복하는 일이 없도록 한다. 가능하면 배치를 변경하고, 어렵다면 차라리 중복 작성한다.
- 이력서를 읽는 입장에서 번거로운 작업이 생기지 않도록 한다. (e.g. 경력을 일일이 계산할 필요가 없도록 총 경력 기간 작성)
링크를 활용해라.
- 이력서에 담아야 할 내용이 지나치게 많다면 강조하고 싶은 순으로 우선순위를 정해라. 이력서는 강점과 핵심만 작성하고 나머지는 GitHub이나 Notion 포트폴리오 등의 링크로 대체한다면, 인지 부하는 줄이되 정보는 더 많이 제공할 수 있다.
- 단, 링크는 어디까지나 보조 수단이다. 중요한 내용을 링크로 대체해서는 안 되고, 너무 많은 링크로 도배해서도 안 된다.
이목 끌기
첫 페이지에서 내가 어떤 사람인지 충분히 설명해라.
- 앞으로 이어질 긴 내용들을 읽게 만들려면 먼저 관심을 가지게 만들어야 한다.
- 2–5줄 내외의 자기소개(커버레터)를 작성한다. 자기소개는 회사에서 요구하지 않았다면 지나치게 길지 않아야 한다.
- 경험과 보유 기술을 작성할 때, 채용공고와 매칭되는 내용을 우선으로 작성한다.
이력서를 읽는 사람의 역할이 다르다는 것을 고려해라.
- 이력서는 나를 판매하는 행위이다. 제품이 하나라고 고객 그룹 또한 하나가 아닌 것 처럼, 이력서도 마찬가지다.
- 그룹은 크게 인사 담당자와 실무자로 나눌 수 있다.
- 인사 담당자는 실무자보다 먼저 이력서를 검토하고 지원자를 걸러낸다. (스크리닝) 수십, 수백 건의 이력서를 받는 입장에서 장문의 이력서는 보는 순간 큰 피로감을 유발할 것이다.
- 그에 반해 실무자는 지원자의 전문성을 파악하고 면접 질문을 준비해야 한다. 때문에 지원자의 이력서를 면밀히 들여다볼 텐데, 만약 본인이 반드시 채용해야 할 만큼 매력적인 경험을 가지고 있지 않다면 1–2페이지의 이력서로는 부족할 수 있다.
- 이력서는 이목을 끌기 위한 목적으로 핵심만 작성하고, 링크를 제공해 포트폴리오로 유도하는 전략을 사용할 수도 있다.
영문 이력서는 1–2페이지를 권장한다.
경험을 포트폴리오로 표현하는지, 이력서에 기술하는지의 차이.
회사가 알고 싶은 것
내가 회사에 적합한 인재라는 것을 나타내라.
- 자기소개 영역을 활용하는 것이 좋다.
- 가장 중요한 것은 경험이다. 모든 내용은 내가 보유한 경험(경력, 기술 등)과 이어지도록 작성한다.
- 지원 동기를 포함한다. (e.g. ~ 이유로 회사와 핏이 맞고 ~ 문제를 잘 해결할 수 있다고 생각하고 ~ 로 성장하고 싶다)
- 원한다면 관심사를 포함한다. (e.g. A에 관심 있어 ~ 를 공부하고 ~ 프로젝트에 적용한 경험이 있다)
경험에 WHY, HOW, WHAT을 포함해라.
골든 서클(Golden Circle) 이론
WHY — Purpose: 이 일을 왜 했는지
HOW — Process: 어떻게 문제를 해결했는지
WHAT — Result: 이 일로 얻은 성과는 무엇인지
- 일을 시작하기 위해 설득이 필요하듯, 이력서도 나를 채용하게 만들기 위한 설득의 과정이다.
- 문제 해결 능력을 중요시하는 회사는 이런 소프트 스킬 또한 중요시한다.
- 직관적이면 이해하기 쉽다. 성과(WHAT)는 가능하면 수치화한다. (e.g. Babel을 ESBuild로 대체해 빌드 시간을 N초에서 M초로 단축)
직무 외적으로 기여한 경험을 작성해라.
- 직무 경험이 충분히 있어야 하지만, 매몰될 필요는 없다. (e.g. 프로세스 개선, 사내 문화 도입)
- 직무 경험과 동일하게 문제 해결 과정은 모두 WHY, HOW, WHAT을 포함해라.
필요하면 토이 프로젝트를 강조해라.
- 토이 프로젝트는 A부터 Z까지, 내 모든 것을 보여줄 수 있다. 회사에서 쌓은 경험이 부족하거나 만족스럽지 못했다면 오픈 소스나 토이 프로젝트 경험을 잘 살리는 것도 방법이다.
- 토이 프로젝트라고 가볍게 여겨 단순히 결과물만 제출하기보다, 실제로 일하는 것처럼 프로젝트의 이유와 목적, 사용 방법, 소프트웨어 설계나 문제 해결 과정 등을 문서화하는 것이 좋다.