수많은 이력서를 보며 느낀 것들

최근 새롭게 팀원을 뽑게 되면서 여러 이력서를 보게 되었다.

처음에는 단순히 지원서를 검토하는 일이라고 생각했는데, 막상 하나씩 읽다 보니 생각보다 고민할 지점이 많았다.
어떤 기준으로 봐야 공정할지, 제한된 시간 안에서 무엇을 우선적으로 봐야 할지, 그리고 나였다면 이력서를 어떻게 써야 할지도 자연스럽게 돌아보게 되었다.

이번 글은 그 과정에서 느낀 점을 정리한 글이다.

그렇기에, 이번 내용은 몹시 주관적이다. 정답이 절대 아니다.
회사마다, 팀마다, 개인마다 보는 성향과 상황이 다를 수 있는 그중 하나일 뿐이다.

수많은 서류

이번에 지원을 받으며 얼마나 서류가 많이 들어오는지 체감했다.

가볍게 이번 공고에 대해 설명하면

• 0~5년차 백엔드 개발자
• 이미지 프로세싱 및 AI 도메인 업무
• 상시 공고

이다.

관심이 있다면, 아래 링크를 참고하자. (채용이 완료되면 존재하지 않는 페이지일 수 있다.)
[미리디] 백엔드 개발자 - 이미지 프로세싱

저연차를 대상으로 하기도 하고, 연차 범위가 넓은 만큼 생각보다 빠르게 많은 지원서가 들어왔다.
기본 조건이나 사전 확인 단계에서 먼저 정리된 건들도 있었지만, 그래도 직접 읽어야 하는 서류가 꽤 많았다.

그 후에도 서류는 계속 들어왔고, 전달받은 서류들을 하나씩 보기 시작했다.

서류 리뷰 시작

전달된 서류를 받을 때는 하나씩 꼼꼼히 보고, 모든 내용을 다 봐야지 라고 생각했다.
그렇게 서류 하나에 20~30분가량이 걸렸다.

서류에서 봐야 할 요소들은 아래와 같다.

• 자기소개
• 깃허브 주소
• 블로그 주소
• 경력 & 프로젝트
• 활동
• 포트폴리오

각 요소들을 보는 데 걸리는 시간은 정확히 산정할 수가 없다.

'깃허브에 있는 프로젝트를 들어가서 README 나 코드를 본다'
'블로그에 흥미로운 글이 있는지 찾아본다'
'프로젝트 내용 및 이력서의 내용을 찾아본다'

한 개를 끝내니, 이력서가 4개 정도 더 추가로 쌓였다. ☠️
해야 하는 업무도 있기에 초조해지기 시작했다.

가장 큰 문제는 백엔드 개발자의 이력서가 대부분 글로 이루어져 있다는 점이었다.
읽는 양이 많아질수록 피로가 쌓였고, 그에 따라 리뷰의 정성이나 기준이 흔들릴 수 있다는 것도 느꼈다.

하나의 이력서에서 너무 많은 자료를 보려고 하니, 오히려 평가 기준이 흐려질 수 있겠다는 생각도 들었다.

이력서나 포트폴리오에 설명이 부족한데도 블로그를 직접 찾아서 보려고 했지만,
어떤 분의 블로그는 하나씩 다 보고, 어떤 분의 블로그는 하나씩 다 보지 못하는 일도 생길 수 있었다.

서류를 보기 위한 기준

위의 문제점을 기반으로 나만의 명확하고 객관적인 기준을 세워야겠다고 생각했다.

이 기준 역시도 지금 현재 나의 상황과 생각이기에 너무 주관적이다.

이력서와 포트폴리오를 위주로, 제한적으로

지원자분의 모든 내용을 보지 않고 주어진 내용 위주로만 보기로 했다.

• 자기소개
• 프로젝트의 README
• 주어진 링크
• 이력서와 포트폴리오에서 일치하는 부분

블로그 링크가 있어도 목록과 정말 흥미로운 내용 하나만 들어가서 구경했다.
누군가의 블로그는 끝까지 보고, 누군가의 블로그는 지쳐서 제대로 보지 못한다면 그것 역시 공정하지 않다고 느꼈다.

그래서 모두에게 똑같이 "주어진 자료 위주로, 제한된 시간 안에" 보자는 기준을 세웠다.

JD 와 회사의 방향성에 맞는지 정렬하기

자격요건과 우대 사항은 결코 허투루 쓰인 문장이 아니다.
팀이나 조직의 목적, 기대에 따라 정리되는 내용이다.

실제로 같이 일할 사람들이 고민해서 적었거나, 조직과 회사의 방향성에 맞춰 정리된 내용이다.
내가 평가하는 기준도 이에 최대한 맞추기로 했다.

BFS 가 아니라 DFS 인가

넓이도 중요하지만, 어느 정도의 깊이가 있으면 좋다고 생각했다.

기술스택이 다양하고, 프로젝트가 많거나, 내용이 많더라도
그게 자신의 내용일까? '정말 이해하고 사용했는지', '본인이 고민하고 결정한 내용인지' 생각이 들었다.

