주니어 개발자 이력서 쓰는 법

·2022년 7월 15일
591

취업준비

목록 보기
1/8
post-thumbnail

신뢰도를 올리기 위하여 제 소개가 먼저 필요하겠죠?

  • 2022.03 ~ 2022.06 부트캠프 백엔드 과정 진행
  • 2018.07 ~ 2022.01 반도체 Set-Up Engineer
  • 2015.03 ~ 2019.02 컴퓨터 공학 초대졸(2년제)

이력이 정말 특이하죠? 컴공이였는데 다른 업계로 넘어갔다가 부트캠프라니
기간을 보시면 취업도 조기취업이라는 것을 어느정도 가늠해볼 수 있습니다.

7월 15일 기준

  • 회사 1개에 대한 최종 오퍼
  • 회사 1개에 대한 최종 면접 결과 대기중
  • 신입이 아닌 2년차 3년차 경력직 서류합격 20건

서류지원은 대략 110개정도 하긴 했습니다...^^...

고작 3개월의 부트캠프 수료한 것으로, 경력직 서류 합격을 받을 수 있던 저의 이력서를 작성할 때
고려를 했던 다양한 부분에 대하여 천천히 알려드릴 것입니다.


글이 매우 깁니다. 제가 2주간 이력서를 작성하며, 수많은 분들에게 피드백을 받아왔고
3주간 면접을 진행하면서 겪은 다양한 경험이 포함되어있기에, 길 수 밖에 없습니다.

하지만 그만큼 필요성을 느꼈기에 내용이 포함된 것입니다.
필요한 부분만 읽어보시거나 아예 처음 작성해보신다면 처음부터 끝까지 흐름에 맞게 읽어보시는 것을 추천드립니다.

해당 글은 개인적으로는 1개 이상의 프로젝트를 진행한 국비, 부트캠프 수료생들에게 큰 도움이 될 것이며 독학을 하셨기 때문에 프로젝트가 없는 분이더라도 제법 도움이 될 것이라 생각합니다.

그리고 채용프로세스는 언제나 누가 운이 더 좋냐에 결정되는 경우도 있습니다. (시기가 정말 중요해서)
솔직히 일희일비할 수 밖에 없는데 그래도 좀 아쉬운 마음을 잘 추스리셨으면 좋겠습니다. (나도)

현재 경기가 좋지 않아 채용시장이 살얼음판인 것은 사실입니다.


이력서, 어떻게 써야해요?

저는 조기취업으로 회사를 취업했기 이력서를 써본 적이 없었습니다.
그래서 어떻게 써야하나 고민을 하고 있었는데, 부트캠프 특성상 수료하면 템플릿을 보여줍니다.

하지만 저는 안썼습니다, 쓰면 피볼 것 같다는 생각이 들었거든요.
전 기수의 졸업생들이 과거 전적이 어떠한지를 모르기 때문에 주는 것을 그대로 사용하는 것은 위험하다고 생각했습니다.

그럼 어떻게 적어야하나....하면서 고민을 하다가 유투브를 찾아보니 이런 영상을 보게 됩니다.
개발바닥 재밌어요

어떤 분인지는 모르겠는데 저런 제목을 쓸 수 있을까. 라는 생각을 하면서 봤고
본인의 이력서를 공개하셨기 때문에 해당 글을 보면서 그림을 그려가기 시작했습니다.

개발자 이력서 작성하기 (feat. 이력서 공개) Wonny(워니)

체크리스트도 있고 중요한 정보들이 많기 때문에 많은 것을 참고할 수 있었습니다.

하지만 주니어는 이렇게 이력서를 작성하면 안된다는 것을 깨달았습니다.

왜 그럴까요?

  1. 주니어는 경력자들처럼 증명할 수 있는 객관적인 자료가 절대적으로 모자릅니다.
  2. 채용담당자들은 이력서 하나만을 보고 다음 스탭으로 넘길지를 고민합니다.
  3. 그렇기 때문에 짧게 쓰는 것이 아니라, 최대한 자세하게 자신을 소개해야합니다.

왜 이렇게 이야기를 할 수 있냐면, 처음은 저도 짧은 것을 강조하여 작성을 해보고 서류를 넣어봤습니다.
깔끔하게 전부 다 날라가더군요(....)

그래서 왜 그럴까, 라는 생각을 해보니 위와 같은 이유가 생각나서
수정을 해서 넣어봤더니, 바로 날라가던 회사들에서 서류합격 이메일을 받게 되었습니다.

그럼 시작해볼까요? 주니어만을 위한 이력서를 작성하는 방법에 대해서.

자, 이제부터 싸움을 시작하지 나는 창이고, 너는 방패를 들꺼야.
이제부터 힘껏 막아보라고 ⚔️

이력서의 구성

이력서의 구성은 사람마다 약간의 차이는 있겠지만, 큰 틀은 벗어날 수 없습니다.

  • 제목(자율)
  • 인적사항
  • 스킬
  • 자기소개
  • 경험
  • 공부이력(있으면 좋음, 저같은 기록형이면 무조건 넣어야함)
  • 학력, 경력
  • 자격증, 어학능력(있으면 당연히 좋음, 근데 전 없음)

한개한개씩 뜯으면서 가보기 전에 잠깐!

이력서는 어떤 곳에서 작성하는 것이 좋을까?

한글도 있을 것이고, 워드, 파워포인트, 노션 등 여러가지가 존재합니다.
개인적으로는 노션 을 추천드립니다.

많은 분들이 노션 이력서를 추천하지 않는데, 그것은 PDF를 뜨지 않아서 그렇습니다.
노션 링크로 제출하는 것이 아니라, PDF로 추출해서 제출하세요.
조금 더 나아가면 PDF에 올린 것을 구글 드라이브에 올려서 제출하세요.

