19.10.30) 강연 정리 - 주니어 개발자의 이력서 쓰기 (이동욱님)

주니어 개발자의 이력서 쓰기

• 19.10.30 이동욱님 특강
• Slide Link

• 첫 직장은 가급적 서비스 개발회사 추천
  • 네이버, 카카오, 쿠팡, 배민 등 ..

보편적인 이력서 구성

• 프로필
• 소개 (5-7줄)
• 기술 스택
• 오픈소스 / 프로젝트 / 경력
• (선택) 교육 / 발표 / 집필
• (선택) 기타

⇒ https://jojoldu.github.io 이동욱님 이력서 (구구콘 발표 샘플)

이력서 팁

• 경력 포함 모든 이력은 역순 정렬로 (최근 순서)

• 한글, 워드보단 PDF

  • 채용 사이트 '브라우저'에서 바로 볼수있는 형태
  • 별도 뷰어가 필요하지 않도록
  • 회사에서 시킨거 아니면, zip 압축하지 말기

• 프로필

  • 깃헙 - 필수
    • 있지만 깡통이라면, TIL부터 시작
    • 좋은 예시 : 진유림님, 코드몽키의 TIL
    • fork는 효과x, 학교프로젝트 정리해서 올리기
    • 코드 없는 저장소는 효과가 없다. 물론 아예 저장소가 없는 것보단 나음
  • 블로그 - 준필수
    • 티스토리, 깃헙 블로그, 미디움 등
    • 네이버 블로그는 비추
  • 사이드 프로젝트 - 있으면 가산점

• 좋은 사람을 놓치는 것보다, 안 좋은 사람 뽑는걸 더 두려워한다 → 긴가민가하면 안뽑는다

  • 물 흐리는 느낌, 기존 잘 하던 사람도 영향, 이직해버리는 등

• 서류 심사관이 도박을 하도록 만들지 말라 ('이건 내가 믿고 걱정없이 뽑아야 하는 카드야!', 증거 많이 노출, 어필)

• 소개

  • 일종의 summary
  • 어떤 경험, 어떤 생각 갖고있는지, 평소에 어떤 노력하는지 등

• 최대한 숫자로 표현

  • 아직 우린 신입이라 힘들수도 있지만. → 신입 개발자의 자세를 강조하자
    • 배우려는 자세
      • 스스로 부끄러워하고 걱정할 줄 아는
    • 좋은 질문을 하는 자세
      • 선임이 A라고 했을 때 납득이 되지 않으면 무조건 '검증하고 다시 질문하는 사람'
      • 바로 수긍 ㄴㄴ, 증명없이 주장 ㄴㄴ
  • '대용량/대규모'는 상대적이다. RPM/TPS/PV/MAU 등 구체적 숫자로

• 이벤트때 분당 57만건 처리

  • read 요청은 캐시, redis 등을 통해 분산가능
  • 주문,결제는 write요청이 많다. 이부분은 위의 방법으로 힘듬
  • 배민은 노하우 쌓이는 중

• 노력, 열정, 도전 등 진부한 단어 ㄴㄴ

  • 단어에 선입견 존재 (공감)

• 기술 스택

  • 한두번 써본 기술은 언급하지 않는다
  • 주력 기술들만 언급
  • 경력에 비해 너무 많은 기술 스택은 오히려 좋지 않다
  • 우리팀에서 믿고 맡길수 있는 기술인가? 가이드 없이 잘 해갈수있을까?
  • 머신러닝, 블록체인은 보통 hello world에서 끝나는 경우가 많음

• 러닝커브를 강조하는 이력서로

  • 내가 얼마나 빠르게/바르게 기술을 배울 수 있는 사람인지
  • 나만의 학습 방법
  • 구글링으로 나온 코드를 바로 적용 ㄴㄴ, 찾은게 best pratice인지 찾고 검증해보고 사용

• 경력/프로젝트

  • (졸작과 우테코에서 한 플젝 위주로)
  • 질문하면 답변가능한 프로젝트만
  • 맡은 개발 파트 요약
  • 플젝에서 강조하고 싶은것
  • 성과, 실적있다면 추가
    • 주변의 칭찬 의미없음, 객관적 자료
  • 가능하면 증명 가능한 링크

• 교육/스터디로 간을 맞추자 (부족한 양 채우기)

  • next step, fast campus, code squad ...
  • 어떤 기준으로 교육을 선택하고, 무엇을 배웠는지 정리
  • 블로그 남기는 중 , 수료증 만으로 증명할 수 없다

