공유받은 경력자의 이력서 & 면접 조언

현재 활동중인 곳에서 개발자 이력서와 면접에 관한 경력자의 조언을 정리하고 공유한 내용을 기록하고자 한다.

 

서류 검토

첫 번째로 고민해야 할 부분은 "자기 경험 위주의 이력서"인가? 생각해봐야 한다. 본인의 커리어만 나열한 것인지 다시 한 번 확인해볼 필요가 있다.

두 번째는 "다양한 기술을 사용해봤구나."라는 인식만 전달해도 괜찮다는 것이다. 다양한 것을 써 본 경험으로도 충분히 인식을 전달할 수 있다.

마지막으로 정말 필요한 것인지, 해당 포지션에 맞게 제대로 지원했는지 생각해봐야 한다. JD를 보고 지원한 동기나 해당 팀에 지원한 이유 그리고 본인이 얼마나 괜찮은 사람인지 전달해야 한다.

 

이력서

비전공자, 프론트엔드 또는 백엔드 분야로 전향하는 이유가 타당한 지 확인할 필요가 있다. 전공자이든 비전공자이든 다른 분야로 전향을 하든 그것에 진심이라는 것을 내용으로 보여주어야 한다.

 

그렇다면 좋은 이력서라는 것은 무엇일까?

느끼고 배운 것을 기술할 수 있어야 한다. 개발적으로 무어볼 질문들이 많게 만들어야 한다. 그리고 개발자를 준비하는 사람으로서 이렇게 생각했고 부족한 것이 이것이라고 생각했으며 부족한 것을 채우기 위해서 이런 것까지 했다는 것을 나타내야 한다.

 

예를 들자면, 나는 A 프로젝트에서 서비스를 생각하며 프론트엔드 개발자로 역량을 발휘해봤다와 같이.

더 정확하게 소개팅 앱을 서비스하면서 1대1 매칭 기능으로 운영을 했더니 약 100건 밖에 되지 않았고 설문조사를 해보니 불편한다는 의견이 있었다. 그래서 UI를 변경을 추진하여 도입하였더니 약 4000개 이상이 늘었다와 같이 구체적인 경험이 필요하다. (실제 서비스를 운영하는 경험은 쉽지 않을 것 같은데...)

 

만약 개발에 참여하지 않았다면 어떤 역할로 참여했는지라도 적어야 한다.

 

기술 스택은 그것을 사용한 근거가 있어서 사용했는지, 어떤 프로젝트에서 그 스택을 사용했는지 정확하게 작성할 수 있어야 한다. 그리고 어떤 것을 겪었고 어떻게 해결했다라는 것이 필요하다.

 

회사 별로 이력서를 다르게 작성하면서 지원동기를 이력서에 넣는 것도 좋을 수 있다. 지원동기를 적을 때는 어떤 개발자가 되고 싶다거나 무엇을 계기로 관심을 갖게 되었는지 알리는 게 필요하다.

 

이력서를 작성할 때, Introduction(소개) 부분에 가장 집중할 수 밖에 없다. 그렇기 때문에 소개 부분이 2줄 이상 넘어가도 더 자세히 수정하는 것을 추천한다. (예. PM을 하고 싶었고 개발부터 ~ 등의 내용) 특히, 작성할 때는 나는 어떤 개발자이고 어떤 개발자가 되고 싶고 이런 것을 위해서 개발 경험을 어떻게 쌓고 어떻게 준비하고 있는지 작성해야 한다. 어떤 개발자가 되기 위해서 노력하고 있고 당사의 JD를 확인해보니 나의 이러한 부분이 잘 맞을 것 같아서 지원하게 되었다와 같이 설득력있게 작성해야 한다. 소개 부분을 작성할 때는 나를 표현할 수 있는 키워드를 사용해서 작성하는 연습을 해야 한다. (예. 서비스에 집중하는 개발자)

 

자기소개서를 입력할 때는 해당 회사에 지원한 이유를 꼭 이필하는 것이 좋다. 실제로 면접관이 이력서를 검토하는 시간은 충분하지 않기 때문에 인트로 부분을 더욱 자세하고 자신의 매력을 어필할 수 있도록 작성해야 한다. 그리고 만약 다른 분야에서 전향을 했다면 다양한 부트캠프 참여 등 개발자에 대한 진심을 더더욱 보여줄 필요가 있다.

 

