스압주의 - 책 자체가 소프트웨어 장인 정신에 대한 요체를 서술하다보니 뺄 내용이 많지 않았다. 그래서 책 내용이 상당히 많다. 이는 책의 저자에게는 상당히 미안한 일이지만 나 자신을 위해서 요약 정리를 해두는 것이 좋다고 생각했다. 만약 이것이 무리가 있는 경우는 개인적으로만 보관하도록 하겠다는 것을 미리 밝힌다. 만약 이 글을 보더라도 개인적으로 책을 사서 읽어보고 개발자의 삶에 있어 지침서로 보관하기를 추천한다. 길더라도 탐독해주시기 바란다

요약 1, 요약 2에 이어서…

완전한 전환

이제 2부에서는 소프트웨어 장인으로서 완전한 전환을 위해서는 개인의 변화를 넘어선 조직의 변화를 위한 이야기를 서술한다.

인재 채용

모두가 부르짖는 최고의 인재란 어떤 사람일까? 최고의 인재가 실제로 어떤 의미인지 모르는 경우가 허다한 경우가 많다. 이 장에서는 소프트웨어 장인을 어떻게 조직에 끌어들이고 적극적인 채용 활동을 어떻게 할 수 있는지 우리에게 알려준다.

전형적인 채용 공고

우리가 흔히 보는 채용 공고는 업무에 필요한 기술/경력을 나열하고 보상 수준을 제시해주는 수준에서 크게 벗어나지 않는다. 하지만 회사 내부에 있어보면 알겠지만 대부분의 문제는 프로젝트 그 자체와 함께 절차, 문화로 인한 것이고 실제로 문제가 되는 부분도 이것과 관련된 가능성이 높다. 흔한 채용공고의 또 하나의 문제점은 비슷한 경력을 요구하는 다른 업체에서 문제를 일으킨 개발자가 올 수 있다는 것이다. 하지만 대부분의 회사는 모든 것을 더 나아지도록 변화시킬 수 있는 사람, 더 품질 좋은 소프트웨어를 효율적으로 만들어내고 비용을 낮출 수 있는 사람을 원한다. 따라서 전형적인 채용공고로는 이런 목적을 만족시키기 어렵다.

대부분의 회사에는 채용 과정이 길고 소모적이라는 편견, 사내 개발자에 대한 불평과 문화가 바뀌어야 한다는 아우성이 존재한다. 이는 회사의 채용과정의 문제 때문에 발생한다. 채용 과정에 많은 노력을 쏟지 않았기 때문에 그 이후에 발생하는 문제인 것이다. 채용과정에서 많은 노력을 들이면 그 이후 발생하는 문제는 많지 않다는 것이 정설이다. 이는 1:10:100의 법칙¹과 유사하다. 따라서 이를 책임질 사람은 개발자가 아니라 채용과정에 권한과 책임이 있는 사람이다.

인터뷰할 시간이 없다는 변명

내부적으로는 다른 업무가 많아서 인터뷰할 시간이 없다고 이야기 하기도 한다. 우리는 가족이나 연인보다 회사 동료들과 더 많은 시간을 보낸다. 좋은 관계를 맺을 수 있는 사람을 동료로 두는 것은 대단히 중요하다. 이를 귀찮아 하는 것은 훌륭한 팀을 구성하는 것을 소홀히 한다는 것과 같다.

