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

면접은 쌍방향이다. 회사는 그들의 목적을 달성하는 데 도움을 줄 수 있는 개발자를 찾으려 하고, 개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려 한다. 새로운 회사에서 일하는 것은 커리어상 대단히 중요한 결정이어서 개인의 삶에 직접적으로 영향을 미친다. 회사와 개발자들이 상호 생산적인 파트너십이 가능할지를 어떻게 판단할 수 있는지 알아보자.

비즈니스 협상

면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야 한다. 비즈니스 협상을 하는 것이다. 한 쪽에는 비즈니스 목표를 달성하려는 회사가 있고 다른 한 족에는 그러한 목표 달성을 도울 수 있는 프로페셔널이 있다.

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

• 뒤처진 일정
• 모호한 비즈니스가치
• 상명하복식 관리
• 공장 노동자처럼 취급받는 개발자들
• 산처럼 쌓인 개발 관련 문서
• 아무런 협의없이 그저 통보되는 기술적 결정
• 개발자가 고객이나 이해 관계자와 격리된 환경

반면에 프로젝트가 위험에 빠져 있기는 하지만 개발자들이 필요한 것은 무엇이든 할 수 있고, 비즈니스 담당과 긴밀하게 협력하고 있는 상황이라면 소프트웨어 장인에게는 역량을 발휘하고 빛날 수 있는 훌륭한 기회다.

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

면접을 하는 동안에는 생산적인 파트너십이 어떠해야 하는지 서로 다른 괌점에서 바라본다.

회사 입장에서의 관점

성숙한 채용 문화의 회사라면 단순히 고용자, 피고용자 관계가 아닌 파트너십을 기대한다. 재능있는 개발자를 채용한다는 의미는 그의 의견을 중요하게 생각하고 일하는 방식을 개선하는 데 그의 도움을 받겠다는 것이다.

면접관의 역할은 지원가자 협업을 잘 할 수 있을지, 권한부여를 잘 감당할 수 있을지 판별하는 것이다.

지원자가 얼마나 많은 질문을 하느냐는 면접관 입장에서 그 사람의 협업 능력과 비즈니스 기여 가능성을 가늠할 수 있는 중요한 단서가 된다. 지원자가 일과 회사에 대해 아무런 질문도 하지 않는다면 단지 ‘아무 일자리’나 찾고 있을 뿐이라는 신호가 될 수 있다. 지원자가 많은 질문들을 쏟아낸다면 그가 그의 커리어를 소중히 하고 올바른 직장을 찾는 중이라고 짐작할 수 있다.

질문을 많이 하는 지원자를 우선시하는 것이 좋다. 질문을 많이 한다는 것이 더 능력있다는 증거는 아니지만 최소한 지원자 스스로 즐겁게 일할수 있는 곳을 찾고 있다는 증거는 될 수 있다.

몇가지 주의를 기울여야 할 사항

• 과거 수행한 프로젝트나 업무, 기술, 또는 스스로 성취한 사항들을 이야기핧 때 얼마나 열정적이고 애착을 보이는가?
• 실패 사례에 대해서 어떻게 표현하는가? 실패에 대해서 책임감을 느끼는가 아니면 남 탓을 하는가?
• 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해본 적이 있는가?
• 이전 업무에서 불평 불만 대신 그 상황을 개선하기 위해 스스로 노려간 적이 있는가?
• 어떤 종류의 업무 환경을 찾고 있는가?
• 회사에서 그러한 환경을 제공해 줄 수 있는가?

지원자에게 회사와 프로젝트에 관해 설명할 때는 좋은 점은 물론 나쁜 점, 껄끄러운 부분까지 가급적 모두 말해야 한다. 면접은 적합한 사람을 찾아 내는 것뿐만 아니라 회사에 남아 잇을 수 있는 사람을 구하는 과정이기도 하다.

지원자 입장에서의 관점

다음은 면접에서 관심을 두어야 할 사항들이다.

