"개발자 채용시 기술검증 어떻게 할 것인가" 워크샵 참석 후기

며칠전에 페이스북에 아주 핫한 포스팅이 올라왔습니다!
OKKY의 공동대표이신 노상범님께서 개발자의 실력검증에 대한 글을 남기셨는데요.
여기서 애자일 컨설팅의 김창준님께서 이 주제에 대한 이야기를 해주시겠다는 댓글이 달렸습니다!

그 핫한 주제의 워크샵이 바로 오늘! 진행되었습니다.
노상범 대표님의 배려로 저 역시 세미나에 참석할 수 있었습니다.

참석하신 대부분의 분들이 개발자 채용을 담당하고 계신 분들이라 정말 현실적인 질문들이 많이 나왔습니다.
개발자 채용 방법에 대한 고민이 있으신 분들에게 도움이 되시길 바라며 기록합니다.

1. 현재 기술력 검증의 문제점

(애자일 컨설팅의 김창준님)

• 프로그래밍에서 Hello World 라는게 있다.
• 가장 간단한 문제의 대명사: Hello World
• 삼각형 판별이라는 QA계의 Hello World를 QA 분들에게 단위 테스트 설계를 요청함
• 전문가들은 풀지 않음
• 대신 그들은 질문을 함
  • "강사님 이 프로그램은 누가 쓰는건가요?"
  • 초보자들은 질문을 하지 않음
  • 사용자가 누구냐에 따라 완전히 다른 단위테스트 설계가 필요함
  • 전문가 입장에선 이게 의미가 없다는 이야기
  • 우린 이런 의미 없는 일들을 훈련하는것 일지도 모름
  • 맥락을 무시한 훈련
  • 우리의 코딩 테스트도 사실 이런 경우일 수 있음
• 전문성 연구가 확 뒤집혀진 계기가 있음
  • 연구비를 최소화하기 위해 짧은 시간안에 풀 수 있는 문제를 제출하게 됨
  • 같은 이유로 표본 숫자도 줄여서 실험
  • 똑같은 문제를 주고, 전문가와 비전문가의 차이를 비교
  • 그럼 전문가와 비전문가를 어떻게 미리 구분 해놓는지?
    • 보편적인 메타 정보 (학력, 경력 등으로)
  • 하지만 축소된 문제가 아닌 복잡하고 확장된 문제를 줬더니 전혀 다른 결과가 도출
  • 전문가일수록 유연하고, 초보일수록 뻣뻣함
    • 초보일수록 능동적으로 대처하지 않음
• X로 테스트하면 X를 잘하는 사람이 뽑힘
  • 코딩 인터뷰로 테스트하면 코딩 인터뷰를 잘하는 사람이 뽑힘
  • 근데 실제로 우리 회사에 필요한 사람이 코딩 인터뷰를 잘하는 사람인가?

Q. 굉장히 쉬운 문제도 못 푸는 사람을 걸러내는 용도로 코딩테스트는 어떤지?

• 그 용도로는 굉장히 가치 있다고 봄
• 이기는 용도가 아니라, 지지 않는 용도로 코딩 테스트는 괜찮다.
• 그러나 많은 상황에서 그 이상의 용도로 사용하는걸 본다
• 코딩 테스트는 기본적으로 비용이 든다.
• 그것보다 비용이 덜 들면서도 이상한 사람을 걸러 낼 수 있는 방법이 있다.
  • 그 사람이 일한 것을 기반으로 구체적으로 물어보기
  • 과거의 그 사람이 어던 상황에서 어떤 행동을 취했는지를 확인해보기
  • 코딩 인터뷰는 굉장히 스트레스 받는 일이기 때문에, 해당 인터뷰를 통해서 스트레스를 잘 견디는 사람을 뽑을때 좋음
  • 하지만 스트레스를 잘 견디는것과 성과를 내는 사람을 뽑는 것은 별개의 문제