그런데 여기서도 또 문제가 발생합니다.

우리가 작성한 것을 PDF로 추출할 경우 원래의 레이아웃에서 크게 달라질 수 있습니다.

레이아웃이 달라지면 무슨 문제가 발생하냐면 가독성을 해칩니다.
대부분의 사람은 글을 읽을 경우 좌상단에서 우하단으로 읽는 버릇을 가지고 있습니다.

그런데 읽는 부분이 페이지가 달라져서 끊어진다면?
읽기 싫어집니다, 신경을 쓰지 않았다. 라는 느낌도 받을 수 있고요.

글로만 보면 이해가 잘 안갑니다, 도대체 얘가 무슨 소리를 하는건지
그래서 자료로 가져와봤습니다.

왼쪽은 디폴트 값, 100%로 PDF로 만든 파일을 들어갔을 때 나오는 결과고
오른쪽은 제가 값을 변경해서 71%?로 PDF로 만든 파일을 들어갔을 때 나오는 결과입니다.

어떻게 보면 단순한 문제라고 생각을 할 수 있지만
이력서를 수없이 많이 보는 채용담당자 입장에서는 저런 상태를 보자마자 불합격을 누를 수 있습니다.
그렇기 때문에 꼭, 계속 비율을 바꿔보고 확인한 것을 제출 하셔야만 합니다. 선택이 아니라 필수입니다.

이력서를 작성할 때 주의할 점

목차를 작성하면서 수없이 강조를 반복해서 알려드릴텐데

거짓을 절대로 적으시면 안됩니다.

개발업계가 아닌 다른 직종은 뭐 자기소설이라는 표현도 씁니다.
그런데 이 개발업계는 그런거 없습니다. 기술면접에서 다털려요.

자신만의 신념 혹은 지식이 없는 것을 작성한다면 진짜 탈탈탈 털리는 것을 경험할 수 있습니다.

Q. 저는 지식이 없어도 있어보이는 것처럼 대답할 수 있는데요?
A. 꼬리질문 들어가면 어짜피 털립니다. 멈춰!

이력서는 자신을 어필하는 글입니다.

절대로 부정적이거나, 약한 모습을 보여주시면 안됩니다.
무조건 강렬한 인상을 남겨주는 것이 중요해요, 일단 서류가 붙어야 무엇이든 해볼 수 있으니까요.
그런데 거짓말은 하면 안됩니다 ㅎㅎ

이력서의 레이아웃

레이아웃은 대표적으로는 두가지가 존재합니다.

위에서 아래로 떨어지는 세로형, 옆으로 갔다가 아래로 내려가는 가로형

그런데 여기서 고려를 해봐야하는 것이 있습니다.
생각보다 채용담당자들은 웹이 아닌 모바일로 이력서를 검토하는 일이 많다고 알고 있습니다.

일반적인 핸드폰으로 본다면 가로형같은 경우는 보기 정말 힘듭니다.
읽어야하는 흐름이 깨질 가능성도 존재하죠.

그렇기 때문에 개인적인 추천으로는 세로형을 추천드립니다.
이것은 정말 개인의 취향에 달린 것이라 누가 정답이다. 라고는 이야기를 할 수 없긴 합니다.

왜냐하면 다양한 이유로 세로형으로 레이아웃을 구성하여 이력서를 제출하는 사람들이 많은데
가로형으로 레이아웃을 구성하여 제출한다면 오, 이 지원자는 조금 색다르네 라는 평가를 받을 수도 있겠죠.

다른 사람들과 다른 구성으로 자신만의 특별함을 강조하는 것도 좋다고 생각합니다.

면접을 보면서 비슷한 이야기도 많이 들었습니다.
이력서 구성은 뻔한데, 내용이 뻔하지 않아서 얼굴이 보고싶었습니다.

수많은 이력서를 보기 때문에 뻔한 이력서는 눈에 들어오지 않는다. 라는 의미와도 비슷한 대답이였습니다.

제목 ~ 인적사항

저는 면접을 볼 때마다 왜 서류가 합격했는지, 이력서는 어떻게 보셨는지에 대한 피드백을 받는 편입니다.

거기서 많은 면접관분들께서는 이렇게 답변해주셨습니다.

솔직히 제목부터 인적사항은 보는 편이 아닙니다, 저긴 거짓이 포함되어있을 가능성이 높거든요.
왜냐하면 증명을 할 수 없고 직접적으로 대화를 해봐야 알 수 있는 내용들이 들어가는 공간이니까요.


난 저기 정말 어떻게 써야하나 일주일 넘게 고민을 했는데 안본데 진짜 너무하다

그래도 어쩌겠습니까 솔직히 저 부분이 없으면 상당한 공백이 있어요, 그냥 적읍시다..
아래 저의 이력서를 보면서 체크를 해봅시다.

제목

제목은 자유롭게, 자신이 강조하고 싶은 것으로 채워넣으면 됩니다.

가능하다면 짧은 것이 좋습니다. 흔히 캐치프레이즈라는 용어로 사용되는 것입니다.
결국 포인트는 어 얘 좀 재밌어보이네 ㅋㅋ 라는 감정을 느끼게 하는 것입니다.

솔직히 저같은 경우에도 제목을 잘 적진 못한 편입니다. 개발자라면 뻔한 이야기를 적어놨죠.
개인적으로는 유쾌하고, 즐겁고, 언어유희적인 부분을 사용하는 것을 추천드립니다.

인적사항(개인정보)

8월 14일 수정

이력서에 사진이 요구사항으로 없다면, 디폴트는 빼시는 것을 추천드립니다.

왜냐면 바로 사진을 넣어야하나 말아야하나 라는 고민을 깊게 했습니다.