• 면접관은 누구인가?(프로젝트 관리자? 개발자? 팀 리더? 아키텍트?)
• 얼마나 많은 지원자들을 면접 보고 있나?
• 원샷 면접인가 다단계 면접인가?
• 지원가에게 어떤 종류의 질문들이 주어지고 있나? 특정된 질문인가 개방형 질문인가?
• 면접관이 기술적 질문에 대해 단답형을 좋아하는가, 좀 더 상세하게 지원자의 생각들을 파보려 하는가?

첫 번째 힌트는 관리층이 개발자들을 신뢰하는지 여부다. 이것만으로도 개발자들에게 합당한 권한 위임이 되고 있는지 아니면 몇몇 고위 직급들에 의해서 모든 결정이 이루어지는지 의문을 갖기에 충분하다.

다단계 면접이 아닌 원샷 면접으로 채용하는 회사는 좀 더 우려스럽다. 너무 급해서 적합한 인재를 채용할 시간이 없을 가능성이 높다. 반면에 다단계 면접은 제대로된 프로페셔널을 채용하는 데 진지하게 임한다는 징표일 수 있다.

면접관의 질문들은 대개 면접관이 중요하게 생각하는 것들을 반영한다. 면접관이 주어진 질문지를 그냥 읽기만 하고 매우 특정된 짧은 질문들만 연이어 내놓는다면, 그 개바팀의 문화자체가 새로운 생각에 폐쇄적일 수도 있다.

바람직한 면접 방법

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

올바른 집중

우리의 핵심 가치는 무엇인가? 우리에게 필요한 주요 기술은 무엇인가? 더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가? 새로운 사람을 채용하기 전에 이러한 질문들에 스스로 대답을 준비해야 한다. 전혀 상관도 없는 사항들을 확인하느라 면접 시간을 낭비하지 말자. 회사의 입장에서 더 중요하고 가치있는 것에 집중해야 한다.

마인드 맵핑 대화

면접관으로서 면접을 진행할 때 마인드 맵을 이용하면 매우 편리했다. 펜과 종이 몇 장을 두고서 지원자에게 특정한 답변이 없는 주관식의 개방형 질문을 던진다. 이러한 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다. 각 항목은 마인드 맵의 노드가 마인드 맵의 뿌리에서 뻗어나간다.

면접이 끝나면 모든 대화가 마인드 맵으로 종이에 남아 지원자와 나누었던 대화들을 다시 기억해내는 데 효과적으로 이용된다.

페어 프로그래밍 면접

지원자가 작성한 코드를 보지 않는다면 대단히 큰 실수이다. 페어 프로그래밍을 하면 지원자에 대해 상당히 많은 것을 알 수 있다.

• 어떤 테스트를 작성할지 얼마나 빨리 결정하는가?
• 개발 도구에 얼마나 익숙한가?
• 클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가?
• 코드를 얼마나 깨끗하고 명료하게 작성하는가?
• 면접관이 제안이나 조언을 할 때 어떻게 반응하는가?
• 지원자가 어떤 방식으로 생각을 전개하는가?
• 문제 해결만이 아니라 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가?

페어 프로그래밍을 할 때는 지원자가 어디까지 해낼 것인지 현실적인 기대를 가져야 한다. 면접관은 해당 문제를 이미 알고 있어서 익숙하겠지만 지원자는 그렇지 않다. 지원자가 곧바로 결론을 내거나 솔루션을 찾을 것이라고 기대해서는 안 된다. 면접관들은 자기가 일을 배울 때 얼마나 오랜 시간을 걸렸는지 잊어버릴 때가 많다.

면접관으로서 어떤 일을 하든지 간에, 지원자가 너무 오래 해매도록 내버려 두어서는 안 된다. 지원자는 이미 압박 속에 있기 때문에 시간을 지체하면 상황만 나빠질 뿐이다. 지원자가 어느 부분을 어려워하는지 파악할 수 있고 면접관으로서 계속 평가할 수 있다면 지원자가 자신의 역량을 보이도록 최대한 도와야 한다.