최근 대다수의 비지니스가 소프트웨어에 의존하고 그 소프트웨어의 성공/실패는 소프트웨어를 개발한 개발자의 영향을 많이 받는다. 이런 훌륭한 개발자를 채용하는 것이 중요하기에 면접관의 자질이 대단히 중요하다. 면접자는 지원자를 자신의 개인적 역량, 가치 기준, 편견에 따라 주관적으로 판단한다. 하지만 좋은 면접관은 항상 배우기를 원하고 더 나은 일하는 방법을 찾는 사람이다. 이런 사람은 자신보다 훌륭한 사람과 함께 일하기를 원하고 최소한 자신과 비슷한 역량의 사람이라도 채용하기를 희망한다. 반면 계층 구조와 통제에 가치를 두는 사람은 자기보다 더 나은 사람, 심지어 자신과 비슷한 수준의 사람조차 배척한다. (필자 주: 이러한 경우를 많이 봤다. 대부분 자신과 비슷하거나 높은 수준보다는 자신의 귀찮은 일을 가져갈 사람을 원하며 그러기에 채용 기준이 높지 않다. 이런 경우 자신의 업무에도 열정이 없는 경우가 대부분이며 자신도 성장하지 못하는 경우가 대부분이다. 이런 구성원의 경우 조직의 암이 되는 경우가 대부분이므로 빠르게 잘 도려내야 한다.)

면접 시간도 문제지만 전체 채용 절차에 소요되는 시간도 문제다. 딱히 다를 것 없는 이력서를 검토하고 부적합한 지원자를 면접하니라 많은 시간을 낭비하기에 이런 불만이 나온다. 유일한 대안은 지원자를 선별하는 기준을 더욱 상세화 하는 것이다.

틀에 박힌 직무 요건

앞서 얘기했듯 채용 공고에 직무 요건 목록을 기술하는 방식은 피해야 한다. 기술과 경험을 나열하는 전통적인 직무 요건은 재능에도 반하고 다양성에도 반하며 성공적인 채용과의 상관관계도 최악이다.² 왜 그런지에 대한 상세 사항이 아래에 있다.

• 절대적인 숫자 - 숫자는 임의적이고 오해하기 쉬우며 변덕스럽다. 높은 학점도 대학/교수 등에 의해 주관적이므로 큰 의미가 없다. 경력도 1년 단위의 같은 일을 5년 동안 반복하는 경우가 있으므로 큰 의미가 없다. 가장 중요한 것은 자발적인 자기계발, 일을 통한 배움이 더 중요하다.
• 키워드 매칭 - 특정 기술이나 플랫폼의 단순 매칭으로는 해당 업무의 본질적인 부분을 잘 모르기 때문에 의미가 없다.
• 기술 목록의 나열 - 희망 기술까지 더한 불필요하게 많은 기술 목록을 나열하면 재능 있고 정직한 개발자가 스스로 지원을 포기하게 만들 수 있다. 이는 후보군만 줄일 뿐이다.
• 잘못된 기업 문화 설명 - 기업의 가치와 기대되는 태도, 책임을 잘못 설명하거나 너무 당연한 가치를 나열하지 않도록 한다. 자기가 그렇다고 생각할 사람은 별로 없다.
• 잘못된 요구 항목 - 그 직무에서 무엇을 책임져야 하는지 설명하는 것이 경력, 학점 등을 설명하는 것보다 훨씬 낫다. 레주메에 기록된 화려한 기술은 실제 역량과 전혀 일치하지 않는 것이 현실이다.
• 잘못된 선별 조건 - 직무 요건은 최고의 인재를 끌어들이는 것이 아니라 최악의 인재를 걸러내기 위한 목적이다. 최고의 개발자는 경험 년수에 기반한 채용 공고에 지원하지 않고 신중하게 일을 찾는다. 관심 있는 것은 회사의 문화, 업무에서의 책임, 프로젝트의 종류가 훨씬 중요하다.
• 승진 요건과의 불일치 - 회사 내에서 승진할 때는 직무 요건에 기술된 바가 아닌 그가 이룬 성과와 팀워크와 같은 다른 중요한 이유 때문에 승진한다. 이 이유와 부합하는 사람을 찾아야 한다.

직무 요건을 나열하는 것은 지양하고 참고 정보로만 기술한다. 직무요건을 꼭 작성해야 한다면 프로젝트 종류, 사용 기술을 요구 조건이 아니라 참고 정보로서 제공하고 태도, 책임, 가치관과 회사의 문화에 집중된 내용으로 채워져야 한다. 나쁜 예와 좋은 예에 대해서는 이 글에서 상세히 기술하지 않으니 책을 참고하도록 한다.

