12/17 자기소개서 세션 메모

 

질문했으면 좋겠는 사항을 적어야한다.
자세히 말할 자신이 있는 항목을 적는 게 좋다.

링크걸어서 코드가 보이는 게 좋아
살아있는 프로젝트라면 링크 주는 것도 좋아
따라서 웹으로 배포가 좋다.

신입의 온보딩?

커피챗 신청

스쿼드 사일로
논란이 있지만 애자일 방식으로 하는 걸 선호하는 방시
넥스트 신입채용

fe팀 be팀 디자이너팀

챕터는 기술부채를 해결하기 위해 움직이는 조직

주니어인 것은 중요하지 않아요. 잘하는 사람과 함꼐 일하고 싶어요
(버그가 잘 안 나 꼼꼼하고 마이그레이션 잘돼? 리팩토링

방법이 있고 이슈가 있는데

잘 생각해보시라 방법을 잘 찾아오는 것 같다.)


고민을 하는 사람이 좋아요

AvsBvsC선택지에서 왜 B를 선택했는지 설명할 수 있는 사람.
처음엔 방황하지만 

깃커밋 기록도 자세히 확인
깃헙링크 있으면 다 보는 것 같다.

포크 뜬 건 안보고, 그 사람이 쓴 코드만 보고
폴더 구조, 코드 스타일, 여러 설정 파일들.

ci/cd 

중복된 패키지 

사이드 프로젝트 봐달라고 
여러명이 작업한 게 많아서 누가 뭐를 작업했는지 보는 게 어렵다.

메인브랜치에 커밋은 깔끔해야 함.

하세요
1. 경력(n년 이상?)
2. "github" > 기술 블로그 등 링크 넣기
3. "내가" 무엇을 했는지
4. 계속 떨어지는 것 같다면 이력서 수정해보기

하지 마세요
1. 남의 걸로 자기가 한 것처럼 하지 마세요. 블로그 짜집기 노노
2. 의미없는 링크 넣는 건 좋지 않아요.
3. 이력서 길다고 좋은 게 아니에요.(중요한것만)
4. 기술스택만 나열하지 마세요.(라이브러리, 프레임워크)

프로젝트가 많은 사람보다 깇가 탄탄한 사람이 채용될 가능성이 높다.

부하테스트
서버개발자라면 대용량 트래픽을 다뤄본사람 우대

나가면 어차피 현직자와 전공자와 경쟁이기 때문에
나의 강점을 무엇으로 하느냐가 더 중요

모른다고 스트레스받을 단계는 아님 
그런데 내가 자랑할만할 걸 뽑는 게 중요하다

성능개선을 수치로 할 수 있는 게 아니라면 안 적는 게 낫다.

링크드인 토스뱅크 박지혜

질문 링크?
https://app.sli.do/event/tBr7snvsy4V544dC4Eg1QW/live/questions

사람의 인생이니까 경력 공백은 당연히 있을 수 있다고 생각해요. 저는 인생에 일이 전부는 아니라고 생각하는 편이에요. 공백 때 어떤 일을 하셨는지 제가 잘 알지는 못하지만, 병원에서 치료를 받았을 수도 있고, 휴식을 취하신 것이든, 여행을 떠나신 것이든, 공부를 하신 것이든, 육아를 하셨든, 무언가 사정이 있으셨을 것 같아요. 그리고 면접은 함께 일할 동료를 뽑는 것이다보니 공백을 딱히 숨기지 않으셔도 될 것 같습니다. 오히려 숨기는 느낌을 풍기면 저라면 안좋은 인상을 가질 것 같아요. 공백이 있었고, 그 때 어떤 것을 하느라 경력공백은 있지만, 이런 것들을 배워서 개발자로 살아갈 때 이런이런 도움이 될 것 같다 설명하셔도 충분하지 않을까요? 공백기간 동안 하신 것들이 지금의 멘탈을 더 단단하게 만들었을 수도 있다고 생각합니다!

라이브러리 사용 경험을 나의 기술역량으로 연관시키기에는 조금 애매한 부분이 있긴한 것 같아요. 다만, 그 라이브러리를 왜 선택하셨는지 스스로 이유가 정리되어 있다면 어필할 수 있을 것 같아요. 그리고 그 라이브러리들이 태어난 이유들이 사실 있어요(상태관리, fetch의 불편함, CSS in JSS의 장단점) 그 라이브러리들이 태어난 이유나 원리(예를 들어 flux패턴)를 알고 계시는 게 제일 중요할 것 같아요!

