@doortts (doortts) 님이 작성한 게시글입니다. ---

[면접팁] 좋은 면접자/지원자를 뽑고 싶은 회사와 면접관에 대한 이런저런 생각들

부제: 면접관과 채용 담당자를 위한 비밀들

그 동안 면접을 진행하고 면접을 진행하셨던 분들의 이야기를 들으면서 느껴지는 것이 몇 가지 있어서 공유합니다.

참고로 제가 'IT 기술면접 - 프로그래머나 엔지니어 채용'밖에 경험이 없기때문에 이쪽분야에 한정된 이야기일 수 있다는 점을 고려해 주세요. 또한 아래 내용은 어디까지나 제 사견/개인의 생각임을 먼저 명확히 밝힙니다. 그리고 필요하면 자세하게 쓰겠지만 당연한 부분들의 디테일은 과감히 생략하겠습니다.

전제

사람을 잘 뽑는 것이 매우 중요하다!에 공감이 필요 하단에 사람을 잘 뽑아야 하는 이유에 대해 조금 적어봤습니다.

면접대상자 찾기

믿을 만한 지인의 소개가 사실 제일 좋은 것 같습니다.
여기서 믿을 만한의 의미는 인간성을 의미하는건 아니고 사람을 보는 시각이나 센스가 좋은 사람을 말합니다.
A급 개발자는 A급 인재를 데려온다는 말이 (분하지만) 맞는 경우가 많다고 느꼈습니다.
- 하지만 'A급 개발자'의 의미는 생각하시는 것과는 굉장히 다를 수 있습니다. (문장이 모호하지만 그대로 남겨두는 걸로)

채용공고(Job Description, JD)

일에 맞는 좋은 사람을 뽑으려면 채용공고도 매우 중요한 것 같습니다.
- 좋은 사람의 의미가 다양하게 해석되기때문에 정말 중요!
기본적으로 두 가지는 명확히 표현되어야 합니다.
- 우리는 어떤 사람을 원한다.
- 그 사람은 와서 어떤 일을 하게 될 것이다. 이때 누구와 함께도 표현되면 더 굿!

우리는 어떤 사람을 원한다.

무슨 일을 할 어떤식으로 할 사람을 찾는지 정확하게 적을 필요가 있습니다.
- '함께 세상을 바꿔나갈 사람', '끈끈한 동지애로 같이 난관을 헤쳐나갈 사람', '슈퍼 개발자를 모십니다', '책임감 있는 서버개발자를 찾습니다', '저희 팀 프론트 개발을 맡아 주실분!' 보다는 '자사의 AAA 모바일 애플리케이션의 API서버를 맡아서 설계와 개발 운영을 함께 하실 분. (참고로 혼자 하지 않고 적어도 2명 이상이 동일 업무를 협력해서 진행하게 됩니다)' 같은 식으로 적으면 (현실적으로) 지원자입장에서 좀 더 잘 지원하게 됩니다.
필수 조건과 가점 항목을 나눠서 적으시면 더 좋습니다.
- 채용 공고를 적다보면 A에 대한 경험도 있고 B도 알고 C도 해봤고 가능하다면 D도 할 줄 아는 분.. 식으로 다 적는 경우가 있습니다. 그러다보면 중요도 문제도 있고 지원자 입장에서도 지원에 부담을 느끼게 됩니다.
- 특히 하나만 열심히 해서 그걸 굉장히 잘하는 겸손 혹은 소심한 사람들은 아쉽게도 지원을 안해요. (아.. 난 아마 안될거야.. 이런 느낌으로..)
- 꼭 필요한 항목과 배우는데 오래 걸리지 않거나 알면 좋고 몰라도 가능은 따로 분리해서 적어 놓으면 서로 좋습니다.
- 물론 특이한 경우로는 채용 요구 스펙을 지나치게 높게 적어서 그게 또 짤방처럼 돌아다녀서 의외의 홍보...를 하게 되는 경우도 있긴 합니다.

대면 면접전에 놓을만한 단계들

서류 심사후 바로 대면면접을 진행하는 것보다 중간 단계를 두는 것이 더 좋습니다. 아래가 대표적인 단계들. 취사선택 하는걸로.

전화면접
- 지원자가 많은 경우 시간 절약용
사전과제
- 특정 항목등에 대해 미리 스킬을 확인해 보고 싶을 때

전화면접

