brunch

매거진 플렉스웹

You can make anything
by writing

C.S.Lewis

by 한상훈 Jan 10. 2022

신입 개발자에게 기대하는 것

플렉스웹이 원하는 개발자 인재상

안녕하세요 플렉스웹 대표 한상훈입니다. 작년부터 올해까지 약 430명의 지원자 이력서를 보고, 그 중 100명 가까운 분들과 면접을 봤습니다. 면접을 볼 때면 준비가 잘된 지원자 분들도 계셨지만 어떤걸 준비할지 몰라 이것저것 준비하시다보니 제대로 답변을 못하시는 경우도 많았습니다. 이번 글에선 저희 회사가 주로 어떤 것을 물어보는지와 어떤 인재를 원하는지에 대한 부분을 글로 담아봤습니다.


1. 학력과 학과

 당연한 이야기지만 학력이 좋고, 학과가 프로그래밍과 가까울수록 좋습니다. 그러나 비전공자라고 해서 색안경을 끼고 탈락시키진 않습니다. 현재 저희 회사 개발자의 절반 이상은 비전공자 출신이고, 대표인 저부터 비전공자 출신이기 때문입니다. 저희가 서류 지원 단계에서 유의미하게 점수를 낮게 보는 것은 한가지입니다. 컴퓨터공학을 전공했으나 학점이 낮은 분은 좋지 않게 평가합니다.



2. 포트폴리오

단순히 어떤 삶을 살아왔는지만 설명된 이력서로는 서류 전형 통과는 불가능합니다. 특히 저희는 웹 개발, 서버 개발자를 뽑기 때문에 깃허브 또는 자신의 프로젝트를 설명할 수 있는 포트폴리오 사이트나 문서가 필요합니다. 이 과정에서 많은 신입 개발자 분들이 착각하시는게 있는 것 같습니다. 바로 클론 코딩 프로젝트를 자기 프로젝트로 속이는 경우입니다.


아무래도 어떻게 해서든 취직을 해야하는 구직자 입장에서는 클론 코딩 프로젝트도 내가 만든 것처럼 면접관을 속여 취업하는게 좋을 수도 있습니다. 하지만 이력서를 수십, 수백장씩 보다보면 똑같은 코드, 클론 코딩 프로젝트들 다 보입니다. 그 중에서도 최악은 학원에서 한 프로젝트를 수정 하나 없이 그대로 포트폴리오에 올리는 경우입니다. 전체 지원자의 약 5~10% 정도는 동일한 템플릿, 동일한 프로젝트를 사용해 자신의 포트폴리오를 구성합니다. 개발자라면 자신이 쓴 코드가 있어야 하는데 학원에서 따라 쓰라고 한 코드를 그대로 써서 이력서에 올리면 그것을 보고 '이 지원자는 꼭 뽑아야겠다!' 라는 마음이 들 수가 있을까요.


저희 회사에 지난 7개월동안 거의 5번 넘게 지원하신 분이 있습니다. 실명을 언급할 수는 없지만 이력서가 올 때마다 바뀐게 있나 확인해봐도 아무런 변화가 없습니다. 포트폴리오도 7개월전 학원에서 한 프로젝트 그대로, 깃허브도 그대로, 바뀐 경력도 없이 이력서만 계속 넣는 겁니다. 현명한 취준생 개발자 분들이라면 포트폴리오를 만드시면서 쉬운 길을 택하지 마시고, 어렵더라도 공부한다는 마음으로 본인이 원하는 기능이나 페이지를 추가해서 만들어보시길 추천드립니다. 만약 포트폴리오를 만드는 것도 정 어려워 학원에서 가르쳐준 그대로 밖에 못하신다면 그보다 힘든 회사 생활은 어떻게 하실 수 있을지 생각해보셨으면 좋겠습니다.



3. 깃허브

