핵심 내용만 요약하자면 다음과 같다.
- 신입 개발자가 갖추어야 하는 역량과 나의 경험을 연관지어 본다
- 나의 강점을 구체적인 수치로 제시한다
- 나에게 유리한 것, 그렇지 않은 것을 구분한다
유리: 관련 도메인 어필 / 불리: 다수가 공감할 수 없는 것
글쓰기도 코드와 똑같다. 같은 함수를 사용하더라도 의도했던 목적에 따라 쓰임새와 활용방법이 다른 것 처럼.
타 직군과의 협업 경험, 프로젝트 관리에 대한 성과, 다수와의 소통 경험 등
이 부분은 공백기와 짧은 경력 중 어떤 것을 내미는 게 나한테 더 유리할 지를 생각해보는 것이 좋다. 근무경력은 아니지만 알바를 해왔거나, 근무경력이 짧지만 계약직이라 원래 그렇게 정해져 있었다면 상황에 맞게 기재할 것. 그 외의 공백기(수험 준비 등)가 있다면 답변을 준비해 놓는 것이 좋다.
프로젝트 파트를 작성할 때와 유사하게 할것. (두괄식, 골든서클, 간결하게)
참여 비중이 낮았던 프로젝트라면, 기존의 경험과 다른 역량을 어필할 수 있는 요소 위주로 기재
개발자 역량과 연관지을 수 있는 부분만 간단히 작성. 그것도 아니고 크게 관련이 없다면 간단히 이력만 작업.
전공자가 비전공자보다 유리한 것은 사실이지만, 최근 비전공 개발자가 느는 추세. 전공자가 비전공자보다 유리한 이유는 기본적인 CS 공부를 했음을 학력으로 나타낼 수 있기 때문.
외국어: 유효한 자격증을 중심으로 기재
수상경력: 개발관련 수상경력을 중심으로 기재
학습 활동: 스터디, 컨퍼런스 참여 경험 등 기재
- 인사담당자는 이력서에 있는 정보만 얻을 수 있다
-> '블로그에 있다', '포폴에 있다' 는 너무 안일한 생각. 이런 수고를 별로 하고싶어 하지 않는다.- 자세함/구체적임은 이력서 길이에 비례하지 않는다
-> 자세함은 길게 쓰라는게 아니라, 숨겨진/모호한 부분을 구체적으로 설명하라는 것- 입사 의지가 뚜렷할수록 매칭 적중률은 높아진다
- 내가 받는 결과에는 대부분 이유가 있다
- 조건이 갖추어졌다면 시도와 합격은 비례한다