[CHAPTER 10] 소프트웨어 장인 면접하기

면접은 쌍방향이다.

흔히들 면접은 회사가 지원자를 평가하는 것만 아니라 지원자도 회사를 평가하는 자리라고 말한다.

이번 챕터는 지원자 입장과 회사의 입장에서 면접에 대한 이야기를 한다.

 

비즈니스 협상

면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야 한다. 비즈니스 협상을 하는 것이다...

장인들은 업계에서 나름의 평판이 있다. 이 평판에 해를 끼치는 것도 위험요소로 보아야 한다.

이전까지 언급되었던 잘못된 프로젝트들을 생각해보자. 그런 곳이 도움이 될까?

 

이러한(잘못된) 프로젝트에서 얻을 수 있는 것은 당황과 분노뿐이다.
생산적인 파트너십이 자리 잡히지 않은 회사들은 피해야 한다...

나쁜 파트너와 함께 일을 해야 할 이유는 없다. 특히 요즘처럼 좋은 소프트웨어 개발자가 부족한 시기에는 더욱 그렇다.

 

 

생산적인 파트너십을 알아보는 방법

- 회사 입장에서의 관점
많은 개발자들의 면접을 진행했다. 지원자에게 질문이 있냐고 물었을 때 '아니오'라는 대답이 더 많았다. 어떤 때는 그런 태도가 너무 실망스러워서 탈락시킨 적도 있다...

면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까?...

얼마나 많은 질문을 하느냐는 면접관 입장에서 그 사람의 협업 능력과 비즈니스 기여 가능성을 가늠할 수 있는 중요한 단서가 된다...
아무런 질문도 하지 않는다면 단지 '아무 일자리'나 찾고 있을 뿐이라는 신호가 될 수 있다.

회사의 입장에서 질문의 중요성을 말하고 있지만 반대로 지원자의 입장에서도 많은걸 알려주는 내용이다.

 

- 지원자 입장에서의 관점
면접은 그 회사와 회사의 사람들에 대해 알 수 있는 대단히 중요한 기회다.

다음은 면접에서 관심을 두어야 할 사항들이다.
- 면접관은 누구인가? 프로젝트 관리자? 개발자? 팀 리더? 아키텍트?
- 얼마나 많은 지원자들을 면접보고 있나?
- 원샷 면접(채용 과정이 한번)인가 다단계 면접(채용 과정이 여러 번)인가?
- 어떤 종류의 질문들이 주어지고 있나?
- 특정한 질문인가 개방형 질문인가?
- 면접관이 단답형을 좋아하는가? 상세하게 생각을 파보려 하는가?

첫 번째 힌트는 관리층이 개발자를 신뢰하는지의 여부다.
면접관이 실무 개발자들이 아니라면 계층 구조의 회사고 신뢰하지 않을 가능성이 높다...
원샷 면접으로 채용하는 회사는 좀 더 우려스럽다...

면접관의 질문들을 분석하면 중요한 정보들을 얻을 수 있을 뿐만 아니라 지원자에게 교육적일 수도 있다.

이번 챕터에서 가장 중요하다고 생각되는 부분이다.

경험이 부족한 지원자에게 회사를 평가해주는 방법을 알려준다.

 

 

바람직한 면접 방법

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다. 
내가 투자 은행의 개발팀에 합류할 때 겪었던 면접은 정말 훌륭했다...
면접관은 "당신의 블로그 글들을 읽어보았습니다... 몇몇 부분은 생각이 다릅니다. 그것에 대해서 이야기를 나누고 싶습니다."...
내 글들에 대해서 1시간 넘게 토론했고 그중 업무 현장에 반영될 수 있는 시나리오와 그럴 수 없는 시나리오를 찾아 나갔다...
이런 종류의 면접은 지원자 입장에서 미리 준비할 수 있는 성격의 것이 아니다...
이 부분이 자유 토론 방식 면접의 백미다. 바로 지원자의 실제 경험을 알아낼 수 있다.

실제 경험을 기반으로 자유 토론이 된다면 어떤 방향성으로 진행이 될지 감이 안 잡힌다. 너무나도 다양하게 접근할 수 있기 때문이다.

저자는 다양한 면접 방법들을 알려준다.

- 올바른 집중
우리의 핵심 가치는 무엇인가?... 설계를 개선할 필요가 있다면, 면접 과정에서 설계 스킬이 뛰어난 사람을 선별해야 한다. 우리 팀에 열정이 부족하다면, 열정이 가득한 사람을 선별해야 한다. 회사의 입장에서 더 중요하고 가치 있는 것에 집중해야 한다.