일은 단순히 일이 아니다. 훌륭한 개발자에게는 일은 취미이자 열정이다. 좋아하는 일을 하면서도 돈을 벌 수 있어서 행운이라고 느낀다.

추천 채용

추천은 권장할만한 채용 수단이기는 하지만 금전적으로 보상이 주어져서는 안 된다. 추천 채용을 훌륭한 개발자에게 배울 수 있는 기회로 생각한다. 훌륭한 개발자가 들어오면 회사에도 좋고 추천한 개발자의 성장에도 좋다. 다른 개발자를 추천하는 것 자체가 스스로의 평판을 시험대에 올리는 행위임을 이해한다. 소프트웨어 장인이 다른 개발자를 추천했다는 것은 그 개발자도 소프트웨어 장인이라는 의미다.

커뮤니티의 활용

재능있는 개발자를 채용하기 위한 최선의 방법은 여러 개발자 커뮤니티와 접촉하는 것이다. 개발자 모임을 후원함으로써 얻을 수 있는 이익은 아래와 같다.

• 훌륭한 개발자에게 노출 - 직접 다가갈 수도 있고 회사를 자연스럽게 소개하는 것도 가능함
• 사내 개발자가 무료로 배울 수 있는 기회 - 회사의 개발자가 핸즈온 코등 세션에 참가해 페어 프로그래밍을 하거나 서로 다른 솔루션을 비교하며 배울 수 있다.
• 무료 기술 컨설팅 - 회사의 개발자가 다른 개발자와 문제를 해결하기 위해 기술적 교류를 한다.
• 저렴한 투자비용 - 후원사로서 투자해야 할 것은 피자 몇 판이나 회사 회의실을 빌려주는 것 정도다.

서로 교류를 함으로써 지식을 공유를 하고 비지니스 파트너쉽을 맺을 수 있고 고용 관계가 되기도 한다.

효과적인 선별 조건의 정의

추천이나 커뮤니티를 통한 채용 방법이 좋지만 항상 이에 의존할 수는 없다. 이 경우 다시 원래의 문제로 돌아온다. 면접 시간을 어떻게 아낄 것인가? 좋은 개발자의 자질, 개발팀에 심고 싶은 문화를 생각했을 때 결론은 열정적인 소프트웨어 장인이다. 열정은 기술적인 역량이나 프로그래밍 언어에 대한 이해보다도 더 중요한 조건이다. 항상 새로운 것을 시도하고 배우고 지식을 공유하고 커뮤니티 활동에 적극적인 사람을 원했다.

훌륭한 개발자를 놓지지 않으려면 훌륭한 개발자에 대한 정의가 명확해야 한다. 이는 채용 상황에 전적으로 종속적이고 조직, 문화, 개발하는 애플리케이션도 다르기 때문에 훌륭한 개발자에 대한 관점을 다를 수 밖에 없다. 하지만 앞서 지속적으로 얘기한 것처럼 기술에 대한 지식이나 경력년수 또는 학위가 훌륭한 개발자의 조건이라고 말하지 않는다. 아래 중 해당 사항이 있으면 기술한 것이 효과가 있었다고 한다.

• Github 계정
• 블로그
• 오픈소스 활동
• 기술 커뮤니티나 사용자 그룹 활동 내역
• 펫 프로젝트 내용
• 트위터 계정
• 좋아하는 기술 서적 목록
• 참석했거나 발표했던 컨퍼런스

물론 이런 활동을 하지 않는 좋은 개발자가 있을 수도 있다. 하지만 높은 확률로 그러할 것이다.

적극적인 리쿠르팅