3개월은 부족한 시간이 맞다고 생각합니다. 취업은 가능하실거에요. 다만, 많은 회사에 합격을 할 수 있는지에 대해서는 3개월이 부족하긴 한 것 같습니다. 저도 실제로 5-6개월 정도 공부하고 첫 커리어를 시작했는데, 많이 부족했던 것이 분명 맞았고, 그래서 시간을 최대한 많이 투자했습니다. 지금도 매일 저녁에는 공부를 하고 있어요!

저는 처음부터 개발역량이 뛰어난 사람은 아니었어요. 그래서 시간을 많이 투자했고, 나름의 공부를 했고, 블로그에 기록도 해왔는데 아마도 그런 노력이 제일 어필이 잘 되었던 것 같아요. 그리고 저는 사이드 프로젝트의 개수를 늘리기보다는 기초적인 언어와 프레임워크, 인프라 공부에 시간을 더 많이 쏟았던 것 같습니다. 그런 것들이 기술면접에서 좋은 인상을 남기지 않았을까 생각해요!

르블랑의 법칙을 혹시 아시나요? "나중은 결코 오지 않는다"라는 뜻이라고 하더라고요.

회사마다 수시채용으로 개발자를 뽑더라도, 그 때 그 때마다 뽑으려는 인원은 어느 정도 정해둔 상태일 거에요. 추가공부를 하셨을 때 시장상황에 따라 채용에 소극적인 시기일 수도 있어요. 채용에 적극적인 시기여도 이직 성수기여서 더 실력자들과 경쟁이 치열한 시기일 수도 있을 것 같아요. 하고 싶은 개발이 무엇인지를 고민해보시고, 그 커리어에 맞는 회사를 지원하시는 게 제일 좋을 것 같습니다. 목표하신 회사가 있다면 지원을 한 번 해보시는 게 좋다고 생각합니다. 르블랑의 법칙을 혹시 아시나요? "나중은 결코 오지 않는다"라는 뜻이라고 하더라고요.


그리고 아마도 프론트엔드 개발자이신 것 같아서 제가 생각나는 키워드를 몇 가지 말씀드려보자면, repaint, reflow, layout shift, micro task queue, 브라우저별로 사용할 수 있는 css 속성이 있고 사용할 수 없는 속성도 있어요. 요런 것들을 혹시 신경써서 작업해보셨을까요?(제가 어떤 작업을 하셨는지 몰라서 드리는 질문입니다!) 신경을 쓰고 작업하셨다면, 그 부분을 잘 녹여내시면 좋을 것 같아요!

devOps 경험은 정말 좋은 것 같으니 빼지 않는 게 좋을 것 같아요. 근데 교육 내용이 잘 기억나지 않는다라.. 다시 살펴보셔도 기억나지 않으시려나요? 빠르게 다시 복습하시는 게 좋을 것 같기는 합니다. 지금 공부안해도 회사 규모에 따라서 백엔드 개발자가 어느 정도는 DevOps 분들이 하시는 업무를 병행하는 경우가 많아서, 어차피 면접 준비를 하실 때 공부하시게 될 것 같아요. k8s, helm 이런걸 좀 더 잘 쓰실 수 있다거나, k8s까지는 아니라면 docker를 좀 더 잘 알고 계신다면.. 상당히 면접에서 매력적인 주니어 개발자이실 것 같습니다!

그 가고 싶은 회사 채용담당자분이 계실 것 같은데, 혹시 질문을 해보셨을까요? 그 회사에서 보통 선호하는 제출방법을 제가 알지 못해서 답변을 드리기 어려운 질문이긴 하지만, 결국엔 나의 이력서를 읽는 사람이 편하게 읽게 해주는 방법이 최고라고 생각해요. 원하시는 명확한 답변을 드리지 못해서 죄송하지만, 한 가지 소개해드리고 싶은 것이 유저테스트라는 방식이 있어요. 이미 알고 계실 수도 있는데요. 질문 주신 분의 이력서를 한 번도 본 적이 없는 사람에게 보여주고 옆에서 지켜보기만 한 번 해보시면 어떨까요? 원하시는 방향으로 이력서를 읽어나가는지, 여기에 넣으면 다 보겠지라고 생각했는데 사실 못보고 지나치는 경우도 있을 수도 있을 것 같아서요.