누구나 원하는 개발자되기

이직을 준비하시는 분이라면, 아래 글을 꼭 읽어보시고, 단단히 준비하세요.

원문 : blog.shiren.dev/2020-11-23/

누구나 원하는 개발자되기

원문을 읽어보고, 귀감이 되는 부분이 많아서, 요약해 봅니다.

1. 이력서를 주기적으로 업데이트하는 것은 주기적으로 반성(?) 하는 시간을 가질 수 있어 동기부여와 목표 설정에 도움이 된다. 이렇게 이력서를 관리하다가 “때가오면” 지원하는 회사 양식에 맞게 수정한다.

2. 단순히 경험을 구구절절 늘어놓는 게 아니라 역량을 어필할 수 있는 포인트를 하나 이상 적는 것이다. 이력서를 검토하는 사람이라고 생각해보자 “그래서 도대체 뭘 했다는 거지?”라는 생각이 드는 이력서와 “이런저런 경험했고 이런저런 성과가 있었으니 이건 잘하겠구나”라고 파악할 수 있는 이력서

3. 단순히 기술을 나열하기보다는 “성과”라는 스토리를 담도록 노력하자. 만약 그런 스토리가 없다면 아직 이직할 준비가 되지 않은 것이다. 우선 지금 회사에서 만들어보자.

4. 사전 과제에서 보고 싶은 것은 정상 동작하는 결과물이 아니다. 정상 동작은 당연한 것이다.

어떤 지원자는 사전과제에서 평소 해보고 싶었던 큰 시도를 하느라 정작 중요한 것을 놓치기도 한다. 참신한 시도를 녹인 코드는 좋지만 여기저기 버그가 있고 제대로 동작하지 않거나 완성도가 낮아 효율이 떨어진다면 오히려 구닥다리 MVC 패턴을 활용해 안정적으로 만드느니만 못하다. 신입급 개발자라면 내용에 따라 어느 정도 가산점이 있을지 모르겠지만 그간 시도해 보고 싶었던 것은 개인 프로젝트에서 하고 사전과제는 기존에 잘하던 것을 보여주는 것이 좋다. 실제로 평소의 코드를 확인하려고 진행하는 프로세스다. 꼭 하고 싶다면 기존에 잘했던 것에 시도는 한 20% 정도만 첨가하자.

위의 문장에서는 뺄 것이 하나도 없네요.

5. 잘 알고 있다고 생각했던 것도 말로 설명하려면 어려운 경우가 많기 때문에 설명하는 연습을 충분히 한다.

6. 간혹 면접 중에 본인이 성장하지 못했던 원인을 팀(or 회사) 탓을 하는 경우가 있다. 물론 회사 사정상 팀이 도무지 성장할 수 없는 안 좋은 팀 일 수도 있다. 하지만 그런 식으로 시간이 무의미에게 흘렀다면 그건 본인의 잘못이다. 팀에 문제가 있다면 답은 셋 중 하나다. 적응하던가, 바꾸던가, 나가던가.

7. 같은 업무를 하더라도 커리어를 만들려는 태도로 접근하면 그 안에서 또 새로운 도전과제를 찾을 수 있다

8. 일상적인 작업을 하다가 단편적인 이해의 조각들이 서로 연결되면서 “뙇”하고 큰 그림 개념이나 원리를 깨닫거나 더 나은 방법이 떠오르는 순간이 있는데 그런 것은 절대로 놓치지 않고 메모해둔다. 그런 내용은 누군가에게 도움이 될 것이고 누군가에게 도움이 된다면 성과의 구체적인 사례가 될 수 있다

9. 요즘은 개발자에게 여러 가지를 기대한다. 개발은 당연히 잘해야 하고, 어디서 교육이나 발표한 경험도 있어야 하고 블로그도 써야 하고 오픈소스 활동이나 커뮤니티에 기여하기도 한다. 물론 이런 스펙(?)들이야 있으면 좋겠지만 이런 과정을 통해 무엇을 경험하고 배웠는지가 더 중요하다. 이력서의 스펙대로라면 충분히 알아야 할 내용을 면접 과정에서 제대로 설명하지 못한다면 오히려 역효과만 생긴다. 이력서는 매력적일지 모르지만 면접에서 결국 탈락한다.

10. 채용은 회사나 지원자나 서로 준비를 철저히 해야한다. 면접관들의 질문이 너무 뻔한 족보 같은 내용들이고 이력서는 읽어보지도 않은 것 같다면 그 회사는 들어갈 가치가 없다고 생각한다. 채용에는 면접관 못지않게 지원자도 시간적인 리소스를 많이 사용하는 만큼 면접관 역시 충분히 준비를 하고 정중하게 채용에 임해야 한다.

읽어 보면서, 요즘 중구난방으로 자기계발에 바쁘기만한 자신을 반성합니다.