이 대답과도 약간 결이 비슷할 것 같습니다.
신입 이력서를 보는경우 다양한 관점이 존재합니다.
- 회사 CTO의 방향성/관점
- FE 리더의 방향성/관점
- FE 팀장의 방향성/관점
- FE 팀원의 방향성/관점
방향성/관점이 일치 할 수 있고, 반대로 일치 하지 않을 수 있습니다. 일치 하지 않다면 최종 결정권자의 선택일 것 같고요. 최종 결정권은 회사 방침일 것 같습니다. CTO를 무조건 거쳐서 뽑는 회사도 있고, 리더선에서 뽑으면 끝나는 경우도 있고 각 팀 팀장의 선택으로 결론이 나는 경우도 있습니다. 보통 팀원은 의견제시(쉐도잉) 정도 입니다.
- 쉐도잉 → 팀장급들의 편향적인 관점으로 사람을 뽑지 않도록 방지하기 위해, 면접에 직접적 영향을 끼치진 않으나, 같이 참관 후 메모를 해주고, 그 메모만 팀장급에게 전달 함. 팀장은 그 메모를 참고용도로만 사용. 나중에 뽑은 후, 수습기간에 이슈가 생기거나, 퇴사를 하게 되면 면접 이력/쉐도잉 정보를 바탕으로 다시 회고를 해서 무엇이 문제였기에 뽑았고, 왜 나갔는지를 파악하고 다시 되풀이 하지 않기 위해 노력
아무튼, 그러므로 이력서에서 중요한 부분은 다양합니다. 정답이 없어요.
그래도 제가 생각하는 중요한 부분은 이러합니다.
- 무엇이든 인턴 경험 혹은 어떠한 포멧의 실무 경험이 있으면 좋습니다.
- 이유는 면접시 질문할 근거가 존재해서요.
- 이력서를 보면서, 궁금한게 생기고 질문할 것이 많은 사람이 좋습니다.
- 왜? 어떻게? 이런 질문이 많이 생기게 작성해주시면 좋겠습니다.
- 근데 사실 신입이 어디에서 실무를 경험하나요? 하면 저도 할말은 이런것 뿐입니다.
- KDT같은 과정 참여 여부 ⇒ 면접관 입장에서 왜 참여 했고, 무엇을 배웠고, 어떻게 성장/학습을 했나요? 같은 질문이 듭니다. 인터뷰가 진행 가능하죠
- 동아리 등을 통해서 프로젝트 진행 유무 ⇒ 왜 그 동아리에서 그런 서비스를 만들었죠? 어떤 것을 해결하기 위해 서비스를 기획했죠? 어떻게 진행했죠? 소통 이슈는 없었나요? 일정 이슈는요? 많은 이슈를 어떻게 해결했죠? 이슈 해결 못한게 무엇이죠? 지금 다시 해결 할 수 있다면 무엇을 바꿔보겠어요? 등등 질문할게 많습니다.
- 혼자서라도 프로젝트 만들고 배포하거나, git이라도 공유 ⇒ 프로젝트가 만들어지고 배포되어서 접속이 가능하면 호기심이 생기죠. 퀄리티에 따라서 다양한 질문이 들어갑니다. git이 있으면, 어떻게 git을 써왔고 어떤 고민으로 코딩을 하고 공부를 했는지 궁금해지기도 합니다.
- TIL등이 적힌 블로그 ⇒ 예쁜거 필요 없습니다. 어떤 흐름으로 학습을 했는지, 어떠한 목표로 글을 썼는지, 어떤 것을 배우고 정리했는지, 어떤 성장이 있었는지, 꾸준하게 공부 했는지 등등 관심이 생깁니다. TIL이 있으면 해당 주제로 면접때 물어볼게 많아집니다. 즉, 본인이 작성한 TIL은 면접 인터뷰로 질문 받을 가능성이 있으므로 책임지고 공부해야합니다.
- 개인적인 생각으로….신입보다 쥬니어 이력서 작성하기가 몇배는 더 어려운 것 같습니다.
- 회사에서 한건 뭔가 많은데, 딱히 보여줄건 없고 특별한것도 없기도 해서요. 포트폴리오로 이것저것 넣자니 별거 아닌 것 같고, 어렵습니다.
- 저는 지인추천으로 이직한 경우가 많아서, 이력서 포트폴리오 보다는 코테/프로젝트테스트/면접으로 판별이 난 것 같습니다.
- 제 이력서는….차차…..사실 모든 포트폴리오 내용 다 빼고, 정말 간략한 경력기술서만 갖고 있어서요.