채용 이력서/포트폴리오 · 신입 개발자
신입 개발자 이력서에서 제일 먼저 보는 3가지
“실력이 중요하죠.” 맞아요. 근데 그 실력을 보기 전에, 이력서에서 먼저 걸러지는 포인트가 있습니다. 제가 이력서 열자마자 습관처럼 확인하는 것 딱 3가지만 정리해볼게요.
신입 이력서를 볼 때, 많은 분이 “내가 한 프로젝트가 대단해 보일까?”를 걱정하더라고요. 근데 현실적으로는 처음 10초 안에 ‘읽히는 문서인지’가 먼저 결정됩니다.
코드를 보기 전에, 이 사람과 같이 일할 수 있을지부터 판단한다.
1) 구조 & 가독성 — 코드 보기 전부터 이미 점수 난다
이력서 파일을 열자마자 제일 먼저 보는 건 기술 스택이 아니라 구조예요. 제목/섹션/프로젝트가 한눈에 정리돼 있으면, 그 자체로 “일 잘하겠다”는 인상을 줍니다.
반대로, 글이 길고 흐름이 없으면 이런 생각이 먼저 들어요.
- 프로젝트는 무슨 문제 → 내가 한 일 → 결과 순서가 제일 읽기 좋음
- “열심히 했습니다/많이 배웠습니다” 같은 문장 줄이고, 사실(근거)로 대체
2) 프로젝트에서 “내가 뭘 했는지”가 선명한가
신입 이력서에서 정말 많이 보는 문장이 있습니다.
이 문장 자체는 틀린 말이 아닌데, 정보가 거의 없어요. 실무 입장에서는 “그래서 본인은 뭘 했는데?”가 바로 떠오릅니다.
- 역할/담당 범위를 1~2줄로 먼저 못 박기
- 가능하면 결과를 숫자/지표로(속도 개선 %, 오류 감소, 트래픽 규모 등)
3) 기술 스택 ‘많음’이 아니라, 기술 이해도가 느껴지는가
기술 스택을 잔뜩 적어두면 좋아 보일 것 같지만… 솔직히 말하면, 스택이 10개 넘어가면 오히려 신뢰가 떨어질 때가 있어요.
대신 이런 걸 봅니다.
- 왜 그 기술을 썼는지 설명할 수 있는지
- 어떤 트러블이 있었고 어떻게 해결했는지
- 하나라도 깊게 써본 흔적(설계/트러블슈팅/성능/테스트 등)이 있는지
“써봤어요”보다 “이 상황에서 이 이유로 선택했고, 이런 trade-off가 있었다”가 훨씬 강합니다.
- 기술 스택은 ‘나열’보다 프로젝트 문장 안에 녹이기
- 자신 없는 기술은 과감히 빼고, 자신 있는 2~4개를 더 탄탄하게
- 깊게 한 경험이 없으면 “학습/개인 실습”으로 분리 표기
마무리 — 신입에게 기대하는 건 ‘완성도’가 아니라 ‘태도와 근거’
신입에게 완벽한 실력을 기대하진 않아요. 대신, 정리할 줄 아는 사람, 배운 걸 자기 말로 설명하는 사람, 같이 일할 때 불안하지 않은 사람을 찾습니다.
이력서는 “저 이런 사람이에요”를 보여주는 첫 대화고요. 그래서 프로젝트가 화려하냐보다, 읽히냐/설명되냐/근거가 있냐가 먼저입니다.
이 메일이 도움이 됐다면, 취업용 프로젝트 4주 안에 만들기 페이지도 한 번 참고해보세요.
—