이제 매니저라는 직함이 어색하지 않은 시기가 되었고, 지원자의 이력서와 면접을 대하는 나만의 원칙 같은 것도 생겼다. 직간접적인 경험에 비추어보면 대개의 채용 과정에서 빠르게 합격하는 경우는 거의 없지만 반대로 빠르게 걸러지는 경우는 많은 듯 하다. 다시 말해 안티 패턴이라고 할만한 행동만 주의해도 흔히 말하는 '광탈'은 줄일 수 있다는 뜻이다. 언제 한 번 정리해야겠다 생각하던 차에 마침 내 의견과 비슷한, 그런데 정리가 잘된 글을 보아서 번역도 하고 내 의견도 남겨보기로 했다.
사실 이 글은 이달 초쯤 트위터(아직도 X라는 말이 입에 붙지 않는다)에서 보고, 지금 진행하고 있는 부트캠프의 주니어 개발자들에게 얘기해줘야겠다 싶어서 갈무리 해두었던 글이었다. 잠시 잊어먹고 있다가 최근 다시 생각나서 그 친구들에게 얘기해주는 김에 아예 블로그 글로 쓰기로 한 것이다. 원본은 @AmeeNH3가 작성한 트위터 글이다(#).
이력서와 면접에서 적신호가 되는 10가지 행동은 다음과 같다.
1. 소개에 유행하는 업계 용어가 너무 많다.
"스케일러블한 마이크로서비스, 분산 클라우드 네이티브 시스템, 애자일 배포 파이프라인 ...(중략)...에 익숙한 풀스택 개발자"
이런 식의 소개는 어디서 들어본 듯하고 또한 무의미하다.
간단하게 시작하고, 사람처럼 말하고, 좋은 인상은 그 후에 주자.
의견) 사실 이력서에서 굉장히 자주 보이는 유형인데 막상 면접시 해당 기술에 대해서 질문하면 두루뭉술하게 알고 있어서 잘 설명하지 못하는 경우를 종종 보았다. 당연히 감점의 요인이 된다. '책임질 수 있는' 말만 써두는 게 좋다.
2. 문제에 대한 이해 없이 코딩부터 하고 본다.
이런 지원자들은 과제를 듣자 마자 바로 타이핑을 시작한다. 스피드런이라도 하는 듯이 보인다.
여유를 갖고 명확한 이해에 도움이 될 질문을 하자. 여러분의 접근 방식에 대해 먼저 이야기를 나누자. 빠른 코딩이 아닌 사려 깊음을 드러내라.
의견) 문제 해결의 첫 번째 단계는 문제의 이해이다. 문제를 제대로 이해하지 못하면 열심히 일해서 엉뚱한 결과를 내놓게 되는데, 의외로 우리 업계에서 흔히 볼 수 있는 빌런 유형이다. 그래서 면접관들이 혹시 지원자가 이런 유형의 개발자는 아닌지 극도로 경계한다는 것만 알아두자. 내 경우에는 일부러 문제가 조금 덜 정의된 과제를 줄 때도 있는데 지원자가 그 함정을 빠르게 알아차리는지도 평가한다. 불완전한 정의를 보고 아무 질문도 없이 코딩부터 시작하는 지원자는 당연히 감점의 대상이다.
3. 처음부터 끝까지 설명할 수 있는 프로젝트가 하나도 없다.
"백엔드 시스템 구축"이라고 말해놓고는 설계, 트레이드오프, 해결했던 실제 문제까지 아무 것도 자세히 설명하지 못한다면 적신호가 된다.
기억력을 시험하자는 것이 아니라, 오너십을 보여달라는 것이다.
정말 개발한 게 맞는가? 아니면 극히 일부만 기여했는가?
의견) 1번에서 썼던 말은 반복한다. 책임질 수 있는 말만 써두는 게 좋다. 면접 전에 냈던 이력서를 다시 확인해보자. 혹시 세부 사항이 기억나지 않는다면 빈 부분을 채울 수 있는 말도 준비해두는 게 좋다.
4. 이전 팀이나 관리자를 비난한다.
"내가 더 많은 일을 할 수 있었는데, 체계적이지 못한 팀이었다"
"더 나은 해결책을 찾으려고 했는데 팀 리드가 허락해주지 않았다"
설령 사실이라고 하더라도 지원자가 어려운 환경을 다루는 방법에 대해 의문이 들 수 밖에 없다.
솔직한 것은 좋지만, 비난처럼 들리지 않도록 주의하자.
의견) 이건 굳이 면접에만 해당하는 말은 아닌데, 다른 사람을 비난하는 사람은 아무도 좋아하지 않는다. 설령 대상이 비난받을만한 충분한 이유가 있다고 하더라도 '아마 나름의 사정이 있었겠지만'이라고 이해하는 모습이라도 보이면 낫다. 예를 들어, '더 나은 해결책을 제안한 적이 있는데, 아마 팀의 업무도 많았고 리소스가 넉넉하지 않아서 팀 리드 입장에서는 허락해주기 어려웠던 것 같다' 정도로 말할 수도 있다.
5. 팀 프로젝트에 "내"가 너무 많다.
팀 프로젝트였다면서 모든 문장이 "제가..."로 시작하면 마치 "나만 일했다"고 말하는 듯 들린다. 면접관들은 이를 금방 알아차린다.
6. 힌트나 제지 신호를 알아차리지 못한다.
가끔 지원자들을 부드럽게 원래 주제로 이끌거나, 작은 질문으로 방향을 잡아줄 때도 있다. 그런데 어떤 지원자들은 아랑곳하지 않고 계속 자기 얘기만 한다. 면접장의 분위기를 읽지 못한다면 그건 분명 문제가 될 수 있다. 특히 일이 빠르게 진행되는 팀에 지원한 경우라면 더욱 그렇다.
7. 근거 없는 미사여구가 이력서에 가득하다.
"지연 시간을 60% 줄였다"고 적었다면 어떻게 줄였는지 설명할 준비도 되어 있어야 한다. 그렇지 않으면 깊이 없는 링크드인 허세처럼 보일 뿐이다.
차라리 "X를 사용해서 API 호출을 최적화했고, 그 결과 로드 시간이 약 30% 줄어들었다"라고 쓰는 게 좋다.
있어 보이는 것보다 진실이 더 낫다.
8. 아무런 질문도 하지 않는다.
"질문하실 것 있을까요?"라고 물었을 때 "아니요, 괜찮습니다"라는 지원자들이 있는데, 이는 좋은 기회를 놓치는 것이다.
지원자도 회사를 면접보는 것이다. 호기심을 보여라. 팀에 대해 묻고, 기술이나 문화, 성공의 기준 등 뭐든 질문하라.
의견) 관심을 보이는 제일 좋은 방법은 질문이다. 팀에서는 어떤 일을 하는지 최근 발표했던 프로젝트를 진행하면서 어려운 점은 없었는지 등 묻기로 마음 먹으면 질문은 무궁무진하다. (설령 그게 사실이더라도) 굳이 높은 연봉에만 관심있다고 알릴 필요는 없다.
9. 무미건조하게 마무리한다.
어떤 지원자는 "아, 감사합니다"하고 끝 인사를 한다. 이렇게 끝내지 말자. 면접이 완벽하지 않게 흘러갔다 하더라도 좋은 분위기에서 끝내도록 하자.
"감사합니다. 오늘 대화 즐거웠고, 이런 팀에서 같이 일해보면 좋을 것 같습니다."
긍정적인 분위기는 중요하다.
10. 면접은 문제 풀이가 아니다.
면접에서는 지원자가 어떻게 사고하고, 어떻게 듣고, 어떻게 행동하는지 중요하다. 이러한 적신호를 피하면 완벽하지 않더라도 충분히 돋보일 수 있다.
완벽한 사람일 필요는 없다. 그저 함께 일하기에 정말 좋은 사람이면 된다.
의견) 코딩 테스트라 하더라도 문제를 대하는 자세, 질문의 내용, 어려운 문제를 접했을 때 해결하는 모습 등 이력서에서는 표현할 수 없는 굉장히 많은 것들이 면접장에서 평가된다. 내 경우에는 '긍정적인 밝은 에너지'와 '커뮤니케이션 능력'을 큰 장점으로 보고 채용을 결정한 적도 있다. '함께 일하기 좋은 사람'이 어떤 사람인지 생각해보자.