개발자 면접관의 시각으로 본 면접을 보는 방법.

 

들어가며.

개발팀장을 여러해 맡게되면서 필연적으로 접하게 되는 것이 면접관의 역할을 수행해야 하는 점입니다.
나름 많은 분들의 면접을 봐오면서 느끼거나 개선해야 할 부분들,
그리고 이글을 쓰면서 생각나는 제 스스로도 주의해야 할 점을 곱씹어보는 계기로 삼을까 합니다.

각자의 면접의 스타일이 있고, 그에 따른 판단 기준이 달라 논쟁의 여지가 있을만한 부분이 있을 수 있습니다.
아래의 내용은 제 개인적인 견해이며 각 상황에 따라 다르므로 정답은 없습니다.

이런 경우도 있구나 정도로만 생각해 주셨으면 합니다. ( 소심 소심 )

 

면접을 봐 왔던 환경의 구성.

현재는 대기업이라 불리우는 곳에서 업무를 하고 있지만 지금까지의 회사는 직원 100명 미만의 중,소 규모 업체였습니다.

보통의 스타트업은 실무 면접과 함께 인성면접을 함께 보는 경우가 많아,
대부분의 경우 인사관련자와 함께 면접을 봅니다.

제가 진행하는 실무면접시에는 코딩면접을 보는 경우는 없으며,

대부분의 경우 작업했던 경험의 리뷰와 각각의 소통능력 위주로만 면접을 진행 합니다.

 

제 면접이 기술적인 부분의 검증 보다는
주로 경험에 따른 해결능력 및 직원들과의 소통능력 그리고 일을 하는 방법보다는
일을 왜 하는지에 대한 이해를 더 가중치를 높게 본 이유가 크며,
그 다음으로는 신규 기술에 대한 지식은 아무래도 저보다는 면접자 분들이 뛰어 날 것이라 판단했습니다.

 

대분의 면접은 경력 약 5년에서 10년 정도의 경력자분들을 위주로 봐 왔으며, 신입을 보는 경우는 몇번 되지 않았습니다.

약 20회 넘는 백엔드/프론트엔드 개발자, 기획, 데이터팀 경력직면접을 보면서 경험한 내용을 토대로 합니다.
회사에 인력이 부족한 곳이 대부분이였다보니, 제 담당인 개발 이외에 데이터팀, 기획자 , SE 면접등에도 참가했었습니다.

면접에 임하는 면접관인 제 자세.

가장 중요하게 생각하는 부분은
대부분의 업무가 B2C 의 업무가 많다보니 면접자이기전에 저희의 고객이라는 마음가짐으로 면접관에 임하게 됩니다.

면접이 있기 약 이틀전에 면접자의 이력서를 약 30분에 걸쳐서 한번 검토를 합니다.

그런다음 저희 업무와 관련된 부분이 있다면 메모를 하고, 
관련이 없더라도 언젠가 할 수 있을 듯한 업무 경험에 대해 메모를 합니다.  

그리고 그에 따른 질문도 미리 메모를 해둡니다.
( 대부분 질문자의 답변에 따라 질문이 변하기는 하나 가이드 되는 질문은 미리 작성해 두는게 좋습니다. )

 

면접 약 30분 전 추가적으로 체크할 부분이 없는지 확인하고 수정할 부분을 수정합니다.

 

이력서의 소소한 내용을 기억해서 이야기 하면 면접자가 "이력서에 대해서 관심을 가져주는구나" 라고
좋아할 것으로(?) 판단해서 입니다. 

한두건은 너무 바빠서 이 프로세스를 못 타는 경우도 있긴 합니다. 

 

면접자 분들이 갑의 입장으로 이력서에 충분히 기술했던 내용을 재질문 하는 것은 면접자에게 실례라고 생각합니다.

 

이력서와 면접에 대한 지원자분들이 알아두셔야 할 것들.

