프로그라피의 5기 리크루팅이 끝났다.

올해 3월부터 7월까지 진행되었던 프로그라피 4기에 멘티로 지원했던 나는, 이번 5기에서는 운영진으로 함께하게 되었다.

그 이유를 3가지로 정리해보자면

첫 번째로 재미있어서, 두 번째론 내가 4기 활동을 하며 겪었던 시행착오를 다음 5기 멘티들에게 공유하고 싶어서, 세 번째로 단체가 돌아가는 것을 경험해보고 싶어서인 것 같다.

아쉬운 게 있다면 생각보다 시간을 많이 소모한다는 점인데, 원래 홍보 과정과 리크루팅 과정이 원래 가장 힘든 과정인 것도 있는데 특히 내가 고민이 많고 걱정도 많아서 그럴까, 관심을 가지고 지원해주신 분들이 모두 합격할 수 없는 게 아쉽다. 그냥 너무 깊게 고민하지 않고 해도 되는 건데, 내가 사서 더 고민하고 사서 더 걱정해서 그런 것이다.

비록 회사가 아닌 동아리 면접이지만, 면접 과정에서 면접관이 되어 느꼈던 점들을 소개하고자 한다. 취업을 위해 공부하고 있는 모든 개발자들 (특히 주니어 개발자들)에게 도움이 되기를 바라며

• 보편적인 면접관의 방식과 다를 수 있음을 미리 밝힙니다. 모든 면접관마다 각자 사고방식이 다른 점을 염두 해 주세요!

• 지원율과 관련한 민감할 수 있는 부분이 있어 모든 수치를 밝히지 못하는 점 양해 부탁드립니다.

1. 지원율

이번 프로그라피 5기는 4기에 비해 더 많은 분들이 지원해주셨고, 내가 속해있는 프론트(리액트) 팀의 경우 지난 기수보다 더 높은 실력을 가지신 분들이 지원을 많이 해주셨다.

프론트팀의 경우 서류를 지원해주신 분 대부분이 합격하셨고, 2차 면접 과정에서 hooks API로 투두리스트만들기 사전과제를 진행하며 합격자의 30% 정도가 과제를 자체적으로 포기하셔서 처음 지원자의 절반 정도를 대상으로 2차 면접을 진행했다.

2. 1차 서류 평가

자기소개서 항목은 총 6문항으로 아래와 같다.

1. 간단한 자기소개
2. 프로그라피에 지원하게 된 동기
3. 본인의 관심분야
4. 프로그라피에서 만들고 싶은 서비스
5. 스스로 만들어서 배포해 보았던 서비스, 혹은 스스로 진행했던 프로젝트들에 대해 서술
6. 위에서 표현하지 못한 자기 자신에 대하여

우선 4기에 내가 제출했던 자기소개서를 첨부한다.

반년전의 나는 지금보다 초조했고, 개발자 세상의 이방인같았다.

만일 이번에 내가 이 자기소개서를 평가했다면 이번 5기에서는 4기보다 조금 더 높은 개발실력을 기준으로 두었기때문에 아마 서류에서 탈락하지 않았을까.

2.1 이 자기소개서가 별로인 이유

조금 더 구체적으로 이야기하자면, 이 자기소개서는 개발자스럽지 않다. 자기소개서에서 어느 정도 개발 능력을 느낄 수 있어야 하는데 너무 추상적인 말들만 나열되어있다.

2.2 자소서를 다시 쓴다면

기본적으로 dry 한 자소서를 선호한다. 시간이 리소스이다. 개발 이외에도 기획력, 협업 능력, 마케팅과 브랜딩, 비즈니스에 관심이 있고 관련한 활동들을 해왔다는 점을 표현하기 위해 객관적인 지표 위주로 나열하되 너무 딱딱하지 않게 쓸 것이다. 이런 점이 개발 능력에 마이너스가 되지 않도록 개발 능력을 확실하게 드러낼 것이다. 부족한 부분은 확실하게 표현할 것이다. 예를 들면 개발 이외에 다른 영역에도 관심이 많아, 상대적으로 개발에 투자하는 절대시간이 다른 개발자들보다 적습니다. 하지만 일에 몰입도가 높아 결코 퍼포먼스가 낮지 않습니다.라고 작성할 것이다.