그런데 위를 보시면 아시겠지만 사진이 없다면 여백이 상당히 많아집니다.
고민 끝에 저는 넣는 것을 선택했습니다만, 이 부분에 대해서는 호불호가 상당히 심하다고 합니다.

>넣는걸 좋아하시는 분도 있고, 극도로 싫어하시는 분이 있다고 피드백을 받았습니다차라리 빼시는 것을 추천드립니다.

사진을 넣는 부분에 있어서는 개인의 선택에 따라 달린 것 같습니다.
그리고 개발업계만 있는 특징이라고 생각하는데 개발업계의 이력서 사진은 동적인 경우가 상당히 많습니다.

저는 부트캠프에서 개인샷을 뽀샵에서 보내줬는데 그 사진이 저기 위에 박혀있는 저것입니다.
주니어로 지원하는 주제에 팔짱이라뇨, 완전 예의없어 보이잖아요.

그래서 저는 걱정을 한 편이였는데, 오히려 재밌게 보신 분들이 많았습니다.
만약에 넣을 생각을 가지고 계신다면, 자신을 표현할 수 있는 나만의 사진을 넣어보세요.


그 다음으로 적어야하는 것은 개인정보입니다.

  1. 이름
  2. 깃허브
  3. 블로그(자유)
  4. 이메일
  5. 핸드폰번호

저같은 경우에는 자바스크립트로 저렇게 표현해봤는데
같이 부캠을 다닌 수료생분과 이력서를 돌려보다가 이야기하고 아이디어를 받아왔습니다.

정말 좋은 생각이라고 느꼈기 때문인데, 다른 사람들은 밋밋한 줄글일텐데 포인트를 준 것이죠.
생각을 해보셔서 조금 더 특별하고 재미난 것이 있다면 적용을 해보시는 것을 추천드립니다.

개인정보에 더 많은 내용을 담아야하지 않나요?

이상하게 개발자 이력서에서는 관심없으니까 제발 쓰지말라고 하는 요소를 제외하고 필요한 요소만 넣어놨습니다.

성별, 나이, 거주지같은거 적지마세요. 채용공고에도 적혀있는 모습을 볼 수 있습니다.
상세한 개인정보는 이력서에 담지말라.

저렇게 5개정도만 적으시는 것을 추천드립니다.

여기서 또 잠깐!

혹시 깃허브 관리는 하셨나요?

깃허브 프로필 만들어놓기

면접을 진행하다보면, 상당히 많은 분들이 레포를 들어와서 코드를 다 확인하고 질문을 하는 것을 볼 수 있습니다.

그렇기 위해서는 자신이 사용한 프로젝트를 깃허브를 들어갔을 때 바로 보여질 수 있게 하는 것이 좋습니다.

이것은 현재 제 깃허브 프로필인데, 하단에 보시면 Sweet-Salty-Project라는 것을 볼 수 있습니다.

저것이 제 팀프로젝트의 레포인데 저렇게 빼놓지 않는다면.
찾아보기 귀찮다고 서류 불합격처리를 받을 수도 있습니다.

진심 개복치같아요 이력서

거창하게 작업을 하실 필요까진 없고, 어느정도 내가 신경을 썼다. 정도만 표현하세요.

인적사항(간단한 소개)

소개같은 경우에도 대표적으로 적어야하는 것이 있습니다.

  1. 간단한 자기 소개
  2. 어떤 스택으로 뭘 했는지
  3. 왜 개발자가 되려고 하는지
  4. 개발자 커리어의 목표
  5. 자기어필할 수 있는 포인트

여기서부터 모든 것은 여러분의 무기가 됩니다.

면접이 시작되었을 때, 보통 자기소개를 요청합니다.
그리고 이력서에 적힌 것과 더블체크를 하면서 질문을 받을 수 있습니다.

거짓이 전혀 담기지 않은 진실된 이야기를 적으세요.


특히 두가지가 중요합니다.

왜 개발자가 하고 싶다고 생각하셨나요?

이거 면접에서 100% 나오는 질문입니다.
전공,비전공 막론하고 무조건 나옵니다.

그러니 고민을 해보셨으면 좋겠습니다, 어제 스페이스에서도 비슷한 질문에 아래와 같은 대답을 들었습니다.

개발자가 요즘 인기고, 돈도 많이 준다길래 해보려구요.

돈을 많이 주는 직업은 다양하고 인기가 많은 직업도 여러가지가 있습니다.

굳이 개발자라는 직업을 선택하게 된 계기를 적어주세요.

목표 또한 마찬가지입니다, 많은 사람들은 자신이 하고싶은 것이 무엇인지 모른채 살아갑니다.
그래도 한번쯤 고민해보세요.

개발자라는 직업을 하면서 어떠한 것이 하고싶은지.

최종 목표가 아니여도 좋습니다. 여러번의 스텝을 나눠서 목표에 도달할 수도 있겠죠.
그런 고민이 담긴 소소한 이야기를 작성해주세요.


마지막으로 자신을 어필할 수 있는 포인트입니다.

저같은 경우에는 문서화라는 것을 강조한 것을 볼 수 있습니다.
제 블로그만 보셔도 아시겠지만, 다양한 태그로 많은 글들이 있습니다.

글이라는 것은 생각보다 아무나 쓸 수 없습니다.
어려서부터 훈련을 받지 않았다면 작문을 하는 것에 있어서 큰 어려움을 느낄 수 있습니다.

그렇기 때문에 저를 어필할 수 있는 포인트 로 사용했습니다.

자신만의 강점을 보여주세요, 그 어떤 것도 상관없습니다.
개발자라는 직군은 소프트스킬과 하드스킬이 복합적으로 필요한 직군입니다.