면접

면접을 볼 때, 회사는 코딩테스트에서 몇 등이고 몇 점이었다라는 정보가 있다. 그리고 지원 이력도 알고 있으며 이에 따라 다수의 마음을 끌 필요가 있다.

 

그리고 하지 말아야 할 말이 있다. 바로 "모르겠다"이다. 이 말은 하지 말아야 한다. 모르겠다는 말보다 최대한 아는 부분까지 말하고 다른 질문을 계속해서 끌어내도록 해야 한다. 예를 들자면 "자바스크립트는 싱글스레드 언어인데 싱글스레드를 벗어나는 API에는 무엇이 있는가?"라는 질문에 "웹 API로 알고 있다" 또는 "모르겠다"라는 답변보다 "제가 알기로는 태스크큐에는 무엇이 있고..."와 같이 말하는 게 낫다.

 

면접을 위해서 면접스터디를 준비하는 것도 좋다. 프로젝트에서 실제 사용해 본 것을 말로 해보거나 글로 써보는 것이 필요하다.

 

면접에서 답변을 할 때는 끝을 흐리면서 마치면 좋지 않다. 모르는 질문이 와도 "제가 사용은 해보지 않았지만 ~것으로 알고 있다."처럼 태도를 보여주어야 한다. 모르는 개념에 대한 태도를 보여주어야 한다는 것이다.

 

면접에서는 멘탈 관리가 중요하다. 들어와서 열심히 할 것 같다라는 인식과 이미지를 전달해야 한다. 준비를 잘하는 것도 중요하지만 모르는 것이 나와도 당황하지 않고 멘탈을 관리할 줄 알아야 한다.

 

면접의 순서와 상관없이 들어가면

 

1. 자기소개 내용
2. 코딩테스트 / 과제 질문
3. 이력서
4. Introducion(소개) 부분
5. 기술 내용

 

으로 표현한다.

 

만약 코딩테스트를 볼 경우, 코딩테스트 질문을 하느라 다른 기술적 질문을 덜 할 수도 있다. 면접은 정해진 시간이 있기 때문이다. 지원자가 풀었던 문제를 질문하는 게 좋을 수 있다.

 

면접에 대해 잘 모르더라도 무작정 솔직하게 모르겠다는 답변보다 아는 선에서 최대한 답변하고 부족한 부분이 있다면 추후에 숙지하겠다는 답변을 하는 것이 좋다. 면접관 입장에서 지원자가 모른다고 답변하면 더 이상 물어볼 것이 없어지기 때문이다. 기술 면접 질문이 이어지도록 최대한 답변하는 것이 좋다. 면접 과정에서는 다시 한 번 언급하지만 멘탈 관리가 중요하다. 면접관 입장에서도 지원자가 어느 정도 포기를 했다는 것이 눈에 보이기 때문이다. 제대로 답변을 못하더라도 포기하지 않고, 지원자가 어려운 상황에서도 열심히 하겠구나라는 인상과 인식을 심어주는 것이 중요하다. 최소한 포기하지 않는 자세를 보여주도록 하자.

 

기술면접

기술면접은 기술과 관련된 다양한 기술, 본인이 사용했던 기술을 답변할 줄 알아야 한다.

 

• "리액트가 무엇인지?"
• "Virtualdom이라면 이것을 쓴다면 무엇이 다른지?"
• "리액트 훅이 무엇인지?"
• "왜 훅으로 뺐는지? 훅 안에서는 스테이트가 어떻게 동작하는지?"
• "어떤 케이스에 훅을 사용해야 하는지?"
• "리액트 메모이제이션은?"
• "useEffect()는?"
• "리액트를 왜 사용하는지?" -> 관심사 분리

 

이 처럼 다양한 기술적인 질문이 올 것을 대비해야 한다.

 

• "클래스에서 펑셔널로 전환이 될 때, HOC 기반으로 한 라이브러리가 있었는데.."
• "리액트 팀에 영입이 된다면 컴포넌트라는 개념을 바라보는 근본적인 것은.."
• "어떤 관점에서 나왔다."