회사는 시급하게 채용해야 하는 상황을 절대 만들어서는 안 된다. 급하게 채용해야 하는 상황에서는 채용된 기준을 낮추고 잘못된 사람이 조직에 들어오기 쉽다. 잘못된 사림이 들어오면 프로젝트를 망치게 되고 회사/조직의 평판이 나빠져서 새로운 훌륭한 개발자가 들어오지 않고 기존 개발자를 가지고 또 다시 프로젝트를 시작하게 되는 악순환을 만들 수 있다.

이런 문제를 해결하기 위해 저자의 회사는 적극적인 방식의 채용을 채택했다. 고객이 늘어나기까지 기다리지 않고 정기적으로 계속 채용하기로 했다. 훌륭한 개발자를 찾는 것은 매우 어렵고 시간이 오래 걸리는 일이다. 때에 맞춰 고용을 하기는 거의 불가능한 일이라 볼 수 있다. 그래서 지속적이고 정기적인 채용을 해나갔다. 대신 관심을 쏟고 싶은 개발자들만 지원하도록 채용 절차를 아주 상세화했다. 이렇게 함으로써 지원자의 수를 줄이는 것뿐만 아니라 채용의 성공 확률도 높아졌다.

그리고 채용할 준비가 되지 않은 상태에서 지원서가 들어오면 우리는 당장은 자리가 없음을 분명히 했다. 대신 채용 절차를 미리 통과하면 다음에 자리가 났을 때 최우선적으로 채용할 수 있다고 언급했다. 또한 채용 절차 중에는 주말을 투자해야만 하는 코딩 과제를 제시했다. 당장 채용할 수는 없지만 이러한 채용 절차를 거칠 동기를 부여하기 위해 모든 코드를 매우 충실하게 리뷰하여 피드백할 것을 약속했다. 이렇게 함으로써 지원자 입장에서는 채용되지 못하더라도 최소한 그들의 코드에 대해 가치 있는 조언을 얻을 수 있고 회사 입장에서는 기본적인 채용 절차를 통과한 실력 있는 후보자를 확보할 수 있었다. 이를 통해 언제든지 필요한 시점에 맞춰 좋은 개발자 채용이 가능했다.

소프트웨어 장인 면접하기

면접은 쌍방향이다. 회사는 그들의 목적을 달성하는데 도움을 줄 수 있는 개발자를 찾으려 하고 개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려 한다. 새로운 회사에서 일하는 것은 커리어상 대단히 중요한 결정이어서 개인의 삶에 직접적으로 영향을 미친다. 많은 시간을 회사에서 보내기 때문이다.

비지니스 협상

면접을 볼 때 면접자가 일자리를 구걸하는 입장이 아니라 비지니스 협상을 하는 것이다. 한 쪽은 비지니스 목표를 달성하려는 회사, 그 목표를 달성하게 하는 소프트웨어 프로페셔널이 있다. 고용계약서에 서명하기 전에 그것이 정규직이든 계약직이든 협상의 결과에 따른 보상과 위험 수준이 어떠하고 그 내용이 무엇인지 반드시 이해해야 한다. 아래와 같은 평판을 가진 회사로의 합류는 자신의 평판을 깎아내릴 수 있으므로 조심해야 한다.

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

이런 프로젝트가 성공할 확률은 거의 제로에 가깝고 얻을 수 있는 것은 당황과 분노일 뿐이다. 생산적인 파트너십이 자리잡히지 않은 회사는 피해야 한다. 프로젝트가 위험에 빠져있지만 개발자들이 필요한 것은 뭐든 할 수 있고 비지니스 담당과 긴밀하게 협력하고 있는 상황이라면 소프트웨어 장인에게는 역량을 발휘하고 빛날 수 있는 훌륭한 기회다. 좋은 파트너십은 양쪽 모두에게 가치있어야 한다.

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

회사 입장에서의 관점에서의 생산적인 파트녀십에 대해 알아보자. 협업과 권한부여 는 성공적인 팀이 되기 위해 반드시 필요하다. 면접관의 역할은 지원자가 협업을 잘 할 수 있을지, 권한부여를 잘 감당할 수 있을지를 판별하는 것이다.