그렇기 때문에 남들 앞에서 이야기를 잘한다. 같은 것도 어필하기 좋은 포인트입니다.

자신을 한번 되돌아보세요. 내가 잘하는게 뭐가 있는지
다른 사람보다 더 나은게 뭐가 있는지

그리고 그것을 적으시면 됩니다.

물론 거짓을 적지 않고 증명할 수 있어야합니다.

발표를 잘한다고 적어놨는데 면접에서 말을 엄청 더듬고 중압감에 눌려있는 모습이 보여진다면 그것은 모순입니다.


스킬(스택)

여기는 정말 하고 싶은 말이 말도 안되게 많은 주제입니다.

내가 미쳤다고 다 적었지 정말
여기서 정말 중요한 포인트가 있습니다.

한번 사용한 것은, 내가 아는 것이 아니다.

자신이 그 스택에 대하여 설명을 할 수 있는 것이 아니라면, 절대로 적으시면 안됩니다.

Q. 아니 저, 그 스택 써봤는데 적는게 좋지 않을까요?
A. 그 생각을 가지고 이력서를 만들었다가 제대로 당했습니다.

아래는 제 면접 질문 리스트인데, 한번 훑어보세요.

신입 백엔드 면접 질문 Ver. 2.0.5

포스트에 있는 질문이 정녕 신입 개발자에게 물어볼만한 질문이라는 생각이 드시나요?

제가 활동하는 트위터에서 면접 리스트를 올렸을 때, 똑같이 나온 이야기가 있었습니다.

  • 신입한테 너무 과한 질문을 한다.
  • 경력인 나도 잘 모르겠는데 신입한테 저것을 왜 물어보냐

그럼에도 불구하고, 저러한 질문을 받게된 이유는 무엇일까요.

신입이라면 깊게 알리 없는 스택이 이력서상에 사용했다고 기술이 되어있어서 확인을 해본 것입니다.

너, 정말 써본 것 맞아? 라는 것이죠.


여기서 그럼 두 가지의 선택지가 존재합니다.
어떻게 보면 전략이라고 이야기할 수 있겠네요.

  • 자신있는 것만 기술한다.
    • 많은 분들과 이야기를 해본 결과 이게 더 담백하다는 답변을 들었습니다.
      자신이 알고 있는 것을 확실히 대답할 수 있고, 결국 스택은 배우면 된다. 라는 이야기였죠.
  • 사용한 것을 모두 기술한다.
    • 이것은 일반적으로는 절대로 사용하시면 안됩니다. 하지만 저같은 사람이 미친 사람이라면 사용해볼 수 있습니다.
    • 사용한 스택에 대하여 깊게 공부하시면 됩니다.

전자의 경우는 후술할 것이 없겠지만, 후자의 경우에는 이야기를 덧붙일 수 있어서 조금 적어보겠습니다.

사용한 것을 모두 기술하는 것은 어떻게 보면 나는 다른 신입과는 다르게 특별하다. 라는 분위기를 담을 수 있습니다.

하지만 그렇게 하기 위해서는 수많은 공부를 동반하여야합니다.


만약, In-Memory DB인 Redis를 적었다고 가정을 해보겠습니다.

고려해야할 것이 무엇이 있을까요?

제가 받았던 꼬리질문의 형식으로 리스트를 만들어보겠습니다.

  1. Redis를 어떤 목적으로, 왜 사용했는지
  2. In-Memory DB의 특징은 무엇인지
  3. Redis의 특징은 무엇인지
  4. 그렇다면 In-Memory DB인 Memcached도 있는데 왜 Redis를 많은 사람들이 사용하는지
  5. 두개의 차이점이 무엇인지

저는 사용한 스택에 대하여 기술질문이 들어오면 이게 기본이였습니다.
짧으면 5단계에서 길게는 8단계까지 꼬리질문이 들어왔습니다(.....)

이것은 절대로 외우는 것으로 설명을 할 수 없는 내용입니다.
자신이 관심을 가지고, 찾아보지 않았더라면 대답을 할 수 없는 내용이죠.

신입에게 물어보기엔 과한 질문이 맞습니다.

하지만 반대로 생각을 해볼까요.

과한 질문을 다 대답할 수 있는 신입이라면

엄청나게 매력적인 신입이 아닐까요. 심지어 개발공부를 한 기간도 짧다면?
자신만의 공부방법이 존재하고 빠르게 성장할 수 있는 사람이라는 것을 증명하는 셈입니다.

아 가성비쩌는 신입 대려왔어요!!!!

그렇지만 말도 안되는 공부량이 필요로 하기 때문에 가급적 추천드리지 않습니다.

제발 별, 상중하 좀 쓰지마세요.

이력서를 피드백받으면서 들었던 이야기입니다.

아 요즘 신입들 별을 붙이던가 상중하 붙이던데 그런거 없어서 좋네요.

이번주 화요일에 받았던 면접 질문이 있었습니다.

Q. 본인이 생각하기에 타입스크립트는 얼마나 사용할 줄 아는 것 같으신가요?
A. 10%도 안된다고 생각합니다.
Q. 그렇게 생각하는 이유가 있을까요?
A. 간단하게 타입 선언을 하는 것은 할 수 있지만, 제네릭 인터페이스같은 것은 자주 사용해본 적이 없기 때문입니다.

왜 저렇게 대답을 했을까요?

저 말에는 두가지의 의미가 포함되어있습니다.

  1. 나는 아직 타입스크립트에 대한 이해가 부족하다.
  2. 하지만 타입스크립트를 사용하는 이유에 대해서는 알고 있다.

보통 하지만이 중요합니다. 이해가 모자른 것으로 끝나면 의미가 없거든요.

