3년차 개발자의 이직 후기

3줄요약

장장 4달 걸쳐서 이직 진행했던 내용을 복기하며 정리해놓다 보니, 너무 본문이 길어졌다 -_-;; 3줄 이상은 누구라도 읽기 싫으니 3줄요약 별도 작성.

• 포지션 지원을 위해, 본인의 주력 position을 알아야 함 (의외로 모르는 경우가 있다... 적어도 나는 몰랐는데...)
• 대부분 면접 떨어진건 본인 fit이 직무와 안 맞아서 그렇다고 생각하면 됨, 자신의 실력을 탓할 필요는 없다. 면접관 및 포지션 따라 평가 방법과 기준도 다르기 때문에 더더욱 그렇다. 다만 별개로 interview시 부족한 점은 파악해서 고치는 게 좋음.
• algorithm 공부만 할게 아니라, software design 공부 및 algorithm interview 연습을 해야 함 (ppt 만들어서 하면 좋음)

Prologue

나는 훌륭한 Software Engineer이 되겠어! 라는 목표가 있었고, 그 신념에 따라 (나름) 열심히 공부하고 새 트랜드를 좇아가며 살았다. 그 성과로 사이드 프로젝트도 이것저것 해 봤고, 지금은 회사에서 나름 훌륭한 개발자로서 인정받는 것으로 보인다는 것이다(아닐수도 있다. 내 착각일지도~). 하지만 내 목마름이 가시지는 않았다. 소프트웨어 개발자만큼 페이가 천지차이가 나는 직종이 몇 없을 것인데, 흔히 말하는 탑 클래스의 봉급은 하위 클래스의 몇 배를 받는다. 개발자 세계에서는 봉급이 곧 실력이라는 풍조가 있다. 틀린 말은 아니다. 그만큼 밥값을 하기 때문에 그 비싼 돈을 주고서라도 고용하는 것이다. 그렇다면 그 탑클래스들과 보통의 개발자들은 어떤 차이가 있을까? 막연히가 아니라 구체적으로 알고 느끼고 싶었고, 또 그들이 사는 세상이 알고 싶었다.

그래서 지금 있는 우물에서 나와 더 높은 세상을 보기로 했다. 기대가 크면 실망하기에 일단 꼭 붙지 않아도 괜찮은 걸로 목표를 정했다. 더 위에 있는 사람들과 만나서 이야기 할 수 있는 기회를 가지고, 깨달음을 얻을 수 있으면 그걸로 소기의 목적은 달성한 것으로 하기로 했다.

면접을 보다 보니 Output도 중요하지만 Delta도 중요하다는 걸 알 수 있었다. 다시말해, 행동을 결과도 중요하지만 행동을 하게 된 경위 또한 중요하다는 말이다. 왜 이러한 결정을 내렸는지에 대한 이유가 없이 행동만 한다면 그건 Engineer의 덕목이 아니라 막말로 SI 개발자에 불과하게 되는 것이고, 면접관들도 이를 알기에 평가의 중요 요소이다. 그렇기에, 이 앎을 실천에 옮기고자 나의 Delta를 상세하게 글로써 남겨보려고 한다.

참고로 시기가 시기이고 어느정도 이 분야가 어느정도 고착화된 상황이라 이직 자체가 쉽지 않았다. 들은 이야기로는 나 정도면(?) 잘 될법한데 결과적으로는 잘 안되어서 솔직히 좀 좌절감이 들기도 했지만... 영걸전에서 조홍이 말한대로, "좌절감이 사나이를 키우는 것이다!"... 배우는 기회라고 생각하면서 복기했다. 적어도 기회 앞에서는 최선을 다했다 ㅎㅎ;

여튼 하고 싶은 말은, 이직의 꿈을 꾼다면 실력 이전에 시장 상황에 따라서 결과가 크게 달라질 수 있으니 이 점 또한 고려대상에 포함해야 한다는 것.

참고로,

• 본인은 이직 전에는 국내의 T모 DBMS 회사에서 일했다.
• 이직 시점에서는 웹 서비스 시장과 머신러닝의 수요가 폭발적으로 증가하여 사실상 백엔드/프론트엔드/MLOps/MLEng 구직자리만 넘쳐났음
• 따라서, 일자리가 폭발적으로 늘었다고는 하지만 로우레벨 소프트웨어 엔지니어에게는 적합한 포지션은 별로 없었다 (이게 패인 😭)

이력

1. 모 BioInformatics 회사 - 첫 이력서, 서류 탈락

이건 제대로 된 이력서를 쓰기 이전의 일. 이메일로 두달 전 헤드헌터에게 연락이 왔었는데, 생명정보공학 석사 경력이 혹시 Fit이 맞을까 하고 지원해 봤다.
결과는 서류탈락. 스펙은 그런데로 마음에 든다고 하지만, 내가 다녔던 곳은 소프트웨어 개발직군이니 안 맞는게 당연하다. 그러려니 했다.

이후에 Toss AI Engineer, Google Software Engineer, MS Software Engineer 등에 넣어봤지만 모두 서류 불합. AI는 Fit 문제였을 거고, 나머지는 어마무시한 인재들이 있는 특성상 경력부족일 것이다.
Software Engineer 쪽은 풀이 적었고, 링크드인에서는 왜인지 AI 구직 공고만 잔뜩 뜨더라. 내 경력에 맞는 Software Engineer 분야는 하나도 안 보였다.
(이후에 알게 된 거지만, 일부 대기업들은 구직공고를 자기 회사에만 올려놓는 경향이 있다. 관심 있는 기업들이 있다면 해당 기업의 recruit 사이트가 있는지, 있다면 가서 직접 확인해 봐야 된다.)

아 이렇게 내 도전은 이대로 끝이 나는가. 낙담한 심정으로 어찌할까 주저하던 찰나에, 아는 지인분의 LinkedIn을 참조해 보았더니 굉장히 깔끔하게 작업 내역이 정리되어 있었다. 이를 바탕으로, 내 이력서를 수정해 나가게 되었다.

2. Intermediate - 정체성 찾아가기, 그리고 계속되는 Resume 수정, 면접 준비

처음에는 신규채용 지원서 쓰던 경험을 되살려 분량 채운다고 열심히 써놨지만 전문성이 하나도 없었다. 경력직은 철저하게 업무 연관성만 보기 때문에 짧은 페이지에 내용을 써내는 것이 중요하다는 걸 알았다. 그래서 서술형을 개조식 형태로 바꾸었다.

동시에 나의 정체성을 찾아나가기 시작했다. 지금까지 단순 개발자인줄만 알았던 나는 시장에서 흔히 일컫는 말로는 Backend Engineer 였다. (지금까지 그것도 몰랐다!!). 하지만 내가 원하는 나의 모습은 Software Engineer 였다. 그리고 이 둘은 분명 차이가 있었다. 그렇다면, 내가 Software Engineer의 자질이 있음을 보여줄 수 있어야 했다. 둘의 차이점을 열심히 구글링해 보았다. 코드 유지보수와 TDD 등 얼핏 알고만 있던 내용들이 나왔다. 이들을 다룬 서적도 찾아 읽어봤다(Working with Legacy Code, Refactoring 2 등). 그제서야 깨달음이 왔다. 분명 개발을 하면서 뭔가 답답하다고 생각하고는 있었지만 이유를 모르는 것들이 한두가지가 아니었는데, 책의 저자는 알고 있었고, 책을 통해서 알 수 있었다. 동료를 통해서 배울 수 없다면 책을 통해서 배워야 함을 너무 늦게 알았다!! 동시에 내가 당연하게 생각해 왔던 작업들이 전혀 당연하지 않았다는 것을 알 수 있었다. 다시 말하면 잘 모르고 작업한 것들 투성이였다.

그렇게 내 자신의 정체성을 찾아가며 아키텍쳐에 대해 다시 되짚은 내용을 기반으로 이력서를 갈아엎은 결과 훨씬 보기 쉬워졌다.