지원자가 얼마나 많은 질문을 하느냐는 면접관 입장에서 그 사람의 협업 능력과 비지니스 기여 가능성을 가늠할 수 있는 주요 단서가 된다. 지원자가 많은 질문을 쏟아낸다면 그가 커리어를 소중히 하고 올바른 직장을 찾는 중이라고 짐작할 수 있다. 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.

면접자를 평가할 때 몇 가지 주의를 기울여야 할 사항은 다음과 같다.

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

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

지원자 입장에서의 관점 의 생산적인 파트녀십에 대해 알아보자. 지원자에게 면접은 회사와 잠재적인 동료에 대해 알 수 있는 대단히 중요한 기회다. 면접에서 관심을 두어야 하는 사항은 크게 세 가지가 있다.

첫째, 면접관에 누가 들어오는가다. 누구인지가 중요한 이유는 관리층이 개발자를 신뢰하는지의 여부 때문이다. 개발자가 아닌 프로젝트 관리자, 팀 리더, 아키텍트만이 들어온다면 계층 구조로 운영되는 회사고 개발자를 신뢰하지 않을 가능성이 높다. 개발자에게 합당한 권한 위임이 되고 있는지 아니면 몇몇 고위 직급에 의해 모든 결정이 이뤄지는지 의문을 갖기에 충분하다.

둘째, 얼마나 많은 지원자가 면접을 보고 있는지다. 다단계 면접이 아닌 원샷 면접으로 채용하는 회사는 좀더 우려스럽다. 너무 급해서 적합한 인재를 채용할 시간이 없을 가능성이 높다. 다단계 면접은 회사에서 지원자의 서로 다른 여러 측면을 보려는 것이다.

마지막은 지원자에게 주어지는 질문의 종류다. 면접관의 질문을 분석하면 중요한 정보를 얻을 수 있고 교육적인 측면도 많다. 면접관의 질문은 보통 본인이 중요하다고 생각하는 것을 반영하기 때문이다. 질문의 폐쇄/개방성에 따라 조직의 폐쇄/개방성이 보이기도 하고 조직의 창의성, 고정관념도 보이기도 할 것이다. 현실 세계의 문제나 아주 구체적인 상황에 대해 개방적인 대화를 하는 것이 좋다. 서로 다른 접근 방법과 해결책을 토론하고 가능하다면 같이 코드를 짜보는 것이 지원자의 수준을 가늠하기 위한 최고의 방법이다.

바람직한 면접 방법

좋은 면접은 자유 토론과 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고 기술/도구/방법론에 대해 의견을 나눠야 한다. 미리 준비할 수 없는 성격이기도 하고 관련 내용을 검색해서 대답하기엔 부족하기 때문에 지원자의 실제 경험을 알아낼 수 있다.

면접을 볼 때 올바른 것에 집중해야 한다. 우리의 핵심 가치는 무엇인가? 우리에게 필요한 주요 기술은 무엇인가? 더 잘하고 싶은 더 나아지고 싶은 것은 무엇인가? 이 밖에 많은 질문이 있을 것이다. 새로운 사람을 채용하기 전 이 질문에 대한 스스로의 대답을 마련해야 한다. 뭔가 개선하고 싶고 도입하고 싶은 것이 있을 때 새로 채용될 개발자는 그런 것을 성취하기 위한 지원군이 되어야 한다. 조직에 필요한 가치/실행 관레에 대한 것이 면접 과정에 포함되어야 한다. 이후는 저자가 추천한 면접 방법 중 일부다.

마인드 매핑 대화 는 저자가 제안하는 유용한 면접 방법이다. “잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?”나 “소프트웨어 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까?”와 같은 먼저 주관식 개방형 질문을 던진다. 이런 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다. 이에 대한 대답을 마인드맵처럼 쭉 펼쳐놓고 이것을 이용해 한 노드 씩 주제를 옮겨가면서 지원자와 대화를 나누기 시작한다. 대화 내용에 따라 마인드 맵은 가지를 치면서 얘기하고 다른 주제로 옮겨가기도 한다. 좀더 구체적인 부분을 파보고 싶다면 직접적인 질문을 할 수도 있다. 이렇게 마인드맵을 그리면 면접을 종료한 뒤 지원자와 나누었던 대화를 기억해내는 데 효과적으로 이용된다.