2. 개발자 채용 어떻게 할까?

• 개발자 채용보다 사람을 잘 뽑는게 더 중요한 영역을 참고해보자
• 군사의 경우가 이 경우에 해당함
• 특수부대는 사람을 어떻게 뽑을까?
• 시뮬레이션 진행
  • 군사지역 지정해서, 보급품과 군사장비를 제공해서 군인들이 어떻게 행동하는지 실시간 측정
• 그럼 우리는?
  • 될 수 있으면, 현실과 가장 비슷한 상황을 연출하는게 중요
  • 코딩 문제를 풀었다고 해서 우리 문제를 해결해줄수 있다는걸 보장하지 못함
  • 풀었다/안풀었다로만 판단하지 말고, 어떻게 풀었는지를 참고
• 그럼 회사에서 어떻게 준비해야할까?
  • 우리가 하는 일을 분석
    • 이 사람이 하는 일이 대부분이 코딩이 아닐수도 있음
  • 이걸 기반으로 대표 케이스를 뽑을 수 있음
    • 개발하는것보다, 고치는 일이 더 많을 수 있음
    • 우리 회사의 버그 중 하나를 샘플링해서 푸는 방법을 보는것도 좋은 방법
  • 대표 케이스를 사내에서 테스트 진행
    • 우리 회사에서 뛰어난 개발자 3명과 평범한 개발자 3명을 뽑아 6명에게 이 대표케이스 문제를 풀도록 해봄
    • 3/3이 결과가 차이가 나도록 문제를 뽑아야 함
    • 만약에 잘하는 사람들은 "이 문제를 받았을때 질문이 많았다" 라는 과정이 있었다면, 이 내용을 채용에서도 참고
    • 이렇게 만든 체크항목으로 면접관들이 체크하도록 한뒤, 면접이 끝나고 서로의 체크항목을 비교하기
    • 이 방법은 굉장히 빡빡한 사례이고, 이 내용을 회사에 맞게 진행

3. Q & A

Q. 블라인드 테스트로 개발자를 채용한다면 장/단점?

• 개인적인 생각으론 코딩 테스트 잘푸는 사람이 뽑힐거라봄
• 성실성 혹은 갈망을 검증하는 자리가 될 확률이 높음
• 이 사람이 들어왔을때 우리가 기대했던 것과 다른 행동을 보여줄수도 있음
• 자기소개서 질문 혹은 인터뷰 질문
  • 본인이 생각한 개발 일정은 한달인데, 팀장님이 일주일 만에 하라고 한다면 어떻게 할것인지? 와 같은 질문이 도움이 될 수 있음

Q. 끈기, 성실등을 짧은 인터뷰 시간에 측정가능한가?

• 과거를 질문하는게 좋다.
• 내가 생각하는 끈기 있는 사람을 떠올리면 비교가 가능
• 그 사람이 언제부터 끈기 있는 사람으로 보였는지 생각해보면 좋음
• 미래형 질문은 하지 않는게 좋다. (거짓말하기 쉬우니)
• 과거 질문을 해야 거짓말을 하면 할수록 과부하가 걸리게 된다.
  • 과거를 부정하면서 실시간 교정은 정말 힘든 일
• 이 사람이 특정 시점을 떠올리게 한 뒤에, 질문을 하면 좋음

Q. 연봉협상을 세밀하게 측정할 수 있는 방법

• 임시로 적당한 금액을 정하고, 3개월 뒤에 다시 재협상하는 방법을 많이 씀
• 실제로 한 두달 일해보면 성과 측정이 쉬움
• 사실 가장 중요한건, 연봉이 중요한 요소가 안되도록 하는게 중요
  • 물론 기본적인 연봉 수준보단 높아야 한다는게 기준
• 내재적 동기 vs 외재적 동기
  • 외재적 동기가 있었던 사람들은 시간이 갈수록 입사후 외재적 동기가 자꾸 감소됨
  • 본인이 점점 그 일을 싫어하게 됨
