서류와 면접 탈락의 고배를 마시며

나는 내가 남들과는 다른, 특별한 사람인줄 알았다. 아니, 그렇게 생각하고 싶었던 것 같다. 서류와 면접에서 탈락이라는 고배를 마시기 전까지는 말이다. 이번 글은 내가 왜 서류와 면접에서 탈락했는지 요인을 분석하고, 더 나은 내가 되기 위해 어떻게 해야 하는지를 중점으로 이야기 해볼 예정이다.

서류와 면접심사에서의 탈락

나는 지금까지 총 4곳에 서류를 넣어서 2번의 서류 불합격, 2번의 서류 합격과 면접 불합격을 통보받았다. 한 곳을 제외하면 모두 각자만의 IT 서비스를 메인으로 운영하는 회사였다. 내가 되도록이면 흔히 네카쿠라배당토라고 불리는 회사에 서류를 넣은 이유는 다음과 같다.

본인은 주변 사람이 달라지면 스스로도 그에 맞게 달라진다고 굳게 믿는다. 그렇기에 업계 최고의 분들과 함께 한다면 나도 그렇게 변할 것이다.
지금까지 프로젝트라고 한다면 작게는 몇명, 크게는 수천명이 사용하는 서비스를 사실상 혼자 개발해왔다. 그렇기에 수천만명이 사용하는 서비스를 함께 개발하는 경험을 쌓고 싶었다.

그렇기에 내게 사실상 워라밸을 따지는 것은 무의미했고, 간단하게 말해 대기업의 업무 환경과 의사결정 구조을 체험하면서 주니어/시니어 개발자분들과 함께 성장하는 것이 중요하다고 생각했다. 그렇기에 크게 내 스택과 엄청 어긋나는 것만 아니라면 그런 기업에 지원을 하게 된 것이었다. 하지만 최종적으로는 지금까지 넣은 모든 곳에 탈락을 통보받게 되었다.

합격과 탈락의 이유

그나마 다행이라고 생각하는 것은 나름 4곳 중 2곳에 서류는 합격을 했다는 것이다. 만약 4곳 모두 서류부터 떨어졌다면 정말 절망적이었을 것이다. 그러면 합격했다면 왜, 탈락했다면 왜 탈락했는지 분석해보도록 하자.

서류 합격

나는 단순히 프로젝트만 진행한 케이스는 아니고, 외주로 시작한 프로젝트에서 계약직으로 약 10개월간 실제로 사용자들이 사용하는 제품을 개발한 경험이 있다. 확실히 토이 프로젝트 선에서 그치는 것이 아니라 실사용자가 있는 프로덕트를 개발했다는 것 자체는 매력적일 요소일 것이다.
나는 문제 해결이라는 목표를 위해서 가리지 않고 모든 액션을 취한다. 이전 직장에서 게임 개발을 위해 게임 기획/디자인/개발까지 모든 과정을 경험한 적이 있다. 이 부분을 특정 기업에서는 프로덕트 엔지니어링이라는 관점에서 선호할 수 있다고 생각한다.
타 이력서 대비 조금은 유니크한 전략을 취했다. 나는 문제 해결이라는 것을 주제로 개발 외적인 곳에서 수상한 경험이 있고 이를 적극적으로 반영했다. 내가 진짜 문제 해결에 진심인 사람이라는 것을 보여줄 수 있다는 것이지 않을까 생각한다.

사실 프론트엔드라는 직무에서 으레 필요로 하는 것이 내 github나 이력서에서 잘 표현되지 않았음에도 서류에 붙을 수 있는 이유는 위와 같은 이유들 덕분이지 않을까 생각한다. 그렇다면 서류, 그리고 면접에서 탈락한 이유도 돌아봐야 할 것이다.

서류 탈락

특정 회사에서는 내가 지금까지 쌓아온 경험이 전혀 상관이 없는 도메인인 경우일 수도 있다. IT라는 넓은 바운더리를 함께 공유한다고 하더라도, 해당 회사의 도메인이 금융권이라면 아무래도 관련 전공자가 더욱 적합할 수 있다.
내 이력서에는 보통 프론트엔드 개발자라면 보여줄 수 있는 프로젝트가 그렇게 많지는 않았다. 예를 들어 모집 공고의 필수 역량이 리액트를 잘 다루는 사람이라면, 깃허브에서 리액트 관련 프로젝트를 까보며 숙련도를 체크할 수 있을 것이다. 그러나 나는 리액트로 만든 대부분의 프로젝트가 깃허브 상에서 잘 아카이빙된 상태도 아니였으며, private repo로 되어 있는 상태가 많았다.
이력서나 포트폴리오가 아닌, 자기소개서 문항에서의 내용이 회사에서 원하는 것이 아닐 수 있다. 이 내용은 첫 번째 서류 탈락 이유와 비슷하므로 이정도로 마치겠다.

