들어가기 전에
이 글은 2년차 개발자의 이직 후기 - 1편 (나는 어떤 회사를 가고 싶은가) 의 후속편이다. 1편에서는 어떤 회사를 가고 싶은지 평소 나의 생각이 담긴 다소 추상적인 내용이었다면, 이번 글은 실용적인 팁 중심으로 작성해보고자 한다. 이직을 준비하는 과정에서 주변 사람들 뿐만 아니라 온라인 내 익명의 사람들로부터 너무나 큰 도움을 받아왔다. 나 또한 비슷한 취업 준비를 하고 있는 다른 사람들에게 조금이나마 도움이 되었으면 하는 마음에 이 글을 적는다.
평소에 이직 준비할 때 인호준님의 2024년 개발자 이직 회고, 지원부터 수습해제까지 라는 글을 자주 읽으며, 큰 도움과 마음의 위안을 얻었다. 이 글에서는 그분의 글에서 받은 인사이트들을 토대로 나만의 시각과 경험을 담아 풀어내고자 한다.
회사 지원하기
회사 탐색하기
1편에서 말했듯 나의 목표는 시리즈 B 이상의 B2C 스타트업이 목표였다. 따라서, 주로 원티드나 InThisWork 를 매일 방문하며 새로운 공고가 올라오는지 확인했다. (사실 매일까지는 필요 없는데 하루에도 여러번 공고 확인하는게 내 취미였다.) 그리고 현실성 이슈로 주요 대기업도 아예 쓰지 않을 수는 없었다. 따라서, 자소설닷컴도 상반기/하반기 채용 시즌에 맞추어 적절히 활용했다. 마지막으로 취업오카방에서 올라오는 공고를 확인하며 혹시라도 내가 놓치고 있는 정보가 없는지 더블체크하였다.
지원은 회사 채용페이지에서
회사 자체의 채용 페이지가 있다면 채용 플랫폼이 아닌 해당 페이지에서 지원한다. 개인적으로 채용 플랫폼보다 해당 페이지에서 지원할 때 합격률이 대체로 높았다. 한번에 이력서를 난사하기 보다 그 회사에 대한 최소한의 성의를 보여주고 싶었고, 이러한 부분이 채용담당자 입장에서 분명 차이가 존재한다고 생각한다.
일단 지원하기 vs. 준비되면 지원하기
크게 두가지 주장이 존재한다. 하나는 “일단 지원해라. 붙으면 준비가 된 것이다” vs “아니다. 그래도 준비가 어느 정도 되면 넣어라”. 나는 반반이다. “정말 가고 싶은 곳은 어느 정도 자신감이 붙으면 넣어야 한다.” 라는 생각이다. 준비가 하나도 되지 않은 상태에서 지원하면 합격할 확률은 매우 낮고, 6개월 지원 제한만 걸린다. 따라서 정말 본인의 기준에서 우선순위가 높은 기업은 준비가 조금이라도 더 되있을 시점에 늦게 지원한다. 하지만, 주의할 점은 생각보다 공고가 빠르게 내려간다. 공고가 한번 내려가면 언제 다시 올라올지 아무도 모르기 때문에, 이 때는 쓰는게 맞다. “대체 뭐 어쩌라는거지?” 라는 생각이 들 수 있다. 한가지 팁을 공유하자면, 기업을 지원하다보면 거의 상시로 열린 곳이 있고, 아닌 곳이 있다. 매일 같이 틈날 때마다 공고를 들여다 보면 어느 정도 감이 온다. 이를 테면 토스는 채용사이트에 들어갈 때마다 거의 항상 Frontend 채용 공고를 본 것 같다. (물론 대규모 채용 기간이 있을 때도 있지만) 이렇게 상시로 열려있는 경우는 최대한 자신이 준비가 되었을 때 넣는 것이 유리하다고 생각한다. 이외의 곳 들은 공고가 당장 내일 닫힐 수도 있다. 실제로 내가 제출하고 나서 바로 다음 날 공고가 닫힌 경우도 종종 보았다. 못써서 후회할 바엔 떨어지더라도 일단 쓰는게 맞다.
서류 전형
개인적으로 서류 전형이 가장 어렵다라고 생각한다. 다른 전형 ex. 코딩테스트는 다른 사람들보다 어느 정도 잘보면 되겠다라는 감이 어느 정도 있지만, 서류는 정말 기업 내부에서 어떤 기준을 통해 뽑히는지 알길이 없다. (그러니 제발 본인이 붙었다고 물서류 아니냐고 하지 마라.) 더군다나 한 두명 뽑는데 수백명이 지원하는 시점에서, 내 이력서가 그 중 돋보이게 할 수 있을지는 지금도 막막하다. 하지만, 그래도 나쁘지 않은 서합률을 가지고 있는 만큼 지금까지 쌓아온 팁들을 공유한다.
이력서 초안 작성하기 (강의 추천)
나보다 이력서 잘쓰는 훌륭한신 분들은 너무 많다. 따라서 직접 설명하기 보단 가장 최근에 참고한 강승현님의 인프런 강의로 갈음한다. 이 강의를 보고 이력서를 싹다 뜯어 고쳤고, 개인적으로 큰 도움이 되었다다. 추가로 한가지 팁은 강의를 볼 때 가장 효율적으로 흡수하는 방식은 ‘일단 무작정 따라하기’이다. “에이, 이건 나한테 적용하기 힘들 것 같은데” 또는 강의 내용을 머리로만 이해하고 실행하지 않는다면 큰 도움을 받지 못할 것이다. 그냥 무작정 믿고 따라하자. 다만, 그렇다고 또 필요없는 것까지 다들을 필요는 없고, 알맹이만 쏙쏙 뽑아먹자. 이 강의에서 배운 한가지를 꼽자면, “경험 나열식이 아닌, why-what-how 가 잘 들어나게 써라” 이다.
피드백을 통해 이력서 개선하기
모든 일에는 항상 피드백이 중요하다고 생각한다. 피드백을 받아야 내가 올바른 길로 갈 수 있는지를 확인할 수 있고, 피드백의 주기가 짧으면 짧을수록 잘못된 길로 갈 확률이 낮아진다. 따라서 이력서 작성이 일단 끝나면 가장 먼저 믿을 만한 주변 사람이나 멘토에게 피드백을 받는 것이 중요하다. 나는 왓에버 라는 멘토링에 참여하였는데, 멘토링 기간이 끝났음에도 멘토(프롬님)께 이력서 피드백을 부탁드렸다.
바쁘실텐데도 정말 꼼꼼히 봐주셨고, 주신 피드백을 바탕으로 이력서를 수정하여 서합률을 드라마틱하게 높일 수 있었다. 이렇게 한 번 피드백을 받고 수정이 완료되면, 이제 실전에서 테스트할 차례다. 혹시 모르니 한 번에 다 지원하기 보다는, 조금씩 나눠서 지원하는 방식을 추천한다. 만약 10개를 지원하고자 할 때 (아직 지원기간이 충분히 남아있다면) 일단 그 중에 3-5개만 지원하고, 결과를 지켜본다. 만약 모두 탈락했다면, 서류에 문제가 있을 수 있으니 다시 한 번 검토를 해볼 필요가 있지 않을까. 그리고 만약 그 중 한개라도 합격했다면, 분명 그 이력서는 어느 정도 매력을 갖추었다는 증거이니 자신감을 갖고 조금씩 다른 회사도 추가로 지원한다.
코딩 테스트
코딩 테스트는 지원하는 기업에 따라 볼 수도 있고 안 볼 수도 있다. 하지만, 코딩 테스트를 포기하면 선택지의 폭이 드라마틱하게 줄어든다. 따라서, 어쩔 수 없이 준비해야 한다.
통과할 정도로만 준비하기
코딩 테스트는 답이 없다. 그냥 하루에 한 문제씩만 풀면 된다. 대신 하늘이 무너져도 한 문제는 풀어야 된다. (단, 기업 면접이 임박하기 전 제외) 나의 경우 7-8개월 동안 매일 문제를 풀었고 이렇게 하니 대기업 코테는 대부분 뚫을 수 있었다. 여기서 한가지 팁은 하나의 기업에 합격하려면 많은 전형들이 존재하는데, 중요한건 이 전형들을 모두 통과해야지만 합격을 할 수 있다. 따라서 하나의 전형에 몰빵하기 보다는 여러 개의 전형을 골고루 준비하돼, 각 전형을 통과할 수준을 맞추는 것이 효율적이다. 코딩테스트도 마찬가지로 통과할 정도로만 준비하면 그만이다.
매일 한 시간만 투자하기
1년 동안 운영해온 알고리즘 복습 큐. 다른 블로그에서 보고 그대로 따라했다.
알고리즘을 잘하는 편이 아니지만, 그래도 한가지 팁이라면 풀이에 절대 한시간을 넘기지 않는다. 문제를 읽는 시간 + 고민하는 시간이 총 40분 이상을 넘겨도 솔루션이 떠오르지 않는다면, 그 문제는 답을 본다. 대신 답을 눈으로만 보지 말고, 이해한 것을 바탕으로 직접 구현한다. 그리고 알고리즘 복습큐에 추가한다. 알고리즘 복습큐는 고등학교 수학 문제 풀때 오답노트와 비슷하다. 한 문제를 다른 사람의 풀이를 풀었다고 해서 절대 나의 것이 되지 않으므로, 내 것이 될때까지 충분히 반복한다.
또 한가지는 코딩테스트 당일 새벽이나 아침에는 머리를 헤비하게 쓰기보다, 간단한 워밍업을 진행한다. 워밍업으로는 알고리즘의 주형 유형별로 자료구조를 구현하거나 대표 유형 문제들을 빠르게 훑는다. 특히 나는 JavaScript 로 코테를 봤는데, Python 과 달리 heap 이나 queue 등을 직접 구현해야하기 때문에 주요 자료구조 구현만큼은 버벅이지 않도록 거의 암기하다시피 했다.
과제 테스트
솔직히 과제 테스트를 많이 보지는 않았다. 올해는 총 2번을 보았고, 운좋게 2번 모두 통과를 했다. 다만, 표본이 충분하지 않은 점은 감안하고 보면 좋을 것 같다.
기능 구현은 누구나 한다. (블로그 추천)
매번 과제 전형을 시작하기 전 읽으면서 마음 속에 새겨두었던 글이 있다. 인호준님의 프론트엔드 과제 테스트 잘하는 법을 상속한다. 즉, 블로그에서 언급되지 않은 나만의 팁을 추가적으로 공유해보고자 한다.
AI 적극 활용하기 (단, 명확한 의도를 바탕으로)
보통 과제는 48~72시간이 주어지는데 과제 구현내용은 그렇게 많아 보이지 않지만, 제대로 만들려면 시간이 매우 촉박하다. 따라서, AI 를 적극적으로 사용할 수 밖에 없다. 나는 비용 이슈로 인해 가장 최신 과제에는 Copilot Agent 모드를 활용했지만, 평소에 Cursor + MCP 등을 통해 생산성을 끌어올리는 사람이라면 이 부분에서는 좀 더 유리할 것 같다. 다만, AI 는 개발자의 실력을 따라간다. (적어도 지금까지는) 단순 딸깍보다는 명확한 의도를 바탕으로 AI 를 활용한다. 이를테면 “이 코드 리팩토링 해줘” 가 아니라 “드롭다운을 Compound 패턴을 적용해줘” 이런 식으로 구체적으로 지시하면 퀄리티와 생산성 모두를 챙길 수 있다.
그리고 AI 의 결과물은 항상 의심한다. AI 가 작성한 코드를 한줄한줄 읽어내려가며 “나 였으면 어떻게 구현했을지?” 를 고민하고, 만약 선호하나 더 나은 방식이 있다면 수정을 요청한다. 예를 들어, Timer 컴포넌트를 만들 때 AI 는 setInterval 과 같은 API 를 사용했다면, requestAnimationFrame 을 적용하여 성능과 모니터의 VSync 주기에 맞춰 부드러운 Animation 을 구현할 수 있을 것이다.
디테일 챙기기
프론트엔드는 개인적으로 디테일에서 갈린다고 생각한다. 디테일의 종류는 너무 다양하지만, 크게 보면 UI/UX, 코드 레벨 정도로 나눌 수 있겠다.
a. Layout Shift 방지하기
UI/UX 단에서 개인적으로 가장 신경쓰는 부분은 Layout Shift 방지이다. 화면이 갑작스럽게 툭툭 끊기는 경험은 사용자 경험에 치명적이라 생각한다. Layout Shift 가 발생될 수 있는 상황은 주로 비동기 API 를 호출할 때일 것이다. 이를 방지하는 방법은 상황에 따라 천차만별이겠지만, startTransition API 를 통해 리액트 내부의 UI 업데이트 우선순위를 낮추어 데이터가 준비가 되면 다음 보여준다던가, Skeleton UI 를 보여주는 등의 방법이 있을 수 있겠다.
b. 에러처리 잘하기
에러를 잘 관리하는 것도 굉장히 중요하다고 생각한다. 예상치 못한 런타임 오류로 인해 전체 앱이 뻗어버린다면, 결코 좋은 인상을 남길 수 없을 것이다. 따라서, ErrorBoundary 를 통해 선언적으로 에러를 처리하돼 가능한 작은 범위에서 잡고, 에러의 종류 (ex. 인증관련 오류 등)에 따라 잘 나누어서 관리하면 좋을 것이다. 에러 처리 관련해서는 우아한 테크 코스의 테코톡 영상을 추천한다. 마지막으로 react-query 를 사용한다면 QueryErrorResetBoundary 를 통해 재시도 로직을 추가하는 것도 좋을 것이다.
c. 폴더 아키텍쳐
코드레벨 단의 디테일에는 대표적으로 폴더 아키텍쳐가 있겠다. 즉, 어떠한 방식으로 프로젝트 폴더 구조를 구성할 것이냐인데, 기술 면접에 빼놓치 않고 물어봤었다. 나의 경우 FSD 를 개인적으로 선호하기도 하고, 실무에서도 FSD 를 사용하고 있기도 있기에, 큰 고민 없이 FSD 를 적용했다. 다만, 중요한 것은 FSD 와 같은 표준화된 아키텍쳐를 적용하든 말든 왜 이 파일을 이 폴더에 위치시켰는지에 대한 명확한 의도와 일관성이 있어야 한다. 이를 테면 FSD 를 사용한다면 “왜 이 컴포넌트는 shared 가 아닌 widgets 레이어에 위치하나요?” 와 같은 질문을 받을 수 있다.
기술 면접
2023년 말 첫 취업부터 불과 몇 주전까지 약 20 번의 스타트업, 중견기업, 대기업까지 면접을 봐 왔고, 여기서 느낀 점을 공유하고자 한다. 나름 여러 번 면접을 봐왔지만, 여전히 면접은 참으로 어렵고 아직도 잘하지 못하는 영역이다. 그래도 내가 그동안 모아 온 팁을 공유하고 싶다. 시작하기에 앞서 면접은 기술, 컬쳐 관계 없이 다다익선이다. 물론, 모의 면접도 좋다. 기회만 주어진다면 한 치의 고민 없이 무조건 보자. 한 번 면접을 볼 때마다 결과와 상관없이 내 자신이 가파르게 성장하는 것을 체감할 수 있다.
기술 면접은 크게 두가지 파트로 나뉜다. 이력서와 기술 파트. 이력서 파트는 자신의 이력서를 바탕으로 질의응답을 하는 시간이다. 기술 파트는 general 한 기술(ex. JavaScript, React 등)의 개념이나 Deep 한 내부 동작 원리를 물어보기도 하고, 특정 상황이 주어지고 그 상황을 어떻게 기술적으로 해결할 것인지 의견을 주고 받는 식으로 이루어지기도 한다. 각 파트별로 어떻게 준비하면 좋을지 살펴보자.
이력서는 line by line 으로 준비하기
이력서 파트는 내가 제공한 이력서에 기반하기 때문에 준비만 잘 한다면 면접을 유리한 방향으로 이끌어나갈 수 있다. 반대로 준비가 제대로 이루어지지 않으면 신뢰도가 매우 깎이니 혼신을 다해 철저하게 준비하자. 나는 이력서를 문장, 필요하다면 단어 단위로 분해해서 들어올 수 있는 모든 질문들에 대비하려고 했다. 조금 더 구체적으로 문장 단위로 준비하는 방법을 공유한다. 나는 각 문장에 대해 Why, What, How 를 정리하고, 필요에 따라 일부 키워드에 대해 Deep Dive 하는 방식을 채택했다. 예시로 나의 이력서에서 문장 하나를 가져와 보았다.
Code Splitting 및 Vite의 ManualChunks 등 번들링 최적화를 통해 초기 로딩 성능 개선하여 다양한 디바이스 및 네트워크 환경에 대응, LCP 기준 평균 초기 로딩 속도를 1.8초에서 1.2초로 단축
-
Why: 00 상용화 테스트 → 특히 00에서 테스트 중인데, 00 로 인해 대시보드 로딩 속도가 느린 문제가 있었음
-
What, How: 이를 해결하기 위해
manualChunks를 통해react나react-dom패키지와 같이 크기는 크지만 자주 변하지 않는 정적인 파일들을 별도의 번들로 분리, 브라우저 캐싱을 통해 새롭게 받아올 필요없이, 재사용할 수 있다.- 왜 정적으로 분리하면 속도가 빨라질까? → 브라우저 캐싱 전략 공부
- 추가적으로 splitting 하는 방식은?
- Code splitting 이외에 추가적인 최적화 방법이 없을까?
LCP말고 다른 성능 지표는 무엇이 있을까?- 왜 다른 지표 말고 LCP 를 측정했고, 어떻게 측정했을까?
위와 같이 Why, What, How 로 큰 틀을 먼저 잡아놓고, 틀을 채우는 과정에서 스스로 꼬리에 꼬리를 무는 질문들을 만들고 답한다. 꼬꼬무는 깊으면 깊을수록 좋다. 단, 한 문장을 가지고 이런 식으로 파고 들면 이력서 한 번 훑는데 굉장한 시간이 걸린다. (나의 경우 2-3일 정도 걸렸다.) 따라서, 나에게 주어진 시간이 얼마인지를 파악하고 꼬꼬무의 깊이를 결정해야 한다.
JavaScript Deep Dive
다음은 기술 파트다. 참고로, 우선순위는 이력서 파트가 더 높다. 이유는 이력서 파트는 무조건 면접에서 나온다. 그리고 준비할 수 있는 범위가 어느 정도 정해져 있다. 다만, 기술 파트는 준비해야 할 범위가 너무 넓기에 단시간에 준비한다고 해결되지 않는다. 따라서, 면접이 임박해있다면 이력서 파트라도 확실히 챙기는 전략을 추천한다.
기술 파트는 앞서 말했듯 크게 두 분류로 나눌 수 있다. 하나는 언어나 프레임워크(ex. JavaScript, React 등)의 개념이나 Deep 한 내부 동작 원리를 물어보기도 하고, 특정 상황이 주어지고 그 상황을 어떻게 기술적으로 해결할 것인지 의견을 주고 받는 식으로 이루어지기도 한다. 본 섹션(JavaScript Deep Dive)과 다음 섹션(React Deep Dive)은 전자에 대한 이야기다.
결론부터 말하자면, JavaScript 의 기본 개념 등에 관련한 직접적인 질문을 적어도 올해 면접에서는 경험하지 못했다. 즉, 그 아무도 나에게 “Closure 가 뭔가요?” 또는 “프로토타입이 뭐고, 클래스와 다른점이 뭐죠?” 와 같은 질문들을 하지 않았다. (2023년도에는 꽤 여러번 들었던 질문이었는데 말이다.) 그럼에도 불구하고, JavaScript 는 필수적으로 DeepDive 를 해야한다고 생각한다. 그 이유는 JavaScript 는 리액트라는 요리에 들어가는 기본 재료이기 때문이다. React Deep Dive 를 위해서는 JavaScript 의 필수적인 심화 개념들이 필요하고, 그렇기에 React 관련 질문이 들어온다면 누가 따로 물어보지 않더라도 자연스럽게 답변 속에 JavaScript 와 관련된 개념들을 언급할 수 밖에 없다. 예를 들어, useEffect의 클린업 함수가 최신이 아닌 이전 상태를 참조하고 있는 이유를 설명하기 위해서는 클로저에 대해 언급하고 갈 수 밖에 없는 것처럼 말이다.
JavaScript 는 왓에버를 통해 만난 프롬님의 도움을 많이 받았다. 매주 코어 자바스크립트 책을 기반으로 모의 면접을 진행했는데, 책을 읽었을 때는 분명 나는 이해했다고 생각했지만 막상 설명하라고 하니 막히는 경우들이 굉장히 많이 발생했다. 이를 보완하기 위해 면접이 끝나고 복기할 때 질문들에 대한 답변을 내 언어로 정리했다.
React Deep Dive
리액트는 크게 두가지 방식으로 Deep Dive 하려고 노력했다. 먼저, 왓에버 멘토링 기간 동안 미니 react를 직접 구현하면서 큰 그림에서 리액트가 어떻게 작동하는지를 파악했다. 이를 테면, jsx 는 어떻게 그리고 누구에 의해 ReactElement 로 변환되는지, useState 는 어떻게 상태값을 유지하는지, 어떻게 변경된 상태만 DOM 에 반영할 수 있는지 등을 직접 경험하면서 내부 동작에 대한 전반적인 흐름을 익혔다.
이렇게 흐름을 익힌 뒤 세세한 디테일들은 개인 공부를 통해 채워나갔다. 예를 들어, setState 를 통해 상태를 변경하면, 비동기적으로 변경이 반영되는 것은 익히 알려져있다. 그러면 setState 호출부터 commit 단계 이전까지는 어떤 일련의 과정이 일어날지를 파악해야 한다고 생각한다. 처음에는 이런 디테일을 잘 설명해주는 글을 찾아다니다 결국 React 코드를 직접 까보는게 가장 정확하다라는 결론에 달했다. 방대한 React 코드를 처음부터 까보기는 상당히 어려운데 React 톺아보기 시리즈 를 참고하며 큰 도움을 받았다. 그리고 글이 부담스럽다면 BOAZ의 React 까보기 시리즈 를 추천한다. (참고로 유튜브 영상 또한 React 톺아보기 시리즈에 기반한 것이다.) 처음에는 양이 너무 많아서 버거웠는데, 거의 2달 동안 매일 출근 전 리액트 코드를 봤고 어느 순간부터 전체적인 React 의 flow 와 그 속의 디테일들이 머릿속에 정리되기 시작했다.
마지막으로 최근에는 Tanstack-Query 관련해서도 질문을 많이 받았다. 따라서, 깊게 파악해야할 필요성이 있다. Tanstack Query는 어떤 문제를 해결하기 위해 세상에 나왔는지, 그리고 어떻게 이 문제를 해결하는지, 어떤 식으로 구현되어있는지를 공부했다. 내 추천으로는 조금 가격이 있지만, 나름 돈 값을 하는 query.gg 코스와 카카오 엔터테인먼트 기술 블로그를 통해 Tanstack-Query 와 관련된 지식을 충분히 익힐 수 있다.
깊게 고민하는 습관 갖기
이제 상황이 주어졌을 때 문제를 해결하기 위한 과정에서 의견을 주고받는 면접 타입(내 마음대로 상황 면접이라 부르겠다.)을 다룰 차례이다. 솔직히 상황 면접은 아직도 나에게 너무나 어렵운 면접이고, 명확한 해답을 찾지는 못했다. 주로 면접에서 주어지는 상황 자체는 그렇게 어렵지 않다. 하지만, 그 상황을 해결하기 위해서 + 꼬리 질문에 답하기 위해서는 기술에 대한 높은 수준의 이해도를 요구할 때가 많은 것 같다. 감이 잘 오지 않을 수 있으니 예시를 하나 들어본다.
Q. 좋아요 버튼이 하나 있다. 좋아요 버튼은 사용자 클릭시 서버에 좋아요 Post 요청을 보내고, 좋아요 아이콘의 색상이 파란색이 된다. 다시 한번 버튼을 누르면, 서버에는 좋아요 취소 Post 요청을 보내고, 아이콘의 색상이 제거된다. 만약 사용자가 좋아요 버튼을 매우 빠른 속도로 버튼을 누르다면 어떤 일이 발생할까?
A. 여러 개의 post 요청이 병렬적으로 진행될 것이고, 결과적으로 어떤 요청이 resolve 될지 모르기 때문에 race condition 이 발생할 것 같다.
Q. 이 race condition 을 방지하기 위해서 어떤 action 을 취할 수 있을까?
...
(이런 식이다.)
내가 생각했을 때 이런 상황 문제를 헤쳐나가기 위한 유일한 해결책은 프로젝트나 실무에서 디테일을 챙기는 습관을 가지는 것 밖에 떠오르지 않는다. 즉, 단순히 기능 구현에 그치지 않고, 더 나은 사용자 경험을 위해 고민하다 보면 자연스레 이 부분에 대해 준비가 되지 않을까 라고 생각한다. 나도 이 부분이 부족하고, 이러한 습관을 만들려고 노력하고 있다.
컬쳐 면접
컬쳐 면접은 앞서 1편에서 정의한 내가 회사를 선택하는 기준과 굉장히 밀접한 관련이 있는 전형이라는 생각이 든다. 나의 기준과 일치하는 회사일 수록 컬쳐 면접에서는 그렇게 준비할게 많지 않다. 왜냐하면 지금까지 나의 기준에 따라 경험을 쌓아왔기 때문에, 그 경험을 면접 때 잘 풀어내기만 하면 된다. 반대로 나와 다른 성격을 가진 회사의 컬쳐 면접을 볼 때는 나의 경험들을 그 회사의 기준에 끼워 맞춰야 하고, 여기에 드는 가공 시간 때문에 상당한 시간과 노력이 필요하다. 컬쳐 면접은 솔직히 많은 경험을 갖고 있지는 않다. 그래도 최근 여러 개의 컬쳐 면접을 보면서, 느낀 점들을 간략하게 공유한다.
면접은 상대방을 설득하는 시간
불과 얼마 전에 깨달은 것인데 면접은 절대 누가 더 말을 유창하게 잘 하냐의 싸움이 아니다. 그보다는 말을 좀 절더라도 결론적으로 면접관을 설득시켰냐에 따라 결과가 결정된다고 생각한다. 그러면 어떻게 면접관을 설득시킬 수 있을까? 이 부분에 대해서는 나는 내 진심을 전달하는 방법 밖에 없다고 생각한다. 물론, 너무 솔직하면 문제가 될 수 있지만, 1) 내가 겪은 실제 경험을 근거로 2) 이 회사에 잘 맞는다는 것을 증명 해야한다. 회사에 잘 맞는다는 것이 무엇일까. 대부분의 회사 채용 홈페이지에 들어가면 회사의 핵심 가치나, 팀과 문화 등 회사에 대한 정보를 제공한다. 만약 공개된 핵심가치가 있다면 핵심가치를 나열하고 핵심가치에 해당되는 자신의 경험을 맵핑한다. 끝이다.
퇴사 이유
퇴사 이유는 컬쳐 뿐만 아니라 기술 면접에도 100% 나오는 질문인데, 항상 어렵다. 정말 드문 케이스를 제외하곤 어떤 답변을 해도 절대 한 번에 설득시킬 수 없다. 따라서 꼬리질문이 이어질 수 밖에 없고, 이런 꼬리 질문은 상대방이 아직 납득이 되지 않았다는 증거이자 아직 설득시킬 수 있는 여지가 있다는 뜻이다. 따라서, 최선을 다해 상대방을 설득시켜야 한다. 설득시키려면 솔직해야 하고, 솔직하려면 이에 따른 자신의 경험에 기반한 근거가 있어야 한다.
마무리
내가 작년에 쓴 2024년 회고 에서 일부를 가져왔다.
내가 좋아하는 그림이 있다. 린스타트업이라는 책의 표지인데 대학교때 한 스타트업 강의에서 강사분께서 알려주신 책이다. 내용은 안봤다. 린스타트업의 핵심은
빠른 속도,피드백,반복이다. 즉, 제품을 MVP로빠르게출시하고,피드백을 받고, 이를 바탕으로 개선하는 과정을반복하여 스타트업이 성장하는 그림이다. 취업/이직 아니, 모든 것이 이 원칙대로 돌아간다라고 생각한다. 개발자의 취업 프로세스는 서류, 코테, 기술 면접, 컬쳐 면접으로 주로 이루어져 있는데, 이 과정을 모두 통과하고 최종합격을 받으면 그때가 하나의 사이클인 것이다. 그리고 풀사이클을 돌았을 때 비로서 일종의 관성 즉, 자신감을 갖게 된다. 다만, 여기서 주의할 점은 한번의 사이클이 끝났다고 안주하거나 포기하면 안된다. 최종 목표가 있다면 여기서 다음 사이클을 돌아야 진정한 사이클의 의미가 있다.
기나긴 과정 끝에 하나의 사이클을 끝낸 것을 진심으로 축하한다. 이제 앞서 정의한 나의 기준에 따라 객관적으로 결과를 평가한다. 평가 결과에 따라 사이클을 종료하고 새로운 곳에서 여정을 시작할 것인지, 아니면 나의 기준에 좀 더 부합하는 회사를 찾아 새로운 사이클을 시작할지는 본인의 선택이다.