프론트엔드 개발자 분들 중 깃허브를 자신의 포트폴리오, 이력서 대체용도로 올리시는 분들이 간혹 있습니다. 자신의 코드를 보여주는 건 좋습니다. 다만 자신의 코드로 이력서를 대체하시려면 깃허브가 면접관이 볼 수 있게 구성해주셔야 합니다. 특히 면접관에게 보여줄 프로젝트라면 README.md 파일에 해당 프로젝트에 대해 간단하게라도 설명을 넣어주시면 좋습니다. 더불어 코드도 줄바꿈 auto formating 사용해서 깔끔하게 푸시해서 등록해두시면 좋습니다. 가끔 줄바꿈도 엉망이고, 띄어쓰기도 안 맞는 코드를 보곤 하는데 이력서를 보는 입장에서 '이 분은 오토 포맷팅을 모르시는구나'로 생각할 수 밖에 없으므로 좋은 점수를 드릴 수 없습니다.



4. 웹 개발자

이제 분야별로 설명해보겠습니다. 먼저 저희가 가장 많이 뽑고 있는 웹 개발자(프론트, 백엔드 모두 포함)는 다음의 질문을 받습니다.


브라우저 동작 방식

ES6 문법과 ES5 문법의 차이점

기본 데이터 형태의 프로토타입 메서드

호이스팅 및 스코프 개념

HTTP 통신 메서드 및 상태코드


위의 항목들을 모두 완벽하게 답변하실 필요는 없습니다. 저희는 개발자끼리 기본적인 소통을 할 수 있는 수준을 기대합니다. 신입 웹 개발자가 Proxy 패턴, 클래스 사용법 등을 모른다고 해서 문제될건 없습니다. 하지만 신입 웹 개발자가 GET 요청을 언제 사용하는지 모르면 뽑지 않습니다. 또는 GET 요청이 무엇인지 모르거나 POST 요청의 데이터가 어디에 담기는지 모른다면 뽑을 수 없습니다. 일을 하는데 최소한의 조건이라고 보이는 용어와 개념을 질문합니다.


위의 링크는 제가 과거에 정리한 GET과 POST에 대한 글입니다. 글에서는 스팩 문서를 기반으로 차이점을 설명하고 있지만 신입에게 이정도 지식을 기대하지는 않습니다. 최소한의 동작 방식과 더불어 실제 코드를 얼마나 써봤는지 보기 위한 질문에 가깝습니다. 이를 확인하기 위해서 실제 개발을 할 때 쓸 수 밖에 없는 여러 함수들과 상황들에 대한 질문을 합니다. 가령 개발자들이 필수적으로 만들어보는 To do list 앱을 만들기 위해서는 목록을 다루기 때문에 배열과 관련된 함수를 필연적으로 쓸 수 밖에 없습니다. 배열과 관련된 아주 기초적인 함수도 설명하지 못한다면 저희는 해당 지원자가 'To do list와 같은 간단한 프로젝트를 만들 때도 스택오버플로우의 도움을 받아야 하겠구나.'라고 판단할 수 밖에 없습니다.




5. 리액트

리액트 개발자분들이라면 반드시 알아야 하는 몇가지를 물어봅니다. 가령 useState와 useEffect와 같은 기본이 되는 훅을 질문합니다. 각 파라미터가 어떤 의미를 가지는지는 인터넷에 자세히 설명이 된 글을 쉽게 찾을 수 있습니다. 리액트의 아주 기본적인 질문임에도 이 질문도 제대로 통과하지 못하는 지원자 분들이 많은걸 보고 개인적으로 아쉬웠습니다.


리액트를 비롯해 프론트엔드 개발자라면 상태관리라는 말을 완벽하게는 모르더라도 동작 방식을 설명하고 공부해야 합니다. 대표적인 상태관리 도구부터 왜 상태관리 도구를 사용하는지, 어떤 식으로 동작하는지 정도는 알아야 한다고 봅니다.


이를 연습하는 방법도 간단합니다. 가령 To do list를 기존에 useState를 통해 만들어봤다면 면접을 준비하시면서 리덕스나 리코일 또는 리덕스 사가 등을 사용해 제작해보는 것입니다. 이해가 어려우면 다른 사람이 쓴 코드를 복붙하지 말고 그대로 카피해서 쓰면서 익히시면 그렇게 어려운 개념은 아니라 생각합니다.



6. 뷰