이를 토대로 링크드인 자기소개 및 빈칸을 채워넣고 나니 본격적으로 슬슬 헤드헌터들에게 연락이 오기 시작했다.
(하루 조회수가 평균 5명이었는데, 키워드를 수정하고 나니 50~60회로 확 늘었다.)
헤드헌터들의 안목은 얼추 정확하기 때문에, 이들을 통해서 서류를 넣으면 불합격은 거의 없는 듯 하다.
실제로 이후 서류에서 불합격은 없었다. 하지만 좋은 것만은 아닌게, 그럼 그만큼 면접을 보러 시간을 내야되는 거니까 ... 어느 정도의 선택과 집중이 필요하다. 버릴 건 과감히 버려야 한다. 실제로 들어온 제의를 전부 받을 수가 없어서, 최대 동시진행 상한치를 4개로 두고 진행해 나갔다. 사실 생각해보면 이것도 너무 많았고, 2개 정도가 인간적인 한계치가 아닐까 생각한다. 쳐낼 건 쳐내자.

어느 정도 진행중인 기업들의 가닥이 잡히자, 면접 준비에도 들어갔다. 보통 아래 작업들을 했다.

• 가상의 질문 만들어서 답변 정리 (이직 사유, 이력 기반의 자기소개, 이 포지션에 지원한 이유, 본인의 장단점, 역경과 고난 등)
• 이력서에 적은 내용들에 대한 답변 정리
• 회사의 가치(간접적인 재무재표 확인해보기), 포지션 상세 정보(요구 스킬셋, 하는 일) 알아두기

답변들은 가능하면 두괄식으로 깔끔하면 좋고, 무엇보다 철저하게 자기어필이 되어야 한다. 단순히 이러이러한 일을 했어요~ 가 아니고, 더 나아가서 선택했던 Toolset에 대한 이유, 문제 해결을 위해 고민한 내용, 문제 해결을 넘어서서 이를 재발 방지하기 위해 고민했던 사항들 등이 들어가야 만족스러운 답변이 될 것이다.
물론 지금 다니는 회사에서 이러한 가치를 중시하지 않을수도 있다. 그래도 혼자서라도 이러한 가치들에 대해 고민해야 한다. 다만 주변 사람들에게서는 그러한 정보를 전혀 얻을수가 없어, 개발자 커뮤니티(velog 등...)와 위의 책들에서 정보들을 얻을수가 있었다.
시간과 기회가 된다면, 이왕이면 자신에 대한 발표자료를 약 30분 ~ 1시간 분량으로 만들어 보는 것도 큰 도움이 된다 (K사에서는 하라고 시킨다). 질문에 답변하는 수동적 입장에서 준비하는 것과 능동적 입장에서 준비하는 것은 분명 다르기 때문에 미처 고민하지 못했던 것들을 쉽게 찾을 수 있다.

다만 지금 생각해보면 경력직 이직인 만큼, 아래 사항들에 대해서도 준비했다면 더 좋았을 것 같다.

• 코딩 인터뷰 준비
• 소프트웨어 아키텍쳐 관련 인터뷰 준비

코딩 인터뷰의 경우는 단순 알고리즘 해결보다 풀이과정을 중시하기 때문에, 단순 문제풀이 사이트에서 문제를 푸는 것보다는 알고리즘 인터뷰 문제 모음집 사이트나 책을 찾아 읽으면서 사고 논리를 어떻게 설명하는지를 공부할 필요가 있다. 소프트웨어 아키텍쳐의 경우도 비슷하게 인터뷰 사례와 함께, 경력에 해당하는 / 본인이 희망하는 포지션에 대한 아키텍쳐를 설명할 방법과 관련 스킬셋 준비를 해야 한다.

생각보다 머리를 많이 굴려야 하는 작업들이라 몰아서 하기보다 평일에도 꾸준히 시간 내서 정리하는 게 좋은 것 같다. 영감이 떠오를때마다 적어놓고 고쳤다. 어디선가 들은 말인데, 당장 필요가 없지만 언젠가 해야 하는 미뤄왔던 일이나 공부는 결국 비참한 형태로 하게 되어있다고 그랬다. 3년간 날로 먹은 커리어에 대한 고민은 이렇게 비참하게 하는 것이었다!

3. 모 핀테크 기업 - Coding Interview 탈락

싱가포르 소재지의 한국 지부가 있는 스타트업 느낌의 기업이었다. 사업 확장을 한다고 해서 개발자를 뽑는다고 하더라.
전혀 새로운 분야에 상세한 작업 분야를 모르니 솔직히 막연했다. 그래도 돈은 많이 줄 의향이 있다(?)고 하고, 일하는 동료들도 최고 수준이라고 해서 좋으면 좋았지, 나쁠게 없었다. (빠르게 변화하는 개발 문화를 따라가야 하는 이 바닥 특성상 개발자들은 서로 동기부여가 될 수 있는 동료가 있는 게 중요하다)