그런데, 이력서에 하지만을 적을 수 있던가요?

별, 상중하를 적는 것을 경우 후술을 할 수 없습니다.
거기서 그냥 끝나는 것이에요.

그런데 말입니다. 더 중요한 것이 있습니다.
그렇게 단계를 나누는 것은 도대체 기준이 무엇인가요?

대화를 나눠본 면접관분들이 이런 이야기를 하셨습니다.

자바스크립트를 상으로 올려놨는데, 무슨 자신감이지?
신입이 상? 기준이 도대체 뭐길래 얼마나 잘하길래?

그리고 상으로 올려놓은 것들 있으면 꼬리질문 미친듯이 들어옵니다.

  • 자바스크립트는 프로토타입 객체지향인데 프로토타입에 대한 것을 알고 계시나요?
  • 그렇다면 프로토타입과 일반 객체지향 언어에서는 무슨 차이가 있을까요?
  • 이미 프로토타입이 존재하는데, 왜 자바스크립트는 클래스를 도입했을까요?
  • 자바스크립트의 클래스는 타 언어의 클래스와 무엇이 다른가요?

(절반은 대답 할 수 있겠네)

털릴꺼 뻔합니다. 스킬에 대한 평가를 하는 이력서를 작성하지마세요.

그럼 스킬은 어떻게 적으라는건데요?

이것은 정답이 없습니다. 알아서 자신에 맞게 적으시면 됩니다.
그런데 저는 이런식으로 적긴 했습니다.

이런식으로 적을 경우의 장점은 바로 하지만 이라는 것을 적을 수 있다는 것입니다.

다시 한번 말씀드리지만, 저와 동일하게 작성하기 위해서는 압도적인 공부량이 필요하므로 따라하시는 것은 추천드리지 않습니다.
그냥 예시입니다 예시(....)

이렇게 적을 경우에 어떤 장점이 있냐면 바로 면접의 질문을 제가 선택할 수 있다는 것입니다.

위에서부터 보면서 나올 것 같은 면접 질문을 적어보겠습니다.
(실제로 받은 질문들이 대부분입니다.)

  • JS에서는 무슨 이유때문에 예기치못한 에러가 발생하며, TS를 사용할 경우에는 어떤 차이가 있을까요?
  • ES6에 추가된 문법 중, 중요하다고 생각하는 것을 몇가지 이야기해주세요.
  • express와 Nest의 차이는 무엇인가요?
  • Nest만이 가지고 있는 특징은 무엇인가요?
    • IoC, DI, 싱글톤패턴은 무엇인가요?
      • 객체지향에서 중요한 것이 무엇인가요?
  • MySQL이 아닌 다른 RDBMS는 무엇이 있고, 어떤 차이가 있나요?
  • NoSQL과 SQL의 차이, 그리고 언제 어떤 것을 사용하면 좋을지 알려주세요.
  • In-memory DB의 특징은 무엇이 있으며, Redis는 다른 메모리디비와 어떤 차별점이 있나요?
  • ORM을 사용하는 이유는 무엇인가요? 또한, ORM이 아닌 SQL을 사용할 줄 아시나요?
  • Docker를 사용하면서 얻을 수 있는 이점은 무엇이 있나요?
    • Docker가 생기기까지 어떤 과정이 있었나요?
  • 클라우드 시스템을 왜 사용하게 되었을까요? AWS Azure에 대해서는 들어보셨나요?
  • OAuth2에 대한 지식이 있으신가요?
  • Serverless라는 의미에 대해서 말씀해주세요.
  • kubernetes는 무엇이고, 왜 사용하는 것인가요?
  • CI/CD는 무엇인지 설명해주세요.
  • Git flow에 대하여 알고계신가요?
    • Git flow의 브랜치들이 어떤 목적에서 사용되는지 설명해주세요.
  • 엘라스틱서치의 특징을 알려주세요.
    • 분석기에 대해 아시나요?
      • 엘라스틱서치의 토크나이저에 대해서 아는 것을 모두 말씀해주세요.
  • Logstash를 사용하면서 얻을 수 있는 장점이 무엇일까요?
  • GraphQL과 REST API의 장단점을 이야기해주세요.
  • RESTful하다는 것은 어떤 의미를 가지고 있나요?
  • REST에 대해서 알고 계실까요?

이렇게 질문을 유도할 수 있습니다.

그렇다면 저 질문들이 나올 것으로 유도를 했으니, 공부를 한다면 완벽하게 답변을 할 수 있는 것입니다.
저는 아마도 위에 있는 질문에 대해서 90%이상은 답변을 할 수 있을 것 같습니다.

하지만 우리가 지금까지 봐왔던 백엔드 신입 면접 질문 리스트에 적혀있는 것과는 큰 괴리가 있는 것을 볼 수 있는데
제가 최근에 기술면접을 다녔던 입장으로써는 질문 리스트에 있는거 거의 안물어봤습니다(...)

아마 적혀있는 스택이 적을 경우에는 거기에 있는 컴공 학부생 CS이 대부분의 기술면접 질문이 될 것입니다.
(웹에 퍼져있는 신입 면접 질문 리스트가 학부생 CS 지식입니다.)

자기소개 (About Me)

자, 이제 자기소개 파트에 왔습니다.
이력서의 꽃이죠? 개발자들은 자기소개서가 보통 없는 편이니까요.

여기서 중요한 것이 있습니다.

무조건 자세하고 길게 적으세요.
막 5줄 10줄 이렇게 적으라는 의미는 아닙니다.

가급적이면 3~5줄 내외로 마무리해주시고, 자신이 어필할 수 있는 모든 것을 어필해주세요.

아래는 제 이력서의 자기소개란입니다.

