개발 직군 공고에는 대부분 포트폴리오 링크를 받는 칸이 있습니다. 그런데 지원자 40명분의 저장소를 하나씩 여는 담당자는 거의 없습니다. 한 명당 3분만 잡아도 두 시간이고, 무엇을 봐야 할지 기준도 서 있지 않기 때문입니다.
결국 링크는 "받긴 받았는데 아무도 안 보는 항목"이 됩니다. 지원자는 정성껏 정리해 냈는데 열람조차 되지 않는 셈이라, 양쪽 모두 손해입니다.
이 글의 요약 — 공개 활동 요약은 점수가 아니라 질문의 재료로 쓸 때 가장 쓸모 있습니다. 활동량을 점수로 바꾸는 순간 회사 계정에서 일해온 지원자가 부당하게 불리해집니다.
무엇을 보면 되나
| 항목 | 읽는 법 |
|---|---|
| 최근 활동 시점 | 최근 몇 달 내 활동이 있는지. 오래됐다고 감점할 일은 아니고, 무엇을 하고 있었는지 물을 근거 |
| 주력 언어 | 공개 저장소에서 실제로 많이 쓴 언어. 이력서에 나열된 기술과 대조 |
| 원본 저장소 수 | 포크가 아닌 직접 만든 저장소의 규모 |
| 대표 저장소의 성격 | 개인 학습용인지, 과제 제출물인지, 유지되는 프로젝트인지 |
이 네 가지면 "이 사람에게 무엇을 물어볼지" 정하기에 충분합니다. 코드 품질을 여기서 판단하려 들면 오히려 시간이 더 듭니다.
점수에 넣으면 안 되는 이유
공개 활동량은 실력의 대리 지표가 아닙니다.
- 회사 계정으로만 일해온 사람은 공개 기록이 거의 없습니다. 보안 정책상 공개할 수 없는 조직도 많습니다.
- 커밋 수와 저장소 수는 늘리려고 마음먹으면 늘릴 수 있는 숫자입니다.
- 육아·간병·학업 등으로 개인 시간이 적었던 사람이 곧바로 감점됩니다.
그래서 이 요약은 평가 점수 산식과 분리해두는 편이 안전합니다. 화면에 보이되 점수에는 관여하지 않는 자료로 두면, 평가자는 참고하고 지원자는 불이익을 받지 않습니다.
반대로 활동이 많다는 사실만으로 가점을 주는 것도 같은 문제입니다. 요약 카드는 "확인했다"의 증거가 아니라 "무엇을 확인할지"의 출발점입니다.
요약 3줄을 면접 질문 2개로
요약을 읽고 나면 질문을 이렇게 바꿀 수 있습니다.
- 저장소 하나를 지목해서 — "이 프로젝트에서 직접 작성하신 부분이 어디인지, 남이 만든 부분과 나눠서 설명해주시겠어요?"
- 선택의 이유를 물어서 — "지금 다시 만든다면 무엇을 바꾸시겠어요? 그때는 왜 그렇게 하셨나요?"
두 질문이면 대부분 10분 안에 깊이가 드러납니다. 코드를 읽지 않고도 검증이 되는 이유는, 자기가 만든 것에 대해서는 선택의 이유를 말할 수 있기 때문입니다.
링크가 없는 지원자는 어떻게 하나
링크가 없는 것이 정상입니다. 비개발 직군은 물론이고 개발 직군에서도 공개 저장소가 없는 지원자가 흔합니다. 링크 유무 자체를 지원 자격이나 감점 요소로 두면, 실제로는 "공개 활동을 할 여유가 있었는가"를 평가하게 됩니다.
포트폴리오를 꼭 보고 싶은 직무라면 공고에 제출 형식을 명확히 적고, 파일로도 받을 수 있게 열어두는 편이 낫습니다.
전체 흐름은 지원자 한 명 파악하는 데 10분, 1분으로 줄이는 법에서 이어집니다.