• 스타트업, 서비스엔 자격증 필요없다. 다른곳 간다면 정처기 같은게 필요할수도?

• 혼자 MSA를 공부하고있다는 말은 ㄴㄴ 신입에겐 탄탄한 기본기를 바란다

  • MSA 대표 사례 : 넷플릭스
  • 저번 중국 모바일 세미나 들은 내용 일부 나옴

• 각 회사마다 잘하는게 많다. 경력땐 회사의 장점들을 흡수

  • 배민은 실시간 주문 이벤트 트래픽 처리 잘함

• 오픈소스

  • 신규 프로젝트에 주로 기여할 부분이 많음
  • rankedin.kr - 우리나라 오픈소스 랭킹
  • 스타는 적어도 코드가 충분한 저장소 의미있음. ex) jojoldu - 'spring-boot-aws-mock'

• 포트폴리오

  • 졸작 전시회 하듯하면 효과 없다. ex) 기능, UI 기획 등이 강조된 PPT
  • 서류검토자는 코드를 보고 싶다. ex) 테스트 코드를 작성하는지, 객체지향적으로 작성하는지 등
  • 물론 깃에 올리자
    • 리드미 작성 잘 하고, 커밋 잘 찍고, 실제 플젝처럼

• 문제 해결 사례 - 가산점 높다

  • 학교, 국비, 스터디 뭘 하던, 만난 문제를 해결한 사례
  • 단순히 복붙으로 해결이 아닌, 자세하게.
  • ex) 로그가 없어 문제 확인 어려웠다. 서버다운없이 요청 확인위해 tcpdump로 24시간 동안 패킷 데이터 남김. 이로 문제를 확인하고, 테스트 코드로 문제를 재현하고 검증 ~~
    • https://jojoldu.tistory.com/40
  • 앞서 몇번 언급된, 문제 파악과 해결책 찾기, 재현과 검증을 통한 ~~

• (이력서) 잘 쓰려면 (좋은 개발자로) 잘 살아야 한다.

• 경력 이직은 같이 일한 사람들과 보통 추천으로. 이력서는 생각보다 나중엔 안쓰일수도. 좋은 개발자가 먼저 되자

QA

• 경력이라면 이력서에 웹 백엔드 관련된 것만 남겨놓고 나머지는 날릴수있을텐데, 신입이라 날리면 내용이 별로 없고 공백의 시간. 이력서에 남길까 말까

  • 남기던 말던 별 의미 없을수도. 분명한건 큰 도움은 되지않는다 (물론 그렇겠지)
  • 질문할거리가 생긴다. 예전에 했던것 대답 제대로 못하면 신뢰감 떨어짐
  • 문장 언급은 괜찮지만, 지금처럼 제대로 한 칼럼으로 넣어버리면 질문 들어올 가능성 생기므로, 대답할수있는 프로젝트만

• 깃헙 프로젝트 중 지금처럼 제대로 설계되지않고 개판인 예전 코드 - 리드미에 변명을 써놓아야. "리팩토링 진행중"처럼. 그럼 가장 마지막 커밋 확인할 것

  • 초기 모델 프로젝트 올려도 괜찮다. 대신 리팩토링 중이다 or 과거에 작성한거라 별로다 언급. 대신 이력서에 리팩못한건 올리지말기. 깃헙에서 볼사람만.
  • 생각해보면 당연한 얘기.

• 가장 감명깊게 읽은 책으로 자바 기본서 비추천. 객체지향 사실 오해나 토비 스프링같은 핵심들 위주로. 문법책보단 아키텍처, 개념, 설계같은 큰 원리 위주 (포비께서도 항상 하시는 말씀)

• spring rest docs > spring contract

• 지원동기에 "~~무엇을 하고 싶어서 지원했다" ㄴㄴ, 회사는 내가 하고싶은걸 시켜주고 돈주는 곳이 아님. 결국 "편식하겠다는 말"

  • 누구나 깨끗한 새로운 코드 만들고싶을것. 레거시는 다 손대기 싫어한다.
  • 왜 회사가 좋고, 개발문화 좋고, 동료들과 배울점 많고 그냥 그런 내용들로
  • 지원동기 생각보다 중요하지 않을수도?
  • 신입으로서의 자세와, 같이 일하고 싶은 동료라는 점을 더 어필

• 꾸준히 오래가기 위한 팁

  • 하루 공부 할당량을 계획하기. 모든 시간 다 쓰고 잠줄이면 오래는 못간다
  • 눈에 보이는 지표로 확인하며, 꾸준히 학습 진행