이력서 특강

이력서와 경력 기술서의 차이 이력서

  • 내 이력과 경험 요약 경력기술서
  • 이력서를 보다 상세히 포트폴리오(UI가 있는 사람들)

사실 거의 비슷하지만 정확한 어원을 따라가면 위와 같은 차이

  • 향로, 원희님 등 잘 쓴 이력서를 보고 따라하기
  • 가져온 템플릿에 내가 한 것들을 쓰기
  • 스스로 이력서를 다듬기
  • 원클릭 채용 플래솜에서 수백개의 서류 제출

아웃라이어 → 평균 기준치가 아닌 오버스펙을 가진 사람들의 이력서를 보게 됨 타인의 경험과 나의 경험의 편차가 크기 때문에 자신의 경험을 녹여내기 어려움 결과에만 집중한 방식으로는 문제점이 될 수 있음 스스로의 경험에 메타인지가 안돼있음 → 밋밋한 이력서가 되어있음 원클릭 채영 → 타게팅이 제대로 이뤄지지 않은 서류 제출 → 낮은 합격률 정확한 타게팅을 하자. 회사가 요구하는 인재가 상품의 구매, 우리는 상품. 나는 이러한 상품이예요 하는 이력서를 제출 적합성이 떨어지는 서류가 될 수밖에 없음

가독성이 좋고 직관적인 이력서가 좋은 이력서 가독성 좋은?

  • 글자에 대한 폰트, 간격, 폰트 처리 등 → 나의 입장 직관적인
  • 서류검토자의 입장에서 사고의 과정을 거치냐
  • 사고의 과정을 많이 거치면 직관적인서류가 아님
  • 어떤 서류, 어떤 강점, 가치관 등에 대해서 바로 알 수 없으면 안됨
  • 추상적 표현이 없고 사고가 필요없는 이력서 쓰기

  • 자신의 역량을 핵심적으로, 객관적으로 잘한 이력서
  • 역량 + 경험을 기준으로 서술
  • 자신에 대한 메타인지가 너무 뛰어나서 자신의 역량을 한 페이지 안에 전부 녹여냄

  • 처음부터 완벽하게 쓰려고 해서
  • 기술 블로그의 글을 처음부터 잘 쓰기 ? = 이력서와 동일
  • 자료 조사, 내용 이해, 글 작성, 글 다듬기
  • 많은 지원자들은 모든 과정을 생략하고 작성부터 시작
  • 처음부터 천천히 과정에 집중해서 진행 즉각적인 피드백 → 함정 처음부터 잘 써야 하기 때문에 기술블로그를 잘 쓰려고 함

이력서 어디서 작성하지?

  • 어디서 작성하느냐에 따라 크게 다름
  • 템빨 → 이력서의 아이템
  • 명확한 기준
  • 디자인, 접슨성, 러닝커브, 버저닝, PDF추출

디자인 역량이 없는 경우가 대부분 디자인이 필요 없음 → 노션(폰트 잘돼있음) 워드 → 러닝커브 한글 쓰지마라 구글 독스 → 구글 드라이브에서 지원하는 웹페이지인데 난이도는 워드와 같음 채용 플랫폼 (랠릿,원티드, 프로그래머스) → 기능 자체가 제한적(대외활동, 구조 등) 디자인을 독창적으로 가쟈가고 싶다 → 워드, 피그마 좋지만 힘듦 노션이 심심하면 워드나 구글 독스, 노션 좀 손에 익었으면 워드와 구글독스 pdf지원이 안되면 무조건 드랍 대부분 기업에선 pdf 요구 노션 → pdf 개열받음 pdf 추출했을 때 안이쁜 플랫폼 바꾸기 keynote와 pptx도 좋지만 가로 사이즈 말고 세로 사이즈 a4로 만들기 → 출력할 때 글자가 짤리거나 작게 나오는 경우가 많음

버저닝 → 아까 앞에서 타겟팅하는 것처럼 난사하지 말고 각각 요구하는 역량을 보고 각각 기업에 맞는 이력서 관리하기(네이버용, 카카오용 등)

브레인스토밍 하둣이 내가 했던 경험 나열하기 자기 자신을 스스로가 모르는데 서류 검토자가 어케앎 결국 나 자신을 알라를 선행하기 이력서 작성 중 가장 중요 대충하게 되면 2,3,4,5단계도 어디선가 무너지게 됨 브레인스토밍하듯이 내가 했던 경험 나열

  • 실무자라면 일일보고, 주간 보고를 찾는 것도 꿀팁 만약 일일기록을 하지 않고 있다면 지금이라도 시작하기 과거의 성과 등 모든 것들을 적기 이쁘게 할 필요가 없다 러프하고 나이브하게 A-Z까지 작성