기술면접 질문에는 레벨이 있다. 레벨 1 질문 -> 레벨 2 질문 -> 레벨 3질문처럼 말이다.

 

그리고 사용한 기술에 대해 동작 원리는 알고 있어야 한다.

 

각 기술에 대한 질문들을 예시로 든다면 다음과 같다.

 

자바스크립트 질문

• 바닐라 자바스크립트라면 모듈 패턴이 어떻게 되는가?
• 사용한 모듈 패턴이 어떻게 되는가?
• ES6 기반이면 Common JS 기반

 

타입스크립트 질문

• 타입스크립트가 왜 개발 향상성이 향상된다고 생각하는가?
  • 협업 할 때, 내가 정의해놓은 컴포넌트를 다른 사람이 사용할 때 인터페이스만 확인하면 된다.
  • 혼자 사용할 때도 마찬가지로 리턴과 파라미터에 대한 타입을 정확하게 알고 기술하였기에 비즈닉스 로직을 보지 않아도 인풋과 아웃풋이 확실하기 때문에 사용한다.

기타 질문

• 백엔드는 어느 정도 해야 하는가?
  • 백엔드라는 것보다 AWS 웹 아키텍처와 같이 서비스라는 아키텍처를 만들 수 있는 사람이어야 하며, 전체적인 시스템 아키텍처 흐름을 알고 있는 사람이어야 한다.
• 로드 밸런스가 무엇인가? 1000명의 사용자가 있을 경우 30명의 데이터베이스를 어떻게 가져올 것인가?
• 전체적인 시스템 이해에 대해 얼마나 이해하고 있는가? 그리고 그런 아키텍처 케이스를 몇 가지나 알고 있는가?
• 테스트 코드는 알고 있는가?
  • TDD 접목이 안 되는 것이 많은데 ~을 해보고 ~정도로 검증을 해본 경험을 해봤다는 답변이 필요하다. 그렇다면 공부를 했다는 것을 나타낼 수 있고 테스팅에 대해 어떤 고민을 하고 있는지 나타낼 수 있다.
  • JEST 기반 등 테스트를 진행했다면 본인 코드에 대한 퀄리티 유지를 하기 위해 이런 방식으로 진행했음을 나타낼 수 있다.
  • 전반적으로 훑어볼 필요가 있다.
• 코딩테스트는 준비를 하면 문제가 뻔하다. 코딩테스트로 지원하는 것은 경쟁을 하겠다는 것, 지원자가 해당 문제에 대해 얼마나 어떻게 고민했는지를 본다. 코딩테스트를 해보고 간다면 기술적으로 도전해봤다는 것을 나타낼 수 있을 것이다. 코딩테스트 결과가 나쁘더라도 뽑힐 수 있기 때문에 스터디부터 해보는 것도 좋다. 코딩테스트 문제를 풀기 위한 사고력을 바꿀 필요가 있다.
• 만약, 본인이 다른 분야에서 전향한 사람이라면 타이틀이 있을 것이다. 물론 인식이 좋지만은 않다. 그렇지만 비전공자이든 아니든 전향을 했다면 어떤 식으로든 보여주는 것이 중요하다. 즉, 자기 증명이 필요하다. 본인이 왜 전향을 했고 본인은 어떤 개발자이며, 어떤 것들을 하고 있는지, 앞으로 어떤 개발자가 될 것이고 그런 과정에서 해당 회사에 입사하게 된 계기가 무엇인지 말할 수 있어야 한다.
• Styled-Components는 정말 좋은 것인가? 사용성이 좋은 것인가?
• 퍼블리셔가 있는 회사라면 CSS/SCSS를 Styled-Components로 치환해야 하지 않는가?
• 스토리북을 가지고 있으면 좋다.
• 오래된 기술 스택을 가진 회사라면 안 가는 것이 좋다.
• 개발자를 평가하는 기준은 머리로 이해하는 사람과 몸으로 체득하는 사람으로 나뉠 것이다.

 

---

 

참조

https://axiomatic-bunny-1ec.notion.site/b2f30fac243a44dca8de219de3cb051f

배철민코치님과의 커피챗!