Post

이직 회고 (feat. 최종합격)

잘 놀다 갑니다.
이직 회고 (feat. 최종합격)

이 직업을 가지고서 정말 기존과 다른 도메인으로 학습을 접근하게 되었고 지금까지 했던 프로젝트와 기술을 좀 더 완성에 가깝게 재구성할 수 있었다. 특정 분야에 얽매이지 않고 연구개발을 진행하면서 단순한 개발 뿐만 아니라 더 탄탄한 개발과 이 분야에 흥미를 가질 수 있었던 이야기를 짧게 써보려고 한다.

바람은 순풍

현 업무를 하면서 이직을 생각하게 되었고 조금씩 준비하면서 현시점에서 결국 3 군데에서 offer 를 받았고 여러가지를 생각하여 입사 날짜가 결정되었다. 서류 준비하는 과정부터 생각하면 신입 때와 조금 달랐다. 신입 때는 pdf 형식으로 추출하고 디자인도 신경 쓰려고 며칠을 투자했었다. 그러나 당시에는 그런 여유가 주어지지 않고 재직중으로 시간이 기다려주지 않아 제출해야 하는 상황이었다.

Notion VS *.pdf

이력서를 업데이트하면서 기존의 이력서를 탈바꿈할 기회가 왔다. 어쨌든 이력서 또한 파일이고 여러 곳에 제출할 때마다 같은 이력서를 내는 것이 아니라 조금씩 수정하고 업데이트 후 제출한다. 이때 분명 제출한 곳마다 차이가 분명 있을 것이고 어디에 기록하지 않는 이상 이에 대해 추적과 버전관리가 필요하다고 판단되어 이전에 만들어놓은 것을 추후에도 유지보수하고자 pdf 로 관리할지 notion 으로 관리할지 정했다.

Resume Refactoring

이전에 지원한 이력서를 열어봤는데 정말 준비한 기간에 비하여 정리가 많이 안 되었다. 또한 현재 근무한 이력이 반영되어 있지 않는 부분이라 추가하던가 아니면 새로 이력서를 작성해야 했다. 근래 Notion 으로 포트폴리오를 만들고 Notion 으로 이력서를 대신하는 사례가 많이 보였다. 또 많은 사람들이 Notion 으로 제출을 많이 하여 대부분이 이를 권장하게 되었다. 그러나 몇몇 기업은 링크를 받지 않고 pdf 파일로 받는다는 문구를 표기해놓기도 했다.

PDF vs Notion

어느 한 커뮤니티에서는 지원자의 고정된 이력을 평가하는데 Notion 으로 제출한 이력서는 마치 시험 끝나고 제출한 답안지와 같다고 말한다. 답안지를 제출했는데 답안지 내용이 바뀐다고 생각하면 어떨까

위와 같은 생각으로 Notion 과 pdf 사이에서 갈등을 많이 헀는데 결국 pdf 로 이력서를 migration 해서 제출하였다. 이번 기회에 pdf 로 resume 를 관리하고자 pdf 로 결과물을 뽑을 수 있는 매체를 찾았다. 자유롭게 디자인과 형식을 작성하고 싶지만 주어진 시간과 들어가는 공수가 많아 기본적인 틀만 맞추어서 pdf 파일을 뽑을 수 있었다.

Resume v2

이력서를 기존에 Notion 이라는 플랫폼을 통해 관리했는데 최근 대다수 기업에서 pdf 파일만 이력서를 받는 모습을 보였다. 하지만 pdf 로 바꿀 필요가 있었고 Notion 에서 뽑는 pdf export 기능은 제대로된 형식으로 출력되지 않았다. 그래서 이번 기회에 이력서를 다른 플랫폼으로 작성하는 방법을 찾았고 이번 기회에 이력서 또한 버전 추적하여 관리하기 위해 pdf 로 추출해줄수 있는 언어와 툴을 찾았다. 추적할 수 있는 파일 그러니까 코드로 관리를 한다면 어디를 어떻게 변경했는지 확인하기 쉽고 추후에 해당 부분에 대한 관리/수정이 매우 용이하다. 조금의 검색을 통해 꽤 괜찮은 도구를 찾을 수 있었고 이직 준비와 동시에 이력서 migration 작업을 시작했다. 시간이 많지 않아 최대한 내용이라도 빠짐없이 작성하자는 취지로 디자인은 신경도 쓰지 않았다.

i8n export PDF

그래도 결국 초안 파일을 만들어서 제출하였다. 해당 작업을 진행하면서 자체적으로 프레임워크에서 i8n 을 지원하여 위와 같이 추후 영문이력서도 관리할 수 있을 거 같다. 바꾼 형식을 보면 버전관리를 생각해서 또 관리를 어떻게 하면 좀 더 쉽게 할 수 있을까에 초점을 맞춰서 그런지 결과적으로 새로운 방식으로 이력서를 관리할 수 있었다.

채용 프로세스

서류 접수

언제나 서류 제출은 작성해야할 것이 많다. 서류를 제출하고 작성한 내용애 대해 재검토했다.

작성한 내용은 아래와 같다.

  1. 이력서 - pdf
  2. 자기소개서
  3. 포트폴리오 - include in pdf
  4. GitHub link
  5. Blog link
  6. 인적사항

