[IT 회사 생활] 엔지니어의 직무 경력서 작성법

※ 일본의 블로그 글의 번역한 포스팅입니다. 오역 및 직역이 있을 수 있습니다.

 

자주보이는 정보가 부족한 직무경력서

---

 채용을 결정하는 매니저가 엔지니어가 아닌 경우나 자세한 내용을 잘 모르는 기술일 경우, 기술에 관련해서 임의로 평가할 수 밖에 없다. 기술을 잘 모를 때 체크되는 항목은 아래와 같다.

- 프로그래밍 언어

- 참가한 프로젝트

- 담당 공정

- 기간, 키워드와 숫자

 그러므로, SI계의 경력 포맷은 위의 항목에 최적화되어 있는 경력서를 보게 되는 것은 어쩔 수 없다. 기술에 대해 분명히 말할 수 있는 틀이 좁으니까 말이다.

 사실상 직무경력에는 포맷이 없다! 그러므로 자신의 일을 보다 잘 표현할 수 있는 포맷을 자기 스스로 만들어보자.  Word여도 Excel 혹은 GitHub여도 상관없다 (작가는 Google SpreadSheet로 만든다).

 엔지니어로서의 활약을 PR하는 포맷을 스스로 만들어, 엔지니어로써의 활약을 표현해주길 바란다.

 

정말 보고싶은 직무경력서

---

 개인적으로 이력서는 거의 보지않는다. 자기 PR문은 생각이 보일 때가 있으므로 흥미롭게 보기는한다. 실력을 예측하기 위해서는 직무경력서를 메인으로 본다. 그 중에 크게 2개의 부분으로 나눠서 체크한다. 하나는 기술 스킬이고 다른 하나는 인간으로서의 소프트 스킬이다.

1) 기술 스킬

 먼저 많은 사람이 쓰고 있는 프로그래밍 언어, 데이터 베이스, 프레임워크 등을 본다. 그리고 어떤 프로젝트에서 그것을 사용하였는지를 본다. 그러나 그 이상을 보는 부분도 있다. 그것은 기술에 대해 이해의 깊이와 생각이다.

 프로그래밍 언어와 같은 기술은 도구 일뿐, 그것을 얼마나 잘 다루는지는 숙련도에 따라 다르다. 기술 타이틀만 작성해도, "사용해 보기만한" 사람과  잘 이해하고 있어 어떤 곳에 사용하면 좋을지를 이해하고 "제안할 수 있는" 사람은 완전히 다르다. 기술 타이틀만 작성하는 것만으로 만족하지 않고 더욱 표현을 채워줬으면 좋겠다고 생각한다.

 그러므로 써야할 것은 아래와 같다.

- 프로젝트 중에 어떤 역할을 해왔는지

- 어떤 이해를 가지고 기술을 사용해왔는지

 항상 비즈니스와의 상호관계를 이루기 때문에 개발 중에 딜레마가 존재한다. 그 안에서 요구되는 요건이나 기간에 대해 어떤 선택이나 생각으로 임한 것인가. 운용 유지등도 포함한 단기, 중기, 장기를 생각한 기술 선택인가, 도전할 수 있는 찬스에서 어떠한 기술을 제안했는가 그리고 그 근거는 무엇인가?

 즉, 비즈니스쪽에서 요구되는 요건의 제안에 대해 엔지니어쪽으로써 기술의 제안을 어떻게 할 수 있었는가를 말하는 것이 가장 역량을 측정할 수 있는 지표가 된다. 그 이유는 제안하기 위해 그 정보를 수집, 이해, 실행하는 힘이 필요하기 때문이다. 

 예를 들어 사용하고 있어 프로그래밍 언어나 프레임워크의 버전등을 충분히 이해하고, 무엇이 좋았는지, 변경하면 따르는 디메리트가 무엇인지, 신경써야만 하는 것들이 늘어나고 있는가? 등, 자신만의 생각을 갖고 있길 바라기 때문에 경력서 상에 버전이 적혀있지 않으면 그 기술에 대한 이해도가 깊지 못 하다고 여겨지게 된다.

(1) 2개의 기술 스킬

① 기초 기술

- 디자인 패턴(GoF, 멀티 스레드 디자인 패턴 등)