개인 컴퓨터를 지참한 면접

지원자에게 자신의 컴퓨터를 직접 가져오도록 요구하는 것도 좋다. 그렇게 하면 지원자가 좋아하는 도구가 무엇인지도 알 수 있고 소중한 면접 시간을 아낄수도 있다. 관심을 가지는 부분이 지원자의 테크닉, 코드의 깨끗한 정도, 테스트 작성 역략, 문제 접근 방법 같은 것들이라면 지원자가 어떤 도구, 어떤 개발 언어를 사용하느냐는 전혀 상관이 없다.

맞춤형 면접

지원자의 면접을 보기 전에, 스스로에게 다음과 같은 질문을 던져보아야 한다. 우리가 소중히 하는 가치가 무엇이나? 동료들로부터 어떤 종류의 태도를 기대하는가? 채용하려는 직무의 핵심 스킬은 무엇인가? 이 질문들에 대한 답은 지원자가 채용되기 위한 기본 요건을 규정한다. 다른 특성들을 보지 말아야 한다는 것은 아니다. 단, 그 부분이 지원자를 배제할 요건으로서 작용하지는 말아야 한다.

번트 홈런

경력 개발자를 위한 채용에 관심 가질 만한 이력서는 아니였지만 펫 프로젝트로 새로운 것을 시도하는 데 여정적인 지원자가 있었다. 업무 시간에는 허락되지 않은 배움의 욕구를 채우기 위해 개인 시간을 투자하고 있었다. 올바른 환경과 기회만 주어진다면 아주 훌륭한 개발자로 빛날 매우 전형적인 스타일이었다.

면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 열정 그리고 잠재성을 보아야만 한다.

기존 팀을 위한 채용, 새로운 팀을 위한 채용

새로운 프로젝트의 초기 개발자들을 채용할 때는 최소한 두 가지 역량이 더 팔요하다. 첫 번째는 프로젝트를 제 궤도로 유지하고 성공적으로 이끌어낸 과거 경험들이다. 고객의 관료적 문제에 대응하고, 비즈니스적 압박을 견뎌내고, 상용화 이슈와 이해 관계자들에 대한 관리 같은 것들에 대한 경험이 필요하다. 이러한 것들은 실제 고객에게 소프트웨어 제품을 공급하는 과정에서만 배울 수 있다.

상용 환경에서 배포되어야 하는 중간 규모 이상의 프로젝트라면, 많은 프로젝트들을 최종 인수 서명 단계까지 이끌어 본 개발자들이 필요하다. 특정 분야만 잘 아는 스페셜리스트보다는 여러 서로 다른 기술들과, 스크립팅, 가상머신 등등에 폭넓게 조예가 있는 기술 분석 전문가도 필요하다.

사전 면접용 코딩 시험

지원자에게 면접 전에 코드를 제출하게 하는 것도 사전 선별을 위한 좋은 방법이다. 단, 지원자에게 충분한 시간을 주어야 한다. 시간 제한을 두지 않거나 넉넉하게 주어서 좋은 코드를 작성하게끔 하는 방법이 적당하다.

지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다

강한 팀은 각 개발자들 모두 면접을 진행할 수 있어야 한다. 모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다. 새로운 개발자가 팀에 합류할 때 팀원들이 직접 면접을 보고 선별 과정에 참여하면 팀의 사기와 주인의식이 높아질 수 있다.

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

좋은 개발자는 나쁜 개발자를 채용하지 않는다. 회사는 개발자 채용 면접을 할 때 반드시 개발자로 하여금 면접관 역할을 하도록 해야 한다. 지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.

요약

면접 과정을 지켜보기만 해도 그 회사와 그 안의 개발팀, 개발자들에 대해 많은 것을 알 수 있다. 소프트웨어 장인이 직장을 찾을 때는 특정한 프로젝트나 펜시한 기술, 괜찮은 급여만을 쫓지는 않는다. 생산적인 파트너십과 일하러 가는 것이 행복한 직장을 찾는다.

참조

• 소프트웨어 장인