• 입사할 때 너무 연봉에 신경쓰지 않도록 만들기

Q. 잘하는 사람으로 채점기준을 만들면 부족한점이 있지만, 다른 측면에서 뛰어난 사람들마저 걸러지지 않는지?

• 위 사례에서 얘기한대로 채점 기준을 만들게 되면 점수를 볼 수 있다
• 점수를 만들면 좋은 점은 Pass/Fail을 만드는게 아니라, 좀 더 좋은 사람과 좀 덜 좋은 사람을 구분할 수 있게 됨
• 만약 "다른 측면에서 뛰어난 사람이 있지 않을까" 란 생각이 든다면, 그 측면에 맞는 채점 기준을 만들어야함
• 내가 갖고 있는 특별한 믿음이 있다면 그 반대 케이스를 한번 고려해보자
  • 술을 잘먹어야 협력이 잘된다는 믿음이 있다면
  • 술을 못먹는데 협력이 안된 케이스가 있었는지 생각해보기

Q. 비개발자와 협업해서 개발자를 채용해야하는 경우에 있다면 어떻게 해야할지

• 회사안에서 어떤 사람을 뽑아야 하는지에 대한 합의가 있어야 함
• 역량모델과 비슷하게 "우리 회사가 바라는 인재상"
• 데이터를 기반으로 만들어야 함
• 우리 회사 내부에서 인정 받는 사람들의 공통점을 추려서 모형을 만들고, 그 모형이 어떤 사건을 계기로 적용된건지를 작성

Q. 전화 면접을 해야한다면 효과가 있는지? 주의해야할게 있다면?

• 커뮤니케이션의 비중은 언어적인게 90%, 비언어적인게 10%
• 텍스트로 하는것보다는 훨씬 더 좋으며, 화상 인터뷰로 했을때와 비교하면 비슷할것으로 본다
• 실제 대화를 진행했기 때문에 크게 걱정하지 않아도 된다고 본다
• 전화 인터뷰는 30분 이내를 권장
• 전화 인터뷰로 확신이 든다면 면접으로 부르는게 좋음
• 서류 -> 전화 -> 면대면
• 단, 전화 인터뷰의 기준이 있어야함. 느낌으로 판단하면 의미가 없다.

모의 테스트

Q & A가 끝나고 아주 재밌는 시간이 진행됐는데요.
3명씩 조를 이루어 우리조라면 어떻게 테스트 할것인지를 논의해보고, 이를 창준님께 리뷰 받는 시간이였습니다.
서기(?)의 역할로 왔지만, 저 역시 합류해서 같이 논의해볼수 있었습니다.

아주 재밌는 테스트 제안이 2개가 나왔습니다.

제안 1: 웹 서비스가 죽었다면 어떤 액션을 취할것인지로 검증하겠다.

• 잘하는 사람은 어떻게 하는지 아시는지?
  • 제안자: 질문을 많이 하는 경우가 대체적으로 좋은 케이스로 본다.
• 조금 더 게임스럽게
  • 리모트 서버를 하나 죽여놓고, 지원자에게 쉘을 주면서 어떻게 이걸 처리하는지를 본다.
  • 옆에 조언을 줄 수 있는 가상의 3년차 팀원(NPC처럼)을 제공한다.
  • 미리 시나리오를 만들어 놓기
  • 지원자의 질문만 보더라도 쉽게 알 수 있음
• 이럴 경우 비용이 많이 드니, 좀 더 저렴하게 확인하고 싶다면
  • 과거에 이런 사례가 없었는지 질문하고, 그때 당시 어떤 행동을 취했는지 답변을 확인
• 임베디드의 경우 데드락이 중요한데, 데드락 코드를 보여주고 어떻게 문제를 해결하는지 보는것도 좋은 예시
• 웹 서버가 죽었다면 서버를 살리는 것만으로 끝내지 않고, 후속 조치(모니터링 등)까지 진행하면 베스트
  • 업무에선 항상 이렇게 진행된다는 점을 명심

