프로그래머 이력서와 코딩 과제, 검토자는 무얼볼까?

최근의 경력상 이력서와 코딩 과제를 검토할 기회가 많았는데요. 지원자들을 어떤 기준으로 선정하고 있는지 돌이켜보니, 이런 정보를 지원자들이 알고 계시면 도움이 되리라 생각하여 공유해봅니다.

일반적인 프로그래머 채용 과정은 다음과 같습니다.

0. 이력서 검토
1. 코딩 테스트 혹은 과제
2. 기술 면접 (1회~n회)
3. 대표 혹은 컬처핏 면접
4. 처우 협의

이 중 '이력서'와 '코딩 과제'를 검토하며 느낀 점을 정리해보았습니다.  (코딩 테스트 혹은 알고리즘 테스트에 대해서는 경험이 별로 없어서 생각을 정리할 수 없었어요.)

이력서

이력에서 보고 싶은 점

• 이 지원자는 00 기술을 얼마나 잘 활용할 수 있을까?
• 이 지원자는 얼마나 빨리 성장할까?

이력서 검토자는 아직 만나지 않은 지원자에게 어떤 점이  궁금할까요? 첫째로는 능력이 있는지, 둘째로는 성장성이 있는지를 보고 싶습니다.

무엇을 만들었고 어떤 회사에 다녔는지 정도만 짧게 작성한 이력서를 만난다면 조금 난감한데요. 엄청나게 유명한 무언가, 기술적으로 실력 있다고 평가 받는 회사에 다녔던 경험 (그것도 직전 회사) 정도라면 관심을 끌 수도 있겠습니다. 반대로 말해서, 그런 경험이 아니라면 좀더 설명을 넣어주세요.

이런 점을 추가해주시면 좋습니다.

• (기술적인 측면) 00 프로젝트에서 어떤 어려움을 겪었는데 어떻게 해결했고 무얼 배웠다.
• (기술적인 측면) 어떤 문제를 해결하고자 00 기술을 검토했고 어떤 점이 어려웠지만 그 덕에 무얼 배웠다.
• (의사소통 측면) 동료와 협업 과정에서 어떤 의견 대립이 있었는데 어떤 식으로 풀어서 결과는 어땠고 무얼 배웠다.

(신입의 경우) 포트폴리오에서 보고 싶은 점

• 이 프로젝트를 만들면서 어떤 기술을 얼마나 배웠을까?
• 실제로 운영까지 이어진 서비스일까?
• 서비스를 운영하면서 겪은 문제는 무엇이고 어떤 고민들을 했을까?

포트폴리오 역시 이력과 비슷합니다. 얼마나 화려하고 흥미로운 프로젝트를 만들었는지보다는 해당 프로젝트를 만들면서 어떤 점을 배웠는지를 보고 싶죠.

한 가지 팁을 더 드리자면 단순한 포트폴리오에 머물지 않고 실제로 서비스를 런칭하고 운영해 본 경험이 있다면 정말 좋습니다. 서비스를 아무리 근사하게 만들었어도 실제로 운영을 해봐야만 알 수 있는 문제들이 생깁니다. 이 문제들이란 이미 취업한 프로그래머들이 겪는 실전 경험과 크게 다르지 않고요. 그렇기 때문에 작게라도 (동시 접속자가 단 열 명 뿐이더라도) 운영해보기를 추천합니다.

기술 점수에서 보고 싶은 점

• 어떤 기술을 얼마나 잘 알고 있을까?

간혹 자신의 실력을 파이썬 4/5, 자바 3/5과 같이 점수로 표현하는 분들이 계십니다. 이런 기록은 장점보다는 단점으로 다가옵니다.

점수가 높다고 해보죠. 자바 실력을 5점 만점에 5점으로 표시했다면 검토자는 이렇게 생각할 수 있습니다. '자바의 모든 내용을 다 이해했다는 걸까? 그게 가능하긴 한 걸까?'

반면 점수가 낮다면 검토자는 이렇게 생각할 수 있습니다. '자신감이 부족한 분일까?' 혹은 '같이 일하기엔 아는 내용이 너무 부족할 것 같다.'

이렇게 적는 대신 알고 있는 기술을 경력 사항에 녹여보세요. 예를 들어, 어떤 자바 프로그래머가 람다에 익숙한데 주변 사람들은 그렇지 않다는 걸 알고서 자신감이 생겨서 스스로에게 5점 만점을 주고 싶다고 합시다. 그러면 자바 5/5라고 적는 대신 람다를 사용해서 어떤 문제(가독성이나 성능 등)를 얼마나 효율적으로 개선했는지를 경력 사항에 적을 수 있겠지요.

깃헙에서 보고 싶은 점

• 무얼 만드는지 알 수 있게 커밋 메시지를 작성했나?
• 협업하기 편하게 일관성 있는 코드를 작성하는가?

