보충역 병특 구직 및 개발자 면접 후기

2022 기준 현역 대학생의 병특 편입은 사실상 불가능한 수준이지만 과거 비슷했던 상황을 보면 다시 상황이 풀리는 경우가 있어, IT 산업기능요원을 하고자 하는 저와 같은 하꼬 대학생들과 저 자신을 위해 후기글을 남겨봅니다..

아 물론 개발자 취준할 때도 도움이 될 만한 것들이 있을 수도? (개발자 컬쳐면접에선 뭘 물어보는지, 기술 면접이 어렵다던데 어떻게 어렵게 나오는지..?)

간단한 배경

전공: 문과대학 소속이지만 정보처리 관련 전공에 속하는 과 / 컴퓨터과학 복수전공

*본인 전공이 정보처리 관련 학과인지, 본인이 2년 이상 재학했는지 꼭 확인하셔야 합니다! 복전으로 병특하려면 대학 졸업 후에 가능합니다. (2022 기준)

인턴: 학교연계 개발 인턴 프로그램 1회 (1개월), 개발 인턴 1회 (2개월)

학점: 3.7 ~ 3.8 (서류 및 면접 단계에서 요구하는 경우는 경험하지 못 했다)

*아무래도 컴과 본전공생은 아니라 면접단에서 가끔 무슨 무슨 수업들었는지 정도 물어보는 경우는 있었다.

결과

한 달 정도 서탈, 기술면접탈, 컬쳐면접탈을 겪고 최종적으로 세 군데에 합격했고, 한 군데는 컬쳐면접만 남긴 채로 회사를 구할 수 있었다.

면접과 과제 전형이 많이 겹쳐서 어쩔 수 없이 과제를 포기한 경우도 가끔 있었다.

이메일로 지원한 회사들 중에는 답신조차 없는 경우도 있었고 전화 인터뷰 후 결과 통보를 1달이 넘었는데도 안 오는 회사도 있었다.

과정

• 서류

  처음에 지원할 때는 노션으로 pdf를 만들어서 보내거나, 노션 링크를 보냈는데 이력서 관련 정보를 찾다보니 노션으로 만든 이력서나 포트폴리오는

  1. 사용자 환경에 따라 의도한 대로 시각화되지 않을 수도 있다는 단점과

  2. 인터넷 환경이 꼭 필요하다는 점

  3. 이력서를 읽는 담당자들 중에 노션 이력서를 좋아하지 않는 담당자 분이 있을 수 있다는 점 등 서류 단계에서 패널티를 얻을 수 있다는 것 때문에 이후에는 노션으로 만든 내용을 markdown으로 export 하고 이걸 pdf로 만들어서 지원했다. 내용은 아래와 같이 채워넣었다. 이력서 Best Example 을 보고 썼지만 서류탈을 많이 해서 앞으로 더 보완해야 할 것 같다는 생각을 한다,,,

  4. 기본 정보 (이름, 이메일, 전화번호, 깃헙 주소, 블로그 주소) ← 전화번호를 적지 않고 낸 경우엔 이메일로 전화번호를 물어보는 경우도 있었다! 전화번호 꼭 써주자,,,

  5. 간단한 소개 ← 관심 기술, 자신 있는 스킬, 관심있는 업무, 관련 경험 등을 썼다

  6. 기술 스택 ← FE 파트에 지원해서 웹 개발 전반에서 갖고 있는 기술을 작성했다. (FE, BE, Infra 등)

  7. Work Experience ← 인턴 업무

  8. Project ← 일이 아닌 동아리, 개인플젝 혹은 창업팀 등의 이력을 작성했다.

  9. Other ← 현재 하고 있는, 혹은 했던 동아리 활동을 썼는데 따로 본인을 파악할 수 있겠다 싶은 기타 활동들 넣어주면 될 것 같다

• 코딩 테스트 / 과제 테스트

  프론트엔드로 지원을 하기도 했고 개인적으로 과제 전형에 더 자신이 있어 사실 코테 준비를 아예 안 함 브론즈가 아니라 언랭이랄까 ^^.. 코딩 테스트보다는 과제 테스트를 보는 곳에 지원했고 몇 군데 안 되지만 모두 통과했다.

  스켈레톤 코드를 주고 채워넣는 형식과 밑바닥부터 완성하는 두 가지 방식이 있는데, 스켈레톤 코드의 경우 시간 제한 4시간정도가 있어서 굉장히 빠르게 구현했어야 했다.

  시간 부족으로 마지막 구현 사항인 api 통신 부분은 세부 구현은 하지 못 하고 껍데기만 만들어서 어떤 형식으로 코드를 짤 계획인지 보여주는 수준으로만 만들었다. 이 방식을 통해 보는 가장 주요한 포인트는

  “숙련도 (좋은 습관이 들어있는지)”, 그리고 “기존 코드 활용 능력 (코드 리딩 능력)” 인 것 같다.

  오랜만에 촉박한 시간을 가지고 집중력을 끌어내서 문제를 풀어서 그런지 재밌었다. 또한 요구된 구현 사항을 만들 때 기존 코드를 수정하면 새롭게 만드는 것보다 더 낫다 싶은 게 보여서 그렇게 했는데 아마(?) 이쪽에서 점수를 얻었다고 생각한다,, 오만방자....

  반면 일반적으로 과제전형 하면 생각나는 밑바닥부터 완성하는 방식의 경우 3일~1주일의 기간동안 주어진 요구사항에 맞춰 개발하면 된다. 여기서 보는 주요 포인트는

  • 재사용성, 확장성, 가독성 등 코드 퀄리티

  • 테스트 코드, 스크립트 등 개발 외적인 부분

    이라고 생각하는데, 이 방식의 과제 테스트를 준비하는 데 도움이 된 글을 첨부한다,, 사실 이 방식도 숙련도를 볼 수 있겠지만 아무래도 시간이 조금 넉넉한 관계로 숙련도보다는 why React? why 이 구조? 등 why ‘특정 기술'? 에 대한 것, 프로젝트 구조에 대한 넓은 시야가 더 중요한 것 같다.