• 지원자의 자세에서.

  • 이력서의 오타.
    이력서의 오타는 치명적입니다.
    이력서의 첫인상이 이력서의 내용으로 확인되는데,
    오타가 있다면 다음 부분으로 읽어내려가기 싫을 정도입니다.
    이력서의 오타는 이력서를 작성하는데 있어 최소한의 성의도 넣지 않았다고 판단합니다.
    하지만, 정말 채용이 어려운 경우 어느정도의 오타는 감안하여 검토합니다. ^^;;
    

  • 자신의 이력서는 자신이 쓴 내용들에 대략적으로 기억해야 합니다.
    이력서의 내용을 물어보는데, "제가 그런것도 썼나요?" 라고 물어보는 경우가 있습니다.
    그러면 면접관도 당황, 면접자도 당황. 하하.
    대략 자신이 제출한 이력서가 어떤 내용인줄 인지하고 그에 대한 대답을 준비하셔야 합니다.
    

  • 단점은 먼저 말하지 말고 장점은 먼저 말하자.
    자신이 먼저 나서서 자신의 단점을 말할 필요는 없습니다.
    자신감 있게 장점을 먼저 피력하고,
    그 다음에 질문에 대해 내 단점을 말해야할 필요가 있을 경우만 제한적으로 설명합니다.
    그리고 그 단점을 꼭 개선이나 극복한 사례를 함께 이야기 한다면 좋습니다.

• 개발자의 자세에서.

  • 프로젝트의 기여도.
    많은 분들이 어떤 프로젝트 완수시 기여도를 높게 기술하거나 혼자서 개발했다고 제출합니다.
    하지만 그렇지 않은 경우들이 대부분입니다.
    막상 해당 프로젝트에 대한 질문을 하게 되면 맡고 있었던 영역이 한정적이였음을 대부분 인정합니다.
    

  • 운영과 개발은 별개의 것.
    어떤 기술들을 개발했다고 했을때 이미 나와 있는 솔루션일 확률이 높아 개발을 했는지 질문을 하게되면
    개발이 아닌 솔루션 구매 후 유지보수의 개념이 많습니다.
    유지보수의 능력도 하나의 능력이라고 판단하지만, 처음부터 개발한 것처럼 이력서에 기술하는 것은 좋지 않습니다.
    

  • 공부해서 배우는 것과 프로젝트 경험은 다릅니다.
    "node.js 를 했다."  라고 말하는 것은 어떤 작은 결과물이나 그에 대한 개발 내용을 숙지하고 있어야 한다는 의미입니다.
    어떤걸 만들어 보셨나요?  라고 질문을 했을때, 책을 보면서 예제를 몇개 만들어 봤다는 이야기로 끝날때가 있습니다.
    그 예제가 소소한 기능들 몇개의 구현이라면 인정을 하겠으나 그렇지 못한 경우가 대부분입니다.

  • 우물안의 개구리가 되어서는 안됩니다.
    회사내에서 아무런 외부와의 접촉 없이 내부 개발에만 집중한다면, 그 회사에 특화된 분이지 다른일을 해결하기 어렵다고 판단합니다.
    그래서 회사에서 시킨 업무 이외에 꼭 사이드 프로젝트 또는 학습을 통해서 어느 회사로 가더라고 일정 수순의 개발 업무에 대한 이해가 되도록 학습을 꼭 해야 합니다.
    

  • 경험을 너무 부풀리지 마세요.
    상식적인 선에서 판단했을때 혼자 할만한 프로젝트가 아닌데도 혼자 했다는 경우, 
    만약에 했다고 하더라도 솔루션을 사용하기만 한 것은 그것을 했다고 인정해 드리긴 어렵습니다.
    운영을 하는 것과 개발을 했다는 것과는 차이가 있다고 봅니다.
    어떤 업무나 개발 언어를 사용할 수 있다고 쓸수는 있겠지만, 그에 대한 실제 경험이 없다면 그건 경험이 아니라고 생각합니다.
    
    예를 들어, 이력서에 node.js 가능이라는 이력서 문구가 있습니다.
    그러면, 저는 당연히 그에 대한 프로젝트 경험과 사용여부를 문의를 드릴테고요.
    책으로 개인적으로 했다고 답은 하지만, 그에 대한 결과물이 없으면 그건 하지 못하는 것 입니다.
    
    UI 가이드가 이력서에 기술되어 있습니다.
    팀 내부 UI 가이드는 어떻게 설득을 시키나요 라는 질문에.  혼자서 가이드 잡아서 업무를 했다고 합니다. 가이드라는 것은 여러명이 작업을 할때 그에 대한 기준점을 제시해 주는 것이지 혼자서 진행할때 가이드 잡은것은 타인과의 작업에 영향을 미치기는 어려우며 그에 대한 검증 또는 되어 있지 않다고 판단합니다.
    

누군가 아무에게나 한분이라도 제 글이 도움이 되길 바랍니다.