소마? 소소하게 마무리하기.

23년 4월 5일 수요일. 김종찬 멘토님의 「소프트웨어 엔지니어의 이력 관리」 멘토링을 들었다.

이력서를 어떻게 써야 하는지, 더 자세히는 좋은 이력서를 쓰기 위해 어떤 이력을 쌓아야 하는지에 대한 멘토링이었다.

 

[느낀 점]

1. 프로젝트의 끝은 배포가 유저 피드백과 리팩토링까지.

- 현업에서 프라덕트를 아예 밑바닥부터 담당하는 경우는 드물다.

  대부분은 "달리는 기차의 바퀴를 갈아끼우기"이다.

- 소소하게 마무리하고, 빠르게 개선하자.

 

2. 팀원들과 사이 좋게 지내자! 생각보다 쉽지 않다.

3. 프로젝트 설계에 공을 들이자.

- 기술 선택에 대한 트레이드 오프 고려해보기

- 구체적이고 수치로 확인할 수 있는 목표를 설정하기

(설계할 때 목표치를 어떻게 확인할지도 계획해야 한다)

 

4. (취업을 고려한다면) 현직에서 요구하는 기술 스펙을 파악하고, 빠르게 학습하기

 

[내용 요약]

1. 어필을 못하면 서류에서 걸러지게 된다.

- 보통 구인 과정은 서류 -> 기술 면접 -> 최종 순.

- 기술, 최종 면접은 고위직이 참여하기 때문에 비용이 많이 든다.

  그래서 서류 단계에서 어필을 잘 못한 사람은 거르게 된다.

- 꼭 어필의 문제는 아니고, TO가 너무 적거나 기술 스택이 안 맞는 것일 수도 있다.

 

2. 서류에서 중점적으로 보는 것: 빠른 적응, 팀의 약점 보완, 개발 능력

① 빠른 적응

- 어차피 기본기는 다들 갖추고 있다.

- 이슈가 생겼을 때, 빠르게 원하는 기능만 익혀서 적용할 줄 아는 능력

- 회사에서 요구하는 언어/ 프레임워크/ 개발 프로세스와 얼마나 일치하는지

 

② 팀의 약점 보완

- 결과물의 안정성, 작업 속도, 기술 트렌드 관심도 및 공유 마인드,
  기술 선택시 트레이드 오프 고려하는 능력, 설계 능력 등

- 인맥을 활용해서 해당 팀의 약점을 찾아보자.

 

③ 개발 능력

- 연차, 경력에 걸맞는 능력이 있는지

- 특정 기술을 학습한 이유, 문제 해결 과정에서 배운 내용 등을 설명할 수 있는지

- 깃헙에 잔디 심기, 코드 공개해놨다가 설명 못하면 레드 플래그

 

3. 서류에서 중점적으로 보지 않는 것: 프로젝트 갯수, 자격증, 절대적이지 않은 것

- 프로젝트는 양보다 질

- 자격증은 좋지만 절대적인 개발 실력이 더 중요하다.

- 절대적이지 않은 것

    - 성격, 성실성, 소통 능력 등

    - 외모, 나이 등

 

4. 이력서 vs 포트폴리오

- 인사담당자가 투입하는 시간: 이력서 < 포트폴리오

- 이력서는 간결한 표현으로 작성. 성과와 기술 스택 위주.

- 포트폴리오는 사진, 영상 등을 포함하여 풍부하게 표현.

  프라덕트에 대한 배경(학습한 것, 시행착오 등)까지 포함.

 

- 공통적으로 나타나야 하는 것

    - 프로젝트에서 기술 키워드(언어, 프레임워크, 아키텍처 패턴, 라이브러리 등)

    - 내가 구현한 기능, 개선 사항 등

    - 외국어 능력

 

5. 인사담당자가 이력서를 넘기다가 내 이력서에서 멈칫하게 해라.

- 어필 포인트는 이력서 상단에 배치하기

(이력서를 모두 읽고 나서가 아니라, 이력서의 상단 콘텐츠를 보고 매력을 느껴야 한다)

 

- 지원 공고에서 요구하는 기술 경험과 매칭되는 기술 키워드를 나열하기

- 나의 성과를 수치로 표현하기

  ex. 2주마다 안드로이드 최신 트렌드 발표. 1년 24회.

 

- 프로덕트 운영 경험

  ex. 메인 릴리즈 5회, 리팩토링 후 뷰 로딩 시간 50% 감소

 

- 작업 결과물에 대한 근거는 웹 링크로 남기기

  ex. 깃헙, 오픈소스 기여 결과 등