• 기술 면접

  프론트엔드로 지원을 했기 때문에 FE 관련 질문을 주로 받았어서 FE 개발자를 목표로 준비하지 않는 분들은 큰 도움이 안 될 수 있다.

  그래서 구글링을 통해 쉽게 알 수 있는 기술 질문들보다 면접관들과 티키타카하면서 풀어야 하는 어려운 기술 질문들에 대해 공유해보려 한다.

  프론트엔드 기술과 관련해서 문제를 풀었지만 이 글을 통해 FE뿐만 아니라 백엔드나 데브옵스 등 다른 직무를 준비할 때 어떤 식으로 어렵게 기술 질문을 하고 실력을 파악하는지 유추하는 데 도움이 된다면 좋을 것 같다.

  물론 본인은 하꼬이기 때문에 아직 실력이 부족하기 때문에 그다지 어렵지 않다고 느낄 수 있다..

  아무튼 티키타카 면접을 소개하기 전에 기술 면접에 대해 먼저 말해보려 한다.

  기술 면접, 더 나아가 주니어로서 가장 중요한 건 논리적 문제 해결이라고 생각했는데, 여러 면접을 거치면서 뼈를 때리는 질문을 통해 도대체 논리적 문제 해결이 뭔지 조금이나마 알게 됐다.

  바로 기술적인 문제를 해결한 과정을 대답하고 나서 들었던

  라는 피드백이었다.

  지금까지는 기술 면접에서 자주 물어보는 질문 중 하나인 ‘어려웠던 문제 해결 과정 설명' 의 답변을 할 때 문제 정의 단계를 설명하지 않았던 것이다.

  즉 논리적 문제 해결 프로세스 안에 이미 아래와 같은 내용이 들어있던 거다..

  능동적 문제 찾기 - 근거를 통해 문제라고 정의하기 - 해결 (해결했다고 / 하지 못 했다고 판단한 근거 또한 필요)

  아무튼간에 티키타카 면접질문 얘기를 해보자면!

  어려웠다고 느낀 질문들 대부분 프로젝트나 업무에서 사용했던 기술과 관련해

  1. 어떤 동작 방식을 가지고 있는지 / 가지고 있을 것 같은지
  2. 왜 그렇게 구현했는지 / 왜 그렇게 구현했을지

  와 같은 질문을 통해 사고력을 확인하려고 했던 것 같다.

  몇 가지 예를 들어보면

  아래와 같다.

  • React 개발 시 list 를 map 함수 등을 통해 풀어서 list의 item들을 컴포넌트로 만드는데, 이 때 key값은 왜 필요한가?

    React 의 Virtual DOM과 React의 렌더링 최적화 방법에 대해 꼬리 질문이 나오면서 렌더링, 상태 업데이트 등 React의 동작방식에 관해 티키타카했다.

    여기에 더해 React에서 setState는 왜 비동기로 구현되었는지? 와 같은 질문도 나왔다.

    당연하게도 따로 찾아보지 않았으면 알 수 없는 부분이었고, 이럴 때는 최대한 현재 가지고 있는 cs 배경지식, js 언어 지식 등 알고 있는 개발 관련 지식을 긁어모아서 유추해야 한다.

    비동기와 동기의 차이점을 통해서 힌트를 얻을 수 있는데,

    setState가 동기라면 첫번째 setState 이후 React가 리렌더링하는 과정이 다음 setState 이전에 실행되는 것이 보장된다. 나중에 call된 setState를 block하고 실행하는 거겠..죠?

    setState가 비동기라면 setState를 짧은 시간 안에 여러 번의 요청을 했을 때 여러 setState가 blocking되지 않고 비동기적으로 처리되므로 리렌더링은 마지막 상태 업데이트 후에만 하면 된다 (React가 이렇게 구현되어있다는 뜻). 동기가 아니므로 setState-리렌더-setState-리렌더링 ... 이라는 과정이 보장되지 않는 것이다.

    위와 같은 아이디어가 생각이 안 난다면 비동기와 동기의 차이가 blocking이므로, 이걸로 힌트를 더 주실 수 있을까요? 이러면서 힌트받고 또 실마리 얻어가고.. 이렇게 하면 된다,,,

  • Redux에서 Reducer가 필요한 이유?

    Redux는 Flux 패턴의 구현체인데 (완벽하게 Flux와 동일하게 구현한 것은 아니고 Redux만의 방식으로 단방향 데이터 흐름을 구현) 이 때 reducer는 Flux에서의 dispatcher+store 역할을 한다.

    그래서 이 질문 다음 꼬리 질문으로 Flux 패턴에 대해 설명해달라, Flux 패턴이 필요한 이유, 그럼 MVC의 문제는 뭐였냐 등 디자인 패턴에 대한 티키타카가 있었다.

    마지막으로는 전역 상태 관리가 없다고 하고 상태관리를 한다면 controlled component VS uncontrolled component, 둘 중 뭘 더 선호하냐, 왜 선호하냐, 둘의 장단점은 무엇이냐,,, 본인은 개발할 때 어떤 식으로 prop 공유를 하냐 등등 상태관리에 관한 질문이 엄청 많았다.

  • 의존성 관련 - 고차 컴포넌트 vs Custom hook

    custom hook은 의존성 관리 힘들지 않냐, 컴포넌트의 재사용성이 떨어지지 않겠냐 등 의존성과 재사용성에 관한 질문을 여러 면접을 통해 굉장히 많이 받았다. 이건 사실 이력서에 재사용성, 확장성에 대한 관심과 custom hook을 통해 로직을 다루는 부분이 자신있다고 작성해서 그런 것 같다..

    실제로 개발하면서 로직 재사용을 hoc로 했을 때와 custom hook으로 했을 때 느꼈던 장단점, 본인이 생각하는 의존성 처리에 대한 시각, 재사용성에 대한 시각을 말해주면 될 것 같다. 정답은 없는 부분이니까 진짜로 관심있는 부분인지 확인하는 용도 및 지원자가 가지고 있는 개발(의존성 처리, 재사용성 높이기 등) 에 대한 관점을 볼 수 있을 것 같다.

    본인은,, 여러 hoc를 거치거나 hoc에서 데이터도 처리하고 처리된 데이터를 prop으로 받는 경우 컴포넌트(아마 container 컴포넌트)가 어느 hoc들에 의존하고 있는지 파악하기 어렵고 반면 custom hook을 통해 로직을 재사용하면 컴포넌트가 가지고 있는 의존성에 대한 파악을 오히려 더 쉽게 할 수 있다..는 식으로 대답했다.

    이 토픽은 추상화랑도 연결이 돼서, 어느 정도로 추상화를 가져가는 것이 좋을지, 추상화에 대한 시각, 추상화 해본 경험, 어떤 성과가 있었는지 등 개발 전반적인 부분에 대한 질문으로까지 이어졌다.