AI를 사용하며, 지식의 범주나 습득 난이도는 몹시 쉬워졌다.
하지만 여전히 자신과 팀에게 맞는 지식과 고민, 그리고 깊은 이해는 스스로 해내야 한다고 생각했다.

Redis, Kafka, Outbox, Kubernetes, MSA, Spring Cloud 같은 기술이 한 프로젝트에 모두 등장하면 자연스럽게 궁금해진다.
"왜 필요했는지", "어떤 문제를 해결하려고 선택했는지", "직접 어디까지 고민했는지"가 함께 설명되어야 설득력이 생긴다고 느꼈다.

이력서를 개선하는 방향

블로그 다듬기

이력서에 블로그 링크를 제공한다는 건, 봐달라는 것을 의미한다.

그런데 막상 들어가면

• 1년 전에 멈춰 있는 블로그
• 이력서의 내용은 없고 단순 알고리즘 코드나 책에 있는 내용만 정리한 블로그
• 설치 튜토리얼을 거의 그대로 따라간 글
• 본인의 문제의식과 경험이 잘 드러나지 않는 글

와 같이 오히려 마이너스가 될 수 있는 글들이 많았다.

개인적으로 생각하는 좋은 이력서에 공유할 블로그 글은

• 겪은 문제나 해결해야 하는 문제가 뭔지
• 어떤 대안들이 있었고, 결정한 방법과 이유가 뭔지
• 어떻게 풀었는지 (가능하다면 실제 코드나 설명할 수 있는 그림이 있다면 BEST!)
• 자신이 겪은 생각과 느낀 점이 뭔지

가 드러나는 글이다.

물론, 이렇게 말하는 나조차도 요새는 단순 지식이나 설정에 대한 내용만 블로그에 쓰고 있다 ㅋㅋ..

이에 더해, 블로그 목록에서 흥미로운 글이 있다면 더 좋지 않을까.

UI, UX 를 놓치지 말 것

이력서 하나에 많은 시간을 쓰기는 어렵다.
보려고 했을 때 불편함을 느끼면 순식간에 의욕이나 흥미가 떨어진다.

• 레이아웃, 폰트는 괜찮은지
• 링크인데 하이퍼링크를 걸지 않았는지
• 링크가 깨지진 않는지 - 주소 변경, private 링크, Notion 등
• 깃허브 프로젝트의 README 는 정리되어 있는지

이외에도
프로젝트 옆에 깃허브 링크나 운영하는 서비스 옆에 서비스 링크 등을 제공해주면 좋다.

억지로 통일하지 않기

예전에 나도 실수했던 내용인데,
억지로 원인 - 해결 - 결과 나 STAR 기법 을 모든 요소에 적용하려고 하는 것이다.

나의 생각이나 고민을 적어야 하거나, 숫자를 적으려다가 오히려 내용을 초라하게 만들 수 있다.
경험의 각 요소들은 요소에 맞게 이력서에 녹여내자.

포트폴리오는 이력서를 보완할 수 있다

포트폴리오는 생각보다 쓰기 귀찮다.
이력서처럼 formal한 형태가 있는 것도 아니고, 대부분 필수로 받는 형태가 아니니까.

대신 자신이 적은 내용에 가독성과 깊이를 더할 수 있는 자리다.

1. 글로 보는 것보단, 그림으로 보는 게 더 이해가 빠르게 된다
2. 이력서 형식상 2줄 정도밖에 쓰지 못하지만, 포트폴리오는 관대하다. (자유지만, 너무 길진 않게)

평가하는 입장에서도 이력서만 있는 것보다
블로그 링크나 포트폴리오에도 설명이 있으면 신뢰가 간다.

다만, 포트폴리오에는 함정이 있다!!

가장 중요한 건, '이력서부터 잘하자' 이다.
이력서에서 흥미가 생기지 않으면, 포트폴리오까지 이어지기 어렵다.

이력서가 어느 정도 마무리되면, 그때 포트폴리오를 고려하자.

진심으로 중요한 거다. ⭐
아무리 많은 내용을 준비해도, 처음 10초의 관심을 붙잡지 못하면 다음 내용까지 읽히기 어렵다.

마무리

채용 결과에는 내가 통제할 수 없는 요소가 분명히 있다.
어떤 사람이 서류를 보는지, 그 시점에 팀이 어떤 사람을 필요로 하는지, 다른 지원자들의 상황이 어떤지에 따라 결과는 달라질 수 있다.

그렇다고 모든 걸 운이라고만 생각하고 싶지는 않다.
우리가 할 수 있는 건, 통제 가능한 부분을 최대한 잘 다듬는 일이다.

[우아한테크세미나] 테크 리더 3인이 말하는 "개발자 원칙"

해당 발표에서 동욱님의 Topic 처럼

제어할 수 없는 것에 의존하지 않도록 해보자.
아마도 이력서 검토가 얼추 끝나고 면접까지 간 분들이 있어서 면접을 본다면,
그때의 느낀 점과 생각을 또 다시 들고 오지 않을까 싶다.

모두들 화이팅!