2.3 자기소개서가 꼭 필요할까?

5기에는 많은 분들이 열정을 가지고 자기소개서를 써주셨다. 사실 나는 자기소개서가 필요한지 의문을 가지고 있었는데, 우리가 사람을 뽑을 때 모두를 면접을 볼 수 없기 때문이고, 면접을 볼 때 그 사람의 정보가 필요하기 때문에 자기소개서는 필요하다.

1차에서 지원하신 분들 중에 일반적으로는 2.5~ 3배수를 면접을 보도록 하는 것이 좋은 것 같지만 우리는 자기소개서에 성의가 없는 분을 제외하면 모두 서류 합격을 드렸다. 즉, 운영진인 우리가 좀 더 발품을 팔기로 한 것이다.

면접은 주관이 들어가기에 객관적으로 수치화할 수 없지만 최대한 공정하게 탈락시키기 위해 4가지 항목별로 10점 만점에 3점, 3점, 3점, 1점으로 항목을 나누었고. 탁월하면 3점, 훌륭하면 2점, 일반적이면 1점으로 평가를 했고, 특이사항칸에 따로 필요한 정보를 기록하였다.

프로그라피 1차서류평가 모자이크.png

이런 과정을 한번 거치니, 눈여겨봐야 할 지원자는 사실 어느 정도 추려지게 된다. 모든 지원자들은 각자의 장점들이 있어 우열을 가리는 것이 어려운데, 이렇게 시트로 정리를 하고 나면 막연히 지원자들이 좋아 보였던 것이 조금 명확해진다.

누군가는 1차에 많이 뽑는 것은 희망고문이라고 말할지도 모른다. 하지만, 자소서에 드러나지 않는 우리가 못 본 점들이 있고, 또 중간에 지원을 철회하는 분이 계셔서 나는 많이 뽑는 게, 면접관의 체력만 괜찮다면 좋은 것 같다.

실제로, 내가 가장 높은 점수를 드렸던 분은 지원을 철회하셨고 1차 합격자 중 30% 정도가 지원을 철회하셨다. 알아서 포기하시는데 나 왜 마음 아파한 거지...

재미있는 점은 자기소개서에서 가장 높은 점수를 드렸던 4분 중에서 2분이 지원을 포기하셨다는 점이다.

3. 2차 면접 평가

사전과제는 기본적인 CRUD, 서버의 데이터를 받아오는 방법, 기본적인 스타일링 방법을 평가하기 위해 사골 과제인 투 두 리스트 만들기를 냈다. 이 정도는 해야 한다고 생각하면서도 어렵지 않을까? 하는 걱정이 있었다.

평가하며 불편했던 점은 두 가지인데, 지원자와 과제 매칭의 어려움 그리고 돌아가는 것을 다 클론 해서 실행해봐야 한다는 점의 어려움이다. 깃헙 아이디와 지원자의 이름이 달라 찾는 것이 어려워 다음엔 레포에 자신의 이름을 영문으로 넣는 것을 포함시키려고 하고, 프론트는 UX&UI가 중요하기 때문에 Readme에 이미지 파일 또는 gif 파일을 첨부하도록 할 생각이다. 물론 말하지 않아도 알아서 그렇게 하시는 분도 있다. 그런 분들은 눈이 더 가게 된다.

3.1 면접자들에게

3.1.1 면접은 주관적이다.