서로의 시간을 줄여 줄 수 있는 것이 장점이지만 제대로 진행하지 못하면 의외의 시간낭비가 됩니다.
이미 서류에서 한 번 검토된 사람을 대상으로
서류상에 적힌 내용들에 대해 깊이나 참여도, 궁금했던 사항들을 확인하는 정도가 좋은 것 같습니다.
기술적인 것을 물어봐도 사실 단답형 이상은 어렵고, 이때 말을 잘한다해도 그게 또 대면면접을 하면 다른 경우가 많기 때문입니다.
전화면접은 면접 전에 이어셋 등으로 자유롭고 편하게 진행할 수 있도록 사전 안내해주면 좋습니다.
그리고 면접 시간전에 먼저 문자나 전화로 해당 시간에 예정대로 진행해도 좋은지 물어본다면 더 좋은 인상을 주게 됩니다.
컴퓨터 앞에 놓고 타이핑하면서 하는걸로 치팅을 걱정하는 경우도 있는데 전화면접에서 치팅을 따질만한걸 묻는 것도 좋은건 아닌것 같습니다.
회사 혹은 면접 주최측과의 첫 대면이니까 시작 시점에서 최대한 편하게 진행할 수 있도록 좋은 분위기를 만들어 주세요
특히 전화면접은 생소하거나 낯설고 상대가 긴장하기 쉽기때문에 '앞으로 얼마의 시간동안 어떤식으로 진행될거다'라는걸 시작할때 미리 알려주면 좋은 배려가 됩니다.

사전과제

해당 직무(JD)에 필요한 기술을 테스트 해보는 목적으로 일정기간을 주고 해결할 수 있는 문제를 냅니다.
- 일반 알고리듬 문제만으로 진행하지 말고 현재 팀내에서 겪고 있는 문제중 하나를 과제로 내는 것을 추천하고 싶습니다.
문제를 정확히 풀었나를 보는 것과 함께 개발/코딩 스타일, 설계 정도, 네이밍 센스, 문서화 등을 같이 보는 것이 필요합니다.
문제도 잘 풀고 README나 설계 문서까지 잘 작성하는 개발자라면 보통 기술면접때도 꽤 괜찮(았었)습니다.

오프라인 기술면접 - 형식

진행 일정은 여유있게 잡는 것이 좋습니다.
1명에 대해 여려명의 면접관이 충분한 시간을 두고 진행하면 좋습니다.
- 물론 이경우 면접관들끼리 먼저 모여서 사전 미팅을 통해 서로의 질문이 겹치지 않고 영역을 나누어서 볼 수 있도록 조율해야 합니다.
- 나중에 결과 논의도 마찬가지로 모여서 하면 더 좋습니다.
- 물론 이것도 다 비용이고 투자인 셈인데 회사내에서 좋은 사람을 뽑는 것을 어느 정도로 중요하게 생각하느냐가 이 부분에서 드러납니다.
개인적으로는 면접관 두 명이 1조로 1명의 지원자를 면접보는 것이 시간 절약도 되고 좋은 것 같습니다
- 둘이 같이 들어가면 다른 한 사람이 질문등을 진행하는 동안 다른 사람은 면접 내용을 적습니다
  - 보통 면접관들은 질문도 하랴 내용도 적으랴 바쁜데 자신이 질문하는 타이밍이 아닐때는 옆 질문자의 의견을 적어주면 질문자는 질문과 진행에만 집중할 수 있습니다. 2인 1조를 추천하는 이유이기도 합니다.
- 게다가 무언의 타이핑을 하는 시간동안 응시자가 면접관이 타이핑하는걸 쳐다보며 정적이 흐르는 어색/긴장 상황도 줄여주고요
- 다만 응시자 입장에서는 한 번에 두 명을 신경써야 하기 때문에 압박이 더 올라갑니다.
- 아니면 일관성있게 서기?같은 분이 계속 함께 계시면서 면접관이 바뀌더라도 면접 내용을 적어주는 식의 '서기 1 + 면접관 1'의 구성도 괜찮은 것 같습니다. (~~이건 해본적은 없고 하고 있는 곳이 있다고만 들었습니다~~) (생각해보니 제가 지금 회사 들어올때 임원면접때 상황이 딱 이랬었군요. 임원분은 저와 계속 대화/질문하고 옆에 계신분은 뭔가를 계속 적기만...)

오프라인 기술면접 - 내용

