19년 차 개발자가 말하는 회사가 뽑고 싶어하는 개발자

[이력서]

인턴 경험이나, 교육 과정, Toy 프로젝트가 있는 개발자
개발에 대한 진정성이 느껴지는 것이 좋다. 취업만이 목표인 지원자보다는, 개발 자체를 즐긴다는 근거가 필요하다. Toy 프로젝트와, 취업 준비용 학습은 전혀 다르기에 Toy 프로젝트가 많으면 좋고, 개발이 왜 재밌는지 표현하는 것도 필요하다.
3~5문장으로 자기소개를 요약, 이에 대한 근거 기재
- 개발에 진정성이 있다면 그 뜻이 무엇인지
- 꾸준하게 노력하는 개발자라고 표현했다면 그 방증의 자료
- 협업이 잘 되는 개발자라면 어떤 사례가 있었는지 등
주니어일수록 기술 스택을 많이 적는 것보다는 핵심 기술 스택을 언급
만약 그래도 많이 적고 싶다면 해당 기술 스택의 경험과 연관된 링크나 설명을 보강하는 것이 좋다. 주의해야 할 점은 별이나 알파벳으로 점수를 메기는 것은 썩 좋은 효과를 보기 어렵다는 것이다. 그 이유는 높게 점수를 매긴다면 의구심을 가지게 되고, 낮게 점수를 기재한다면 자신감 부족 혹은 잘 못하는 기술을 언급한 것에 대한 아쉬움을 느낄 수 있기 때문이다.

[블로그]

최근에 틀린 정보를 쓰는 블로거가 많다. 물론 항상 맞는 정보로만 글을 쓸 수는 없는데, 기본적으로 블로그를 해야 한다는 강박이나 기본 포폴이라는 스펙 같은 느낌의 블로그로 느껴지기 쉽다. 출처 표기 없이 복사+붙여 넣기한 블로그도 수두룩하다. 날짜를 보고 비교해야지만 해당 글의 원본 블로그를 확인할 수 있을 정도다. 혹은 특정 토픽에 대한 참고 자료만 모아 놓은 글도 많다. 물론 이러한 글도 쓸 수는 있지만 이런 글만 존재해선 좋은 점수를 받기 힘들다.

블로그에서 확인하고 싶은 주요 소재는 본인의 생각과 경험을 작성하는 것이다. 개발 일기, 디버깅 과정, 삽질기, 의견, 고찰 등 아래 주제라면 조금 더 관심이 가는 주제다.

복잡한 비즈니스 로직 구현 이슈
힘들게 한 버그
트래픽 이슈

기본적으로 면접 요청을 하면 지원자나 면접관이나 모두 큰 코스트를 쓴다는 것을 안다. 원하는 성향의 개발자인지를 블로그 등으로 먼저 확인하길 바라는 측면이 있다고 보면 좋다.

[Github]

Github도 사실상 표준처럼 자리 잡았다. 최근에는 취업 준비용 스터디, 혹은 학습 기록 등도 Github에 많이 올려져 있다. 학습 기록이나 스터디 자체가 부정적인 영향을 주지는 않지만 이런 저장소만 존재하면 좋은 점수를 얻기 힘들다. 도움을 받은 프로젝트나 관심 있는 프로젝트에 대한 fork도 나쁘지 않지만 이것도 마찬가지로 이러한 저장소만 있는 것은 좋지 않다.

비즈니스 로직을 구현하는 프로젝트가 좋으며, 서비스 유사 경험 혹은 특정 서비스 모방을 통한 학습, 직접 사용하기 위한 기능 개발, 실제로 배포하고 운용한 경험까지 이어지면 좋다. 또 패키지 저장소에 배포도 해서 진짜 오픈 소스 개발을 하는 것도 유의미하다. 만약 면접관이 사용하거나 영향받은 저장소의 개발자가 지원한다면 바로 뽑고 싶어지지 않을까?