내가 했던 것들을 하나하나 다 적기 모든 것들을 적기 사생활적인 것들도 다 적기 작성하면서 경험을 계속 물음표 던지면서 기억해내고 구체화하기 KPT 회고 방식 이용하기 잘했냐 못했냐가 중요한 것이 아닌 나의 경험을 작성한다는 것에만 집중 면접을 대비해서 경험을 구체화하기

  • 추상적인 표현 한번 더 검증하기
  • 성과. 수치, 결과를 추가
  • 2단계에서 작성
  • 성과가 없는 신입 ? → 서오가와 실적은 다름
  • 성과 → 문제해결역량, 주관적인 것
    • 내가 여기서 뭘 배웠고 뭘 이뤄냈는지
  • 실적 → 매출, KPI 등 사용자 증가추세 등등..
  • 상대적 수치화 → 구체적 수치화
    • 보통 퍼센티지를 이야기
  • 비즈니스 임팩트
    • 기술 + 경험 + 비즈니스적인 가치를 함께 적기

50% → 퍼센티지는 추상적임 이게 어느 정도의 개선? 4초에서 2초 → 조금 더 구체적 유저 이탈율 감소 → 비즈니스적 가치 집착하지 않기 결과가 본인에게 의미 있었다면 자신있게 작성 %가 높고 낮음으로 역량을 판단하지 않음 → 궁금한 것은 문제 해결 역량 높고 낮음으로 기죽지 말기

프로젝트 → 필수는 아님 프로젝트는 경력직인 경우에는 굳이 쓰지 않고 합침 중복되는 경우가 많기 때문 → 경력에다 합쳐버리기 경력이 없으면 프로젝트만 적기 한줄 자기소개는 마지막에 작성

  • 강점을 정하고 경험을 작성하기
  • 경험에서 강점을 도출하기
    • 일단 작성하고 자기소개 작성 추천
    • 나중에 실제 내 강점이 아닐 확률이 높음

최근의 경력부터 최신순 나열하기 서류검토자들은 수백장들을 보면서 익숙해져 있는데 반대로 읽히게 되면 경험이 좋지 않음 회사가 망한건데 경력이 짧아서 걱정 → 간단히 작성 아무도 뭐라하지 않음. 대신 핑계가 되게 하지 말 것 이 안에서 뭘 했는지가 중요 감안해서 볼 것임

  • 자신이 없다고 하더라도 신뢰할 수 있을까? → 주관적인 생각
  • 지원공고에 요구하는 스택에 맞게 작성하기
  • 자바를 원하는데 메인 스택이 파이썬이고 자바 찍먹이더라도 일단 쓰기
  • 레벨(숙련도) ? → 요구하는 것이 아니면 먼저 작성 X
    • 어차피 안 믿음
    • 어차피 깊게 물어보면서 검증함
  • 그럼에도 깊게 작성하고 ㄱ싶으면 말리진 않음
  • 소거시킬 수도 있음

  • 문제 해결 역량 위주 작성
  • 내가 여기서 어떤 문제에 부딪혔고 어떤 것을 배웠는지
  • 단순 경험만 나열 → 이해하기 어려움
  • ~해서 구현? → 어느 정도로 정확성 있게? 어느정도로 했길래 구현했다고 했을까
    • 가장 추상적인 레벨
    • 밋밋한 이력서가 되는 방법
  • 프로젝트 설명 → 사바사
    • 히스토리가 진짜 궁금하면 면접에서 물어봄
    • 기술적인 핏함과 소프트스킬을 물어봄
  • 기술적 역량과 문제 해결 역량 강조
  • 제3자가 봐도 직관적이게 별다른 사고과정을 거치지 않아도 이해할 수 있게끔
  • 고객관리플랫폼(제우스 프로젝트) 처럼 별칭은 괄호안에
  • 주로 기여한 것들

컨퍼런스, 오픈소스, 스터디, 자격증, 수상내역, 외부활동, 교육 등..

  • 스터디 경험 대충 쓰지 말기
  • 엄청난 강점으로 살릴 수 있음

  • 스터디를 통해 뭘 배웠고 이걸 어떻게 응용했는지
  • 스터디만 했어도 개발에 대한 역량과 성장가능성을 많이 봄
  • 이거를 가지고 응용력까지 가면 벽이 있음. 벽을 넘기
  • ~학습했습니다. 이를 바탕으로 ~
    • 이 지원자는 단순 책을 따라한게 아니라 진짜 적용을 했네? 깃헙 레포 확인
    • 일단 조금 먹고 들어가기