이력서에 작성한 내용들에 대해 어떻게 답변할지 생각도 해보고 GitHub 에서 진행했던 여러 프로젝트나 소스코드 버전관리에 대해 리마인드했다.

1차 면접 && 2차 면접

1차 면접은 처음이라 꽤 떨렸다. 진행했던 업무에 대해 답변하고 스킬과 프로젝트에 대한 진위여부를 확인받았다. 근데 후기를 찾아보니 경력 면접은 그냥 프로젝트를 물어보는 정도라 사실은 평소에 성실히 잘헀다면 큰 문제없이 기술면접을 통과할 수 있을 것이라는 후기가 있었다. 그래도 지금껏 했던 활동들과 스킬을 나름대로 정리하고 다시 한 번 점검하는 시간을 가졌다.

2차 면접으로 꽤 많은 임원들이 들어와서 한 분 한 분 질문을 주셨다. 기억에 남는 것은 압박면접은 아니지만 긴장해서 스스로 압박면접 환경으로 만들었다. 여태까지 해온 업무와 연구개발들에 질의응답을 가지는 시간이었다.

평판조회

1차는 주중으로, 2차 면접 결과는 꽤 빠르게 확인할 수 있었다.

다음 과정은 레퍼체크 평판조회였다. 먼저 알아본 바 지난 생활이 첫 시험대에 오르는 기분이었다. 레퍼런스체크는 서류와 면접에 대한 진위여부를 파악하고 놓친 부분이 있는지 파악하기 위해 진행한다고 한다. 지정인으로 진행해도 비지정인으로 진행해도 꽤 긴장됐다. 그래도 지난 시간 고생과 보람있던 순간들을 옆에서 묵묵히 지켜봐준 동료들을 지정해서 부특하였고 더도 말도 덜도 말고 사실 그대로 요청하였다.

결과는 마감 후 2일 뒤 나왔고 문제 없다는 결과와 함께 다음 과정인 처우협의 및 입사 날짜를 조정할 수 있었다.

레퍼체크에 도움을 주신 분들께 진심으로 감사하다. 추후 레퍼체크에서 특별한 특이사항이 없어 처우협의 과정을 거쳤다. 갑작스러움에도 응해주신 분들께 이 글을 빌어 다시 한 번 진심으로 감사하며 작은 답례를 드렸다.

처우협의 및 최종입사

처우협의를 진행하고 입사날짜를 지정했다. 너무 쉬는 것도 좋지 않고 너무 빨리 출근하는 것도 아쉬울 거 같아서 적당히 조절하여 시간을 정했다. 이로써 끝이 보이지 않을 거 같았던 그리고 확신이 없었던 이직 프로세스가 마무리되었다.

최종 회고

최종 합격 후 또 다른 것을 기대하며 준비하고 있다. 이직은 단지 과정에 불과한 것 같다. 그 위에서 준비해야 하는 그리고 또 공부해야 하는 많은 요소들에 꾸준히 시간을 투자하려고 한다. 2년 전 이맘때를 생각하면 사람은 알다가도 모른다. 2년 전 나는 오늘의 나를 예측할 수 있었을까? 혹시나 망설이고 있는 게 있다면 하나씩 또 시작하고 도전해보려고 한다.

퇴사하며

지난 2년 좀 안된 시간은 전혀 다른 세상이었다. 한 가지 분야에 기준치 이상으로 통달할 때 비로소 인사이트가 생겨서 범위 안에 리소스를 자유롭게 사용할 수 있게 된다. 연구개발을 하면서 가장 크게 느낀 것은 전혀 다른 세계를 볼 수 있는 것이었다. 코드를 작성할 때 역으로 코드의 영향을 모니터링했다. 에러가 발생하면 crash log 를 통해 손쉽게 이 부분을 추적할 수 있지만 그렇지 같은 경우가 다반사였고 이 부분이 굉장히 어려운 진입 장벽이 있었다.

그래서 생각한 것이 알려진 문제를 재연하여 이를 트리거 시켜 그것을 추적할 때 실제와 어떻게 다르게 보여지는지 연구했다. 에러 메세지를 구글에 바로 검색해보고 ChatGPT 를 통해 검색도 해보았는데 별다른 성과가 없었다.

보통 버그메세지에 관하여 검색을 진행하면 10개 링크 중에 1개가 정답이거나 그 정답인 답변도 오래된 답변이어서 버전 의존성에 의하여 또 다시 검색을 시작하게 될 수 있다. 근데 생각을 해보면 사실 이런 구글이나 스택오버플로우에 달린 답변들은 스스로 본인들의 문제를 추적하여 답변을 단 사람들로 구성되어 있는 게 아닌가 싶다. 그래서 에러메세지는 같지만 그 에러를 발생시키는 원인은 다를 수 있어 참고한 링크대로 가이드를 따라하면 제대로 되지 않는 것이다.

우리 팀은 문제를 구글링하지 않는다. 해당 버그가 일어난 곳으로 들어가서 현재 점유하고 있는 문제를 확인한다.

이러한 것들을 돌아보면 가장 좋은 건 Ref Docs, 그 다음은 code 를 보는 것이라고 생각한다. 예시를 보고 싶다면 Community 를 참고하는 것이 좋다고 생각한다.

This post is licensed under CC BY 4.0 by the author.
If you find any errors, please let me know by comment or email. Thank you.

© Ruffalo. Some rights reserved.

I'm

Using the Chirpy theme for Jekyll.