앞 단계(서류면접, 시험, 전화면접, 사전과제 등등)에서 어떤 부분을 얼마만큼 검증해 줬느냐에 따라 내용이 달라집니다.
그리고 회사, 혹은 해당 직무에서 뽑고자 하는 사람에게 맞춘 질문이 필요합니다.
- 개인적으로는 신입은 경험보다는 기본기를 더 높게 보는게 좋고 경력은 경험을 더 깊게 보는 편이 좋은 것 같습니다.
- 신입의 경우에는 속칭 열의있고 똘똘한 사람을 뽑아서 3개월 정도 훈련시키면 비슷해질 경력이나 지식은 높게 치지 않으시길 권합니다.
(당연하지만) 프로그래머를 뽑는거라면 프로그래밍을 실제로 시켜봐야 합니다. (아래 독립 항목으로 좀 더 설명)
면접자가 해당 문제를 힘들어 한다면 대화식으로 힌트를 주면서 진행하는 것도 저는 좋다고 생각합니다.
중간 중간 압박면접식으로 다소 공격적인 코멘트나 의문제기로 진행하는 회사나 조직도 있는데 저는 프로그래머에게 압박면접은 추천하고 싶지 않습니다.
- 압박을 견디고 프로그램을 짜는 사람만 통과되면 그 정도로 뭔가 독한 개발자가 들어온다고 생각하셔야 합니다. (...)
- 조직이 팀개발 위주라면 다시 잘 생각해 보시길 권합니다.
단순히 질문응답식으로 진행하지 말고 지원자와 계속 다양한 커뮤니케이션을 시도하는 것이 좋습니다.
맘에 안든다고 절대 공격적으로 대하진 마세요.
- 농담처럼 하는 말이 있는데 면접 끝나고 회사 문을 나가면 그 다음 순간부터는 바로 그 사람은 고객이라는 말이 있습니다.
면접이 다 끝나면 반대로 지원자에게 질문을 받는 시간을 주시면 좋습니다.
조금만 노력하면 면접 진행 자체가 지원자에게 도움이 될 수 있도록 잘 진행해 줄 수 있습니다.
- 나중에 틀린부분에 대해 알려주고 질문의 의도가 무엇이었는지 어떤 점이 아쉬웠는지 등을 알려주는 시간을 가질수 있다면 더 좋습니다.

기술면접시 프로그래밍 테스트

페이퍼/보드 코딩만으로 진행하는건 전 추천하고 싶지 않습니다.
다양한 방법들이 있지만 (특히) 경력직을 뽑는 상황이라면 본인이 익숙한 환경을 기반으로 작업할 수 있도록 노트북을 준비해 오라고 하거나 준비해 놓는 것이 더 좋다고 생각합니다.
여기에는 전통적인 코딩테스트 방법에 대한 '어떤 의문'을 기반으로 하는데 바로 개발자의 생산성은 어떤 문제를 백지 위에서 푸는 시간만으로 한정할 수 있는가?라는 의문입니다.
그래서 가급적 입사 후 본인이 작업하게 될 상황과 유사한 환경에서 어떤 도구를 사용해 어떤 방식으로 해당 문제를 해결하는지 볼 수 있도록 노력해야(한다고 저는 생각)합니다.
지금 코딩 테스트의 현실은 마치 우리가 현업에 화이트보드나 노트패드로 코딩을 한다고 가정한 경우가 많기 때문입니다.
- 물론 알고리듬 자체에만 집중하고 싶다던가 아니면 무언가 나름의 철학이 있다면 다르겠지만요.
- ...샘표, 신입 공채 시험...
그래서 항목에 따라서는 혹은 제한적으로 인터넷 검색까지 허용하고 전방위적으로 응시자의 개발 하는 방식을 옆에서 볼 필요가 있습니다.
문제 유형으로는 채용 영역에 따라 다르겠지만 센스나 재치, 혹은 아이큐 측정 같은 문제만 내지 않도록 유의해야 합니다.
- 이를테면 1부터 100까지 곱하면 0이 몇개냐? 길이가 다른 양초를 태워서 특정 시간을 찾아내라! 늑대랑 농부와 양이 강을 건너는데...같은
항목자체도 알고리듬, 응용능력, 설계능력, 기본기술지식 등을 두루 볼 수 있는 항목 여러개를 제공하면 더 좋습니다.
주요 알고리듬 시간복잡도 Big O는 충분히 물어볼만한 항목입니다.
면접관들이 보통 문자열 조작(뒤집기, 조합하기, 잘라내기 등등), 간단한 길찾기, Stack 응용, Queue 응용, LinkedList 응용, Binary Search, 깊이우선탐색, 너비우선탐색, 기초 확률 문제 같은것들을 많이 내는 편인데 이정도는 흔히 많이 알려져있다는걸 알아야 합니다.
하지만 그럼에도 아직까지는 기본 허들로 많은 지원자들을 저정도 항목으로도 걸러낼수 있습니다.
지원자가 풀다 못풀면 힌트 주세요. 또다른 여러가지를 볼 수 있는 기회가 생깁니다.
XXX의 특징, 추상 클래스, 인터페이스, Stack/Queue/List 설명, OSI 7 layer 같은 단답문제는 기술면접에서는 잘 안물었으면 좋겠습니다.

