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

인덴트와 좋은 프로그래머와 더 많이 인연이 닿기를 바라는 마음으로 서류 전형과 코딩 과제 전형 합격 비기를 알려드립니다.

프로그래머 이력서와 코딩 과제, 검토자는 무얼볼까?
Photo by Markus Winkler / Unsplash

인덴트의 채용 과정은 다음과 같습니다.

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

이 중 '이력서'와 '코딩 과제'를 검토하며 느낀 점을 정리해볼까 합니다. 인덴트 채용에 관심 있는 분이라면 인덴트 홈페이지의 채용란을 참고해주세요.

이력서

이력에서 보고 싶은 점

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

이력서에 무엇을 만들었고 어떤 회사에 다녔는지 정도만 작성하는 분이 많더군요. 서류 검토자는 아직 만나지 않은 지원자에게 어떤 점이  궁금할까요? 첫째로는 능력이 있는지, 둘째로는 성장성이 있는지를 보고 싶습니다. 따라서 A라는 기능을 만들면서 어떤 어려움을 겪었는지, 이 과정에서 무엇을 배웠는지 등 좀더 구체적인 경험을 보여주시면 지원자에게 관심이 더 생깁니다.

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

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

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

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

기술 점수에서 보고 싶은 점

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

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

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

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

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

깃헙에서 보고 싶은 점

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

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

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

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

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

코딩 과제

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

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

기능 구현 방법

인덴트에서는 필요한 기능을 최대한 간결한 코드로 작성하길 기대합니다. (이 부분은 회사나 팀마다 성향이 다를 수 있음을 일러둡니다.) 기능에 비해 코드가 장황하다면 나중에 읽기도 힘들고 버그가 발생할 우려도 생기니까요.

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

커밋 메시지와 컨벤션

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

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

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

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

질문하기

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

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

결론

이력서와 코딩 과제를 검토하는 기준을 적어보았습니다. 가급적 일반적인 기준을 적어보았으니 타 회사에 지원하실 때에도 갖고 계신 실력을 더 잘 전달할 수 있기를 응원합니다.

마지막으로 인덴트의 채용에 관심 있는 분은 인덴트 홈페이지의 채용란을 참고해주세요.

사람이 온다는 것은 실로 어마어마한 일이다.
그 사람의 과거와 현재와 그리고 그의 미래가 함께 오기 때문이다.
바로 한 사람의 일생이 오기 때문이다.
 
방문객, 정현종