페어 프로그래밍 면접 은 가장 좋은 기술 면접일 것이다. 지원자가 작성한 코드를 보지 않는다면 대단히 큰 실수다. 페어 프로그래밍 면접을 하면 아래와 같은 것을 확인할 수 있다.

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

페어 프로그래밍의 주제를 찾는 쉬운 방법 중 하나는 공개된 프로그래밍 연습 문제 카타를 이용하거나 직접 카타를 개발하는 것이다. 카타는 지원자의 TDD 역량을 시험하거나 일반적인 클린 코드 원칙을 얼마나 지키는지 알아보는데 좋다. 또 하나는 회사에서 실제 사용 중인 코드 베이스에서 일부를 발췌하는 것이다. 테스트 코드가 만들어지지 않았고 가장 엉망으로 작성된 부분을 고르면 더욱 좋다. 그 코드를 개선하고 테스트를 작성해보도록 한다.

페어 프로그래밍 면접 시 주의해야 할 점이 있다. 페어 프로그래밍을 할 때는 지원자가 어디까지 해낼 것인지 현실적인 기대를 가져야 한다. 곧바로 결론을 내거나 솔루션을 찾을거라 기대하며 안 된다. 만약 개발 도구를 제공하는 것이라면 지원자가 도구에 익숙해질 때까지 기다려야 한다. 익숙해지는데 시간이 걸린다는 것은 나쁜 것이 아니다. 이런 당황스러운 상황을 어떻게 대처하는지 집중해서 관찰하자. 면접이긴 하지만 페어 프로그래밍이기 때문에 가장 당연한 대응은 도움을 요청하는 것이다. 이때 면접관은 지원자가 올바른 방향을 찾을 수 있도록 가능한 모든 도움을 주어야 한다. 너무 오래 지원자가 헤매게 하면 안 된다. 최대 3-4분만을 기다려야 한다. 압박 속에 있기 때문에 시간을 지체하면 상황은 악화될 뿐이다. 어떤 부분을 어려워하는지 파악할 수 있고 면접관으로서 계속 평가할 수 있다면 지원자가 자신의 역량을 최대한 도와야 한다. 실제로 페어 프로그래밍 하듯 자연스럽게 하고 싶은 것을 들어서 면접관이 작성해주는 것도 가능하다. 이를 통해 면접자는 새로운 개발 도구에 대해 익숙해져 간다. 새로운 것에 대한 열정과 배움의 속도를 보여주는 증거가 될 수 있다. 그럼으로써 나와 팀을 이뤄서 일할 수 있음을 쉽게 보여줬다. 마지막으로 코드를 작성하는 부분에서 합의되지 않는 부분도 있지만 나름의 근거가 있었다면 인정하는 것이 좋다. 깨끗하게 코드를 작성하는지도 확인 가능하다.

개인 컴퓨터를 지참한 면접 도 괜찮다. 지원자에게 Github 프로젝트를 클론하고 인터넷 연결을 통해 작업하게 하는 것이다. 이를 통해 git에 대한 친근성 등을 확인 할 수 있다. 그리고 아래 사항을 알 수 있다.

• 선호하는 도구
• 빠른 프로젝트 시작
• 테스팅/목업 프레임워크의 사용 여부와 익숙함

맞춤형 면접 을 고려해야 한다. 면접을 시작하기 전에 소중히 하는 가치, 기대하는 태도의 종류, 채용하려는 직무의 핵심 스킬에 대한 답, 즉 면접을 위한 기본 요건에 대해 생각해놔야 한다. 다른 특성을 보지 말아야 하는 것이 아니라 그 부분이 지원자를 배제할 요건으로서 작용하지 말아야 한다. 사전 선별 절차는 극히 중요하지만 사전 선별은 회사의 핵심 가치에 따라 지원자를 걸러내는 단계다. 핵심 가치를 반영하지 않은 조건으로 사전에 지원자를 떨어뜨리면 안 된다.