뷰에서 저희가 중요하게 여기는 부분은 각 기능을 얼마나 정확하게 이해하고 있는지입니다. 디렉티브, 믹스인, 슬롯, this 컨텍스트, 라우터 개념 등 개발에 필요한 전반적인 내용을 질문하며, watch와 computed의 사용법의 차이라던지 라이프사이클 등에 대한 내용을 더 물어보기도 합니다. 뷰는 리액트와 다르게 vuex 하나로 통해 상태관리를 하다보니 FLUX 패턴에 대해서 좀 더 깊게 질문하는 편입니다.



7. 조금 깊은 질문

저희는 동일한 신입이라고 해도 실력에 차이에 따라 다른 급여를 받아야 한다고 생각합니다. 그래서 지원자 분들이 생각보다 실력이 뛰어난 경우에는 더 깊은 질문을 드리면서 깊이가 어느정도 있는지 판단하려 노력합니다. 대표적인 예시는 Authorization, Typescript, 그리고 대표적인 라이브러리에 대한 사용 경험이나 이해 정도를 측정합니다.


그 뿐 아니라 지원자 분이 Firebase나 Docker 등을 경험해보셨다면 해당 기술에 대해 어디까지 진행해봤는지, 어떤 이슈를 마주했는지, 기술의 장단점도 자유롭게 이야기하는 편입니다. 이 부분들은 지원자 분들이 설명이 옳고 그름을 떠나 얼마나 깊게 생각하고, 프로젝트를 대했는지 판별하는 부분입니다.


저희는 처음부터 완벽한 개발자가 없고, 특히 신입이라면 잘못된 지식도 많이 생길 수 밖에 없다고 생각합니다. 그렇기 때문에 문제를 마주했을 때 어떠한 방식으로 해결했는지에 대한 과정을 듣고 싶은데 이것을 적극적으로 설명하고, 고민에 대한 해결책까지 발견했다면 큰 가산점을 드리고 있습니다.



8. 퍼블리싱

프론트엔드 개발자는 기본적인 HTML 엘리먼트에 대한 이해 및 CSS 이해도가 필요합니다. 이를 검증하는 질문을 몇가지 꼭 내는 편인데 대부분 프로젝트를 본인 힘으로 진행해보면 마주하는 이슈들입니다. 저희는 아직까지 항상 하나 또는 두 개의 질문만으로 퍼블리싱 실력을 판단할 수 있다고 보고 있는데 언제나 그렇지만 기본적이고, 중요한 것을 물어봅니다.


가령 display: block과 inline의 차이점과 같은 질문입니다. css의 기본이 되는 속성이 position과 display인데 이것에 대해 명확하게 이해하지 못하고 있으면 이 사람은 제대로된 레이아웃을 그릴 수 없다는 결론에 이르게 됩니다. 이와 같이 퍼블리싱에서 가장 중요하고 기본이 되는 질문이 뭘까 생각해보시면 저희 회사 면접에 큰 도움이 되실겁니다.



8. 서버 개발자

서버 개발자는 프론트엔드 분야와 다르게 서버 자체에 대한 이해 및 리눅스에 대한 이해, 마지막으로 DB에 대한 이해를 폭넓게 질문합니다. 대부분 서버 개발자 분들은 신입 보다는 짧은 경력이 있으신 분들이 많았는데 놀랍게도 대부분 아주 간단한 쿼리와 라우트로 구성된 서버만 개발해보신 분들이 많고, 서버 프레임워크별 특장점이나 주의점에 대해서는 모르시는 경우가 많았습니다.


제가 이것에 대한 질문을 하는 것은 본인이 사용하는 프레임워크에 대한 관심을 알고 싶기 때문입니다. 본인이 택한 기술에 대해 관심이 없다면 이 기술의 장단점을 비롯해 작동방식도 제대로 인지하지 못하곤 합니다. 어쩌면 5~10년 가까이 이 기술로 전문성을 쌓아야할 사람이 이 기술의 작동방식도 모른다면 제가 판단하기에 학원에서 시켜서 공부했거나 큰 관심 없이 시작한 일처럼 느껴집니다. 개발을 자신의 업으로 삼은 사람이라면 저는 선택한 기술에 대한 기본적인 개념은 있어야 한다고 생각하고, 설령 개념이 약하다면 코드라도 많이 써봐야 한다고 생각합니다.