인사담당자

지원자와 계속 연락을 주고받게 되는 인사담당자는 사실상 회사나 조직의 이미지/아이콘이 됩니다.
지원자를 대함에 있어 친절의 지나침은 없다고 생각해주세요
지원서 제출부터 면접 진행까지의 속도도 매우 중요합니다. 느릿하면 놓치는 경우 종종 생깁니다.
지원자들은 진행상황이나 피드백등에 목말라 있습니다. 가려운 곳, 목마른 곳 잘 해소해주세요.
말끝마다 '감사합니다.'가 붙는 식의 답장은 안쓰니만 못한 경우 많습니다. 진심으로 대해주세요.
거절메일은 정말 요령이 필요합니다. 최대한 모노톤으로 쓰려고 하는 경우 많은데 저는 그건 오히려 그다지 서로 도움이 안된다고 생각합니다.
- 정말 생각이 깨인 조직이라면 지원자에게 도움이 될 수 있도록 면접관들을 통해서 아쉬웠던 점, 더 잘 키우면 좋을 것 같은 점등을 취합해서 보내주세요. 아마 그것만으로도 응시자는 좋은 인상으로 추천하거나 발전 후 다시 지원할겁니다.
합격되었든 불합격 되었든 마지막에 면접 진행 전체에 대한 설문을 받으면 채용 프로세스 개선에 도움이 됩니다.

사람을 잘 뽑아야 하는 이유

다 아는 당연한 이야기. 모든 일이 다 그러하겠지만 사람을 잘 뽑는것이 정말 중요합니다.
물론 기본 인력 수준과 사업영역에 따라 다르긴 하지만 대개 시스템(방법론, 개발프렉티스, 산출물 등)이 고도화 되는 경우는 개발팀 개개인의 역량차이를 보완해 주기 위해서인 경우가 많습니다.
시스템은 일종의 평준화(Normalization)를 통해서 결과물이 일정수준이하로 떨어지는 것을 막아줍니다만 그걸 위해서 때때로 장황한 작업들을 해야 하기도 합니다.
그런데 뛰어난 인재를 뽑으면 뽑을수록 시스템에 투자를 덜 해도 괜찮습니다. 이렇다할 시스템이 존재하지 않아도 결과물이 동일 혹은 그 이상으로 더 잘 나오는 경우가 많습니다. 예) 토발즈가 방법론을 따라서 리눅스를 만들었던가? 전설의 레전드 존 카멕은 '개발자는 개발 파트에 1명이면 충분하다'라고..
자원적 여유가 있는(속칭 돈 많은) 기업들이 인재영입에 어마어마한 돈과 시간을 쓰는 이유도 그렇습니다.

면접관에 대한 심리적인 측면

'과연 내가 누군가를 뽑을 만한 능력이 있는가?' 라던가 '좋은 사람을 어처구니 없이 놓치고 있는건 아닌가?', '다른 사람의 인생에 큰 영향을 주는건 아닌가'라는 고민을 하는 면접관들이 많다는 걸 알게 되었습니다.
제 생각을 이야기 드리자면 어쩔수 없습니다. 답이 있는것도 아니고 우리가 이 짧은 시간에 누군가를 제대로 보는 것이 가능한지도 잘 모르겠습니다. 다 랜덤이고 다 운 아닌가? 라는 생각이 들 수도 있습니다.
그리고 과연 어떤사람을 뽑아야 할지 정말 모르겠다! 라고 좌절하는 분들도 있습니다.
그런 분들께 제가 드리고 싶은 어떤 기준은 이렇습니다. 내가 같이 일하고 싶은 사람, 한번 키워보고 싶은 사람이라면 그 외 것들이 다소 고민되어도 한 번 베팅해볼만 합니다. 그리고 생각보다 당신은 사람을 더 잘 보는 사람일 수도 있습니다. :)

기타 생각해 볼 문제