번트 홉런

이런 기준을 가지고 면접을 보다보면 경력 상으로는 미천할 수 있으나 훌륭한 잠재성을 가진 지원자를 발견할 수 있다. 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다.

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

새로운 프로젝트와 기존 프로젝트의 채용은 약간 다르다. 기존 팀에 채용할 때는 탄탄한 소프트웨어 기초 역량이 중요하다. 특정 개발 언어나 프레임워크, 도구는 부차적이다. 프로젝트 초기 개발자는 열정과 소프트웨어 기초 역량 외에도 최소한 두 가지 역량이 더 필요하다. 프로젝트를 제 궤도로 유지하고 성공적으로 이끌어낸 과거의 경험이다. 고객의 관료적 문제에 대응하고 비지니스적 압박을 견뎌내고 상용화 이슈와 이해 관계자에 대한 관리 등에 대한 경험이 필요하다. 이는 실제 고객에게 소프트웨어 제품을 공급하는 과정에서만 배울 수 있다.최종 인수 서명 단계까지 고통 속에서 이끌어 본 노련한 개발자들이 필요하다. 신규 프로젝트의 초기 구성원이 될 개발자는 열정, 잠재성과 더불어 현실에서의 경험과 성공적인 이력 이 필요하다. 특정 분야만 잘 아는 스페셜 리스트보다는 여러 서로 다른 기술과 도구, 스크립팅, 가상머신 등 폭 넓게 조예가 있는 기술 분석 전문가도 필요하다.

사전 면접용 코딩 시험

지원자에게 사전에 코드를 제출하게 하는 것도 사전 선별을 위한 좋은 방법이다. 단, 지원자에게 충분한 시간을 줘야 한다. 스피드 퀴즈가 아니라 지원자가 최선의 코드를 작성하게 하는 것이 목적이다. 가장 좋은 방법은 시간 제한을 아예 두지 않는 것이다. 지원자가 준비됐을 때 코드를 제출하게 한다. 지속적으로 채용이 필요한 큰 회사나 좋은 지원자를 누적해서 확보하는 데 특별히 관심이 있는 작은 회사에게 적합하다. 지원자에게 코드 제출이 있을테니 미리 준비해 달라고 하는 것도 방법이다. 몇 장의 이력서가 모였을 때 약 1~2주 간 코드 제출을 받는다고 동시에 통보한다. 선착순으로 다음 채용절차에 들어간다.

이 때 개발 언어나 도구를 마음대로 선택할 수 있게 하는 것이 좋다. 특정 도구나 기술보다는 개발자가 얼마나 좋은 코드를 만들어 내는지 파악하는 것이 목적이다. 채용할 직무에서 사용해야 하는 개발 언어가 Java나 Ruby 처럼 정해져있더라도 이 단계에서는 문제 해결을 위해 어떤 테크닉을 사용하는지 보는 것이 중요하다.

이 과정을 불필요하다고 생각하는 지원자도 있을텐데 회사 입장에서도 바람직하다. 채용과정을 얼마나 진지하게 생각하고 있는지에 대한 척도가 되기 때문이다.

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

강한 팀은 각 개발자 모두 면접을 진행할 수 있어야 한다. 이런 팀을 만들기 위해서는 경험 많은 개발자는 면접을 진행할 때 반드시 경험 적은 주니어 개발자를 대동하여 참관하게 해야 한다. 옆에서 지켜 보는 것이 훌륭한 공부가 될 수 있다. 팀원이 직접 면접을 보고 선별 과정에 참여하면 팀의 사기와 주인의식이 높아질 수 있다. 팀 구성원이 누구와 함께 일할지에 대해 영향력을 행사할 수 있고 자신 프로젝트를 자신이 통제할 수 있다는 확신을 심어준다.

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

