회사가 뽑고 싶어하는 개발자

📌 글 작성

성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
아주 작은 스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 개발자

소개

나는 19년 차 개발자다.

여러 회사에서 공채 면접관, 공채 교육, 수시 채용 면접관, 신입 직원 케어를 담당해 보았다. 면접관 입장에서 지원자를 탈락 시키기보다는, 합격 시키고 싶다. 회사 입장에서도 채용, 그리고 면접에 큰 코스트를 쓴다. 그렇기에 서류 검토라는 과정에서 가능하면 합격 확률이 높은 지원자와 대면하고 싶고, 면접 과정에서도 지원자의 장점을 보려고 노력한다.

하지만 이러한 준비 과정이나 마음가짐에 대한 이해가 떨어지는 지원자가 많은 것이 현실이다. 이에 대해서 이야기해 보고자 한다.

개요

어디든 상관없다는 생각이 아니고서야, 우리가 회사를 지원할 때는 그 회사에 꼭 가고 싶은 마음이 있다. 그래서 지원한 회사의 선택을 받기 위해서 채용 전형을 진행한다.

하지만 생각보다 우리는 회사가 어떤 지원자를 뽑는지 잘 모른다.

관심이 없어서라기보다는 알기 어렵다고 말하는 것이 정확할 것 같다. 보통 채용 경험이 있는 면접관이나 인사권자가 이러한 이야기를 공개적으로 하는 경우가 드물고, 뚜렷한 정의나 솔직한 이야기보다는 채용 중인 포지션의 지원자를 늘리기 위한 관점이 더 커서인 거 같기도 하다.

전제

모든 채용에서 일반화할 수는 없고, 회사나 조직마다 인재상이 다르다. 주로 내가 대화해 본 면접관이나, 채용 경험, 또 내가 같이 일해본 동료들이 이직하고 나서의 선호하는 인재상이 이런 것이라는 관점에서 봐주면 좋겠다.

이력서로 살펴보는 선호하는 이력서

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

블로그

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

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

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

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

Github

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

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

사례로 살펴 보는 면접 경험

합격 시킨 케이스

• 고민의 폭이 넓은 지원자
• 자신이 속한 시스템의 문제점과 나아갈 방향까지 고민해 본 지원자
• 깊이 파고드는 경험의 지원자
• 원리를 이해할 때까지 끈질긴 고찰과 결론의 과정이 드러나는 경험, 또 그러한 경험에 대한 답변으로 이어지게끔 대화를 끌어나가는 지원자
• 협업이 잘 될 거 같은 지원자
• 질문의 핵심을 잘 파악하거나 대화 과정의 피드백에 대한 수용
• 질문을 이해하기 위해, 전제 조건이나 의도를 재확인하는 지원자
• 누가 봐도 똑똑한 지원자
• 지적 호기심이 많은 지원자
   

불합격 시킨 케이스

• 이력에 적혀있는 내용에 대한 설명을 잘 못하는 지원자
  포트폴리오든 업무 경험이든 이력서를 쓰고 기억이 흐릿해지는 경우가 있을 순 있지만 이러한 경험은 부정적인 인식을 심어주게 된다. 자신의 이력서와 포트폴리오에 대한 내용은 다시 복기하고 예상 질문을 준비한 뒤 면접에 참여하는 것이 좋다.
   
• 본인이 담당한 부분에 대해서 겉핥기 설명만 하는 지원자
  예를 들어 “웹 소켓을 써서 채팅을 구현했습니다. 웹 소켓의 원리에 대해서 설명해 보시겠어요?”라는 질문을 받았는데 “잘 모르겠습니다.”와 같은 답변이 온다면 기술을 가져다 쓰는 데에만 관심이 있다고 인식되고 이는 기본기가 좋지 않고 탐구심이 낮고, 원리 이해 부족, 근거가 부족한 선택을 하지 않았을까 하는 부정적 인식을 심어주게 된다.
   
• 컴퓨터 과학 기초에 대한 이해도가 우려되는 지원자
• 어떠한 기술을 왜 쓰는지, 그렇게 구현한 이유가 무엇인지에 대한 설명을 못하는 지원자
• 동작 원리에 관심이 없는 지원자
   
• 시간 복잡도가 무엇이고, 어떠한 알고리즘이 어떤 시간 복잡도인지 외운 것 같은 지원자
  물론 대답 자체를 못하는 경우는 당연히 부정적인 인식을 갖게 된다.
   
• 구글에서만 답을 찾았다고 하는 지원자
  구글링으로 안 나오는 이슈는 어떻게 할 것인가? 구글에서 나온 답만 의미가 있는 게 아니라, 그 원리를 이해해야 하는데 이러한 인상을 못 받는다면 부정적인 인식을 갖게 된다.
   