코드를 써봤는지 안 써봤는지는 기본적인 메서드 동작방식만 물어봐도 보통 실력을 판단할 수 있습니다. Express을 비롯해 Node에서는 Authorization에 Passport.js를 많이 사용하는데 이 부분의 동작이나 사용법을 질문하기도 하고, 또는 세션 인증과 JWT의 차이점 등 프로젝트를 진행해보면 알 수 있는 내용들을 물어보는 편입니다.


가끔 CRUD만 구현된 리스너만 개발했다는 분들도 있습니다. 서버 개발은 API 코드만 짜는게 전부가 아니라 AWS와 같은 클라우드에 서버를 올려봤는지, 올릴 때 젠킨스나 깃액션과 같은 CI/CD는 사용해 봤는지, 그리고 AWS 사용자라면 로드밸런서는 어떤 역할을 하는지 등에 대한 질문도 드리는 편입니다.



9. 코드를 쓰고 싶은 사람 vs 카피한 사람

결과적으로 저희 회사의 개발자 채용은 코드를 쓰고 싶은 사람을 뽑는데 중점을 두고 있습니다. 답변의 완성도도 중요하겠지만 그 과정이 더 중요합니다. 자신이 프로젝트를 진행할 때 어떤 이슈를 만났고, 어떤 방식으로 해결했는지. 이력서에 쓴 내용과 자신이 쓴 코드가 온전히 자신이 만든 결과물인지가 가장 궁금한 부분입니다. 설령 지금 코드가 좋지 못할지라도, 아는게 적을지라도 저희는 채용하기도 합니다. 그 분들의 경우에는 미숙하지만 개인 프로젝트를 진행하면서 좌충우돌 역경을 만났거나, 제대로된 방향을 잡지 못했지만 계속 시도하시는 분들입니다.


저희는 코드를 쓰고 싶은 사람을 원하고, 그 중에서도 제대로 된 코드를 쓰고 싶은 사람을 원합니다. 더 나은 코드에 대한 욕심이 있는 사람은 어떠한 형태로든 흔적이 남습니다. 그것이 깃허브의 잔디밭일수도 있고, 본인이 운영하는 개발자 블로그일 수도 있습니다. 또는 작은 사이드 프로젝트를 진행하거나 스터디 모임을 이끌어 가면서 여러 시도와 실패를 하기도 합니다.


어줍잖게 학원 3개월, 6개월 다니며 시키는 것만 한 분은 뽑지 않습니다. 설령 운 좋게 들어온다고 해도 개발자 세계에서 오랫동안 살아남기는 어려우실 겁니다. 이곳은 꾸준히 공부를 해야 살아남을 수 있는 곳이고, 그런 사람들이 대접받는 곳입니다.


저희 회사 뿐만 아니라 인터넷에 조금만 검색해보시면 개발 면접 예상 질문과 답변을 정말 쉽게 구하실 수 있습니다. 인터넷에 올라온 면접 예상 질문에 대한 답변도 공부해보시고, 조금 더 나아가서 코딩 인터뷰 관련 책들도 좋은게 많으니 읽어보시면 어떨까 싶습니다.




제가 이 글을 적었으니 이대로만 준비하면 플렉스웹 입사는 어렵지 않겠구나 생각하실 수도 있습니다. 그런데 제가 글에서 적은 내용 정도를 준비하는 사람이 세상에 많지 않다는걸 계속해서 봐왔습니다. 제가 다른 회사 면접도 알아보고, 여러 스타트업 면접도 들어보면 이것보다 많이 어렵거나 또는 아예 없는 편이거나로 갈라지는 것 같습니다.


만약 저희 회사에 입사하고 싶으신 신입분이시라면 제 글의 기준과 더불어 자신이 코드쓰는걸 정말 좋아하고, 잘해보고 싶다는 것을 증명할 코드만 있으면 입사는 어렵지 않으실 겁니다.


웹 개발, 블록체인 컨트렉트 개발 문의: https://flexweb.io​​




매거진의 이전글 2021년 플렉스웹 회고록
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari