본문 바로가기

분류 전체보기318

토스 프론트엔드 기술면접 후기 참 여러번 지원해봤고 번번히 서류 탈락의 고배를 마셨던 회사다. 이번에 프로그래머스 프론트엔드 데브매칭을 통해서 지원한 것이 우연찮게 데브매칭 -> 사전과제 -> 1차인터뷰 -> 2차 인터뷰로 순으로 전형이 진행 되었는데 1차 인터뷰까지 보고 탈락했다. 과제는 그렇다 쳐도 인터뷰까지 들어가서 내가 궁금해 했던 내용들에 대한 충분한 답을 얻었기에 이제 토스에 대한 관심은 거둬도 될거같다. https://www.youtube.com/watch?v=LmLchZ4tCXc&t=1844s 토스에 관심 가진 계기 1. 3명으로 예정된 인터뷰어가 2명으로 변경됨. 2. 면접 시작시 기존의 지원 내역(서류탈락 다수)을 언급함. 3. 질문의 답변을 얻으려는 태도가 아니라 웃으면서 그냥 하고 싶은말이나 해보라고 함. 이렇듯.. 2022. 4. 12.
리액트 1. dom을 직접 접근하는 경우는 어떤 이점을 가져서 그럴까? 2. 라이프 사이클의 주기를 좀 더 세분화 하는 장점은? 3. 경험적 근거 이상의 보편화된 이론에 필요한 것? 4. ux를 공식으로 치환 할 수 있을까? 5. view에 특화된 개발 방법론이란? 6. 리액트의 한계? 7. ui/ux의 지향점? 2022. 4. 11.
리액트 포탈과 렌더링 고민 컨텍스트를 포탈로 감싸는게 flux 패턴을 위함일까? 기존의 provider 방식과 무슨 차이를 가질까? 렌더링 측면에서 관련없다. 포탈로 context를 제공한다고 해도 각 상태값이 렌더링 되는건 기존의 context api와 차이가 없다. context을 제공하는데 portal을 활용하는게 아니라 portal을 공통으로 제공하는데 context를 활용하는 측면이 있다. 그 역은 성립하지 않는다. (라고 설명을 들었다.) 개인적으로 영감을 느낀 부분이 조금 있어서 해당 부분을 상태관리에 활용할 방법을 고민해봐야겠다. DOM트리를 벗어나는 설계를 한 이유는 그냥 모바일 특유의 네비게이션 이 목적으로 보인다. UI 특징에 상단 해더와 하단 버튼등 해당 레이아웃을 포탈을 통해서 컨테이너 컴포넌트 내부에서 관.. 2022. 4. 9.
프론트엔드 설계 고민 -2- 일반적인 웹 애플리케이션을 구성하는 부분은 어떤 게 있을까? 해당 웹의 라우팅, 해당 웹의 UI, 해당 웹의 상태 사용자 액션에 따른 요청 처리 등을 생각해 볼 수 있다. 간단하게 정의 내리면 라우팅은 두 가지 측면을 가진다. 해당 애플리케이션의 절차라는 측면과 해당 애플리케이션이 제공하는 서로 다른 도메인을 가진 기능이라는 측면으로 말이다. 즉 동일 도메인 내의 플로우나 서로 다른 도메인을 라우팅으로 구분지어서 제공 할 수 있다. 도메인의 경우 보통 루트에 가까운 라우팅으로 나뉘는 경우가 대부분이지만 특정 액션이 복잡하거나 반드시 특정 절차를 따라서 지켜져야 한다면 복잡도가 증가함에 따라서 동일한 도메인에 속하더라도 서로 다른 도메인으로 분리해서 취급 하는게 좋을 것이다. 라우팅을 통해서 코드스플릿까지.. 2022. 4. 8.

티스토리툴바