올해들어 인터뷰(인터뷰어로)를 볼 기회가 많아 몇 가지 생각들을 정리해보았다.

.

회사마다, 담당자마다 다를 수 있지만, 나는 보통의 경우 이메일로 연락한다. 이력서만으로 판단하기 어려운 부분이 있다면 이메일로 사전에 간단한 질문을 하기도 하고, 인터뷰 시간을 잡을 때도 이메일로 연락한다. 가장 효율적인 방법이라 생각하기 때문이다. (물론 회신이 일정 시간안에 없는 경우, 전화나 문자로 안내한다.)

이 때 좀 의아한 부분이 이메일 수신 및 회신 비율이다. 정확한 비율을 얘기하기는 어렵지만, 생각보다 회신하지 않는 분들이 꽤 많다. 물론 나의 메일이 스팸에 걸릴 수도 있고, 어떤 이유로 인해 이메일을 확인하지 못했을 수 있다. 하지만 이력서 지원을 진지하게 생각했다면, 이메일을 주기적으로 확인하는건 당연하다고 생각한다.

가능하면 스마트폰과 연동된 이메일 계정을 기재하면 좋겠다. 격식을 차리지 않은 짧고 간단한 내용이더라도 적시에 회신하는 것보다 좋은 커뮤니케이션은 없는 것 같다. 참고로 이메일 회신까지 걸리는 시간이 어느정도는 중요한 첫 인상으로 기억된다.

.

*** 이 부분은 신입 또는 신입에 가까운 경력직에만 해당하는 얘기다.

희망연봉을 기재하는 것은 분명한 장단점이 있다. 희망연봉이 공고한 포지션에 대한 회사의 가이드라인과 맞지 않는다면 인터뷰 자체를 제안하지 않는다. 서로에게 시간 낭비가 될 수 있기 때문이다. 다만 회사의 가이드라인은 지원자의 능력에 따라 다르게 적용되는 것이지, 연차나 포지션에 따라 일괄적으로 결정되는 것은 아니다. 즉, 회사 입장에서는 인터뷰 과정을 통해 가능하면 세밀하게 지원자의 수준을 판단하고, 회사가 생각하는 수준과 지원자가 생각하는 본인의 수준이 비슷하다면 인터뷰는 곧 채용으로 연결된다. 연봉 수준은 그 수준에 따라 결정된다. ‘이정도 수준의 포지션을 생각하고 있고, 대략 이 정도 연봉 수준이면 좋겠다’는 처음의 생각이 인터뷰를 통해 얼마든지 바뀔 수 있다는 것이다.

짧은 이력서만으로 지원자의 수준을 판단하는건 매우 어렵다. 때로는 판단할 수 있는 근거조차 미약한 경우가 많다. 따라서 희망연봉을 기재한다면 자신의 이력서가 그 수준에 맞는지 이력서로 표현해야 한다. 스스로의 수준을 알고 있고, 그 수준이 이력서로 표현되어 있고, 스스로의 수준에 맞는 희망 연봉이 기재되어 있다면 오히려 면접까지 진행해놓고, 연봉 수준이 달라 입사 진행이 안되는 불상사를 막을 수 있다. 반대로 제출된 이력서가 공고에서 기대하는 수준과 정확히 일치하지 않는다면 (더 뛰어나거나, 좀 부족하거나 양쪽 다) 희망 연봉은 인터뷰 단계로 넘어가는 걸림돌이 될 수도 있다.

.

우리 회사에 지원하는 분들의 절반 정도는 신입이다. 다시 말해, 능력을 판단할 근거가 이력서에는 없다는 얘기다. 누구나 거쳐야하는 과정이지만, 그래서 이력서에 적을 내용이 없다는 것을 충분히 이해하지만 이력서를 검토하는 입장에서는 정말 어렵다.

판단의 근거가 없는 경우에는 얼마나 성실하게 배우고 있는가를 확인한다. 개발자라면 결국 그 노력은 Github 계정과 블로그로 표현된다. 예를 들어 ReactJS에 대해 6개월 이상 꾸준히 포스팅을 올릴 수 있다면, 실무 개발 경험의 유무를 떠나 몇 가지 허들은 넘었다고 판단한다. 그리고 그 판단은 대체로 틀리지 않는다. 혹시라도 접속 가능한 프로젝트가 있다면 링크를 공유해놓는 것도 좋다. 이러한 활동들이 결국 본인 스스로 성장하는 방법임과 동시에 성장 가능성을 판단해야하는 인터뷰어에게도 좋은 소재가 된다.

한가지 주의할 점은 어느정도의 업데이트다. 6개월 이상 아무런 포스팅이 없거나, 공개된 프로젝트의 수준이 한참 낮다면 부정적인 영향을 줄 수는 있다. 난 그래도 판단이 가능하다는 점에서 무조건 좋게 평가하려고 노력한다. (단, 디자이너라면 좀 다를 수 있다. 눈에 보이는 것이 전부일 수 있기 때문에 현재의 본인 수준을 완전히 대변하지 못하는 오래된 프로젝트는 공유하지 않는게 좋을수도 있다.)

.

인터뷰를 보면서 한 시간안에 개발자의 역량을 평가하는건 사실 불가능하다. 그래도 주어진 상황에서 최선을 다한다고 가정할 때, 내가 하는 인터뷰의 방법은 다음과 같다.