큰 주제를 분류하고 속에 내용을 채우는 것으로 진행이 됩니다.

왜 길게 적어야만 할까요? 그것에 대한 이야기를 적어보겠습니다.

자기소개를 길게 적어야하는 이유

그러나 갑자기 의문이 듭니다.

이력서는 한페이지로 정리하는 것이 좋다고 하던데 도대체 왜 자세하고 길게 적어야할까요?

그것은 신입이라는 특수성 때문입니다.

경력직인 경우에는 결과물이 존재하는 것에 반하여, 신입의 경우에는 결과물이 대부분 존재하지 않습니다.
언제나 회사입장에서는 신입을 뽑는 것은 리소스의 낭비이며, 경력직을 뽑는 것이 다방면으로 이득입니다.

그럼에도 불구하고 신입을 뽑는 이유는 단순합니다.
숨겨진 다이아원석을 찾기 위해서, 신입을 뽑는 것입니다.

많은 개발자분들은 아래와 같은 말씀을 하는 것을 종종 보았습니다.

개발 그거 누구나 다 할 수 있어, 단지 코더가 아니라 개발자가 되는 것이 어려운거지.

단순히 따라치는 것이 아니라, 이해를 하고 자신만의 스타일에 따라서 코드를 작성해나갈 수 있는 사람을 개발자라 칭합니다.

이것은 공부를 잘하는 것과는 조금 다른 영역에 속해있습니다.
그렇기 때문에 학벌을 엄청 볼 것 같은 개발자인데 상대적으로 학벌을 보는 편이 아니라고 이야기를 합니다.

애초에 학벌을 본다면 필드에 계시는 수많은 비전공자분들이 있을 수 없는 업계입니다.
본인을 증명할 수 있다면, 누구든 괜찮다. 라는 것이죠.

그렇기 때문에 자신이 누구임을 알려주기 위해서 길게 적어야합니다.

이것은 사람마다 다릅니다, 이력서의 인트로에 적었던 자신의 강점을 조금 더 세부적으로 적을 수 있는 공간인거죠.

여기서 적어야하는 것은 이러한 것입니다.

  • 강점
  • 가치관
  • 경향성
  • 경험

이렇게 4가지 요소가 들어간 제목으로 작성하고, 그것의 근거로 사용할 수 있는 경험에 대하여 서술하셔야만 합니다.

보통 이론으로만 보면 이해가 어려우니, 위에 있긴 하지만 제가 작성한 이력서 일부를 가져와서 설명드립니다.

문맥을 살펴보면, 위에서 강조했던 4가지 요소가 전부 다 들어가있는 모습을 확인할 수 있습니다.

  • 강점
    • 자신이 알고 있는 것을 문서로 만들 수 있는 사람
  • 가치관
    • 저는 어릴 때부터 알고 있는 것들을 토대로 글을 작성하는 것을 즐기곤 했습니다.
  • 경향성
    • 이해가 되지 않는 부분을 정리해서 포스팅을 하는 것으로 배운 것에 대한 복습을 하기 시작하였고
  • 경험
    • 벌어진 다양한 문제를 매일매일 포스팅하였고 비슷한 문제가 발생할 때마다 적어놓았던 것을 찾아서 금방 해결할 수 있게 되었습니다.

이런식으로 문장 구조를 만들어서 작성하시면 높은 평가를 받으실 수 있습니다.
또한 저같은 경우에는 문서화를 강조하였기 때문에, 그것에 대한 증거가 있어야합니다.
그래서 저는 아래처럼 그것을 증명하기 위하여 제 블로그를 달아놓은 모습을 보실 수 있습니다.

이 부분에 대해서는 정말 뭐를 써라. 추천을 하는 것이 아니라 주관에 담겨있기 때문에 이정도로 줄여보겠습니다.
개인적으로는 세개의 주제가 적당한 것으로 보이고 넘치거나 모자른 것은 아쉽다 라고 생각하고 있습니다.

추가로 제발 1남1녀에 막내로... 이런거 적지말라고 전해달라는 면접관의 피드백이 들어왔습니다.
필요없으니 제발 적지좀 말아달래요(....)

경험(프로젝트)

개발자에게 있어서 자기소개보다 더욱 중요한 경험파트입니다.

이것은 제가 자신있게 이야기를 할 수 있는 것 같습니다.
정답이 존재합니다.

경험 파트의 정답에 대하여

수많은 피드백을 받으면서, 이 부분에 대해서는 더할나위 없다. 라는 대답을 들었습니다.
아래는 제가 작성한 이력서의 경험 파트입니다.

제가 다닌 부트캠프에는 총 3개의 프로젝트가 진행됩니다.

혼자 만드는 미니 프로젝트와 메인 프로젝트
그리고 프론트 백엔드 디자이너가 붙어서 만드는 팀프로젝트.

하지만 저는 혼자 만든 프로젝트는 정말 초창기에 만든 것이라 이것을 공개하는 것은 부끄럽다는 생각이 들었습니다.
코드도 난잡하고 그냥 모든 것이 형편없고 심지어 배포도 되지 않은 상태였습니다.

그래서 저는 팀프로젝트에 모든 것을 걸고 작업을 시작했습니다.

전 기수의 팀프로젝트 발표시연 영상을 보면서 저는 이런 생각을 했습니다.

기획이 그렇게 만만치 않은데, 기획부터 발표까지 3주는 너무 짧은 것 같은데?
마땅한 기획이 없을 가능성이 높으니까, 지금 내가 하고 있는 메인프로젝트의 볼륨을 키우고 기획을 튼튼하게 해서
팀 프로젝트에서 사용해보자.

그렇게 팀원이 정해지고(랜덤) 기획단계에서 자신이 하고 싶은 것에 대하여 투표가 진행됐고