• 면접관은 직전 참가자의 모든 서류를 다 기억하지 않는다 (못한다)
• 직전에 봐야 하지만, 그러지 않는 사람들도 있다.
• 사전과제(포트폴리오)를 클론 해서 돌려보는 사람도 있지만 그러지 않는 사람도 있다.
• 공통질문을 정해놓는 경우도 있지만 즉석에서 궁금한 걸 물어보는 면접관도 있다.
• 옆에 면접관이 하는 질문 나도 잘 모르는데 ...

면접은 굉장히 운이 많이 좌우하는 요소이다. 최대한 객관적으로 하기 위해 노력했지만, 면접은 주관적이다. 그리고 결국은 마음이 가는 사람이 있는 것 같다. 그건 대체로 질문에 대한 답변에서 느껴지는 스마트함(매력) 때문이다. 은은한 건 빠르게 오진 않는다.

3.1.2 면접 시간은 처음 아니면 마지막을 택하라

지원자를 위한 나만의 팁을 소개한다. 면접 시간을 처음 아니면, 마지막을 택하는 것이 좋다.

처음 시간으로 선택하면 떨어지던 안 떨어지던 면접관들이 풀 컨디션이어서 세세한 피드백을 받을 수 있기 때문이다. 마지막을 택하는 이유는 역시 마지막이어서 지친 면접관들이 컨디션을 끌어올려서 면접을 진행하기 때문이고, 또 마지막이기 때문에 면접관에게 임팩트를 남기기가 좋기 때문이다. 마지막 면접 시간에 지원해주신 한 지원자분은 굉장히 밝은 인상이었고 답변도 굉장히 밝고 자신 있게 답변을 해주셨는데 그분의 긍정 에너지를 받아 나도 힘을 더 낼 수 있었던 것 같다.

3.1.3 레포를 제발 관리하자

자기소개서는 정말 열정 넘치게 써주셨는데, 기술적인 부분에 대한 언급이 없는 경우 깃헙레포에 들어갔는데 레포가 3개. 그런데 한 개는 생활코딩의 web1... 이런 지원자분들이 몇 분 계셨다.

정말 이렇게 자소서를 잘 쓰셨는데 레포 관리가 안 되어있으면 누구나 입개발자라고 오해하게 된다. 처음에 나는 이런 분들을 정말 오해했는데, 면접을 보면서 아 내가 잘못 생각했구나...라는 것을 알고 얼마나 다행이었는지 모른다.

3.2 면접관들에게

3.2.1 우리의 전략은

한 분 한 분 면접이 끝날 때마다 모두가 합의하여 순위를 매겼고 1~5 순위까지 스택을 쌓아 한번 면접이 끝날 때마다 순위를 재조정했다. 즉.. o(n*n)의 복잡도.... 인 건데, 이런 방식이 휘발되는 '느낌'이라는 주관을 그나마 객관적으로 측정할 수 있는 방식이라고 생각했다.

그럼에도 면접관은 면접자를 기억하지 못한다.

뒤로 가니까 그렇게 열정을 가지고 새끼 질문을 하고, 면접자분들의 가진 고유한 장점들을 찾아내려고 노력하던 나도 조금씩 지쳤고, 당이 떨어져서 콜라나 다과로 억지로 당을 보충하기도 했다. 재미있는 점은 한 분당 자소서를 5번도 넘게 읽고, 레포를 클론에서 실행해보고 코드도 확인해봤음에도 불구하고, 너무 많은 분을 면접을 보다 보니 면접이 끝난 뒤에는 면접자분들의 인상이 기억이 안 났다. 사진이라도 있었으면 좋았을 걸이라는 생각이 들 정도로 말이다.

3.2.2 질문은 균등하게 분배하자.

또한 면접을 보면서 우리는 나름 누가 어떤 질문을 물어볼지 정해놓았었는데, 그것보다는 각자 분야를 나누고 그 분야에 맞는 질문을 하는 것이 효율적이라는 것을 느꼈다. 궁금한 게 너무 많아 내가 질문을 굉장히 많이 했고, 그렇다면 공통질문을 조금 더 다른 면접관들에게 분배하는 게 좋았을 걸이라는 생각이 들었다. 물론 후반부에는 그래서 우리 프랖의 짱짱맨 디발자 S가 내 질문을 많이 가져가 주었다 ( S 고마워요! )