1차 면접은 코딩 면접이었다. 으레 코딩 테스트 하면 과제를 풀고 이를 채점 솔루션이 갖춰진 의뢰 사이트에 업로드하는게 일반적인데, 여긴 화상으로 면접하며 알고리즘 문제를 풀어나가는 자리였다.
그런데 처음 보는 분류의 문제가 나왔다. 정렬된 수들의 배열이 있는데, 하나의 숫자 빼고 나머지가 짝수번 등장할 때 홀수번 등장하는 숫자를 찾거나 / 나머지가 홀수번 등장할 때 짝수번 등장하는 숫자를 찾는 문제였다.
이 바닥에선 유명한 문제인가 보다. 이른바 Find the Number Occuring Odd Number of Times [https://www.geeksforgeeks.org/find-the-number-occurring-odd-number-of-times/ #] / Even Number of Times 라고 하더라.
단순무식하게 푸는건 당연 쉬운데, Memory Complexity O(1) 및 Time Complexity O(n)으로 푸는 솔루션부터 Time Complexity O(logN) 까지 물어봤다. XOR을 알고리즘 문제 푸는 데 쓸 거라고는 상상해본적도 없었고, Pivoting을 Element Counting 할 때 쓸 거라고도 상상을 못해봤다.

솔직히 문제를 풀면서 많이 당황했다. 그래프 유량 문제, 다이나믹 알고리즘만 잔뜩 풀었는데 정작 단순한 문제를 풀지를 못했다.
동시에 어떤 알고리즘을 설명하는 것에 대해서 고민해 볼 필요가 있었다. 첫번째로 당시 알고리즘 인터뷰에 대해서 전혀 대비를 못해서 사고과정을 설명하지를 못하고 혼자 끙끙대기 일쑤였고, 두번째로 항상 알고리즘을 푸는게 중요하다고만 생각했지 이걸 어떻게 효율적으로 설명할지에 대해서는 생각해 본 적 없었다. 당연하지만 잘 알고 있다면 설명할 수도 있어야 하고, 또 협업이 중요한 개발자 특성상 그래야 한다. 당연하게 생각하고만 있던 걸 나는 잘 못하고 있었다. 고쳐야 할 점을 또 하나 찾았다.

• 결과: 코딩 인터뷰 탈락

많은 가르침을 받고, 깔끔하게 1차 면접에서 떨어졌다... ^^;

4. N사 - 1차 면접

Search 엔진 개발 업무였다. 아주 커다란 시스템을 관리하고 최적화 해야 했다.
매년 컨퍼런스 같은 데에서 연구성과를 발표하기도 하는 것 같았다. 중요해 보였고 재밌어 보여서 커리어에도 도움이 될 것 같았다.
3명의 사람들과 면접을 보았다. 각각 1시간이니 총 3시간이다.
3시간 면접 보는거 생각 이상으로 힘들다. 물이나 음료 준비하고, 목소리도 최대한 톤을 낮춰서 말하는 게 좋다 (안 그러면 목 나감...)
아, 참고로 화상 면접이다. 코로나 시즌이라 밑에 있는 면접들도 죄다 집에서 화상면접으로 진행하였다.
처음엔 별 준비없이 노트북 올려다놓고 했는데(이 면접 포함), 이후 방구석이 너무 지저분해서 배경으로 간단한 블라인드 쳐서 가리고, 노트북은 밑에 깔개를 넣어서 화상카메라가 눈높이까지 올라올 수 있도록 하여 기본적인 면접 매너(?)를 갖췄다.

1번째 면접

팀장님이라고 자신을 소개하셨다. 두루두루 물어보셨다.

• 지원 동기
• multithread에서의 유의 사항 (data race 등)
• C++에서의 singleton 패턴
• 홀수 번 나타나는 정수 찾기 (이거 단골 질문인가..?)
• OOM 발생했을 때 어떻게 대처할 것인가? (그냥 자유롭게 헛소리 함)
• 개발 도중 힘들 때 어떻게 극복하는지? (스트레스 관리 방법?)
• 추가 질문 겸 잡담시간...

2번째 면접

주로 기술면접이 이루어졌다.

• PL/SQL 런타임
• Bison의 LR/LALR/GLR 질문 (순간 당황해서 다 까먹음. 아는 키워드 조금이라도 대면서 말했어야 했는데, 아쉽다.)
• ANN 질문 (너무 간단하게 모른다고 대답해버림 ...)
• GC (구현까지 해본적 있다고 하시니 그냥 pass 당함)
• 지원 동기?

3번째 면접

여기는 팀장을 리더분이라고 부르는 것으로 보인다. 코드 디자인에서의 질문을 상당히 깊게 물어보셨다.

• 간단한 알고리즘 (O(n) 해결책을 요하는 알고리즘인데 바로 생각하기에는 조금 어려울지도 ...)
• iterator 문제점 분석
• multithread에서의 queue 인터페이스 문제점 분석

첫 심층면접이었는데, 못 봤다는 느낌마저도 들지 않았다. "면접을 봤는데, 내가 뭘 평가당한 거지?" 라는 생각만 되뇌일 뿐이었다. (당시에는) 의도를 모르니 전략 없이 되는대로 내뱉을 수밖에 없었다. 지금 생각해보면 C++ 코드의 민감성, 소프트웨어 디자인을 설명할 수 있는 능력, 기술적인 능력(ANN 등)에서의 Fit check 정도가 있을 것 같다. (그런데 지금 생각해도 PL/SQL 아키텍쳐에 대해서 질문한 것은 도저히 이해가 되지 않는다. 나랑 전혀 관련없는 내용인데 기술면접의 대부분이 그 내용이었다. 혹시 내가 이력서를 잘못 썼나..?) 그 이외의 것에 대해서는 전혀 질문이 오지 않았다. 내가 주로 해왔던 Test Driven Development와 발생한 문제의 해결 과정, 레거시 코드 유지보수, 이슈트래커 같은 것들에 대해서 어필을 전혀 하지 못한 점이 아쉬웠다. 시스템 이해도 및 C++ 숙련도 연관 질문만 계속 답하는 시간들이었다. 이것도 지금 생각해보면 마지막 질문 시간때 어필했어야 했던 것 같다!

그리고, 두괄식으로 열심히 답변했는데 시원치 않은 느낌이었다. 질문이 들어오면 두서 없이 답변하는 문제를 고치기 위함이었다. 답변 나름 열심히 한다고 했는데, 당시 두괄식으로 말하기에 너무 치중해 있었던 나머지 요점만 위주로 말한 탓이었나, 뭔가 서먹한 느낌의 분위기가 조성되었다. 면접관님들이 당연히 세부사항을 물어보실 줄 알았는데, 그렇지도 않았고...

이때도 아직 이직 준비가 완성되지 않았던 때였다. 이력서를 난잡하게 썼던 만큼 난잡하게 물어 보았다. 당시 내가 했던 일들을 elegant하게(업계 용어를 사용해서) 잘 표현하지 못해서, 소소한 개발작업까지 다 적어서 이력서에 적었다. 그러다 보니, 내가 제일 중요시하는 가치를 어필하지 못한 게 확실히 있었다.

그리고 팀장분이 책 좀 읽어봤냐고 물어보셨던 것이 나에게 가벼운 충격을 주었다. 생각해보니 근 몇년간 개발서적 포함 책을 단 한권도 읽지 않았다. 면접에서 불어본 내용도 가만 생각해보면 코드 디자인 관련 서적이나 More Effective C++ 서적 내용들이 꽤 있었다. 그나마 저것들을 읽어본 적이 있어서 어느정도 답변은 할 수 있었지만, 가만 생각해보니 내가 잘 한다고 이야기 할 수 있는 언어나 분야들 중 관련 서적을 읽어놓은 게 단 한권도 없었다. 그때그때 문제가 발생하면 필요한 것들만 찾아 놓으니 깊이가 너무 얕았다. 이 때부터 나에게 필요한 서적들을 찾아 읽어나가기 시작했다.

• 1차 불합격으로 마무리

5. K 엔터프라이즈 회사

K카오의 면접 프로세스는 까다롭기로 악명이 높다.

보통 아래 과정으로 진행되는 것 같다. 경력자도 얄짤없이. 회사다니면서 다 해야 한다.

코딩 테스트 --> 전화 면접 --> 과제 전형 --> 1차 면접 --> 2차 면접

코드 테스트.

팀바팀이라고는 하는데, 굉장히 빡셌다. 6시간짜리 코드 테스트는 ... 태어나서 처음 해본다.
문제는 당연히 유출할 수는 없고, 다만 데이터 프로세싱에 관한 과제가 인상깊었다. 꼼꼼히 스펙 파악 하지 않으면 틀리게 되어 있다. 시스템에 대한 이해와 기본적인 코딩 능력에 대한 평가를 하기에 이렇게 훌륭한 문제였다고 생각한다.
뭐 이외에 기하랑 2D map에 대한 검색 문제인데 BOJ 좀 해본 사람들이면 충분히 풀 수 있다만... 나는 너무 힘들어서 그냥 하나 Timeout 내고 말았다 -_-;
그래도 통과는 시켜주더라. 크게 특이사항도 없었는지 코테에 대한 질문 또한 이후에도 없었다.

다만 지금 생각해보면 아쉬운 점이 있다. 근래의 코딩 테스트 솔루션들은 대부분 녹화 기능을 가지고 있는데 (Autocomplete 되는 것이면 거의 빼박이다), 이는 코딩테스트는 정답 뿐만 아니라 풀이과정 또한 중요하게 여긴다는 뜻이다. 당시 잘 몰라서 외부 IDE에서 작업하고 코드를 거진 복붙한 후에 다듬는 작업만 했는데, 그렇게 할 게 아니고 사고방식을 주석으로 남겨가면서 IDE에다가 코드를 짰어야 했다. (그게 다 기록이 된다)

그리고 전화 면접. 상급자 분들 두분과 짧막하게 질답 시간을 가졌다.

• Big data processing을 하기 위한 효율적인 방법에 대한 설계 (failure 설계 등)
• Sharding 설계 (해싱 등)
• C 언어 (포인터배열/배열포인터... 순간적으로 생각이 나지 않음!!), c++ rvalue reference에 관한 질문

정말 본인 이력이 맞는지 확인하는 수준의 간단한 인터뷰였다.

과제 전형

그리고 과제 전형인데... 보자마자 경악을 금치 못했다.
검색엔진을 만들라는 문제였는데, 내 머리로는 아무리 생각해도 훌륭한 해답이 나오지 않아서 밤낮이고 엄청나게 고민했다. 그래도 나름 데이터 분석까지 수행해가면서 해 보려고 했는데... 솔직히 일 다니면서 하기 너무 힘들었고, 개인 컴퓨터에 분석툴 같은게 거의 없어서 예전 대학원 다닐때처럼 다시 세팅도 제대로 할 힘도 없었다.

여기서 끝나나 싶었는데 용케 다음 과정으로 진행됐다. 아니, 생각해보면 여기서 끝났어야 했다. 어차피 결과물을 보면 fit이 안 맞을걸 알았을 텐데 말이지.

동시에 지금 생각해보면 난 이 과제 면접이 소모하는 시간이나 정신력이나 너무 부담이 큰 것 같다. 열정도 중요하지만 어차피 실력 없으면 기업에서 뽑을 이유가 없다. 다음에 또 과제 면접을 하게 된다면 과감하게 시간할당해놓고 그 비용이 너무 커지면 쓰로우 할 생각이다.

1차 면접

1차 면접도 쉽지는 않았다. 일단, 과제 전형과 내 이력에 대한 발표자료를 준비해야 했다. 시작부터 난관이다. 안그래도 집 컴퓨터에 ppt가 없어서 구글드라이브로 엉성하게 썼다. (이후에 다시 갈아엎었다)

그래도 2주 텀이 있어서 나름 2주간 방에 틀어박혀서 열심히 준비했다. 이력서 내용을 다시 준비하다 보니 부족한 부분이 또 수십곳은 발견되었고, 고치는 작업을 계속했다.

1차 면접은 수많은 사람들이 들어와 주셨다. 거의 7:1의 압박면접(?) 분위기였지만 실제로 들어오는 질문은 전화면접의 그 두분이 대부분이었다. 들어가서는 과제 전형을 열심히 발표했고, 역시 많은 태클이 걸렸다. 많은 피드백이 오고 갔지만 주된 논점은 바로 데이터에 대한 관점이었다. 나는 데이터를 단순 binary stream으로 보았는데, 그 분들은 분산시스템을 고려하여 data의 semantic 위주로 접근하길 원했다. 보는 관점이 완전히 달랐고 이렇게 나는 또 한수 배웠다. 아, Data Engineering이 이런 것이었구나. (이건 이후에 찾아보고 알았다. 이런 분야가 있었는줄도 몰랐다!!) 그리고 Tech Stack이 정말 많이 다르다는 것을 느꼈다. 다르게 말하면 일하려면 정말 많이 공부해야겠다는 생각이고, 직설적으로 말하면 잘못 지원했구나!. 이력 발표는 뭐... 별 특이사항 없었다.

다만 3시간 넘어가도록 거의 계속해서 말을 하고 있으니 목에 슬슬 무리가 가는 것이 느껴졌다. 콜라 열심히 먹어가면서 했지만 그래도 힘들다. (지나서 생각해보면, 톤 자체가 너무 높았다. 이후로 의식하면서 목소리 톤 조절을 하니까 오래 말해도 훨씬 괜찮았다.)

그래도 분위기 자체는 그렇게 나쁘지는 않았다. 엄밀히 말하면 오답을 들고 왔지만 면접관 분들이 나름 tolerant 해주신 것 같다. 분위기랑 별개로 Fit에서 문제가 있는 상황이니, 좋은 처분을 기대할 수는 없었다.

2차 면접

짐작대로였다. 앞선 인터뷰에서 부족한 자질이 드러난 만큼 다른 포지션으로 면접을 옮겨서 진행하겠다는 통보를 받았다. 하지만 나 자신도 자질이 부족하다는 것을 느끼고 있었기에, 이 점은 인정하고 있었고, 아니 오히려 실무를 해야하는 입장에서는 이쪽이 더 적합할 것 같았다. 그리고 여전히 내가 관심있는 팀이기도 하였으니. 여전히 배울 점은 많았다.

사실 이건 2차 면접이라기보다는 1차 면접의 연장선에 가까웠다. 앞선 사정상 기술 검증도 어느정도는 이루어져야 했기 때문이었다. 실제로 들어온 질문들도 대부분이 기술 면접이었다. 하지만 1차 면접보다는 확실히 덜 치밀한 질문들이 들어왔다. 아무래도 시간 자체가 짧기 때문이기도 했을 것이다...

기술 분야 질문

아무래도 해야 하는 일이 frontend도 일부 섞여있다 보니 관련 기술들을 얼마나 다룰 수 있는지에 대한 질문이 들어왔다.

• 자기소개 간단하게 하고... 이 쯤 되니 자기소개 하는 기계가 된 것 같다.
• 우리 포지션에 지원한 이유?
• REST API 관련 질문 - 해당 포멧이 무엇이고 왜 쓰는지, Cacheable의 강점에 대해서 설명했다. 내가 중요하게 생각하던 부분들을 쭉 이야기함.
• 웹 페이지를 로드할 때 어떠한 일들이 일어나는지에 대해서
  • 전 질문을 받고 나서 정신이 없어서 HTTP 프로토콜을 통해 데이터를 주고 받는다는 것만 설명해 버렸다. DOM을 통째로 이야기 안한게 너무 아쉽네.
  • 이외에도 HTTP request header field 관련 질문들이 몇개 나와서 대답했다.
• Golang의 Goroutine이 pthread와 어떻게 다른지?
  • Golang의 문법 정도만 알아가는 처지라 심도깊은 이야기를 전혀 할 수가 없었다. 다만 OS 쓰레드를 그대로 쓰는 것이 아니라 Golang framework 위의 경량화된 구조로 이용한다고 아주 얕은 이야기 할 수 있었을 뿐...
• VM과 Docker 차이는?
  • Docker이 Microkernel 이용하여 보다 경량화된 구조로 부담이 적다고 간단하게만 이야기 함.
• 시스템적인 측면에서의 Docker 내부 구조나 구현에 대해서 아는지?
  • 모른다라고 말할 수밖에 없었다. 분명 시스템 측면의 이슈가 꽤 있는걸로 아는데, Docker/kubernetes로 서비스하는 입장이 되어본 적이 없으니 ... 이 부분은 클라우드 기술이랑 담 쌓을게 아니라면 당장 면접이 아니더라도 차후 공부가 필요하다고 느꼈다.
• 분산시스템 써 본적이 있는지?
  • 없다. 분산시스템 아키텍쳐에 관심이 많고, 분산 데이터베이스 개발 같은걸 해봤다 식으로 얼버무려 이야기 해두었다.
• 분산시스템을 써본적 없는데, Docker을 활용해 본 적 있는지?
  • 분산시스템은 아니고 CD(Cont. Distribution)을 위해 적극 활용한다고 이야기해 주었다.

인사 쪽 질문

• 팀장하면서 가장 힘들었던 일이 무엇인가?
  • 으레 팀장 커리어가 있으면 다들 물어보는 질문으로 보인다. 별 꾸밈없이 있는대로 이야기를 했다. 주로 팀원들과의 의사소통, 협업, 그리고 팀의 방향성에 대한 이야기들.
• 통상적인 질문 몇 가지
  • 회사 다니면서 힘들었던 일 (극복내용 포함해서 서술)
  • 개발의 어떤 점에서 보람을 느끼는지 (완성품이 나올 때..?)
  • 화나는 상황이 있는지 (정말 솔직히 찐텐으로 화난적은 거의 없어서 그렇다고 이야기는 했지만...)
  • 야밤에 긴급이슈가 발생했는데 타 모듈이면 어떻게 대응할 건지 (내 이슈는 아니지만 자료수집 등 해줄 수 있는 부분은 선행해줘서 신속하게 처리할수 있도록 해준다. 책임감이 중요하다는 어필을 조금 더 할걸 그랬다. 이건 응당 그래야 하기도 하다. 역으로 당해보면 참 화가 많이 난다...)
  • 회사에서 커리어에 도움이 안 되는 일들을 하게 된다면? - 커리어에 도움이 안 되는 일은 없다는 나의 논리를 적당한 예를 들어서 설파. (그런데 이런 질문은 왜 하는 걸까? 말이야 그렇지만 정말 구질구질한 일만 하게 된다면 적어도 이 포지션이면 다 도망갈텐데 + 악평이 올라갈텐데, 이걸 인지하고 문제 요소 파악 후 컨트롤 해주어야 하는 윗단 역할이 중요하다고 생각한다. 충성도 테스트인가...)

본래 진행하려던 포지션과 달라졌기도 하고, 해당 포지션의 skillset이 내가 가지고 있는 skillset과 다소 다른 점이 있어서 다소 얕은 깊이의 대답밖에 할 수 없었던 게 참 아쉽다. 질문들이 그렇게 어렵지 않은 내용들이라 더더욱 그렇다. 일단 내가 하고 싶은 이야기와 아는 한에서의 답변은 다 했으니, 처분을 기다려 본다.

• 결과: 불합격
  • 2~3일만에 결과가 왔다. 이제 확실히 알 수가 있었는데, 데이터 엔지니어 분야는 관련 지식 없으면 절대 안 뽑는다. 어떻게 생각해보면 당연한 거지만, 아무래도 DBMS 말고 다른 일을 하고 싶어 어줍잖은 기본기로 비비려 들었던 나의 괜한 욕심이었다. 아키텍처 공부 좀 했어야 했는데!
  • 불만사항인게, 전반적으로 너무 면접과정에 쓰는 시간이 많았다. 솔직히 다른 회사 대비 3배는 투자한 것 같다. 내가 잘못된 아키텍처로 접근했고 과도하게 투자한 점도 없잖아 있지만, 과제의 절대적인 양 자체가 너무 많다. 다음에 유사한 방식의 이직 프로세스를 경험하게 된다면, 진지하게 던지거나 타협을 해야 할 듯. (솔직히 합격 보장 시켜줄것도 아닌데, 고생만 하면 억울하다)

6. 의료보조기구 회사 (S사)

대충 의료보조기구(PCR) 관련 회사다. 여기도 헤드헌터 연락을 받았는데, 나름 잘 알려진 회사라서 한번 도전해 보았다. 결점이라면 중소(중견)기업이라는 것이고, 따라서 근무여건이나 시스템이 구성이 잘 안 되어 있을 가능성이 있다. 그리고 중견 회사로서 꽤 오랜 시간을 보내온 것 같은데, 회사가 성장을 못하는 요인은 문제 있는 경영진이 있을 가능성을 적지 않게 의심해 볼 수 있어서 다소 고민이 되었다. 그래도 욕심을 내서 포지션을 데이터 분석 쪽으로 넣었는데 어째서인지 서류합격이 되더라.

1차 면접

근데 뭔가 소통에 문제가 있었는지, 포지션이 바뀌어 개발팀으로 진행하게 되었다. 여기부터 첫인상이 썩 달갑지는 않았다. 보통 포지션이 바뀔 정도의 중대사항이면 확실하게 지원자한테 연락이 가야 하는게 국룰일텐데.

면접하면서 조금 고민이 되었다. 애당초 회사 메인 비즈니스가 의료데이터 분석인데 IT 서비스 개발은 그 분야에서는 곁가지 같은 일이라는 생각이 들었고, 코로나 특수로 회사가 펌핑된 상황에서 앞으로의 장래를 가늠할 수 있을지도 의문이었다. 하지만 그 분야에서도 해볼만한 일이 있을 것이고, 바이오데이터를 다룬다는 점에 있어서는 여전히 내 관심 범주 안에 있는 일이거니와, 더 나아가서 새 시스템을 구축해 나가는 과정상 여기서는 지긋지긋한 Legacy 코드 및 System과 싸우는 일은 없을 것이다. 해볼 수 있는 것들과 배울 수 있는 것들이 더 있을 것이다. 그리고, 부잣집은 3년은 간다는 말이 있다 (?). 기술력와 재무재표, 그리고 앞으로의 사업 방향성 및 잠재력을 확인해 봤을때는 괜찮지 않을까 싶었다.

약 서너일이 지나서 합격 통보가 왔고, 2차 면접을 보게 되었다.

2차 면접

• 간단한 자기소개 - 여느때처럼 커리어 위주 자기소개를 하였고, 덧붙여서 연관있는 사이드프로젝트 및 대학원 이야기도 같이 짤막하게 꺼냄.
• 우리 포지션에 지원한 이유? - 관심있어서 관련 분야 공부 했다는 이야기로 퉁침.
• 회사 다니면서 어려운 일이 있었는지? - 레거시 코드랑 싸우고 승리한 내용을 이야기 해주었다.
• 팀장이 비교적 빠른 시기에 되었는데? - 이것도 단골 질문이더라... 솔직하게 인력부족과 회사에서 능력 인정받았다고 잘 굴려서 이야기 해주었다. 별 코멘트는 없음.
• 팀장하면서 가장 힘들었던 일 - 위에랑 똑같이 대답함. 이것도 단골 질문...
• 다니던 회사에 어떻게 기여하였는지? - 제품품질 향상으로 기여했다고 이야기하고 이를 위해 진행한 일련의 작업들을 간단하게 이야기함.
• 기존 하던 skillset과 다른 일인데 잘 할수 있겠는지? - 사이드플젝 해온것도 있어서 자바스크립트 나름 한다고 이야기하고, 스킬셋 이전에 소프트웨어 엔지니어로서의 역량에 대해 이야기함.
• 회사에서 쌓고자 하는 커리어 - 질문부터가 아주 추상적이기에 그냥 훌륭한 소프트웨어 엔지니어로서 역량을 갖추고 싶다는 이야기를 길게길게 풀어서 설명함. (어째서인지 이 질문도 자주 들어온다)
• 팀장하면서 가장 힘들었던 일이 무엇인가? - 위에서 답변한 것과 동일하게 얘기함.

면접은 빠르게 끝나고, 적당히 회사소개를 듣고 질문시간으로 남는 시간을 떼웠다.

아무래도 인사체계와 시스템을 구축해 나가는 상황이다보니 면접관 분들도 많지 않으셨고 질문들도 앞선 면접들과 똑같이 스무스했다. 다시 말하면, 깊게 파고들지 않았다. 이력서 내용들이 진짠가? 확인하는 수준의 captcha 정도였다. 할 말이 없으셨는지 아니면 본래 절차인지 희망연봉을 이 단계에서 질문받았다...

• 결과: 최종합격
  • 문제는 처우 결정을 해야 하는데, 다른 건 몰라도 시간을 너무 빡빡하게 주었다. 난 좀 쉬고서 일하러 가고 싶은 마음도 있었는데, 업무시작일도 너무 타이트했고, 무엇보다 오퍼 수락 데드라인이 너무 짧았다. 일주일도 안 주었다... -_-; 일부러 다른 데 고민도 하지 말라는 식으로 그렇게 빡빡하게 준 건가, 아니면 정말 빡빡한가? 전자의 냄새가 난다.
  • 그래도 하는 일과 오퍼가 나름 마음에 들어서 참 고민을 했지만, 그래도 다른 선택지도 없는 것도 아니고, 이 오퍼를 수락하면 (가능성이라도 있는) 다른 기회를 모조리 날려야 하는데 그럴 수는 없었다. 꽤 아쉽지만, 오퍼 연장을 해줄 수 없다면 거절하기로 했다. (결국 오퍼 연장을 받긴 했다)

7. 이xx 코리아

여느때처럼 집에 와서 별 생각없이 쉬고 있는데, 헤드헌터분으로부터 연락을 받았다. 당시 이미 면접을 세군데 진행하고 있어서 카카오 하고 있다고 이야기했지만 일단 진행해보자는 식으로 이야기가 되었다.

당시에는 잘 모르고 "하고싶다!"라는 느낌으로 Data Engineering을 넣었는데, 넣고 나서야 데이터 엔지니어링이라는 분야가 어떤 분야인지 알 수 있게 되었다 (ㅋㅋ).

귀찮게 면접 가는 일 없이 깔끔하게 서류불합격이라서 만족스러웠다.

일줄 알았는데 결과가 늦게 나왔다... 시기가 다소 늦게 잡혀서 면접 보기가 껄끄러운 상황이었지만, 나 자신을 테스트하는 동기로 생각하고 면접 보기로 했다.

1차 면접

헤헌분이 잘 말해두셨는지, 코드 테스트는 프리패스하고 바로 면접에 들어갔다.

• 자기소개
  • 커리어 위주 소개 + 회사에서 뽑아야 하는 이유 적당히 잘 말함.
• 소프트웨어 아키텍처 관련
  • 현재 개발중인 DB 아키텍처에 대해서 설명하면서 여러 주제로 파생되어 감. 최근 트렌드인 MSA와 분산 시스템을 의식해서 최대한 저격해서 설명했다.
  • 분산 시스템 아키텍쳐에 대해서
  • 클라이언트와 서버 통신에 관해
  • 서버 failover 방법
  • 성능을 위한 캐시 구성
• Data Scientist 관련
  • 석사 학위때 사용했던 Loss function 물어봄. (예전에 공부 좀 해뒀긴 한데, 지금 가물가물해서 기억도 잘 안나고, 결국 그냥 모른다고 해버림 ㅋㅋ;)

Data Scientist는 과감하게 포기하고 소프트웨어 엔지니어링과 Data Engineering쪽에 몰빵하고 준비해서 인터뷰를 했다. 아키텍처 관련해서는 확실히 공부한 보람이 있었다. 기존과 대비해서 면접관분들이 대답 이해하는 속도가 빨랐고, 분위기도 스무스한 편이었다. 뭐, 그래도 결국은 빅데이터 안 다뤄봤으니 엔지니어링 쪽으로 쓰기는 좀 그렇네? 라는 반응이었지만 ㅋㅋ... 역시, 결국은 경력이 없으면 얄짤없다.

8. 미국 스타트업 회사

뜬금없이 어느날 스타트업 대표님로부터 직접 제의가 들어왔다.
일 자체는 Cloud system의 backup solution을 개발하는 일이었고 한국에서의 R&D 센터 초기 시작을 위한 스타팅 멤버를 뽑고 있었다. 자율(재택)근무 및 비자제공(!!)의 솔깃한 복지를 제공해준다고 한다.

대표님이 한국 동포 분이셨고 이전 면접들처럼 깐깐한 분위기(= 기계적으로 지원자의 fit을 체크하는 느낌)는 아니었다. 간단하게 introductory 면접을 보고 난 이후, 코딩 면접을 보고 그 이후 실무진 면접 2번 가량을 보고 영입 여부를 결정할거라고 하신다.

아무래도 스타트업은 처음이라 다소 불안감이 있었다. 먼저 커리어 고민이었다. 물론 지금 회사보다야 훨씬 훌륭한 인재들과 일할 수 있을 것이라는 막연한 기대감은 있지만, 안정된 시스템을 갖춘 대기업 대신 결국 똑같은 중소기업에 들어가서 온갖 고생 다하고 커리어는 없는 신세를 다시 한번 맛보게 된다면 이는 결코 반가운 일이 아니다. (이를테면 SI만 하게 된다든가... 혹은 체계 부재로 여타 혼란을 겪을 수 있다) 하지만 유망한 클라우드 솔루션의 최전선에서 뛸 수 있는것 자체가 어떻게 보면 굉장한 커리어 기회가 아닐까?

그리고 회사 자체가 너무나도 생소해서 신뢰성의 문제가 있었다. 미국 스타트업 회사다 보니 당연하게도 블라인드 같은 곳에서 정보가 전혀 없다. 열심히 구글링해가며 투자는 얼마 받고 있으며, 회사 가치는 얼마고, 매출은 얼마고, 성장 진행중인지, 직원들 평판은 어떤지, Salary 정보는 있는지, 경쟁사들은 어떻고, 해당 분야의 전망은 어떤지 전부 찾아보아야만 했다. 다행히도 어느 정도 정보를 찾을 수 있었으며, 회사 자체는 나름 어느정도 안정화되어가는 상황에서 수익도 나고 있는 좋은 상태인것으로 보였다. Salary도 실벨 기업답게 꽤 상당히 높은 편이었다 (Avg. 12만불 가량). 투자도 Series C까지 받았다. 이후에 안 건데 Series C 정도면 보통 어느정도 궤도에 들어선 것으로 보아도 된다고 하더라. 그리고 가장 중요한 회사 가치는 이후에 알게 된 건데 이미 중견기업의 스케일을 넘어선 것 같았다. 하긴 글로벌 연구센터를 차리는 것 자체가 어느정도 성장한 기업이란 뜻으로 봐도 되지 않을까.

Introductory 면접

외국 기업 특유의 문화인지 Introductory 면접이 따로 있었다. 기업 소개 받고, 앞으로 진행하게 될 interview에 관한 간략한 이야기들 및 복지 등에 대하여 전달받고 질문과 대답을 받을 수 있었다. 특이한 점은 CTO 분이 평가의 의도 없는 질문을 하는 것이었다. 지원자들은 어떤 점에서 이 회사의 매력을 느낄지에 대해서 등... 새로 지부를 만드는 만큼 그 나라에 대한 culture 조사를 하시는 것 같았다. 사무적인 기존 면접들과 달리 인간적인 분위기의 면접이었다.

1차 면접

2번에 걸쳐서 진행하였는데, 둘다 본사(US)에서 일하시는 분이셨고, 따라서 난생 처음으로 준비도 없이 영어 면접(!)을 진행하게 되었다. 각각 1시간의 시간이 주어졌다.

첫번째는 한국인, 두번째는 인도인이었다. 어차피 두분 다 오랜 타지 생활로 인해 영어 빼고는 쓸 수 없는 상황이라고 하셨다(?). 특유의 악센트 때문에 인도식 영어발음을 정말 못 알아듣는데, 그래도 다행히 알아들을만한 수준으로 말해주었지만, 실은 3~40% 정도는 못 알아들었던 것 같다 ㅜㅜ.
문제는 그렇게 어려운 건 아니었다. serialize와 knapsack 문제에 대해서 질문받았다. 하지만 역시 코드로 풀면 쉽지만, interview 형식으로 풀어나가는 것은 이야기가 다르다. 받자마자 뭔가를 보여줘야 하고(?), 보는 눈도 있고, 설명도 해야하고, 마냥 성의없이 짤 수도 없고... 이래저래 부담이다. 뭐, 그래도 할말은 다 했던것 같았다.

불합 여부를 제외하고라도, 영어 인터뷰를 무료로(?) 할 수 있었다는 점에서 재미있는 경험이었다.

2차 면접

이번에는 둘다 US 분이셔서 발음 알아듣기가 쉬워서 좋았다 ㅎㅎ. 첫번째 인터뷰는 마찬가지로 코딩테스트였는데, 두번째는 정말로 "Technical" interview가 나와서 살짝 당황했다. 사실 관련 지식을 확인하는 테크니컬 인터뷰를 통해 자질을 파악해야 하는건 당연하지만 ...
이번 인터뷰도 1시간 정도만 소요하였다. 심층 인터뷰치고 시간이 꽤 짧아서 좋기도 하지만, 사실 네/카가 악질이 아닌가 싶은 생각도 든다 (특히 K사... 어차피 기술적 자질 안 되면 안 델고갈 거면서 ;;).

코딩 테스트에서는 in-place로 중복된 수를 제거하는 알고리즘과, maximum concurrent range를 구하는 문제가 주어졌다. 후자의 경우는 다행히도 요즘 알고리즘 복기하면서 비슷하면서 다른 문제 "회의실 배정"이 떠올라서 어렵지 않게 풀 수 있었다. 오히려 면접관이 이해를 잘 못해서 설명하느라 진땀... 내 영어실력으로는 효율적으로 설명이 어려워서, 열심히 예시를 주석으로 달아가며 설명해 주었다.

알고리즘 면접들을 나름 많이 해오다 보니까 느낀 점이 있는데, 먼저 Naive solution을 제시할 수 있으면 좋고 이후에 optimize solution을 제시하는 방식이 흐름 상 좋은 것 같다. 그리고 코딩하면서 내가 이걸 왜 이렇게 만들었는지 설명해주면 또 좋은 것 같다. 그러면 가끔 면접관들에게 조언도 받을 수 있고, 면접관의 오해(?)가 깊어지는 일 없이 생각도 효과적으로 공유된다. (라이브 코드리뷰, 혹은 코딩 방송 한다고 생각하면 편할지도..?) 또한, edge case에 대한 고민도 충분히 해 주면 면접관들이 아주 좋아한다 (보통 100이면 90은 물어보기도 함). 근데 edge 케이스 짜는 건 정말 실력의 영역이라 뭐라 해줄만한 게 없고... 알고리즘을 평상시에 많이 풀어놓는 수밖에.
이와 반대되는 행동이라면, 아무 말 없이 고민만 하다가 코드 짜고 결과만 보여주는 케이스가 아닐까. 물론, 보통은 혼자 알고리즘을 짜니까 그렇게 해도 되지만 아무래도 면접의 케이스는 좀 다른 것 같다는 것이다.

테크니컬 인터뷰에서는 회사에서 사용하는 클라우드 서비스에 대한 경력이 있는지에 대한 질문과, 이에 관련된 아키텍쳐 및 최적화 요소들에 대해 간단하게 이야기를 나누어볼 수 있었다. 나는 정직하게 클라우드 서비스 개발은 안 해봤다고 했고(...), 스케쥴링, 캐시, Green Thread 등 주워들은 정보 이것저것들을 이야기하였다.

• 결과: 최종합격

최종합격 하고나서야 인터뷰에 대한 최종 피드백을 들을 수 있었다. English skill은 협업하는 데 지장은 없는 수준 (so-so?), Coding interview는 스킬이 좀 쌓여서 그런지 짧은 영어에도 불구하고 좋은 평가를 받았고, 맨 마지막 면접인 Software design에 대해서는 부족한 부분이 있다는 평가였다. 복기하면서 나중에서야 Software Design Interview 관련 질답들이 있다는 걸 뒤늦게 깨달았다. 한없이 부족한 나의 준비성과 정보력... 그래도 이 정도 평가해 준 게 어딘가, 가감없이 능력 그대로를 인정받은 것 같아서 흡족했다 ^^;

약간의 마이너한 이슈가 있었지만, 마찬가지로 최종 오퍼 조율 과정을 거쳤다. 현재 임금과 내년 인상률, 그리고 다른 오퍼 제의에 대한 이야기를 했는데 바로 칼같이 맞춰 주었다.

9. 11번가

다른 헤드헌터분이 또 다른 제안을 주셔서, 저기도 괜찮겠다 싶어서 써보게 되었다. 그냥 다른 회사들이 다 괜찮아 보이는거 보니 이거 뭐 뷔페도 아니고...

그런데 이 즈음 상황이 되니까 이미 난 너무 면접에 지쳐 있었다. 이미 오퍼도 있고, 모종의 인맥 회사도 있어서(?) 도피처도 있는 데다가, 그리고 솔직히 지금다니는 회사 처우도 나쁘지 않고 해서 이젠 열심히 할 의지도 거의 바닥을 찍어 가고 있었다. 뭐... 이미 헤드헌터분이 절박하셨는지 이미 서류를 넣어주셔서 허허...

포지션이 Data Platform engineer 이었는데, 이젠 내가 원하는 포지션과 맞지 않는다는 사실을 알기에 그렇게 기대가 되지 않았다. 이미 외국기업으로 가기로 맘을 굳힌 상태였지만, 그냥 코딩 테스트 한 번 해 보기로 했다. 그런데 코딩 테스트가 정말 코테가 아니고 linux command, python, SQL, hadoop command 같은 것들에 대한 퀴즈 수준이었다 (...). 확실히 내가 하고 싶은 일이 아닌게 분명했기에, 진행할 의향마저도 없어졌다. 그 와중에 가끔 필요할때나 man 찾아들어가서 쓰는 sed 명령어는 왜 물어보는거고, API 쓰라고 던져줘놓고서 description 한 줄 없고 autocomplete 하나 없는건 실망스러운 수준...

확실한 건, Data "Engineering"의 분야가 몹시 넓다는 사실을 다시금 확인할 수 있었다. 근데 이건 설계 엔지니어링 분야도 아니고 시스템 메인테이너/관리자 같은 느낌인데...

이후 헤헌에게는 포기 의사를 밝혔다. 나쁜 마무리를 기대하고 있었는데, 의외로 해당 스타트업에 대해서 검토도 해주시고 좋은 피드백도 얻을 수 있었다. 고맙다는 말씀을 드렸다.

10. 이외에도...

모 S 대기업의 자회사에서도 헤드헌터 요청이 와서 서류를 넣었는데, 한참 시간이 걸린 후에 회사가 추구하는 Fit과 지원자분의 이력서 특성이 일치하지 않을 것 같아서 지원을 거절받은 사례가 있었다 (불합격..?). 굉장히 특이 케이스였는데, 사측에서는 보통 이런 새로운 거 하는 거 좋아하는 사람들은 회사에 만족을 못하고 일찍 나간다고 하셨다. 어떻게 보면 어차피 안 갈 곳인데 면접에 시간 허당치는 것보다는 차라리 이런 식으로 빠르게 필터링해주는게 서로에게 좋은 걸지도.

11. 오퍼 수락, 그리고 그 이후

최종합격이 결정되었다면 회사와 딜을 해야 한다. 나 같은 경우는 아래 자료를 들고가서 처우 협상을 했다.

• 기본급, 연봉계약서 및 인센티브 정보
• 월급 명세서 전부
• 현재 회사의 스톡
• 인상 예정인 연봉 내역 (있다면)
• 다른 회사에서 제안받은 오퍼 (있다면)

찾아보니 보통 20% ~ 30% 정도 올려서 이직하곤 한다고 했고, 실제로도 그 정도 수준으로는 기본적으로 맞춰주는 듯 했다. 물론 저건 보통의 경우고, Fit이 맞거나 능력을 인정받는 경우라면 훨씬 더 많이 받을 수 있는 경우도 있다. (듣기로는 스톡 포함 100%도 있는 듯하다)

그리고 처우협상도 중요하지만, 회사를 보는 안목 또한 많이 중요했던 것 같다. 아무리 오퍼가 마음에 들어도 회사가 마음에 안 들고 삶의 질이 떨어지면 무슨 소용인가... 주로 아래 정보를 찾아보게 되었던 것 같다.

• 회사의 정보 (매출액, Stock share, 성장률, 투자정보, 향후 전망 등)
• 재직자의 평가 (근무시간, 근무형태, 기업문화, 분위기 등)
• 포지션에 대한 재검토 (내가 추구하는 커리어랑 맞나?)
• CTO/면접관의 이력 (나랑 Fit이 맞을까?)
• 회사 위치 (출퇴근 시간도 은근 중요... ^^;)

이렇게 생각 이상으로 최종합격 후에도 고려할 것들이 많았다.

그리고 오퍼 accept를 한 이후에도 계속해서 포지션 제의가 들어왔다. 매주 4~5 개씩은 들어왔던 것 같은데, HR들이 내 프로필의 어떤 점에서 메리트를 느낀 것인지 궁금하다. 아무튼, 기회는 계속해서 들어온다. 마음에 들지 않는 포지션이면, 아주 급한 상황이 아니고서야 과감하게 내치는 것 또한 괜찮은 선택지라고 나는 생각한다.

그리고 추가로 알아봤는데, 기업과 개인의 최종합격/입사 번복 기준이 다르더라. 기업은 최종합격 번복하면 근로계약성립설에 의해 해고로 간주하게 된다고 합니다 (계약 전이더라도). 개인은 계약번복에 관해서 딱히 법적으로 규제는 없습니다. 관련링크 혹시 모르니 계약서 꼼꼼히 읽어볼 것 그러니 더 좋은 오퍼를 받으면 출근 전에 다른 회사로 눈을 돌리는 일도 가능하고, 실제로 그런 경우도 꽤 있다. 물론 계약번복은 도의에 어긋나는 일이기 때문에 조심스럽게 해야 한다는 것 잊으면 안된다... 특히나 이 바닥은 은근히 좁아서...

결과 평가

이직 결과 자체에 대해서 평가해보면 거진 실패에 가까웠다고 생각한다. 내가 처음 희망하던 대기업이나 및 힙한 회사들 (네카라쿠베, 흔히 말하는 한국식 "FANG") 에서는 전부 실패했다.

• 대기업은 전부 탈락했고(면접이후 2곳 탈락)
• 서류 및 코테 탈락 2곳
• 최종합격 2곳

복기해보면 코딩테스트는 거의 대부분 문제가 없었고 면접에서 떨어진 경우가 굉장히 잦았는데, 기술적인 fit이나 소프트웨어의 큰 틀을 디자인하는 측면에서 많이 부족한 부분이 있었다. 사실 그동안 소프트웨어 전반적인 설계에 대해 무심한 점도 있었고, 회사에서도 큰 틀의 설계보다는 세부설계 및 개발위주로 작업하다보니 많이 부족할 수밖에 없었다. 이런 점은 고쳐야 할 부분일 것이다.

그리고 내 자신의 방향성 부재 또한 실패에 큰 영향을 끼쳤던 게 분명하다. 면접할 때 회사에서 어떤 일을 하게 될지 질문하는 것은 금기라는 것은 알고 있었지만, 나 자신이 지원한 포지션을 잘 모르는 관계로 거의 대부분의 면접에서 "어떤 일들을 하게 되나요?" 에 해당하는 질문을 많이 했던 걸로 기억한다. 자신이 무슨 일을 할지를 모르는 사람을 경력직으로 뽑겠다... 사람이 상당히 급한 곳 아니면, 더더군다나 다른 지원자가 있다면, 나 같아도 절대 안 뽑긴 할 것 같다 ㅋㅋ. 애당초 처음 도전하는 분야라면 최소한 책이라도 한권 읽고 와서 전반적인 설계나 실제 데이터 프로세싱에 대해 입이라도 털 수 있어야 했다. 너무나 당연한 건데, 경력직 이직에 대해 내가 너무 안일하게 생각하고, 예전 신입때처럼 하고 싶다는 이유만으로 지원한 것이 패착일 수밖에 없다. 심지어 사이드 프로젝트들 또한 지원한 포지션과 전혀 연관이 없었고, 그래서 추가 질문도 거의 들어오지 않았다. 또 생각해보면 면접관들이 이리저리 질문한것도 결국은 "이러이러한 분야에 관심이 있고 내가 잘 하는데, 회사가 마침 그러한 사람을 찾고 있어서였다" 이라는 대답을 받고자 위함일 텐데, 아는게 없으니 "그냥, 일이 재밌어 보여서" 라는 대답을 한게 전부였다 ㅎㅎ...

또 느낀 점은 내가 포지션을 잘못 선택했구나 하는 생각이었다. 경력직 이직은 Final product를 설계 및 개발할 수 있는 수준을 기대치로 보는 것 같은데, 내 경력이나 그동안 해온 토이 프로젝트 한정으로는 그렇게 할 수 있다고 자부할 수 있다. 아마 나의 경우는 DBMS+Cloud 쪽을 지원했어야 커리어 측면이나 결과 측면이나 성공적이었을 것이다. 토이 프로젝트 측면에서는 게임개발쪽도 의외로 잘 먹혔을지도 모르겠다. (여담으로 이직 결과와 별개로 이직하고자 하는 곳은 맘에 든다 ^^;)

후기

이렇게 길고 긴 이직 시도가 끝났다.

생각보다 첫 이직은 힘들었다. 처음에는 내 커리어와 스스로의 발전동기로 삼아서 시작했지만, 약 두세달의 시간이 지나자 지치기 시작했다. 이직을 처음 해보다 보니 시행착오도 많이 있어 본업과 함께 병행하기에는 쉽지 않았던 점도 있지만, 무턱대로 면접을 동시에 많이 진행한 탓도 있을 것이다. 자신의 분야와 지향하는 바 등을 고려하여 쳐낼 건 쳐내야 되었을 것이다. 불합격에 대한 상세 설명이 없는 불친절한 피드백도 좌절감을 안겨주어 힘들었던 점 중 하나였는데, 결국은 다른 기회가 있었던 걸 생각하면 자존감을 유지하는 것 또한 중요한 것 같다.

그래도 이직 과정중에 수많은 걸 배울 수 있었기 때문에 시도 자체만으로도 가치가 있다고 생각한다. 이직을 위한 이력서 준비를 하면서 내 자신의 커리어와 포지션에 대해서 다시금 생각해 볼 수 있었고, 구직을 하면서 시장 동향과 기업 가치에 대해 직접 파악해 볼 수 있었다. 그리고 면접을 준비하면서 얻은 알고리즘 및 소프트웨어 사고과정, 그리고 이를 남에게 설명하는 방법, 그리고 업무 포지션에 대한 통찰은 어디에서든 필요한 능력이라고 생각한다. 꼭 이직이 아니더라도 요즘은 개발자 커뮤니티들에서 활동하다 보면 그러한 정보를 얻을 기회가 비교적 많은 것 같긴 하다.

그리고 나 같은 경우는 이직시에 LinkedIn을 이용하여 맨바닥 헤딩을 해 봤는데, 인맥의 도움이나 학교 과 홈페이지 등을 한번 찾아가 보는 것도 좋을 것이다. 좋은 기회를 많이 얻을 수 있을 것이다.

이제 잠깐 남을 시간동안 회사에서 사용할 Skill(MSA, Golang) 및 Cloud 분야 공부를 빠르게 해서 follow-up 해야겠다. 그리고 여전히 후속으로 써야 될 정보들이 많이 남아 있는데, 부지런히 남겨놓을 수 있도록 해야겠다.

참고 자료들

아래는 면접 보면서 도움이 되었던 내용들을 정리해 보았다.

• 준비하면 좋은 내용들
  • 타인의 면접후기 (포지션별로)
    • 질문을 보면 어떤 background를 가진 사람을 뽑으려고 하는지, 그리고 무엇을 준비해야 하는지 알 수 있다.
  • 포지션별 시스템/소프트웨어 디자인 및 Roadmap 찾아보기
    • 자신이 지원하고자 하는 분야에 대한 설계(디자인) 공부는 필수이다. 새로운 분야에 도전하는 사람이라면 필수적으로 해야 하고, 기존 분야에 있던 사람도 기초가 부족하다고 느껴지면 해야 할 필요가 있어 보인다. Coursera 강의나 GDE(Google Developers Experts) 커뮤니티 등에서 많은 정보를 얻을 수 있는 것 같았다.
    • 요즘 이런거 - Data Engineer Roadmap 2021 많던데 보면 준비해야 할 세부 skillset이 무엇인지 빠르게 캐치할 수 있을 듯.
  • 포지션에 지원한 이유, 그리고 포지션의 Tech Skill
    • 경험상 포지션에서 사용하는 Tech Skill을 모르면 떨어진다고 보면 된다. 입문책을 읽거나, 최소한 검색해보고 어느정도 알고는 있어야 한다.
    • 그리고 Tech Skill만 겉핥기로 알아서는 절대 안 된다. 이를테면 Backend Position이면 Golang든 Kotlin을 쓰든 상관없이 Linux System Architecture 관련 질문은 반드시 나올 것이다. 기본기는 항상 챙기고 가야 한다.
  • 자기소개 발표자료 만들고 발표해 보기
    • ppt로 손수 준비해보니 생각 이상으로 내가 모르는 부분이 꽤 많다는 걸 캐치할 수 있었다
• 의외로 그렇게까지 중요하지 않은 것
  • 회사의 소개 및 가치관
    • 신입일 때나 보는 내용 같다... 어차피 Fit이 안 맞으면 경력 이직은 무조건 나가리다. 실력과 background가 제일 중요하다. (재무재표를 보는게 차라리 더 나을 수도 있다)
• 공부
  • GeeksforGeeks
    • 다양한 알고리즘들과 이들의 분류 및 해설 잘 정리되어 있고, 풀어볼 수도 있으며
    • 게다가 알고리즘을 기반으로 한 인터뷰 준비도 무려 "영어"로 가능.
    • Software Design Interview 준비에 도움되는 내용도 많다.
• 이력서 및 포트폴리오 (220527 Update)
  • 이력서에 가능하다면 구체적인 내용 제시: 문제와 이를 해결하기 위한 방법, 가능하다면 수치 활용 (e.g. 효율성을 향상했다면, 몇 %의 수치의 향상인가?)
  • 자신을 보여줄 수 있는 방식의 개인작업물을 꾸준히 만들 것
    의도해서 한 건 아니고 제가 좋아서 한 일이지만, 그래도 제 경우에는 이 점에서 면접관들의 관심을 많이 샀습니다. 방향성을 확실하게 잡아서 한다면 분명 좋은 결과를 보여줄 겁니다.
  • 개발서적 및 관련 내용들 읽어놓은것들 꾸준히 정리해놓기
  • 이를테면, leetcode나 BOJ와 같은 알고리즘 사이트
    • 기록이 체계적으로 남아서 스스로 학습하기에도 좋고, 지속적으로 해 왔다면 포트폴리오 자료로도 써먹을만 함.