제안: API 응답속도가 갑자기 느려졌다면 어떻게 할것인지?

이 질문에는 창준님께서 직접 답변하신게 없어서 질문만 남겼습니다.

이 질문 이후로 더이상의 제안은 없었고, 다시 Q & A가 시작됐습니다.

Q. 개발의 전문성이 없는 소규모 회사에서 개발자를 채용해야한다면?

• 우리 회사 외부의 전문가들을 직접 찾아가서 인터뷰해보자
• 외부의 전문가들은 우리 회사의 문제 상황을 만났을때 어떻게 답변하는지를 모아보자
• 그 답변들을 기반으로 개발자 채용의 기준을 삼을수 있음
• 전문가들의 공통점이 있음
  • 평상시 공부를 함
    • 어떤 공부를 하는지만 봐도 알 수 있음
    • 책보는 것과는 관계없음
  • 비전문가일수록 확신함
    • 만약 대답을 바로 하지 않고, 유연하게 답변을 한다면 전문가일 확률이 높음
    • 전문가일수록 유연하다
• 전문성을 측정할수 없다면 학습능력을 보자

Q. 언변이 떨어지는 사람을 판단하는 방법은?

• 우리 회사에서 사례를 찾아본다
• 언변이 떨어지지만, 성과가 좋았던 사람의 특징을 뽑아 본다.
• 그 특징을 기반으로 판단한다.

Q. 새로운걸 빨리 학습하는 능력을 검증하는 방법은? (러닝커브)

• 능력 좋은 사람이 노력도 많이 함
• 뛰어난 사람일수록 의도적 노력의 양이 많음
• 간단하게 판단하는 방법은?
  • 학습 방법을 테스트 해보면 됨
• 예시)
  • 입사지원서에 간단한 테스트를 포함시킨다.
  • 본인이 여태껏 사용해보지 않은 언어로 이 문제를 풀어달라
  • 그 언어를 어떤 기준으로 정했고, 어떻게 공부했는지를 타임로그로 남겨서 보내달라고 함
  • 공부한 방법을 보면 그사람의 학습 능력이 드러남

Q. 개발을 잘 하는 사람은 팀 리더를 안하려고 하고, 개발능력이 안되는 친구들이 계속 팀 리더를 하려고 하는데 어떻게 하는게 좋은지?

• 본인이 생각하는 개발을 다시 정의해볼 필요가 있음
• 보통은 순수 코딩 능력을 보는 경우가 많음
• 최근의 프로그래머의 능력 측정에는 협력을 꼭 포함시켜야 한다고 함
• 협력이 안되면 결국 성과가 나오지 않음
• 흔히들 하는 실수가 기술 능력만으로 리더를 삼으려고 하는 것
• 내가 따르고 싶어했던 팀 리더를 떠올려보면 답이 나옴
  • 그 리더가 꼭 개발능력이 최고여서 따르고 싶었는지를 생각
• 개발 트랙, 매니징 트랙을 분리해서 이야기하면 안됨

마무리

정말 재밌었던 시간이였습니다.
저는 채용하는 입장이 아니였지만, 우리 팀에 어떤 사람이 합류하면 좋을지를 다시 한번 고민해볼 수 있는 시간이였습니다.

반대로 지원자 입장에서는 이런 테스트가 점점 늘어난다면 어떻게 준비하면 좋을지도 생각해볼 수 있는 좋은 기회였습니다.

역시 결론은 회사에서 많은 문제를 만나고, 직접 해결하고, 정리하는게 좋은 방법이지 않을까 추측해봅니다.

이번에도 좋은 세미나 참석하게 되서 정말 감사드립니다!

긴글 끝까지 읽어주셔서 고맙습니다^^