그 결과 제가 건의한 프로젝트가 채택이 되었습니다.
그러면서 저는 팀리더와 PM의 역할을 맡게 되었고 사실상 모든 것을 책임져야하는 상황에 놓였습니다.

프론트,백엔드,디자이너 모두 저에게 이건 어때? 라는 질문을 하고 제가 답을 해줘야만 작업이 진행이 되는 상황까지 간 것입니다.

그래서 이건 정말 아니다. 라고 생각하면서 모든 인원이 자유롭게 이야기를 해달라. 할 수 있는 것은 다 해보자 라는 것으로 진행이 됐습니다.

그러나 이런 것도 중요하지만, 결국은 이것을 증명할 수 있는 결과물이 존재해야만 의미가 있습니다.

그래서 저는 팀원들에게도 이야기를 하면서 모두 매일매일 회고록을 작성하자. 라는 이야기를 꺼내게 됩니다.

매일 작성한 팀프로젝트의 회고들

기획부터 체크까지 모든 것을 담당해야만 했기 때문에 작업량은 미친듯이 많았고
팀원들끼리의 분쟁이 있을 경우에는 그것을 해결해야만 했고
같은 백엔드 팀원과도 다툼이 있어서 정리를 해야만 했지만

매일매일 회고록을 쓰기 시작했습니다.

심지어 좋은 말만 있는 것도 아닙니다.
제가 올바르지 못한 선택을 하는 것으로 다퉜고, 그것에 대해 반성하는 글 또한 포함되어있습니다.

하지만 저는 그게 옳다고 생각했습니다.
사람은 완벽할 수 없고, 문제가 발생하고 그것을 뒷수습하면서 발전한다고 생각하는 것이 저의 확고한 신념이기에
면접관이 나쁘게 볼 수 있다고 하더라도 다 적었습니다.

그리고 면접이 진행되면서 이것은 저에게 엄청난 무기가 되었습니다.

결국 회사도 팀을 구성하여 작업하길 마련이고, 그 부분에 있어서는 다양한 다툼이 발생합니다. (소프트스킬을 강조하는 개발자 사회)
그런 것에 있어서 어떻게 대처를 했는지, 팀장으로 어떤 역할을 했는지 설명을 할 수 있는 근거가 되었습니다.

또한 스택에 있어서도 증명을 할 수 있게 됐습니다.

신입이 사용한 것이 신기한 스택에 대하여 이것은 분명 질문이 들어올 것이다. 라는 생각이 들었고
매일 회고에도 기술회고에 이미 적혀있는 내용이지만

팀프로젝트 당시에는 바빠서 세부적인 것은 알아보지 못했는데
부트캠프 수료 후 그것을 보충할 수 있는 글을 작성하면서 제가 가지고 있던 지식을 구체화할 수 있게 되었습니다.

그리고 잘 보시면 밑줄이 그어져있는 것을 확인할 수 있는데
밑줄이 그어져있는 것들은 모두 제가 작성한 블로그의 포스트를 링크로 걸어놨습니다.

완벽한 증명을 한 셈이죠.

물론 적어놓고서 모르겠다고 답변하면 당연히 감점요소입니다.
면접 시작 전에 저는 이력서를 보면서 제가 작성한 포스트를 다 확인해보는 편입니다.


덕분에 경험 파트에 있어서는 제가 정답이다. 라고 확고하게 말씀드릴 수 있다고 생각합니다.
특히 팀프로젝트 하나가 사실상 유일한 결과물인 부캠, 국비 수료생분들에게는 더더욱이요.

아, 그리고 어떤 분께서는 깃허브 리드미에 적는게 더 좋다고 말씀을 하시는 분도 있긴 했습니다만
전 블로그에 적어버린게 너무 많아서 되돌릴 수 없어가지고 그냥 블로그로 다 링크를 걸어놨습니다.

이 부분에 대해서는 취향이 갈릴 것이라 생각합니다.

저같은 경우에는 블로그가 저의 강점이니 블로그 링크로 걸어놓으면 다른 것도 보겠지 라는 생각도 가졌습니다.

학력, 경력

이것은 많은 의견이 있는 파트라고 생각합니다. 차라리 적지 않는게 좋다! 라고 말씀하시는 분도 분명 있습니다.

개인적인 의견으로는 적어야한다고 생각하고 있습니다.

왜냐하면, 아무것도 적지 않고 공백기간이 길다면 사회성이 모자른 사람이라고 비춰질 가능성이 매우 높습니다.
그럼 서류 바로 짤립니다(....)

다른 회사를 다녔다는 것은 어느정도 사회성을 보장한다는 의미입니다.

개발자들은 커뮤니케이션을 중요하게 여기기 때문에 오히려 환영하는 분위기로 알고 있습니다. (케바케임)

또, 다른 업계에 있다가 온 것은 무조건 장점이라고 보는 시각이 있습니다.

일반적으로 개발자들은 컴공에 있다가 넘어가는 경우가 대다수였습니다. (요즘은 다양한 분야에서 진입해서 다르긴 합니다.)
그래서 개발말고는 아는게 없다. 라는 시각도 있었습니다.

그렇지만 개발이라는 것은 특정 서비스 를 제공하는 경우가 상당히 많습니다.
그것에 대한 경력이 있다면, 이해도가 다른 사람보다 월등히 높기 때문에 엄청난 장점이 됩니다.

피시방에 관련된 것을 개발해야하는데, 피시방 사장이였다? 와 이건 대려와야해

업계가 달라져서 걱정이 되시겠지만, 관련이 있는 곳으로 가실 경우 플러스 점수를 많이 받으실 수 있을 것입니다.
물론 바꾼 이유에 대해서 설명을 잘 해야겠지만요.

