- 모바일(iOS/ Safari)에서 이슈가 자주 생긴다.
- 프로젝트를 어떻게 이력서에 녹여낼 수 있을까? 개인적으로 녹여내라. 기술 문제 + 협업 시 어떤 어려움을 겪었고 문제를 어떻게 해결했는지 블로그에 작성하기
- 최종 프로젝트 조언
- 기획, 디자인은 백엔드와 함께 해야 한다. 프론트만의 업무가 아니다.
- 백엔드와 비슷한 속도로 개발이 진행될 것. 백엔드의 작업이 늦어지면 프론트엔드의 일정이 늦어진다. 이를 어떻게 현명하게 관리할 것인가?
- 효용성이 없는 방법은 사용하지 말아야 한다.
- 마지막 하루 이틀은 Q&A만 해라
Q&A
- 렌더링 최적화 백엔드의 성능 최적화가 더 효용이 좋다. 그럼에도 프론트에서의 성능 최적화는 중요하다. 성능에 대해서 공부해야 한다.
Performance 탭에서 성능을 측정해보기
구글 라이트하우스
Performance Insights 개발자 도구 살펴보기(오프팀 블로그 참고하기)
- 3개월 유효 시간 면접관들은 배포 사이트 링크는 잘 들어가지 않는다. 실제로 웹사이트가 잘 구동되고 있는가는 중요하지 않다.
본인의 역할과 임무. 배움. 어려움, 해결 방안이 핵심 질문이다.
스크린 샷, GIF는 남겨두면 좋을 것이다.
- 서버의 API를 바꾸는 것이 불가능한 상황이었음을 설명해야 한다.
- 사용자의 데이터를 전역적으로 관리하기
네트워크 요청을 줄이는 것은 좋지만....
그러면 놓치는 게 있었을 것 같다. 포기한 것이 있었을 것 같다.
서버의 실제 데이터와, 프론트엔드의 데이터가 싱크가 안 맞는 데이터는 어떻게 해결하지?
그것이 중요한 데이터라면? (다른 브라우저에서 삭제를 한 것이 반영이 안 된다면)
그렇게 관리하면 놓치는 게, 포기한 게 있었을 것이다.
또한 그것을 포기한 만큼의 성과를 얻었는가? 그것을 어떻게 증명할 것인가?
API 요청은 몇 개가 많은 것이라고 생각하는가?
이런 것들에 관해 미리 고민해봐야 한다. 그래야 면접에서 잘 답변할 수 있다.
- 실제 개발할 때는 성능을 별로 고민하지 않는 것이 좋다. 문제가 발생했을 때 고민하면 된다. 리액트, 컴퓨팅의 성능이 뛰어나니 어느 정도는 괜찮다.
React.memo는 잘 쓰지 않는다.
memo를 사용함으로써 어려운 버그가 발생할 수 있기 때문이다.
논쟁 거리가 있는 주제이긴 하다.
- 큰 회사를 지망한다면 정보를 제공해 줄 수 있다. 정보가 많다. 상담해 줄 것.
면접 상담도 해 줄 수 있다. 이력서도 봐 줄 수 있다.