면접 탈락

사실상 가장 하이라이트인 부분이 아닐까 싶다. 지금까지 면접에서 질문을 했던 내용을 복기하면서 정리해보겠다.

면접에서 나온 기술적인 질문에 대해 잘 대답하지 못했던 부분이 있다. 첫 번째 면접에서는 진짜 말 그대로 준비를 거의 안했다. 그렇다보니 자바스크립트의 클로저라는 내용에 대해서 아예 답변하지 못했다. 두 번째 면접에서는 이전 면접에서의 경험을 바탕으로 나름 준비를 한 후 아는 선에서는 답변을 했지만, 선언형 프로그래밍이라는 개념에 대해 얘기하지 못했다. 특정 언어와 프레임워크에 대한 내용뿐만 아니라 프로그래밍이라는 본질적인 개념에 대한 이해가 부족했던 것 같다.
간단명료하게 답변하지 못했다. 면접관이 질문을 하면 주장-이유-사례-결론으로 이어지는 틀은 지키되, 너무 내용이 늘어지지 않도록 하는 것이 필요했다. 하지만 나는 나름 틀은 지켰다고 생각하지만 질문의 의도에 대한 내용만 깔끔하게 답하지 못하고, 필요없는 주변부의 내용까지 덧붙여 답변하였다.
위 내용과 이어지는 부분인데, 질문의 핵심을 잘 파악하지 못했다. 어떤 면접에서는 결국 A라는 것을 아는지를 질문하는 내용에서 계속 A-1, A-2, 혹은 B라는 내용을 답변해서 면접관이 더욱 구체적으로 설명해준 적이 있다.
그리고 내가 함께 일하고 싶은 사람으로 비쳐졌는가? 라고 질문한다면 아니었던 것 같다. 지금까지 나는 나만의 개인적인 목표가 있고 회사에 다니는 것을 수단으로써 여겼다. 즉 “나중에는 결국 내 목표를 위해 나갈건데, 그때 동안 너희 회사에서 필요한 경험 좀 하고 갈게”라는 느낌으로 답변을 이어나갔던 것 같다. 내가 회사에 무엇을 제공해줄 수 있고, 회사가 나에게 제공해줄 수 있는 것을 셈하는 것도 중요하지만 결국 일은 혼자하는 것이 아니다. 같이 하는 것이다.

서류와 면접에 합격하기 위해서는?

위 내용을 토대로 내가 고민해볼 것, 혹은 고민해서 바꾼 부분을 정리해보겠다.

Q. 일이라는 행위는 무엇인가?

내게 있어서 일, 노동이라는 행위를 정의내리는 것이 필요할 것 같다. 내 목표와 꿈이 다른 사람에게 도움이 되는 것임은 분명하다. 이를 이루기 위해서는 일이라는 행위가 필요한 것도 분명하다. 그렇다면 이 일이라는 행위, 개념을 어떻게 받아들여야 할지 고민해야 할 것 같다. 이에 대해 고민하다보면 내가 함께 일하고 싶은 팀원이 되기 위해서는 어떻게 바뀌어야 할지도 명확해질 것 같다.

Q. 좋은 개발자가 되기 위해 갖추어야 하는 것은 무엇인가?

이는 거시적으로, 미시적으로도 볼 수 있을 것 같기도 하다. 거시적으로는 내가 개발자라는 직무에 걸맞는 사람이 되는 것을 의미하는 것이라면, 미시적으로는 프론트엔드 직무에 내가 어울리는 사람이 되는 것을 의미할 수 있다. 즉 개발자로서의 역량과 프론트엔드 엔지니어로서의 역량을 갖추기 위해 필요한 내용을 한번 더 떠올려야 할 것 같다.

Q. 정말로 문제 해결을 좋아하는 사람이 되기 위해서는?

내가 지금 주 테마로 가지고 가는 문제 해결이라는 단어가 조금 더 효력을 발휘하기 위해서는 어떡할지에 대해서도 고민해보아야 할 것 같다. 문제 해결이라는 내용을 개발적인 관점에서 보자면, 현재 존재하는 문제를 빠르게 개발로 만들어 내는 것일 수도 있고, 내가 사용하는 특정 프레임워크나 라이브러리에 지원하지 않는 내용을 만들어 기여하는 것일 수도 있다. 또는 알고리즘을 학습해 다양한 문제를 해결하는 것일 수도 있으므로, 다양한 문제 해결을 적극적으로 해보아야겠다.