3.2.3 잘하면 뽑고 싶어지는 건 어쩔 수 없어

사전과제를 하지 않은 사람 중에 실력이 뛰어난 사람이 있는 경우 한번 고민하게 되었다. 사실 이 사람은 안 해도 잘하니까 뽑고 싶은데.. 하지만 그런 분들은 프로젝트에도 성실히 참여하지 않을 가능성이 높다고 판단되어 배제하는 것이 옳다고 생각했다. 그리고 이분은 결국 면접에 나오지 않으셨다.

자기소개서를 읽었을 때 나는 성실함이나 꾸준함이 느껴지는 분들에 높은 점수를 드렸다. 그런데 막상 면접에 들어가 보니 성실함보다는 질문에 스마트하게 답변해주신 분들에게 끌리는 나를 발견했다.

사실 이번에 면접 준비하며 선배 개발자들에게 면접을 볼 때 어떤 점을 가장 중요하게 생각하는지 여쭤보았는데, 내가 존경하는 C도 질문에 스마트하게 답변하는 사람을 뽑는다고 말씀해주셨다. 그 이유는, 30분짜리 면접에서는 협업 능력을 알 수 없기 때문이라고 해주셨는데 면접을 해보니 C가 왜 그렇게 말씀하신지 알 것 같다.

그리고 뻔한 말이지만, 이미 실력이 코드로 검증된 분에는 오히려 내가 그분에게 배우고 싶어서 질문을 하거나, 실력 관련해서가 아닌 결격사유가 없는지에 대한 간단한 몇 가지 질문만 하게 된다.

3.2.4 아쉬운 사람에게는 자꾸 더 물어보게 돼

처음 면접 때는 면접관들끼리 리허설까지 했음에도 불구하고, 시간관리를 잘 못했다. 그것은 지원자님의 개발 실력이 서비스를 만들기에는 아쉬웠기 때문이다. 그분을 탈락시켜야 하는 아쉬움 때문에 씁쓸해하는 나에게 우리 동아리의 MC K는 열심히 준비해서 다음에 지원하면 되지!라고 말해주었다. 생각해보면 그렇다. 그분은 진지하게 개발을 공부하시려는 분이었으니까 다음에 지원하시면 될 거다. 에이, 그러면 그렇게 아쉬워할 필요도 없었는데 괜히 마음 아파했다.

개발 실력이 아쉬운 경우에는 러닝 커브를 생각하게 된다. 그러면 개발에 투자할 수 있는 시간을 물어보게 되고, 열정을 물어보게 된다. 하지만 사실... 이런 질문이 나오게 되면 위험하다. 나 이외의 다른 면접관은 물어보지도 않았다.

아쉬운 사람이 지원하면 어떻게든 가능성을 찾아보려고 질문을 더하게 된다. 개인적으로 나는, 악이 있는 사람. 독한 사람. 개발을 꼭 해야만 하는 사람을 좋아한다. 그건 어쩌면 과거의 또는 지금의 나 역시도 그런 마음이 있기 때문인 것 같다. 하지만 면접이 끝나고.. 왜 이렇게 질문을 많이 하고 오래 하냐고 한소리를 들었다. 면접 시간 컨트롤은 매우 중요하다. 면접관인 우리가 4시간 넘게 면접을 봐야 하기 때문이다. 면접관이 컨디션 관리가 안 되면 공평하지 못하다.

3.2.5 질문을 많이 했던 이유

1. 사람을 알고 싶다.

내가 질문을 많이 했던 이유는, 사전과제도 완료해주시고 면접까지 오신즉 우리 프로그라피를 1순위로 면접을 보러 와주신 분들은 과연 어떤 분들일지 알고 싶었기 때문이다.

