기업은 도대체 나의 어떤 점을 보고 채용을 진행할까?
안녕하세요, 현재 스타트업에서 프론트엔드 개발자로 일하고 있는 손지민입니다.
코로나 사태로 인하여 취업 시장도 많이 위축되었습니다. 이러한 위축된 취업 시장에서도 많은 개발자를 희망하시는 분들께서 스타트업뿐만 아니라 중소기업 및 대기업 등 많은 기업에 지원을 하고 있습니다. 실제로 기업에서 인사를 담당해보고 면접까지 본 사람으로서 어떠한 절차로 돌아가는지 써보고자 합니다.
물론, 저의 주관적인 부분일 수도 있지만 너그럽게 봐주시길 부탁드리겠습니다 :)
현재도 한 기업에서 인사를 담당하면서 프론트엔드부터 디자이너 그리고 기획자까지 약 150명 이상 스타트업과 기업에 필요한 모든 직군의 지원서를 검토하였습니다. 예전엔 비즈니스 성향이 강한 이력서가 대부분이었지만, 최근 들어 Notion(노션)으로 이력서를 작성하는 경우가 많이 나오고 있습니다.
하지만, 기업에서는 여러분이 열심히 시간을 들여서 만든 이력서를 제대로 보지 않습니다.
기업에서는 채용 후 바로 투입되어 서비스를 유지할 수 있는 사람을 원하지, 이력서를 잘 작성하는 사람을 원하지 않습니다. 아무리 여러분이 시간을 들여서 이력서에 MBTI를 올리고, 자신이 생각한 모토를 올려도 기업에서는 그런 것들을 절대로 보지 않습니다.
말을 많이 한다는 것과 잘한다는 것은 별개이다. - 소포클레스
기업에서 집중적으로 보는 것은 '바로 투입될 수 있는 사람'을 찾기 위해서 여러분의 포트폴리오를 보게 될 것입니다. 어떤 프로젝트를 진행하였고, 어떤 식으로 협업하였고, 문제가 발생하였다면 어떤 식으로 해결하였는지. 이러한 것들을 여러분 포트폴리오를 통해서 기업은 여러분을 알아가게 됩니다.
실제로 포트폴리오를 보면 '마켓 컬리 클론 코딩', '핀터레스트 클론 코딩' 등 여러 가지 클론 코딩이 존재하고 있습니다. 하지만, 기업에서 원하는 것은 클론 코딩이 아닙니다. 클론 코딩을 하는 과정은 결국 정해져 있습니다. 프론트엔드 개발자에서는 클론 하는 사이트와 동일한 UI를 제작하고, 회원가입이나 로그인 그리고 리스트를 로딩하는 그러한 과정들을 거치며, 백엔드 개발자에서는 JWT 사용해보고, CRUD를 만들어보고, 스키마도 설계를 해보는 여러 가지 과정들이 정해져 있습니다. 보통 클론 코딩에서는 이 과정에서 조금 더 추가되는 정도라고 보고 있습니다.
독창성의 장점은 참신이 아니라 성실이다. 믿는 사람은 독창적인 인간이다.
기업에서 여러분을 가장 많이 보는 것은 '기획 능력'입니다. 물론 대기업과 여러 구조가 잡힌 스타트업에서는 이러한 것들을 넘길 수도 있으나, 현재 빠르게 개발을 진행해야 하고 출시해야 하는 스타트업에서는 자사의 서비스를 빠르게 이해하고, 개발자로서 더 많은 것들을 보여주기를 원하고 있습니다. 그러하여, 직접 기획도 해보고, 디자인도 해보고, 개발까지 진행을 한 개발자를 원하는 경우가 많습니다.
한 가지 클론 코딩을 지양해야 하는 이유를 약 150명의 지원자의 이력서를 본 경험으로 주관적으로 말씀을 드리면, 지원자 중 40%가 클론 코딩을 진행하였는데 그 클론 코딩을 한 내용이 거의 흡사하였습니다.
기업 입장에서는 클론 코딩을 해도 예전에 검토한 지원서들이 있기 때문에 기대를 하지 않습니다.
대학 입학을 위한 자소서를 작성할 때도 비슷합니다. 수많은 지원서 중에 입학사정관 눈에 띄지 않으면 안 된다고 생각됩니다. 이 말은 즉, 특별한 것들이 있지 않으면 다른 지원서와 다를 게 없다는 말입니다.
남들과 동일하게 클론 코딩을 한다면 이력서를 검토하는 면접관도 실망하게 될 것입니다.
기업에서는 이력서에 적힌 프로젝트를 보고 지원자가 어떠한 활동을 하였는지 파악합니다. 클론 코딩 그리고 여러 가지 프로젝트가 많은 지원서가 있지만, 실제로 깃헙을 보았을 땐 프로젝트는 1 커밋으로 커밋되었고, 성실함을 볼 수 있는 커밋 조차 없는 경우가 많습니다.
성실하지 못한 사람은 위대한 것들을 생산할 수 없다.
기업에서는 지원자를 파악할 때 기술 스택, 프로젝트 코드, 깃헙 등 다방면에서 지원자를 파악하기 위해 노력을 하고 있습니다. 하지만 약 150개 지원서 및 면접을 진행하면서 실제로 사용하는 기술 스택이 기업과 다른 경우도 있으며, 프로젝트를 진행한 코드는 기술 스택과 다르거나, 환경 세팅만 해둔 상태가 많았습니다.
또한, 커밋 수가 많다고 좋은 것은 아니지만 자신의 블로그(Github.io)에서 글을 올리거나 레이아웃을 수정하는 등 불필요한 커밋은 아니지만, 기업 입장에서는 프로젝트 코드는 없고 블로그만 꾸준히 올린 커밋만 있어 지원자를 파악하기 어렵습니다.
최소한, 개발자가 되려는 분들은 깃헙에서 프로젝트 관리와 커밋 관리 등 기업에서 지원자를 알 수 있을 정도를 보여주셔야 합니다. 보통 프라이빗으로 작업을 하는 경우가 있습니다. 하지만, 이런 경우에는 깃헙에서는 여러분의 코드를 볼 수 없고, 프로젝트를 알기 어렵습니다.
지원서를 보면 다 같이 공통적인 부분이 존재합니다. '유저 로그인 회원가입 시 JWT 토큰 관리', '페이지 네이션 구현', 'Redux에서 토스트 창 구현' 이런 3가지 부분을 포함한 여러 가지가 공통적입니다. 무엇을 관리하고, 구현한 것까진 기업에선 궁금할 수 있습니다. 하지만, 기업에서는 그다음을 궁금해합니다.
노력 없이 쓰인 글은 대개 감흥 없이 읽힌다.
분명 구현을 할 때 기술적인 부채가 생기거나, 협업 과정에서 큰 어려움이 생길 것입니다. 이런 부분은 어떠한 기업을 가도 기술적인 부채와 협업 과정에서 생기는 소통의 부재는 필연적으로 생길 수밖에 없습니다. 그렇기에 기업에서는 프로젝트 과정에서 지원자가 구현이라고 작성한 부분을 어떤 식으로 구현을 하였는지, 환경에 따라서 어떠한 문제점이 있었는데 이런 문제점을 어떤 방식으로 해결하였는지, 팀 프로젝트로 진행하였다면 서로 소통은 어떤 방식으로 진행하였는지, 소통의 부재로 인해 불화가 일어났을 때 어떤 식으로 해결하였는지를 기업에서는 원하고 있습니다.
이러한 문제는 단순 구현만 했을 때는 생각할 수 없는 부분입니다. 기술적인 부채가 생겼을 때 스스로 구글과 스택오버플로우 등 여러 가지 매체를 통해서 기술적인 부채를 해결하고, 서로 협력하여 소통의 부재를 해결하는 것에 있어서 기업은 단순 구현보단 생각을 하면서 구현하는 것을 좋아합니다.
개발자를 희망하는 취준생을 위해 약 150개 지원서를 검토하면서 이 부분은 고민하고 수용하면 좋겠다.라는 부분을 적어보았습니다. 제 주관적으로 작성하였으나, 실제로 저도 공감하고 있는 부분이며 대기업과 중소기업 등 체계적으로 운용되는 곳에서는 일어나지 않겠지만, 체계를 직접 만들어 나가야 하는 스타트업에서는 일어날 수도 있다는 생각에 작성하였습니다.
실제로 많은 지원서를 검토하면서 이 사람은 조금만 노력을 더 했다면 함께 핏을 맞추고 할 수 있을 것이라는 생각을 많이 하였습니다. 하지만, 조금 강력하게 말하면 회사는 학교나 학원이 아닙니다. 바쁘게 달리는 자동차를 만들고 있는 곳입니다. 기초를 더불어 실제로 기획을 하고 디자인이 나왔을 때 구현할 능력이 없으면 기업에서는 여러분을 채용하지 않을 것입니다.
부디 여러분들이 더 많은 것을 경험하고 더 많은 것을 할 수 있기를 응원합니다.
마지막으로, 이 글을 보시고 불편하시다면 너그럽게 용서해주시길 부탁드립니다.
감사합니다.