• 컬쳐, 핏, 인성 면접

  기술면접만큼이나 컬쳐면접이 어려웠었는데, 구글링해서 찾은 면접 질문들을 통해 도움을 받고 준비를 했으나 실상 면접을 들어가면 머리가 백지가 되는 것이었다.. 그래도 컬쳐 면접 덕분에 지난 이력과 생활 속에서의 나를 곱씹으면서 스스로에 대한 생각을 많이 할 수 있었다.

  병특을 통해 경험한 컬쳐 면접은 구글링해서 나오는 스타트업 개발자 컬쳐 면접 질문들과 맥락은 같았다. 맥락은 같았지만 질문은 달라서 준비해 놓은 답변을 하지 못 하고 어버버대기도 했다...

  컬쳐 면접의 경우 본인 성향, 업무스타일, 회사에 관심 갖게된 이유, 가장 몰입하는 순간, 회사에 기대/우려하는 점과 그 이유, 개발자로서 궁극적인 목표, 인생 목표, 일을 하는 가장 큰 동기, 본인이 생각하는 워라밸이란, 열정을 갈아넣은 경험 등에 대해 솔직하게 얘기하면 된다!

  사실 회사와 나 사이의 Fit을 보는 것이므로 떨어진다고 해서 내가 회사 생활을 하지 못 할 사람일까 등의 부정적인 생각을 할 필요는 없다.

  컬쳐 면접 관련해서는 많은 정보를 줄 수 없을 것 같다. 회사마다, 그리고 지원자마다 다른 질문과 답변이 오고갈테니 자기 자신에 대한 객관화를 잘 하고 솔직하게 얘기하면 좋을 것 같다는 생각...

마무리

아무튼.. 얼레벌레 작년 2학기 (2021) 부터 휴학하고 인턴, 팀플젝 등 하면서 병특 준비를 했는데 가고싶은 회사 중 한 군데에 입사하게 되었다...!

정말 많은 걸 경험하고 해결하면서 성장하면 좋겠다 하하 소년 만화냐고 ㅋㅋ

음...네.. 항상 마무리가 어렵다.. 끗