그리고 그분들이 어떤 경로로 개발자의 길에 들어오게 되셨는지 알고 싶었기 때문이다.

나는 사람마다 고유한 색이 있다고 믿는 사람인데 그분들의 색을 느끼고 또 배우고 그 색이 얼마나 진한지를 보고 싶었던 것 같다.

2. 정답이 없는 질문에 대응하는 방법

또 우리가 냈던 질문이 사실 정답이 없는 질문들이었기에 나 역시 이 답을 알고 싶었기 때문이다. 예를 들면 이런 거, 프로젝트 할 때 내가 너무 마음에 안 드는 아이디어가 있다면 어떻게 해야 할까요?

그런데 면접자분들께서 정말 멋진 답변을 많이 해주셨다. 그래서 면접을 보면서 내가 더 많이 배웠다. 주옥같은 답변을 해주셔서 면접을 보면서 평가하기 위한 기록이 아닌 정말 좋은 말씀이어서 나도 그걸 잊지 않고 싶어서 기록하게 되었다.

3.2.6 누구를 떨어트려야 할까

처음에는 너무 많은 분이 지원해주셔서, 우리가 조금만 팁을 드리면 빠르게 성장하실 분들이 떨어지면 어쩌나라는 걱정이 있었다. 사실은 혼자서도 잘하는 사람은 프로그라피가 아니어도 프로젝트를 할 사람들을 만날 수 있지 않나? 실력이 심사에 한 축이다 보니 인성과 성격에 모두 훌륭하신 분이 지원해주신 경우에는 논리상 실력이 뛰어난 분을 뽑을 수밖에 없기 때문이다.

그런데 다행히, 기존에 실력이 뛰어나신 분들은 지원을 철회하시거나, 면접관 3명 모두가 느꼈던 면접에 어울리지 않는 답변을 해주셔서 뽑을 수가 없었다.

그리고, 프로젝트를 진행하시기에 기본적으로 필요한 JS나 리액트에 대한 최소 마지노선을 넘지 못한 분들이 계셔서 뽑을 수가 없었다.

이런 모든 고민을 포스팅하는 것은 두려운 일이다. 하지만, 그럼에도 불구하고 더 많은 사람에게 도움이 되었으면 하는 마음에 이렇게 포스팅을 한다. 다음에는 면접관을 하고 싶지 않다. 하지만 한다면. 더 독하게 해야지. 그래야 공정하니까.

4. 마무리하며

면접자들에게

면접관이 이렇게 많은 걸 고민한다니, 이렇게 많은 다른 지원자가 있다니!라고 생각하면 뭐 이렇게 고민해야 할 게 많아... 면접 지원하는 게 너무 어려울 것 같다.

하지만 일단 시작하자. 좋아한다면 지원해보자. 누군가 면접은 소개팅이라고 했다. 맞다. 걱정만 해서는 아무것도 못한다. 그러니 일단 시작해야 한다. 하지만 쉽지 않을지도 모른다. 잘나가는 모 스타트업은 탈락자가 1년 이내로 재지원할 경우 이력서를 읽지 않는다고 한다. 속상하지만 스타트업은 바쁘다. 잘해보고 싶다면, 최선을 다해야 할 것이다.

면접관들에게

누군가를 떨어트려야 하는 것에 너무 속상해하지 말자. 여기서 못 만난다고 해도 다음이 있고, 그분들은 계속 개발을 하실 거니까.

내가 닮고 싶은 개발자님은 블로그를 안 하신다. 그건 아마도 정말 도움이 되는 글을 쓰고 싶어져서 이 지 않을까. 글을 쓸 때 품이 너무 많이 들면 좋아서 쓰는 글이 오히려 자신을 힘들게 만든다. 그분이 쓰신 마지막 멘트를 오마주 하며 글을 마무리한다.

글이 정성스럽지 못하더라도 누군가에게 도움이 되길 바라고, 또 누군가는 프로그라피에서 함께 하길 바라는 마음으로.