서술형 → 명사 종결 ~향상시킴, ~을 실천,~을 담당, ~을 구현 이력서는 결국 나의 경험을 압축해서 빠르게 전달 강조가 필요한 곳에만 볼드 처리하고 명사종결로 빠르게 파악할 수 있도록 하기 볼드 → 전체 다 볼드처리하지 말기

  • 진짜 중요한 문장, 핵심 문장, 핵심 강점 등
  • 여기저기 다 하면 의미 퇴색
  • 뭘 강조하고 싶은데?를 버리고 가기

  • 나중에 계속 경험이 쌓이면 10페이지도 넘음
  • 신선도가 떨어진 경험은 제거 또는 함축(3~4년 이내)
  • 지원 공고에서 요구하는 역량에 맞게 경험 선별
    • 프레임워크에 대한 역량
    • 프론트엔드인데 백엔드, 인프라 등 상관 없는 경험 굳이 적지 말기
    • 진짜 궁금해할 내용인지 자문해보기
  • 애매하면 검토자가 봐도 애매함
  • 얼마나 많은 플젝 경험 → 지원공고와 적합한 인재인지
    • 결국 검토자의 입장은 지원공고와 적합한 인재인가가 중요
    • 커뮤니케이션 맞추기

브레인스토밍 꼭꼭 하기

  • 비즈니스 가치 → 정의하기 나름
    • 생산성이 될 수도 있음

문제 해결 역량 → 능력치 조건문 급하게 달아서 막는 사람과 근본적인 문제를 막는 사람의 차이

실제 서비스까지 오래 했던 프로젝트가 있어서 프로젝트 경험에 넣고 싶은 프로젝트가 있습니다. 이 프로젝트가 좋은 경험이기도 하지만 문제 해결 등이 제가 생각했을 때 개발을 시작한 지 얼마 안됐을 때 했던 프로젝트라 초보적인 문제 해결이나 경험들이 많아서 쓰기가 어려워지는 것 같습니다.. 이러한 프로젝트를 잘 녹여낼 수 있는 방법이 있을까요?

현재 그리팅이나 나인하이어 등 간편하게 이력서를 제출하는 플랫폼이 있는 회사에 지원할 때 자소서 제출칸이 없어도 자기소개 위에 지원동기를 간단하게 적어서 제출하고 있는데 괜찮은 전략일까요?? → 지원동기를 꼭 작성하자!

  • 작은 기업이라도 엄청 많이 지원함
  • 인사채용하는 사람의 입장에선 얼마나 오래 있을건지에 대해서 어떻게 검증할까가 지원동기와 연결됨
  • 지원동기가 personal하게 만들어져 있으면 호감이 생김

링크 첨부 → hooking이 되는가?가 확실해야 됨

굉장히 튀는 자기소개가 아니라면 간단하게 쓰고, 절약한 공간을 나만의 장점으로 채우자

  • 따른 사람 이름으로 바꾸었을 떄 이상하지 않으면 평범한 자기소개서

  • Programming Language
  • Frontend Technologies
  • Database
  • Productivity Tools
    • 면접에서 질문 나오면 솔직히 말하기

기술을 바로 위에

  • 커버 레터 필요하면 작성
  • 관련 없는 과거 경력
    • 이력서에 쓸게 없으면 써야함
    • 물경력이라고 생각한다면 다시금 생각해봐야함
  • 면접관에게 할 수 있는 질문

커리어 발전이란?

문제 정의 잘하기 뜨는 기술 꼭 알아야 한다고 생각하기 보다는 나에게 맞는 업무를 성공을 하고 결과지향적으로 사는 것이 좋음 좋은 평판 → 지인 추천 형태로 기여

문제해결의 난이도가 작은 것 같다 → 왜 좋은 경험인지 검토자에게 설득할 수 있다면 그 관점을 기준으로 설명하기

링크로 모두 제출하기 보다는 하지 않기 대외활동 한 이유 → 내가 실무하게 되더라도 개발욕구를 해소할 수 없다고 생각해서 사이드프로젝트라는 창구를 통해 실무 협업에 필요한 새로운 기술 스택 시도 지원동기 적으면 좋음 → 왜 이 회사의 이 팀에 들어가고 싶은지

내 이력서 피드백

문제해결

  • 기술스택 교체 업그레이드
  • 바꿀 수 없는 환경에서 개선을 한 케이스 캐싱 → 누구나 할 수 있음 바꿀 수 없는 환경에서 개선을 한 것이 진짜 역량이 보임 캐시를 바꾸는 것은 구글링하면 당연히 됨 캐시 이전에 다른 대안이 있지 않을까 문제 해결 과정을 좀 더 넣기