2년여만에 또 이력서를 검토하게 됐습니다.
오랜만에 보는 이력서라
“요즘 지원자들은 어떠려나~” 하는 흥미를 가득 품은 채 검토를 시작했지만,
이내 아쉬움의 탄성을 연이어 쏟아내는 저를 발견하고,
바로 글을 작성하기 시작했습니다.
오랜만에 다시 읽어보니 여전히 중요한 것도 있고 반대로 더이상 중요하지 않은 것들도 있더군요.
다소 중복이 있더라도 한번 더 강조한다는 생각으로 적어보겠습니다.
자동완성되는 이력서는 가급적 피해주세요
(지원 시 회사에서 일괄적으로 입력받는 곳은 해당되지 않습니다.)
요즘은 항목만 채우면 자동으로 이력서가 만들어지는 서비스들이 많습니다.
물론 이력서의 형식보다는 안에 채워지는 경험과 능력들이 중요하지만
이력서의 심사 역시 사람이 하는지라
자신에게 최적화된 방식으로 더 효율적이고 효과적으로 자신을 표현한다면,
좋은 인상을 심어줌과 동시에 합격률도 올라갑니다.
PDF 포멧, A4 사이즈 최적화
아마 대부분 이력서 제출 시 pdf 포멧으로 전달할텐데요.
iOS개발자는 당연히 Mac을 사용할테니 특히 더 pdf가 선호되겠죠.
(아주 가아끔 워드 파일로 전달해 주시는 분들도 계십니다.)
이 pdf문서를 만드는 방법도 각자 다양한데,
문서를 작성하고 나면 꼭 A4 사이즈로 pdf변환을 해보세요.
가끔 기본 용지 포멧이 letter(미국 표준설정)로 되어 있어 줄바꿈이 깨져 오는 경우가 있기도 하지만,
변환된 문서를 모니터에 실제 A4사이즈로 띄워보면 제출하기 전에 문서 전반적인 가독성을 확인할 수 있어요.
오탈자는 물론 폰트가 너무 작지는 않은지,
너무 고/저용량의 이미지가 들어가진 않았는지,
링크들은 다 정상작동 하는지 등을 확인하는건 기본 중에 기본이죠.
만든 앱이 어떤 서비스인지 궁금하지 않습니다
여러분은 서비스 기획자로 지원한게 아니라, iOS 개발자로 지원한겁니다.
어떤 서비스인지는 그렇게 중요하지 않아요.
내가 구현한 기술을 설명하기 위해 최소한의 기능을 설명하는 정도는 괜찮지만
서비스의 전반적인 설명은 안하셔도 됩니다.
특히, UI 구현에 대한 내용을 설명할 때 단순 화면 구성에 대한 내용은 피해주세요.
예쁜 UI는 디자이너의 영역이고,
우리는 Interaction이나 Animation같은 ‘기술’에 더 집중하면 좋겠습니다.
“기술을 적어주세요”
ㅇㅇ의 예약 기능 구현, 제품 상세 페이지 UI 작업, ㅇㅇ코드 버그 수정 같은 표현들은
심사자가 이해할 수 있는 범주가 아닙니다.
작업한 범위가 어디까지인지 모르겠어요
혼자 작업한 경우도 있고, 여럿이서 작업한 경우도 있겠죠.
구현한 부분에 대해 명확하게 구분짓고 설명해야 서로 오해하지 않고 내 역량을 명확하게 전달 할 수 있어요.
깃에 올라가 있는 코드도 있지만 회사 서비스라 코드가 없는 경우도 있죠.
깃에 코드가 있는 경우, 구현한 코드에 대한 링크나 PR에 대한 링크를 올리는 것도 좋은 방법이 될 수 있어요.
뻔한 기술스택은 안적어도 됩니다
iOS, Swift, Xcode… 등 너무 뻔한 내용은 자리만 차지할 뿐 굳이 적지 않아도 됩니다.
UIKit은 SwiftUI와 구분지을 필요가 있을 때 쓰면 됩니다. (Swift도 Obj-C와….)
외부 라이브러리를 나열해주시는 경우도 있는데, 라이브러리를 쓰기위한 특별한 능력이 필요한게 아니라면 이 역시 적지 않으셔도 됩니다.
예를 들어, RxSwift가 적혀 있다면 비동기 시퀀스에 대한 지식이 있겠구나 하고 이해하는데 도움이 되는 반면,
Alamofire, Kingfisher, Snapkit 같이 그저 사용만 하면 되는 라이브러리의 경우 별 다른 특징이 되지 못합니다.
(물론 아무 지식없이 사용할 수 있는 라이브러리는 아니지만 너무 기초라서…)
“어떻게 활용해봤는가”라는 질문을 받아도 충분히 대답할 수 있다면 적어주시면 좋겠습니다.
Link는 ‘추가 정보’를 보여주기 위해 넣습니다.
이력서에 이런저런 링크를 달면 한정된 페이지 안에 좀 더 많은 정보를 담을 수 있죠.
심사하는 사람 입장에서도 많은 도움이 됩니다.
하지만 이력서에 담긴 모든 링크를 전부 들어가서 모든 내용을 읽진 못해요.
전반적인 코드스타일을 확인하거나
우리 회사에 맞는 기능을 개발해봤다던가 하는
다양한 부분들에 대한 ‘추가 정보’를 얻고 싶을때 링크를 클릭해요.
즉 기본적인 정보는 링크가 아닌 이력서에 담고 있어야 합니다.
MyMusic
- 듣고 싶은 음악을 추천해주는 앱 (링크)
MyMusic
- CoreData를 이용한 DB 구성, 저장, 탐색 등 구현 (링크)
검토자가 CoreData를 어느정도 사용해봤는지 궁금하다면 저 링크를 통해 ‘추가 정보’를 얻을 수 있겠죠.
하지만 링크를 들어가지 않아도 ‘CoreData 활용 능력’이라는 정보는 확실하게 전달할 수 있습니다.
포트폴리오는 역할이 다릅니다.
포트폴리오는 작업한 앱들의 결과물들을 모아둔 문서의 형식입니다.
이력서와는 분명 구분되는 특징을 가지고 있습니다.
이력서에는 기본 정보를 포함한 내가 가진 기술, 즉 능력에 대한 문서라면,
포트폴리오는 내 능력으로 이뤄낸 성과를 중심으로 작성하시면 됩니다.
물론 이력서와 포트폴리오를 하나의 형식으로 작성해 표현하는 방법도 있습니다만,
두 문서를 구분해 작성하는 경우, 서로의 역할이 구분되도록 작성해주세요.
그 외
많이 실수하는 부분은 아니지만 분명 존재하는 개선점들은 따로 분류해 모아봤어요.
Link를 걸 때
pdf에 링크를 걸 수 있다는건 알고 계시죠?
길게 늘어선 링크의 전체 주소보단 깔끔하게 처리된 링크가 보기도 읽기도 좋은건 당연합니다.
LINK : https://apps.apple.com/kr/app/%EB%9D%BC%EC%9A%B4%EC%A6%88-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EA%B0%80%EC%83%81%ED%94%BC%ED%8C%85-%EC%95%88%EA%B2%BD-%EC%84%A0%EA%B8%80%EB%9D%BC%EC%8A%A4-%EC%87%BC%ED%95%91%EC%95%B1/id1375822406
이 외에도 전화번호, 이메일 등에도 링크를 걸 수 있어요.
하지만 다양한 링크를 걸기전에 한번 생각볼 것, 위에 적어뒀어요. 잊지 마세요 ;)
얼굴은 궁금하지 않습니다.
왜 굳이 얼굴을 올리시는 건지 모르겠습니다.
아니, 얼굴을 올려주시면 그나마 다행인데,
이모지나 여행간 풍경의 뒷모습 같은건 정말 왜 넣으시는지 잘 모르겠습니다.
물론 다들 멋지고 아름다우시지만 그런다고 합격하진 않아요.
지원하신 회사가 어디인지 아시죠?
아예 이름도 모르고 오시는 분들은 안계시지만, 여전히 많이들 실수 하시는 부분입니다.
이해하기 쉽게 예를 들어보자면,
카카오뱅크 지원하며 카카오톡 개발해보고 싶다고 하기
NHN 지원하며 네이버 서비스 잘 쓰고 있다고 하기
헷갈리지 않게 잘 알아보고 지원하시길 바랍니다
전직하셨나요?
적지 않은 분들이 원래 하던 일에서 개발자쪽으로 전직을 하셨죠.
때문에 이력서 작성 시 해당 경력을 빼고 작성해주시는 경우가 많은데요.
검토하다보면 상당기간 비어있는 경우가 되버리니, 한줄이라도 적어주시면 많은 도움이 됩니다.
(자격증 같은 정보는 안적으셔도 됩니다. (공인중개사, 조리사, 운전면허 등))
다른 개발을 하시다 iOS로 넘어온 경우도 마찬가지로,
기술적인 내용들을 전부 적기보다 한줄보단 좀 더 많이, 하지만 간략하게 적어주시면 됩니다.
요즘 자소서 잘 안씁니다. (대기업은 다릅니다.)
(선배 개발자님들께 전합니다.) 쓴다고 해도 상단에 몇문장 소개하는 정도만 씁니다.
임팩트 있는 한두 문장이 이력서 전체를 사로잡기도 합니다.
협업도 능력입니다
JIRA, Confluence, Slack, Notion 등의 협업툴을 능숙하게 사용하는 것 역시 중요하지만,
동료들과 어떤 방식의 토론을 해왔고, 코드리뷰는 어떻게 했는지 등의 협업에 대한 내용들을 넣는 것도 좋습니다.
모두 성공적인 취/이직 되시길!!
우리팀은 이직하지 마시길!!
쓰고 나니 괜히 찜찜하네….