- 마인드 맵핑 대화
펜과 종이 몇 장을 두고서 지원자에게 특정한 답변이 없는 주관식의 개방형 질문을 던진다. "잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?" "프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까?"...
각 항목은 마인드 맵의 노드가 마인드 맵의 뿌리에서 뻗어 나간다...
면접이 끝나면 모든 대화가 마인드 맵으로 종이에 남아 다시 기억해내는 데 효과적으로 이용된다.

- 페어 프로그래밍 면접
그 어떤 기술 면접도 지원자와의 페어 프로그래밍만큼 좋을 수는 없다. 지원자에 대해 상당히 많은 것을 알 수 있다...
페어 프로그래밍 면접은 진행하기 까다롭고 좋은 코딩 문제를 찾기도 꽤 어렵다...
이러한 면접을 통해 지원자가 실제 프로젝트에서 어떤 능력을 발휘할 수 있을지 알아볼 수 있다.

- 개인 컴퓨터를 지참한 면접
지원자가 좋아하는 도구가 무엇인지 알 수 있고 소중한 면접 시간을 아낄 수가 있다. 

- 맞춤형 면접
지원자의 면접을 보기 전에, 스스로에게 질문을 던져보아야 한다.
우리가 소중히 하는 가치가 무엇인가?
직무의 핵심 스킬은 무엇인가?...
채용되기 위한 기본요건을 규정한다. 지원자의 다재다능한 면을 알아보는 것이 바람직한 행위다. 단, 그 부분이 지원자를 배제할 요건으로서 작용하지는 말아야한다.

위의 면접 방식 중에서 나는 한 번도 겪어 본 적이 없다. 아직 제대로 된 면접 경험도 별로 없거니와 경력 이직을 시도해본 적이 한 번도 없기 때문이다. 

 

 

사전 면접용 코딩 시험

지원자에게 면접 전에 코드를 제출하게 하는 것도 사전 선별을 위한 좋은 방법이다. 단, 지원자에게 충분한 시간을 주어야 한다.
코드를 통한 선별에서는 지원자가 작성할 수 있는 최선의 코드가 어떠한지 알아보는 것이 목적이지 주어진 문제를 얼마나 빨리 코드로 구현하느냐를 시험하는 것이 아니다. 시간을 짧게 하면 문제 해결에만 집중하게 만든다.

예전에 국비학원을 다녔을 때 많이 들었던 면접사례다.

짧은 시간 내에 게시판을 만들어서 제출하는 과제가 많다고 미리 준비하라고 했었다.

이는 잘못된 면접에 방법이고 경험 없는 지원자에게 잘못된 그릇된 생각을 심어 줄 수 있다.

당시의 나에겐 '빨리 구현하는 게 최고구나'라고 생각하게 만들어주었다.

 

어떤 지원자는 채용될지 모를 상황에서 코드를 제출하느라 긴 시간을 소모하기를 꺼릴 수도 있다...
회사 입장에서는 바람직하다.
최소한 코드를 제출한 지원자들은 그만큼 채용 전형을 진지하게 생각하고 있고 들어오길 원하는 사람이라고 볼 수 있다.

코드 제출은 단순하지가 않다. 진지하게 생각하고 임하는지, 그리고 제출한 코드를 통해 지원자를 선별하기 위한 과정이 담겨 있다.

 

 

개발자 채용 면접은 개발자가 보아야 한다

동료가 새롭게 채용될 때, 그 선발 과정에 아무련 의견도 반영할 수 없으면 개발자들은 무력감에 빠진다...

좋은 개발자는 나쁜 개발자를 채용하지 않는다. 좋은 개발자는 그들 자신보다도 더 훌륭한 개발자를 찾으려 노력한다...

지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.

면접관 중에서 개발자가 없다면 면접관들은 도대체 무엇을 보고 지원자를 평가할까? 실무자가 없으면 지원자는 무슨 질문을 해야 할까?

고민을 해본다. 

 

 

---

후기

이전 챕터와 이어지는 내용이며, 면접을 주제로 이야기했다.

처음엔 시니어가 읽어야 하는 내용이 아닐까 생각했었지만

경력에 상관없이 누구나 읽어도 되는 좋은 내용이었다.

 

면접관이라면 채용자의 입장에서 알아보고

취준생이나 주니어는 지원자의 입장에서 면접을 통해 회사를 알아볼 수 있게 알찬 내용만 가득했다.

조만간 다시 구직을 한다면 회사를 잘 파악할 수 있도록 나중에 다시 한번 읽어봐야겠다.

 

저자가 마지막에 남긴 문구다.

소프트웨어 장인은 생산적인 파트너십과 아침에 일어날 때마다 일하러 가는 것이 행복한 그러한 직장을 찾는다.