좋은 개발자는 나쁜 개발자를 채용하지 않는다. 좋은 개발자는 자신보다 더 훌륭한 개발자를 찾으려고 하고 좋은 팀을 구성하는 것이 얼마나 중요한지 알고 있다. 회사에도 도움이 되지만 자신에게도 도움이 된다. 회사도 개발자 면접에는 개발자를 참가하게 해야 한다. 지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.

잘못된 면접 방식

회사의 채용 절차를 하나하나 상세하게 뜯어보면 그 회사가 추구하는 가치와 문화를 엿볼 수 있다. 경험 많고 재능 있는 개발자는 자율성, 배움, 목적, 생산적 파트너십, 열정적인 사람, 좋은 업무 환경과 같은 것을 우선한다. 특히 면접에서 어떤 사람을 만나는지는 그 회사에 들어갈 것이냐 말 것이냐를 결정짓는 매우 중요한 요소다. 아래는 저자가 제안한 좋은 개발자를 뽑기 위해서 면접에서 피해야 할 8가지 사항이다.

• 똑똑한 척하는 면접관을 세운다 - 면접관이 지원자보다 똑똑하거나 더 우월해보이고 싶어해서는 안된다. 사람을 채용할 때는 파트너가 될 사람, 팀이 더 나아질 수 있도록 도와줄 수 있는 사람을 찾아야 한다. 프로페셔널 개발자로서 대하고 채용을 위한 평가나 취조가 아니라 당신이 존중하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다. 지원자 앞에서 겸손하고 정직해야 하고 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다.
• 수수께끼식 질문을 던진다 - 직무와 전혀 관계 없는 바보 같은 질문은 하지 말아야 한다. 예전 좋은 코드를 작성하고 좋은 팀 플레이어가 되고 프로페셔널다운 태도를 가지는 것과 전혀 관계가 없다.
• 답을 모르는 질문을 한다 - 면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용 중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다. 또한 팀 동료가 짜증을 낼 질문이라면 지원자에게도 삼가해야 한다.
• 지원자를 바보로 만든다 - 지원자의 의견이나 경험을 비하하려고 하면 안 된다.
• 인터넷 접속을 막는다 - 실제 업무 현장과 같은가? 솔루션을 탐색하고 더 나은 문제 대응 방법을 찾는 것은 소프트웨어 개발자로서 갖춰야 할 핵심적인 능력이다. 검색으로 인해 코딩 면접이 변별력을 잃을 수 있다면 면접 과제 자체가 문제가 있는 것이다.
• 종이에 코드를 작성하게 한다 - 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 사항을 지원자에게 요구해서는 안 된다. 자신의 도구와 기술을 마스터하고 테스트와 리펙토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야 한다.
• 알고리즘 문제를 낸다 - 시스템 개발에 필요한 상당수의 업무가 알고리즘에 대한 깊은 이해를 필요로 하지 않는다. 지원자의 문제 해결 능력을 본다며 알고리즘 문제를 낸다. 회사의 실제 프로젝트와 가까운 다른 연습 문제를 통해서도 문제 해결 능력을 평가할 수 있다. 실무에서의 대부분의 문제는 잘못된 설계, 코드의 품질, 지속적인 요구사항 변경, 도메인 모델의 문제가 가장 흔한 실제 문제였다. 실제 문제가 알고리즘과 연관이 있다면 그래야 한다. 즉 중요한 것은 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.
• 전화 면접을 한다 - 사전 선별 작업이 부족할 때 최소한의 요건을 갖췄는지 확인하기 위해 필요하다. 하지만 얼굴을 마주보지 않는 상태에서 컨텍스트가 부족한 상황에서 의도를 충분히 설명하기 어렵다. 지원자가 해외에 있거나 하는 경우에만 어쩔 수 없는 경우에만 전화면접을 사용하자.

- 요약 3부 끝 -

Reference