요즘 이력서에는 개인의 깃헙 링크를 많이 넣어두시는데요. 깃헙 저장소가 항상 좋은 평가로 이어지지는 않습니다. 다음과 같은 부분을 꼭 신경 써주세요.

커밋 메시지: 커밋 메시지를 보고 무얼 하려는지 이해할 수 없다면 협업하기 어려운 사람으로 느껴집니다. 간결하면서도 커밋 내용을 잘 전달할 수 있는 커밋 메시지를 써두세요. 커밋 메시지 작성이 어렵게 느껴진다면, 좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 같은 글을 읽어보시길 권합니다.

컨벤션: 일반적으로 프로그래밍 언어에는 그 언어에 통용되는 규칙이 있습니다. 팀과 회사마다 이 규칙도 다르죠. 코드에서 컨벤션을 신경 쓴 흔적이 보인다면 팀/회사의 기존 컨벤션도 잘 따라오리라 기대할 법합니다. 따라서 한 프로젝트 혹은 한 사람의 코드에서 컨벤션을 통일시켜두세요. 커밋을 만들기 전에 컨벤션을 검토하는 방식도 있으니 참고하면 좋겠죠?

이걸 지키지 않은 저장소라면 차라리 비공개(priavte)로 전환하길 추천합니다.

코딩 과제

까다로운 이력서 검토를 무사히 지나면 코딩 테스트나 코딩 과제를 치르게 됩니다. 저도 이제는 달라져야 하는 코딩 테스트 글에서 말하는 코딩 테스트의 단점들에 동의하다보니, 코딩 테스트보다는 코딩 과제를 내드리는 편인데요. 코딩 과제를 살펴볼 땐 다음과 같은 점들에 주목합니다.

• 필요한 기능만을 적재적소에 활용했나?
• 협업하기 편한 코드인가?
• 필수 요구사항을 모두 구현했나?
• 요구사항을 제대로 이해하고 구현했나?

기능 구현 방법

이 부분은 회사나 팀마다 성향이 다를 수 있음을 일러둡니다.

대개 검토자는 필요한 기능이 모두 구현된 최대한 간결한 코드를 기대합니다. 일반적인 코딩 과제의 요구 사항이 그리 복잡하지 않기 때문에 코드가 복잡할 필요도 없겠지요. 그리고 검토자도 사람인지라 너무 복잡한 아키텍처, 너무 긴 코드를 만나면 답답함을 느끼고 이는 좋은 인상으로 이어지기 어렵습니다.

반대로, 코드는 간결한데 특정 라이브러리에 지나치게 의존적인 경우도 있습니다. 이러면 해당 라이브러리가 얼마나 신뢰할 만한지, 이 문제를 해결하는 데 꼭 필요했을지도 궁금해집니다. 가급적 반드시 필요한 라이브러리만 가져다 쓰시고, 최근까지 업데이트되고 있는지, 얼마나 많은 이들이 사용해봤는지(star 수나 최근 다운로드 횟수 등)도 검토하길 권합니다.

커밋 메시지와 컨벤션

코딩 과제를 작성할 때도 당연히 커밋 메시지나 컨벤션에 신경써야 합니다. 출중한 코딩 실력과 함께 협업에도 뛰어난 지원자를 찾기 때문이고, 커밋 메시지와 컨벤션이 협업에서 정말 중요한 역할을 하기 때문입니다.

필수 요구사항 vs. 추가 요구사항

최대한 과제의 '필수 요구사항'에 집중해주세요. '테스트 통과' 같은 필수 요건을 충족하지 않은 결과물이라면 굳이 '추가 요구사항'을 구현했는지도 확인하지 않기 때문입니다.

필수 요구사항을 모두 작성했다면 이후에는 추가 요구사항을 하나씩 작성해봐도 좋습니다.

질문하기

과제를 제출받은 지원자들은 평가를 받는 입장이다보니 아무래도 긴장이 되겠죠. 하지만 과제를 보며 궁금한 점을 묻지 않는다면, 과제 출제자의 의도와는 거리가 먼 코드를 작성하게 되는 경우도 많습니다. 코드 품질이 아무리 좋아도 요구사항과 거리가 멀다면 좋은 평가를 받기 어렵겠죠.

그러니 이메일이나 깃헙 이슈 등으로 궁금한 점을 많이 물어보세요. 너무 자주 묻기가 걱정된다면 질문을 모아두었다가 하루에 한 번 정도 보내는 것도 방법이겠네요.

결론

지금까지 이력서와 코딩 과제에서 기대하는 부분을 적어보았습니다. 구직자분들이 갖고 계신 실력을 검토자들께 전달하는 데 도움이 되었길 바랍니다.

취업을 준비하고 팀원을 구하는 분들이 서로 인연이 닿길 바랍니다.

너와 내가 떠도는 마음이었을 때
풀씨 하나로 만나
뿌린 듯 꽃들을 이 들에 피웠다

도종환 <인연>