• 의견에 대한 고집이 많아 보이는 지원자
   
• 면접 피드백 과정에서, 정정해 주거나 혹은 디테일에 대한 의견을 주고받을 때, 자신의 의견에 조금도 양보하지 않으려는 지원자
   
• 자신의 능력에 대한 자만심이 있는 지원자
  자신의 결과물에 대한 애착과 기술이나, 자신의 역량에 대한 자만심은 다르다. 개발자는 20년 이상의 경력자들도 항시 배우고, 자극받고, 개선해야 하는 직업인데, 자신의 지적 능력이나 개발 경험, 개발 기술에 대한 자부심을 표출하면 자만심으로 보이기 쉽다.

좋은 평가를 주는 경우

• 학습에 대한 갈증이 느껴지는 지원자
   
• 깊게 고민해 보고 대답하는 지원자
  오답일지라도, 근거 기반의 대화를 시도하는 지원자에게 점수를 주는 경우가 많았다. 중간에 생각을 포기하거나, 결론을 내리지 못하는 경우는 점수를 주기 어렵다.
   
• 주도적이고 의욕적이고 실천적인 지원자
• 제품의 중요성에 대해서 이해하고 있는 지원자
• 다른 개발자들과는 다른 특별한 장점이 있는 지원자
   
• 글쓰기와 문서화를 잘 하는 지원자
  개발자에게 글쓰기는 커뮤니케이션이다. 코드와 문서화로 소통이 부족한데 말로는 설명 잘 한다? 임기응변만 잘하는 입 개발자이거나 팀 작업에 어울리지 못하고 고집을 부리는 개발자라고 볼 수도 있다.

면접을 볼 때 지원자와 함께 일한다면 어떤 경험일까를 고민한다. 조직이 갖고 있는 문화에 적응하고, 발전시켜나갈 성향인지, 역량인지를 감안하고 채용을 결정하게 된다. 회사의 상황에 따라, 신규 채용은 기존 직원 대비 차별점이나, 역량 자체가 우수한 사람을 선호하게 된다. 최근 트렌드상 팀 단위는 4명에서 10명 이하를 선호하는 추세이며, 개발자 한 명이 가진 영향력은 굉장히 크다.

또한 좋지 않은 역량이나 성향의 개발자 한 명을 채용하면, 그 팀에 잘하는 개발자가 퇴사하는 일도 비일비재하기 때문에 자신이 긍정적인 영향을 줄 수 있는 개발자라는 인상을 심어주기 위해 노력해야 하고, 실제로 그런 역량을 보유하기 위해 노력하는 것이 좋다.

회사에 따라 선호하고, 집중적인 질문이 다르다.

항상 이런 것은 아니지만 회사의 도메인에 따라서 중요시 여기는 기술이 다른 경우가 많다. 핀테크 등의 돈과 정합성이 최우선인 도메인의 경우 디비 이해도를 조금 더 중요시 여기는 경우가 많다. 또는 교육 문화가 좋아서 학습 코스트를 들이더라도 기본기가 좋은 지원자를 뽑는 회사들의 경우 CS 기초를 중요시 여기고 물어보는 경우가 많다.

데이터 처리량이 중요한 회사들은 Hadoop, Spark, Kafka 등의 사용 경험과 함께 NoSQL 이해도와 사용 경험을 우선시하곤 한다. 혹은 데이터의 처리 속도를 끌어올리기 위한 메커니즘 이해도를 중요시 여기기도 한다. 제품의 빠른 사이클을 중요시 여기는 회사는 평균적 능력치, 제품 위주의 마인드를 가질 수 있는지, 유연한 생각과 마인드에 대해서 확인하곤 한다.

또 생산성을 위해서 도메인 이해도나, 기술 스택에 대한 친숙도를 우선시하는 경우도 있다. 즉, 어느 정도 회사의 관심사를 확인하면, 기대하는 개발자의 성향에 대한 온도를 유추할 수 있고, 이에 대해서 준비가 가능하다는 뜻이다.

마치며

이직도 전략이어야 한다. 사정에 따라서 퇴사를 하고 나서 구직 활동을 하는 경우도 적지 않겠지만, 재직 중에 차근차근 목표로 하는 회사에 대해 준비하거나, 취준생의 경우에도 목표로 하는 회사의 범위를 좁혀놓고 타게팅 기반의 준비를 한다면 좀 더 합격률을 높일 수 있다.

부디 이 글이 도움이 되어 많은 개발자가 본인이 원하는 회사를 갈 수 있길 바란다.