경력을 연수로 표시하는 경우.
- 예를 들면 자바서버개발 4년 이상. 같은 표현은 사람에 따라 기대도 다르고 내포한 의미가 모호한 경우가 종종 있습니다.
- 따라서 차라리 어떠한 것이 가능한지에 대한 표현이나 ~~한 것에 대해서 ~~게 가정하고 있다는 것을 표현하면 더 좋습니다
- '멀티스레드 프로그램을 작성해서 실제 서비스에 적용해 본적이 있는 분', '혼자서 다른 사람의 도움없이 동접 100명정도의 서버를 구축하고 운영하실 수 있는 분' 같은식
실력우선주의 채용
- 팀개발을 할 개발자/개발팀의 일원을 뽑는거라면 개인의 실력만으로 순서를 세워서 뽑는건 꽤 위험할 수 있다는 걸 이해해야 합니다.
- 볼만한 기사
  - 유능한 또라이 비판
  - '호감가는 바보'가 '유능한 또라이'보다 낫다
- 우리는 우리와 함께 일할 좋은 동료를 찾기위해 우리 자체가 준비되어 있지 않기때문에 좀 더 쉬운 잣대인 '실력, 코딩, 지식'만으로 사람을 뽑고 있는 건지도 모릅니다.
내가 혹은 우리 들이 뽑는 방식으로는 면접관인 나도 합격 못할것 같다!라고 느껴지는 경우
- 너무 우리가 가혹하게 보는건 아닐까라는 남들에게 말못할 두려움을 갖고 있는 면접관도 많습니다.
- 괜찮습니다.(You are not alone!) 다만 해당 면접 문제나 방식이 해당 JOB 포지션에 적합한지에 대해서는 계속해서 고민하는 것만 멈추지 말아주세요. 점점 더 나아질겁니다.
- 팁으로는 면접 문제는 면접관들이 서로 공유해서 다 풀어보는것이 좋은 것 같습니다. 면접관도 다른 면접관을 통해 또 배울 수 있는 계기가 되거든요.

개인 의견이지만 더더 개인의견

직업에 대한 몰입도나 적성을 볼 수 있으면 더 좋습니다. 그러기 위해서는 다양하게 상대를 바라 봐야 할 필요가 있습니다.
원석을 볼 수 있으려면 면접관(들) 자신도 많이 생가하고 준비해야 하는 것 같습니다.
- 면접관도 회사/조직 차원에서 잘 길러야 하고 본인의 실력에 우쭐하지 않고 다른 사람을 잘 보는 눈을 길러야 할 필요가 있습니다.
- 그리고 면접관들의 좋은 사례들이 전파되고 전승될 수 있도록 노력을 기울일 필요 있습니다.
짧은 시간동안의 면접으로 누군가를 채용하는것 보다 인턴십이나 해커톤, 아니면 커뮤니티활동을 하면서, 모임에서 만나서 이야기 해보면서 등등을 통해 사람을 뽑는것이 더 좋은 것 같습니다. 그러려면 시간과 비용도 많이 들지만요.
뭐, 구글처럼 한 사람을 수개월에 걸쳐 수십번 면접후에 뽑는것도 '구글급'이라면 가능하니 좋겠다고는 생각합니다.

작은 회사 한정된 리소스

좋은 사람을 뽑기가 정말 어렵다는걸 잘 압니다.
지인소개 적극 권장합니다.
서비스를 매력적으로 만들면 그게 돈/복지 이외의 매력이 되어 인재 채용의 또 다른 방안이 될 수 있습니다.
- 비바 리퍼블리카로 이직한 이야기 <= 물론 여기정도면 이미 작은 회사는 아니지만...
개발자에 유리한 좋은 문화를 만들기가 의외로 더 쉬울수도 있는데 이점을 잘 이용하는 것도 괜찮습니다.
- 특히 큰 회사나 큰 시스템에서 자신의 실력을 제대로 인정받지 못했거나 이러저런한 이유로 상처받고 방황하는 사람들을 잘 품을 수 있는 가능성을 보여주면 같은 배를 선택하게 됩니다.
- 기술 커뮤니티등에 가보면 의외로 많습니다.

기타참고링크

[면접팁] 좋은 면접자/지원자가 되는 방법 도 같이 보시면 반대로도 좀 더 생각해볼만한 부분이 있지 않을까합니다.

PS

이렇게 길게 쓰려던 것 아니었는데 너무 길어져서 급히 줄입니다. 마찬가지로 생각나는 부분있으면 틈틈히 업데이트 해 놓겠습니다.

관심있으신분은 사이트 가입하셔서(목적이 이거 아닙니다...ㅋ) 우측 상단의 지켜보기 누르시면 업데이트 내용 메일로 받아보실수 있으실겁니다.

--- attachments --- 155292714444.png 994776939471.png

doortts / blog

[면접팁] 면접관과 채용 담당자를 위한 비밀들 #266