자격증, 어학능력

이건 있으면 무조건 적으세요. 안적어서 나쁠거 하나도 없습니다.

여긴 할 말이 없네 제가 없어서(....)

한번 작성한 것이 끝이 아니다.

마지막 파트입니다. 바로 한번 작성한 이력서로 바로 제출을 하지 말라는 것입니다.

글을 아무리 많이 써본 사람이더라도, 한번 작성을 한 후 처음부터 끝까지 다 읽어봅니다.
그럼 오타도 보이고, 문장이 어색한 부분도 보이고 강조하고 싶었는데 안된 부분도 보일 것입니다.

그런것을 고치기 위해서 작성한 것에 대해서는 제발 바로 제출하지마세요.

제일 좋은 방법은 다른 사람들에게 보여주는 것입니다.

많은 사람들에게 피드백받기

이게 틀리다고 말씀하시는 분이 계신다면 제가 하루동안 물만 먹겠습니다^^!!

그 누구든 좋습니다. 자신의 이력서를 부끄럽다고 생각하지 말고 많은 분들에게 보여주세요.

저같은 경우에는 부트캠프를 같이 다녔던 동기, 친형, 개발자지인에게 1차로 보여줬습니다.

하지만 뭔가 모자르다는 것을 느꼈고, 그때부터는 커뮤니티에 찾아봤습니다.
공개적으로 신입 이력서를 적어봤는데, 어떤지 피드백을 받아보고싶다. 라고 적어놓으면

아, 나도 취준할 때 저런 고민이 있었는데.... 라면서 생각보다 많은 개발자 분들께서 리뷰를 해주십니다.

그렇게 다른 분들에게 보여주다보면 공통적으로 이 부분은 아쉬운데, 라고 말씀하시는 포인트가 분명 존재합니다.
그런 부분을 고쳐나가다보면 조금 더 보기 좋은 이력서가 완성이 될 것입니다.

저는 이력서를 쓰기 위해서 2주가량의 시간을 소비했고, 대략 30분 가량에게 피드백을 요청해서 수정을 했습니다.

제가 이력서 링크를 달아놓고 싶은데 문장 정리좀 한 다음에 달아놓던가 하겠습니다(어제 작문 못한다고 혼났음 흑흑)


취업을 하는 수많은 취업준비생 여러분에게 저의 삽질 일기를 거창하게 적어봤습니다.

해당 글에 조금 달라졌으면 하는 부분이라던가, 다르게 바라보시는 시각이 있을 경우 댓글로 적어주시면 좋겠습니다.
많은 취업준비생들이 볼 것이고, 면접관분들도 보실 것이라 예상이 되기에

자유롭게 의견을 주시면 감사하겠습니다!


해당 글을 작성하기 위하여 도움을 주신 다온님, 에센님, 80rian님, Song Yongseok님께 감사드립니다.

다음 작성 예정인 글은 면접에 관해서입니다.

참고하면 좋은 자료

개발자 이력서 작성하기 (feat. 이력서 공개) Wonny(워니)
99CON : 주니어 개발자의 이력서 쓰기 - 이동욱

profile
물류 서비스 Backend Software Developer

16개의 댓글

comment-user-thumbnail
2022년 7월 15일

도움많이됬습니다 감사합니다

답글 달기
comment-user-thumbnail
2022년 7월 20일

안녕하세요! 글 너무 잘 보았습니다! :)
궁금한게 있는데, 혹시 노션으로 PDF를 제출할 때 하위 페이지 링크 걸어놓은 건 어떻게 PDF 로 보여주나요?!

1개의 답글
comment-user-thumbnail
2022년 7월 25일

이직 준비중인 주니어 개발자로써, 정말 많은 도움 되었습니다. :)
보여주신 토대로 좋은 이력서를 만들어 이직 성공하겠습니다 감사합니다!

답글 달기
comment-user-thumbnail
2022년 8월 23일

1일 1 커밋하는 이상한 것만 있었는데 이 글쓴이 분은 엄청나네요

답글 달기
comment-user-thumbnail
2022년 9월 27일

이직을 준비하면서 이력서를 어떤식으로 작성해야 할지 갈피를 못잡고 있었는데 좋은 글 감사합니다~!! :)

답글 달기
comment-user-thumbnail
2022년 11월 7일

너무 잘 보았습니다 ! 취준 하는데 참고하겠습니다. 정성스럽고 좋은 글 고맙습니다 :)

답글 달기
comment-user-thumbnail
2022년 11월 13일

도움이 많이 되었습니다. 노트에 하나씩 적어둔것들 드디어 이력서에 하나씩 퍼즐처럼 만들어보겠습니다. 감사합니다.

답글 달기
comment-user-thumbnail
2022년 11월 17일

와 회고록은 제가 눌러 보고 싶을 정도로 궁금하네요. 혹시나 공유 해주실수 있으신가요 ?

답글 달기
comment-user-thumbnail
2023년 2월 7일

좋은 글 너무 감사합니다!

답글 달기
comment-user-thumbnail
2023년 5월 31일

주니어 개발자입장에서 정말 필요한 정보들이네요. 도움이 많이 됐습니다. 정말 감사합니다!

답글 달기
comment-user-thumbnail
2023년 6월 23일

좋은 글 감사합니다!

답글 달기
comment-user-thumbnail
2023년 8월 12일

이력서를 작성하려니 막막했는데 도움이 많이 되었습니다! 좋은 글 감사합니다

답글 달기
comment-user-thumbnail
2023년 8월 13일

감사합니다

답글 달기
comment-user-thumbnail
2024년 3월 28일

너무 잘 보았습니다!! 많은 동기부여 얻고 갑니다!! 감사합니다:)

답글 달기