가능하면 함께 일하게될 팀원, 사용하는 개발 언어와 인프라, 기술들을 설명한다. 입사했을 때 누구와 협업을 해야하는지, 어떤 방식으로 업무를 할당하고 관리하는지, 우리가 중요하게 생각하는 개발자의 역량과 태도는 무엇인지 등을 비교적 상세하게 설명한다. 이유는 간단한데, 회사가 지원자를 평가하는만큼, 지원자가 회사를 평가하는 것이 중요하다고 믿기 때문이다. 즉, 돈을 버는 직장으로서의 의미 외에 한두가지 의미를 더 갖고 입사하길 바라는 욕심에서다. 그래야 입사한 직원이 최소한의 기간을 일할 수 있다. (난 그 기간을 2~3년으로 본다.) 고용하는 입장에서 가장 걱정하는건 입사자의 능력과 기존 팀원과의 케미스트리이지만, 결과적으로는 얼마나 오랫동안 일할 수 있는지도 매우 중요하다. 모든 사람이 시간이 지남에 따라 성장한다고 가정한다면, 이 근속년수라는 간단한 지표는 생각보다 의미가 있다.

이 부분은 면접을 진행하는 사람에 따라 많이 다를 것으로 짐작한다. 어떤 태도가 좋은지는 아직 모르겠지만 반드시 피하는 몇 가지가 있다.

물어보는 질문에 모두 대답해야 인터뷰에 합격하는게 아니다. 어느정도까지 개발에 관심을 가지고 있는지, 얼마나 고민해봤는지 (a.k.a 삽질의 경험), 질문에 대해 어떻게 이해하고 커뮤니케이션하는지를 전체적으로 판단한다. 이렇게 질문하는 또 다른 목적은 지원자가 어느정도 수준인지 내가 판단하고, 그 판단에 지원자도 동의하게 만들기 위함이 있다. 하지만 한번쯤 들어본 내용을 아는 것처럼 얘기하는 사람, 고민의 시간 없이 질문과 동시에 말을 시작하는 사람, 질문을 이해하지 못했음에도 되묻지 않는 사람은 가급적 피하기 위해 노력한다. 이런 분들은 협업에 있어 매우 취약할 가능성이 높다. 마지막까지 모른다고 얘기하지 않고 혼자 문제를 싸안고 있다가 완료 시점에 임박해서야 문제를 실토(?)하는 유형일 수 있다.

회사에 대해 미리 리서치를 해보았다면 질문이 많을 수밖에 없다. 급여 수준은 어떠한지, 출퇴근 시간은 어떠한지, 야근은 얼마나 자주하게 되는지, 누구와 함께 일하는지 같은 기본적인 업무 환경에 대해 질문할 수 있다. 디자인은 Zeplin으로 공유되는지, 업무 관리는 Trello를 사용하는지, TDD 방식으로 개발하는지, Github 코드 관리는 어떤 규칙을 가지고 운영하는지, 서버 인프라는 무엇을 사용하는지 등도 질문할 수 있다. 지급받게될 맥북의 사양을 물어볼 수도 있고, 기계식 키보드 사용이 가능한지도 물어볼 수 있다. 개발자가 받게될 개발요구 사항의 샘플과 디자인가이드, 깃헙 히스토리를 보여달라고 요구할 수도 있다. 질문을 받아보면 지원자가 우리 회사를 ‘입사하면 어떻게 일해야할까?’를 고민하고, 기대하고, 궁금해하면서 인터뷰에 왔는지, ‘어디라도 일단 붙어보자’는 생각으로 이력서를 제출했는데 대략 파악할 수 있다.

개발자 포지션에 지원하면서 서비스와 사업에 대한 의견을 피력하는 지원자들이 의외로 많다. 결론적으로는 자신이 회사에 돈을 벌어다줄 수 있는 인재이며, 개발만 하는 개발자가 아니라는 것을 어필한다. 한두명의 팀원이 전부인 초기 스타트업이라면 매력적인 수 있다. 하지만 개발팀이 구성되어 있고, 명확한 개발의 포지션이 정해지는 회사라면 개발자에게 개발 외의 것들을 요구하지 않는다. 사업이나 서비스에 대한 의견은 입사하고 제시해도 된다. 지금은 회사가 필요로하는 포지션에 맞는 사람인지 확인하는 자리다.

생각보다 인터뷰어도 힘들다. 대화를 원하는 방향으로 이끌어야하고, 궁금했던 부분들에 대해 명확한 답변을 얻어야 한다. 답변이 명확하지 않다면 어떻게든 판단할 수 있는 근거를 찾아야 한다. 따라서 인터뷰의 시간은 세밀하게, 그리고 의도를 가지고 관리된다. 간단한 질문에 장황하게 대답한다면 인터뷰어는 집중력을 잃게된다. 자신만의 리듬이 깨질 수 있고, 확인하고 싶었던 지원자의 역량, 성향, 경험 등을 놓치게 된다. 인터뷰가 끝나고 다른 임원들에게 지원자에 대해 명확히 설명할 수 없는 경우가 보통은 이런 상황에서 발생한다. 따라서 가급적이면 물어보는 질문에 짧고 명확하게 대답하면 좋겠다. 만약 인터뷰어가 더 흥미를 느낀다면 추가적인 질문을 할 것이다. 이렇게 오고가는 대화를 만들어가는 것이 중요하다.

.

10명 정도 인터뷰를 진행하면, 1~2명 정도가 인터뷰 후에 메일을 보낸다. 보통의 경우 이메일은 1) 인터뷰 때 바로 답변하지 못했거나, 보여주지 못했던 자료나 링크를 보내는 경우가 있고, 2) 합격 여부를 떠나 피드백을 달라는 요청이 있다. 그 외에는 3) 다른 회사의 입사 결정이 나서 못가게 되었다는 연락이거나, 언제까지 결과를 알려달라는 요청이 대부분이다. 결국 입사 인터뷰는 ‘함께 일할 사람을 찾는’ 과정이라는 점을 생각한다면, 이런 방식의 사후 이메일은 확실히 고맙다.

쓰고보니, 채용 과정이 너무 주먹구구식인가 싶기도하다.