동아리(GDGoC Konkuk) 세션에서 이력서 멘토링을 진행을 했다.
아직 취준까지는 꽤 남았고 백엔드 공부를 시작한지 얼마 되지 않아서 쓸 말은 별로 없지만 작성해보는 기회가 되었다.
다만 한정된 멘토링 시간이기에 보잘 것 없는 내 이력서는 리뷰되지 않았다 ㅎ....
그래도 이력서가 무엇이고, 어떻게 작성하는 것이 좋은지에 대해 알 수 있었다. 까먹기 전에 기록해보고자 한다.
취업을 준비하는 개발자가 이력서를 작성하기 전에 반드시 알아야 하는 것
사실 이력서가 뭔지 막막해서 동아리가 제시한 예시를 따라서 작성했는데 아래 내용들도 못지킨 부분들이 있었다.
아래는 각 이력서 멘토링에서 공통적으로 언급된 기초적인 부분들이다.
- 이력서와 포트폴리오는 명확히 구분되어야 한다.
- 이력서(Resume) : 경력, 학력, 기술 등을 한눈에 파악할 수 있게 정리 한 것이다.
- 포트폴리오(Portfolio) : 이력서에서 생략된 내용을 보완하기 위해 프로젝트 경험이나 작업 결과를 상세히 보여줄 수 있도록 구성한 것이다.
- 회사에 따라 이력서는 달라질 수 있다. 한장으로 모든 채용공고에 돌려막기 하는 것은 좋지 않다.
- 특히, 기술 스택의 경우 회사의 Job Description에 따라 바뀌는게 당연한 것이다.
- 이력서는 한장에 20분은 커녕 수백, 수천장을 다 볼 시간 없으니까 최대한 컴팩트하게 핵심을 넣어야한다.
- 결국 코드를 잘 짜기위해 얼마나 꾸준히 노력하는지를 채용담당자는 궁금해한다.
- 아무리 좋은 이력서여도 흠이 있다면 -200점이 될 수 있으니까 조심하자.
- 맞춤법 검사는 정성이다. 꼭 하자.
- 걸려있는 링크들은 모두 시크릿 모드로 열어봐서 접속가능한지 확인하자.
분야(FE, BE, AI)와 관계없이 이력서 멘토링에서 인상깊었던 부분들
멘토가 각 분야별로 한분씩 계셨는데, 공통된 의견들이 은근 많았다. 그런 부분들은 기억하면 좋지않을까?
- 깃허브, 기술블로그 중요시하는 채용담당자는 많다. 성장과 노력의 흔적을 보여주기 가장 쉬운 부분이라는 것이 멘토분들의 공통적인 의견이었다.
- 두개를 열심히 준비했다면 링크를 상단에 배치해두는 것도 꽤 괜찮은 전략이다.
- Introduction은 아래에 나올 내용과 기승전결이 중요하고, 큰 임팩트를 주지 못한다면 포트폴리오로 빼는 것도 괜찮다.
- 너무 길고, 장황하게 작성한 Introduction은 구리다고 한다.
- 컴팩트하게 "나는 확실한 실력을 가진 실력자"라는 느낌을 줄 수 있다면 넣어라.
- Awards(수상실적)은 면접관의 관심사는 아닌 것 같다.
- 차라리 이력서에 스터디나 동아리 활동을 넣는 것은 어떨까?
- 양질의 스터디를 진행한 흔적이 있다면 적을만하다. (어떤 책을 읽었는지, 어떤걸 배워서 적용해봤는지)
- 기술스택에 관한 내용
- 채용 공고에서 요구하는 기술이 아닌데 적는 것은 오히려 방해요소로 작용할 수 있다. 전문성 영역에서 백엔드 개발자에게 프론트엔드 기술 스택은 담당관 입장에서 별로 호감을 사지 않는 것 같다.
- VCS(Version Control Service) 또는 **협업도구(Jira, Slack 등)**은 별로 안궁금하다. 회사오면 다 배울테니까.
- 테스팅에 대한 부분을 깊게 이해하고 잘 작성한 포트폴리오가 있다면 도움이 될 가능성이 크다. 대신 면접때 대답을 할 수 있어야한다.
- 운영 도구(메트릭, 성능측정, 로깅, CI/CD)와 같이 안정적인 서비스를 위한 도구들은 잘 이해하고 적는다면 도움이 될 수 있다.
- **스타트업이나 멘토 같은 경험(Experience)**을 적으면 그 활동이 어떻게 기여가 됐는지 정확한 임팩트를 남겨야한다.
서버(백엔드) 개발자 이력서에 대한 멘토링 중 기억해볼만한 부분
일단 서버 개발자분은 TOSS에 다니시는 분이고, Spring Framework를 다루시는 듯하다. 따라서 Java에 관한 이야기가 많았으며 한명의 의견이기 때문에 이 분이 정답은 아닐수도 있다. 그럼에도 알고있어서 나쁠건 없지요?
듣고나니 어떻게 공부 방향성을 잡아야하는지가 눈에 보이기 시작했다.
- 결국은 기본기가 핵심이다. 채용 담당관도 Redis, Kafka, K8s 같은 고오급 기술은 0년차 개발자에게 딱히 기대하지 않는다.
- Java (Java 21도 LTS 버전이 됐지만 21까지의 기능은 별로 안중요하다고한다.)
- Reflection
- Stream API
- 객체지향프로그래밍
- JUnit 등등..
- Spring Framework
- Dependency Injection에 관한 이해
- AOP에 대한 이해
- JPA에 대한 이해
- @Transactional 에 대한 이해
- 디스패쳐 서블릿은 어떻게 동작하는지 등등..
- SQL
- Index, Hint, Query 개선과 관련된 내용들
- 프로젝트들이 대부분 비슷한 스킬셋을 갖고있을텐데 따로따로 적지말고 한번에 적어보자. 분산된 것보다 임팩트를 줄 수 있다.
- 요즘 로그인 없는 서비스가 어딨나? 이런 것도 가볍게 작성하면 별로 이득이 없다.
- 스프링시큐리티라는 프레임워크 자체가 매우 어렵고 복잡한데, 이력서보면 전부 적혀있다. 뭔가 나만의 무기를 만들어보자.
- ex) 스프링 시큐리티에 대해 쓰레드 로컬 트러블 슈팅 경력이라던지.
- 'Redis로 인증 캐싱' 같이 요즘은 세트로 따라오는 내용들이 흔하다. 이런건 사실 이력서에서 크게 매력적이지 않은 것 같다.
- 구체적인 기술 명과 개선된 수치를 명시하면 되게 기억에 잘남는 이력서가 될 수 있다.
- 근데 10% 같은건 1% 에서 1.1%된것도 10%니까 말장난 같이 보일 수도 있다. 절대 수치를 기록하는 것도 괜찮을 듯하다.
- 코드, 구현, 기본기에 대해 좀 자세히 적어보자. 좋은 코드는 뭐라고 생각하고, 그 코드를 작성하기 위해 어떤 노력을 했는지 보이면 좋을 것 같다.
- 결국은 트러블 슈팅 경험이 핵심이다. 인위적으로라도 빅데이터를 주입하고 처리해보는 경험을 해라.