- 아키텍처 패턴(OOP, DDD, Cloud 아키텍처)

- DB특성(RDB, KVS, 컬럼형 DB 등)

- 알고리즘 (수학, 데이터 구조 패턴)

정리하자면, 기술 이해의 깊이를 알고 싶은 것이다.

② 트렌드 기술

- 유행하는 프로그래밍 언어, 프레임워크, 미들웨어, 툴

- 새로운 언어의 개념의 이해

- 편리한 포인트나 도입되지 않는 상황에 대한 고찰

정리하자면, 실행력이나 새로운 기술에 대해 안테나를 세우고 있는지를 알고 싶은 것이다.

트렌 기술만 잔뜩 쓰는 사람도 있지만, 그걸로 기술의 깊이를 보지 않는다. 두 기술의 밸런스를 적절히 잡아 작성하는 것이 중요하다.

2) 소프트 스킬

 엔지니어에 대해 말하자면, 회사에 소속되어 있는 경우에 한 명의 사원으로써 혼자서 물건을 완성하지 않는다. 혼자서 일하고 싶다면 회사에 소속될 필요가 없다.

 따라서 주변에 미치는 영향력도 엔지니어로써의 능력의 일부이다. 아래와 같은 항목을 염두해두고 프로젝트를 진행하는 중에 담당한 역할이나 생각에 대해 읽는다.

- 팀에서의 콜라보레이션 능력

- 리더십

- 팀 내, 팀 외에 미치는 영향력

- 과제를 발견하고 지적할 뿐만 아니라, 스스로 해결하는 자립성

등을 알 수 있는 설명이 있다면 좋을 것이다.

 다만, 소프트 스킬에 대해 쓸 경우 주의할 점이 추상적인 내용이 되기 쉽다는 점이다.  팩트를 기반으로 표현하고 수치나 변화를 구체적으로 쓰도록 의식하는 것이 좋다. 예를 들어, 리더가 됐기 때문에 훌륭한 것이 아니라, 리더가 됐을 때 리더로써 행동할 수 있는 것이 중요하다. 

 

자기 PR

---

현재 회사의 문제로 하고 싶은 일을 하고 있지 못한 사람은 자신이 하고 싶은 것에 대해 이것 저것 만져 본 것을 적는 것이 좋다고 생각한다.

 자신이 작성한 Blog글 이나 Qitta 등의 포스트나 스터디 그룹 등에서 작성한 자료도 괜찮다. 프로젝트에 대해서 임하는 자세나 의식하고 있는 것도 좋다. 자기 PR에 적혀있는 것이 진정으로 자신이 쓰고 싶다고 생각하는 부분이라고 생각하므로 나(작성자)는 이 부분을 가장 좋아한다.

 가능하면 기업에 응모할 때마다 새로 작성하는 것을 추천한다.  기업마다 조사해서 어떤 기술이나 문화가 있는지를 이해하고 그 중에 자신이 하고 싶은 것과 공헌할 수 있는 것을 몇 줄 적어 준다면 회사에 얼마나 맞는 사람인지 예측하기 쉬워진다.

 주의할 것으로 구체적으로는 "하고 싶은 것" == "어떠한 행동", 즉 행동이 포함되어야 한다. Go가 하고 싶다면 Go사이트로 가서 다운로드해서 프로그래밍해보는 것이다. 하고 싶다면 할 수 있는 범위에서 해보는 것이야말로 정말로 해보고 싶다는 것을 어필할 수 있다.

 

정리하자면

---

직무서에 쓰길 바라고 알고 싶은 포인트는

- 시스템에 대한 기술 활용정도

- 기술 선택이나 사용한 기술에 대한 의견이나 고찰, 생각

- 비즈니스와 기술의 최적의 관계를 생각하는 것

- 기술 선택에 있어 주변 사람들과의 조정법

- 향후 성장하고 싶은 방향성과 현재의 행동

사용한 기술, 프로젝트가 알고 싶은 것이 아닌 위의 포인트와 같이 어떤 생각으로 어떠한 행동을 해왔는지가 알고 싶은 것이다. 

---

참고자료

qiita.com/ashketcham/items/8ab3626feb9b4228f358