프론트엔드 면접 유형과 준비법

프론트엔드 면접의 특징

프론트엔드 면접은 일반 소프트웨어 엔지니어 면접보다 알고리즘 비중이 낮고 도메인 지식 비중이 높다. HTML, CSS, JavaScript를 실제 상황에 적용하는 능력을 본다. LeetCode만으로는 부족하지만, 기본 자료구조·알고리즘은 여전히 나온다.

유형 구성은 업계 표준이 없고 회사마다 조합이 다르다. 퀴즈를 아예 안 보는 회사도, UI 코딩 대신 시스템 디자인을 보는 회사도 있다. 회사 하나의 기술 면접은 보통 3~4세션이고, 대부분 JavaScript 코딩과 웹 기술 토론이며 나머지가 알고리즘이나 비헤이비어럴이다. 역사가 짧은 회사일수록 JavaScript 비중이 크다. 오래된 회사는 프론트엔드·백엔드를 가리지 않고 일반 소프트웨어 엔지니어로 뽑아 왔기 때문에 알고리즘 비중이 남아 있다. 지원 회사의 후기와 회사별 프론트엔드 면접 형식과 단골 문제로 조합을 확인하고 그에 맞춰 비중을 정한다. 회사는 같은 문제를 자주 재사용한다.

국내 프론트엔드 기술 면접은 개념 문답의 비중이 크다. 질문 빈도는 대체로 JavaScript > CS(네트워크·브라우저·운영체제) > React > HTML·CSS 순이다. 진행 형식은 아래처럼 섞인다.

형식	진행	준비
개념 문답	짧은 질문 하나에 답하면 그 답에서 꼬리 질문이 이어진다	아래 「꼬리 질문 사슬」처럼 개념을 연결해서 익힌다
포트폴리오 발표	동작하는 서비스를 시연하고 질의응답을 받는다. 길면 1시간씩 발표와 기술 토론으로 나뉜다	기술 선택 이유(예: Next.js를 도입한 이유), 겪은 문제와 해결 과정을 설명할 수 있게 한다
구술 코딩	가벼운 알고리즘 문제를 코드로 다 쓰기보다 어떻게 접근하고 풀지를 말로 설명한다. 예고 없이 들어오기도 한다	문제 이해, 접근법, 복잡도를 소리 내어 말하는 연습을 한다(코딩 테스트 접근법)
의견 묻기	정답이 없는 질문으로 문제를 마주했을 때의 사고 과정을 본다. 예: 「브라우저마다 CSS가 다르게 보이면 무엇을 기준으로 삼나」, 「이 프레임워크는 언제까지 쓰일 것 같나」	근거와 함께 자기 기준을 말한다(웹 표준과 크로스 브라우징)

한 면접에 프론트엔드가 아닌 리드 개발자(백엔드, 게임 클라이언트 등)가 들어오면 웹 세부보다 일반 CS와 협업 질문이 늘어난다.

기본기: 모든 유형의 바탕

어느 유형이든 기본기를 드러내야 한다. 아래 개념은 퀴즈로도 묻고 코딩·설계 중에도 쓰인다.

영역	확실히 알아야 할 것	개념 노트
CSS	명시도(specificity), 박스 모델, 레이아웃, 포지셔닝	CSS 기초, 박스 모델, Flexbox, 그리드, position
JavaScript	`this`, 프로토타입, 클로저, 비동기 코드, Promise, 타이머(`setTimeout`, `setInterval`)	함수와 this, 프로토타입, 클로저, Promise, 이벤트 루프
패턴	옵저버 패턴, 모듈 패턴	JS 디자인 패턴
DOM	이벤트 위임(거의 모든 면접에 쓸모 있다), DOM 탐색·조작, 폼 검증·제출	DOM 이벤트, DOM 조작, 폼 제출

React를 못 쓰게 하는 면접도 있다. 프레임워크 없이 Vanilla JS로 DOM을 다룰 수 있어야 한다.

여섯 가지 유형 한눈에

유형	보는 것	대표 문제	준비법
JavaScript 코딩	유틸 함수·내장 API 폴리필을 정확하고 효율적으로 구현하는가. 프론트엔드판 LeetCode	`debounce`, `Promise.all`, `Array.prototype.filter`, `getElementsByClassName`	직접 구현하고 테스트 케이스를 써 본다
UI 코딩	HTML·CSS·JS로 컴포넌트·앱·게임을 만들고 극단적 입력·접근성·보안까지 챙기는가	자동완성, 이미지 캐러셀, 탭, 틱택토	컴포넌트를 처음부터 만들어 보고 체크리스트로 점검한다
알고리즘	기본 자료구조·알고리즘을 JavaScript로 풀 수 있는가	트리 탐색, 해시맵 활용	패턴 위주로 쉬운~중간 난이도를 푼다
퀴즈	개념을 이해하고 짧게 설명할 수 있는가	클로저란? Promise와 콜백 차이? 박스 모델?	개념을 이해하고 프로젝트에 적용해 본다
시스템 디자인	컴포넌트·앱 구조와 트레이드오프를 스스로 이끌며 설계하는가	이미지 캐러셀, 뉴스 피드, 이메일 클라이언트	RADIO 순서로 말하는 연습을 한다
비헤이비어럴	협업, 소통, 갈등 해결, 멘토링 경험	이력서 항목 설명, 이직 이유	구체적 사례와 결과를 미리 정리한다

JavaScript 코딩

수준	시간	문제 예
기본	10~15분	`Array.prototype`의 `map`·`reduce`·`filter`·`sort`, `Promise`·`Promise.all`·`Promise.any`, `debounce`·`throttle`, `cloneDeep`·`groupBy`·`flatten`, `classnames`, 객체 키 snake_case ↔ camelCase 변환, `getElementsByClassName`·`getElementsByTagName`, 이벤트 이미터(옵저버 패턴)
고급 (주로 시니어)	25~30분	변수 치환·간단한 조건문이 있는 템플릿 엔진, `JSON.stringify`, HTML 페이지에서 목차 생성

가장 자주 나오는 문제는 debounce·throttle 구현이고, 다음이 Promise를 순서대로 하나씩 실행해 결과를 모으는 순차판 Promise.all이다.
기본 문제는 시간을 다 쓰지 않는다. 대개 한 문제를 더 받는다. 후속 질문은 앞 답을 확장하는 꼴이 많다. 예: chunk() → map() → Promise.all로 mapAsync → 청크 단위로 나눠 돌리는 mapWithChunksAsync.
lodash처럼 옛 브라우저 예외까지 처리할 필요는 없다. 대신 시간 복잡도는 신경 쓴다. 해시맵으로 O(n)이 되면 O(n²)로 쓰지 않는다.
외부 상태에 기대지 않고 부수 효과가 없는 순수 함수로 쓴다.
재귀라면 최대 스택 깊이를, 중첩 객체라면 순환 참조가 있을 수 있는지 먼저 묻는다(보통 없다고 답하지만 확인하는 것 자체가 평가된다).
개념 노트: Debounce와 Throttle, Promise, 배열과 객체, 이벤트 믹스인과 이벤트 이미터.

UI 코딩

회사에 따라 UI 구현 라운드가 아예 없거나 드물게 나온다. 나오면 HTML·CSS 기본기와 도구·프레임워크 숙련도가 그대로 드러난다(예: Google 같은 자동완성 검색창을 1시간 안에 만들기). 진행 감각은 알고리즘 라운드와 비슷하다. 최선의 방법을 찾으며 생각을 소리 내어 말하고 결정마다 이유를 설명한다.

진행 환경은 네 가지다.

환경	특징
미리보기 있는 온라인 에디터	CodePen, CodeSandbox. 결과를 보며 고친다
미리보기 없는 온라인 에디터	CoderPad 등. 머릿속으로 렌더링 결과를 그려야 한다
자기 노트북(BYOE)	주로 현장 면접. Vite 같은 스캐폴딩으로 바로 시작해 설정에 시간을 쓰지 않는다
화이트보드	드물다. 일부 빅테크 현장 면접에서만 보고됐다

문제는 다섯 갈래로 나온다.

갈래	예
컴포넌트	탭, 모달 대화상자, 이미지 캐러셀, 아코디언, 별점, 진행 바, 자동완성(가장 흔하다), 툴팁
위젯	신호등, 디지털 시계, 스톱워치, 전송 목록(Transfer List)
앱	할 일 목록, 정렬·필터 되는 데이터 테이블, 파일 탐색기, 칸반 보드
게임	틱택토, 두더지 잡기, Wordle, 고급으로 테트리스·스네이크
페이지 재현	주어진 명세대로 그 회사 서비스의 실제 페이지 한 화면을 픽셀 단위로 똑같이 만든다

구현 전후로 아래를 짚는다. 다 구현할 필요는 없지만 범위를 면접관과 먼저 확인하고, 못 한 것은 말로 언급한다.

관점	확인할 것	개념 노트
독립성	전역 변수가 없나? 한 페이지에 여러 인스턴스를 둬도 서로 영향이 없나? 옵션을 받는 API가 있나?	컴포넌트 분리
극단적 입력	문자열이 아주 길면(`word-break`)? 이미지가 크면? 항목이 0개면(빈 상태) 또는 수천 개면(최대 높이, 페이지네이션, 가상 리스트)?	리스트 가상화
네트워크	앞 요청 응답 전에 새 요청이 나가는 경쟁 상태? 타임아웃·에러 복구? 캐싱·지연 로딩·요청 묶기?	지연 로딩
UX	모바일 대응, i18n과 RTL	반응형 디자인, 논리 속성
접근성	글자 크기, 대비, 포커스 가능 여부, 탭 순서, `aria-label`	키보드 접근성, 접근 가능한 위젯
보안	사용자 입력을 `innerHTML`로 넣지 않는다(XSS). `textContent`를 쓰고, 원시 HTML이 꼭 필요하면 이스케이프한다. URL에 넣는 값은 인코딩한다	웹 보안

접근성은 주니어와 시니어를 가르는 지점이다. 잘 모르면 모른다고 밝히고 아는 범위에서 반영한다.
점검은 DevTools 네트워크 스로틀링(느린 네트워크), 긴 문자열·큰 이미지·많은 항목 입력, 여러 화면 너비로 한다.
마무리로 「시간이 더 있으면 프로덕션에선 이렇게 하겠다」(테스트, 키보드 단축키, 반응형 검증 등)를 말한다.

알고리즘

프론트엔드 지원자에게는 대체로 쉬운 문제가 나온다. 배열·Set·Map 다음으로 트리를 우선한다. DOM이 트리이기 때문이다. BFS, DFS, 레벨 순회를 익혀 둔다. 답을 외우지 말고 문제 패턴을 익힌다. 풀이 순서와 우선순위는 코딩 테스트 접근법에 있다.

알고리즘 라운드는 언어를 고를 수 있는 경우가 많다. JavaScript에는 내장 최소 힙과 이진 탐색이 없어서, 힙·이진 탐색 문제가 잦으면 Python으로 푸는 선택지도 있다. 언어 고르는 기준은 기술 면접 준비에 있다. Google·Meta·Apple·Amazon처럼 프론트엔드 지원자에게도 LeetCode 중간 난이도 이상을 내는 회사가 있으니, 지원 회사의 비중은 따로 확인한다.

퀴즈와 토론

전형 초반에 많이 나온다. 답이 짧고 분명해 비개발자 리크루터도 채점할 수 있기 때문이다. 초기 평가에서는 변수 호이스팅, 구멍 난 배열(holey array, 빈 슬롯이 있는 희소 배열), 비엄격 모드의 동작, switch 문의 fall-through 같은 언어 세부까지 묻기도 한다. 라이브 면접으로 넘어가면 이벤트 루프, Promise, async/await, 스코프와 클로저처럼 더 깊은 개념을 묻는다. 시니어에게는 「React는 어떻게 동작하나, 가상 DOM은 무엇을 푸나」, 「왜 X 대신 Y 라이브러리를 골랐나」처럼 정답이 없는 질문이 나온다. 암기보다 개념 이해와 실제 적용 경험으로 준비한다. 시간이 없을 때만 암기로 메운다.

영역	자주 나오는 주제	개념 노트
JavaScript	호이스팅과 실행 컨텍스트, 클로저, `this` 바인딩, 프로토타입, 이벤트 루프, Promise와 콜백, `async`/`await`	실행 컨텍스트, 클로저, 함수와 this, 이벤트 루프, async/await
HTML·DOM	`<!DOCTYPE>`·`meta`의 역할, `script` 위치와 `defer`·`async`, 이벤트 버블링·캡처링	문서 head, 스크립트 로딩, DOM 이벤트
브라우저	렌더링 과정, 가상 DOM	브라우저 렌더링, UI 변경 감지
CSS	박스 모델, `position` 값의 차이, Flexbox·Grid, CSS 애니메이션과 JS 애니메이션의 차이	박스 모델, position, CSS 애니메이션
네트워크	CORS가 생기는 이유와 해결, 캐시, HTTP 메서드와 상태 코드	CORS, HTTP 캐시
라우팅	SPA에서 해시 라우팅과 History API의 차이	클라이언트 사이드 라우팅
React	가상 DOM과 재조정·key, state 스냅숏과 불변성·배칭, 훅 규칙과 `useEffect` deps, 리렌더링 원인과 `memo`, 동시성 렌더링, 서버 컴포넌트와 hydration	재조정, 리스트와 Key, State, Hooks, 리렌더링, 동시성 렌더링, RSC, 버전 변천사

float 해제나 JSONP 같은 질문도 나오지만, 각각 Flexbox·Grid와 CORS로 대체된 레거시 기법이라 왜 대체됐는지까지 설명할 수 있으면 된다.

꼬리 질문 사슬

개념 문답은 한 질문으로 끝나지 않는다. 앞 답의 한 단어를 붙잡아 한 단계씩 깊어진다. 답할 때 다음 고리를 스스로 꺼낼 수 있으면 대화를 원하는 방향으로 끌고 갈 수 있다. 실제 면접에서 자주 이어지는 사슬은 이렇다.

출발 질문	이어지는 질문	개념 노트
변수 선언 방법	`var`와 `let`·`const`의 차이 → 호이스팅의 차이 → TDZ → 변수 호이스팅과 함수 호이스팅의 차이	변수와 타입, 스코프와 클로저
원시 값과 객체	저장 방식(값·참조)의 차이 → 얕은 복사와 깊은 복사	변수와 타입, 배열과 객체
실행 컨텍스트	스코프 → 클로저 → 클로저와 가비지 컬렉션의 관계	실행 컨텍스트, 가비지 컬렉션
동기와 비동기	이벤트 루프 → 태스크 큐와 마이크로태스크 큐 → 콜백을 쓰는 이유 → Promise → `async`/`await`의 장단점	이벤트 루프, 콜백과 Promise, async/await
데이터 요청	`XMLHttpRequest`와 `fetch`의 차이 → 응답 상태 코드 종류	Ajax, HTTP
브라우저 렌더링 과정	렌더링 중 JavaScript가 끼어드는 방식(파싱 중단, `defer`·`async`) → 리플로우와 리페인트	브라우저 렌더링, 스크립트 로딩
에러 처리를 하는 이유	처리하지 않으면 생기는 일 → 처리 방법	에러 처리
React를 쓰는 이유	가상 DOM → `setState`는 동기인가 → 배칭	UI 변경 감지, State
써 본 훅	함수 컴포넌트와 클래스 컴포넌트의 차이 → 라이프사이클 메서드와 훅의 대응 → `useEffect`와 `useLayoutEffect`의 차이 → `useMemo`와 `useCallback`의 차이	Hooks, 라이프사이클
Redux를 쓴 경험	기본 원칙 → 리듀서에서 불변성을 지킬 때 얕은 복사인가 깊은 복사인가(얕은 복사다. 바뀐 경로만 새로 만든다) → Flux 패턴 → thunk와 saga의 차이 → Redux Toolkit을 쓰는 이유	Redux, MVC와 Flux, Redux 미들웨어
쿠키와 세션	저장 위치와 수명 → 토큰을 어디에 저장하나	쿠키와 세션, 세션과 토큰 인증
TypeScript를 쓰는 이유	타입과 인터페이스의 차이 → 언제 무엇을 쓰나	TypeScript 기초
SPA와 SSR의 차이	하이드레이션 → SEO	SPA·CSR·SSR, SEO 기초
반응형에 쓴 상대 단위	CSS 선택자 → 우선순위(명시도) → `id`와 `class` 중 무엇이 이기나	CSS 기초, 선택자, 반응형 디자인

긴장하면 아는 것도 뒤집어 말하기 쉽다(예: 얕은 복사를 깊은 복사로 정정). 사슬의 아래 고리(복사의 종류)가 단단하면 위 고리(리듀서의 불변성)에서 흔들려도 스스로 바로잡을 수 있다.

정답 하나를 묻기보다 대화로 이해도를 보는 토론 라운드도 있다. 주제는 세 갈래다.

주제	묻는 것	개념 노트
웹 개발 도구	번들링이란, 트리 셰이킹이란, 지연 로딩은 왜 중요한가, 로더는 어떻게 동작하나. 도구 복잡도를 직접 감당해야 하는 스타트업에서 더 자주 묻는다. 큰 회사는 도구를 추상화해 두는 편이라 그 역할이 아니면 덜 묻는다	번들러와 Vite, webpack, Babel, 지연 로딩
React 또는 쓰는 프레임워크	공고에 React가 있으면 컴포넌트를 짜거나 개념을 설명한다. `useEffect` 의존성 배열, `shouldComponentUpdate` 같은 리렌더링 제어. React 경험이 없으면 다른 프레임워크로 답해도 되지만 내부에서 일어나는 일을 설명할 수 있어야 한다	Hooks, 리렌더링
업무 경험	이력서에서 면접관이 흥미를 느낀 항목 한두 개를 깊게 묻는다. 예: Babel 플러그인이나 jscodeshift 코드모드로 코드베이스를 개선한 경험	레주메 작성법

열린 질문: 「아키텍처는 어떻게 고민하나」

경력자에게 자주 나오는 열린 질문이다. 범위가 넓으므로 층위를 먼저 나누고 면접관의 반응에 따라 한 층을 깊게 판다. 네 층으로 나누면 빠뜨리는 곳이 없다.

층위	다룰 것	대표 꼬리 질문	개념 노트
시스템·인프라	모놀리식, 마이크로서비스, BFF. 서비스가 쪼개지며 흩어진 인증·권한 처리를 BFF 한 곳으로 모으는 식의 도입 배경	BFF의 단점(단일 장애점, 운영 부담), 마이크로서비스로 옮길 기준(팀 규모, 독립 배포, 도메인 경계), BFF에 어디까지 맡기나	BFF, 마이크로서비스
프론트엔드 애플리케이션	상태를 성격(서버 상태, 전역 클라이언트 상태, 레거시)에 따라 다른 도구로 나누기, 기능 단위와 역할 단위를 섞은 폴더 구조	두 상태 라이브러리가 공존해도 되나, 서버 상태 라이브러리의 역할, 기능 단위 구조의 단점	React 상태 관리, 폴더 구조
컴포넌트 설계	공통 UI 라이브러리를 자체 컴포넌트로 감싸기, 재사용 범위에 따라 로직을 둘 자리 정하기	감싸기의 단점, Container·Presentational 분리, 추상화 시점	React 스타일링, 컴포넌트 분리
코드 설계	의존성을 UI → 비즈니스 로직 → 데이터 접근 한 방향으로 두기, 타입을 레이어 간 계약으로 쓰기	API 타입과 도메인 타입 분리, 과한 추상화, 팀에 공유하는 방법(ADR, 리뷰 규칙)	관심사 분리, 프론트엔드 의존성

마무리는 원칙 한 줄로 맺는다. 구조에 정답은 없고 규모·팀 상황·변경 가능성에 맞는 수준을 고른다. 작은 프로젝트의 엄격한 레이어는 과잉 설계이고, 큰 프로젝트의 무구조는 유지 보수 비용이 된다.

프론트엔드 시스템 디자인과 RADIO

프론트엔드 시스템 디자인은 분산 시스템 설계가 아니라 클라이언트 쪽 구조를 설계한다. UI 코딩과 겹치는 부분이 많다. UI 코딩 중에도 데이터 모델과 API를 설계하고, 시스템 디자인 중에도 상태 모양을 보여 주려고 코드를 조금 쓴다. 차이는 범위다. 여러 컴포넌트와 웹 스택 전반이 걸리므로 각 컴포넌트의 세부 구현까지 내려가지 않고, 클라이언트-서버 API, 컴포넌트 구성과 각 컴포넌트의 API(props)를 중심으로 높은 수준에서 이야기한다. 1시간 이내 면접이면 코드를 쓰기보다 설계 트레이드오프와 가능한 구현을 말로 다룬다.

문제 종류	예
컴포넌트	자동완성, 이미지 캐러셀, 드롭다운 메뉴, 모달 대화상자, 리치 텍스트 에디터, 투표 위젯, 데이터 테이블, 툴팁
앱	뉴스 피드(Facebook), 채팅(Messenger), 핀터레스트형 이미지 피드, 공동 문서 편집(Google Docs), 동영상 스트리밍(Netflix), 음악 스트리밍(Spotify), 디자인 툴(Figma), 화상 회의(Zoom), 숙박 예약(Airbnb), 이커머스(Amazon), 공동 스프레드시트(Google Sheets), 사진 공유(Instagram), 이메일 클라이언트(Outlook)

회사별로 실제 나온 설계 문제는 회사별 프론트엔드 면접 형식과 단골 문제에 모았다.

백엔드 시스템 디자인과 무엇이 같고 다른가

진행 방법은 같다. 요구 사항을 모으고, 큰 구성 요소를 나누고, 끝에서 끝까지 API를 설계하고, 최적화를 논한다. 지원자가 발표를 이끌어야 하고, 코드는 거의 쓰지 않으며, 체크리스트를 하나씩 지우는 시험이 아니라 열린 질문이다. 모든 항목을 깊게 팔 필요는 없다. 면접관이 특정 부분에 관심을 보이면(대개 그렇다) 그쪽으로 초점을 옮기고, 그렇지 않으면 자기 강점 쪽으로 대화를 끈다.

축	백엔드 시스템 디자인	프론트엔드 시스템 디자인
주로 다루는 것	서버 쪽 구조와 서비스 구성, DB 종류 선택과 샤드 간 데이터 집계, SQL 테이블 스키마, 전 세계 사용자를 위한 리전 전략, 지연·가용성·장애 허용	렌더링 패턴(CSR·SSR·SSG와 그 중간), 데이터 가져오기 방식(REST·GraphQL·gRPC)과 API 모양, UI 컴포넌트 세부, 여러 층의 캐시로 지연을 줄이거나 오프라인 지원, 때로 React 컴포넌트의 props나 복잡한 상태 관리
단순화하는 쪽	클라이언트는 API 계층으로 축약한다. 브라우저 사정이나 실시간 갱신이 부르는 리렌더링은 따지지 않는다	백엔드는 블랙박스로 둔다. DB 확장이나 WebSocket이 로드 밸런서에 스티키 세션을 요구하는 문제는 따지지 않는다
사용자 상호작용	거의 다루지 않는다	면접관을 PM처럼 대하고 사용자 스토리마다 해법을 짚어 가는 경우가 많다
정량 추정	저장 용량·처리량을 추정해 설계가 현실적으로 가능한지 보이는 것이 기본이다	드물다. 메시지 크기 × 개수로 클라이언트 메모리를 계산하는 식의 추정은 거의 하지 않는다
하지 않아도 되는 것	-	DB 스키마 설계, SQL vs NoSQL 선택, 서버·DB 확장(샤딩, 수직·수평 확장), 가용성·장애 허용·지연 논의

프론트엔드 쪽 구체 주제는 이런 모양이다.

이미지를 지연 로딩하는 무한 스크롤 뉴스 피드에서, 레이아웃 이동을 막으려고 이미지 가로세로 비율을 클라이언트가 미리 받아 두기(CLS 최적화, Intersection Observer).
검색 결과는 묶음 단위로 점진적으로 받고, 이미지는 서버 푸시로 동시에 받는 자동완성.
네트워크 응답이 뒤섞여 도착해도 올바른 순서로 이미지를 보여 주는 갤러리.

다만 면접관의 배경(프론트엔드·백엔드·풀스택)과 역할 범위(프론트엔드 팀인지, 스택 전반을 맡는지)에 따라 백엔드 주제가 섞인 혼합형이 될 수 있다. 실제로 DB 스키마나 백엔드 다이어그램을 요구하는 회사도 있다. 서버 쪽 설계 면접은 기술 면접 준비의 7단계를 따른다.

RADIO 프레임워크

질문은 일부러 모호하게 주어진다. 지원자가 대화를 이끈다. 화이트보드나 온라인 에디터에 RADIO 다섯 글자를 적어 두고 빠짐없이 다룬다. 순서가 꼭 이대로일 필요는 없다. 면접관이 집중할 영역을 정해 주면 그쪽을 따른다.

단계	컴포넌트 문제	앱 문제
Requirements	지원 기기(주 기기 포함)·브라우저, i18n, 스타일 커스터마이즈 범위를 질문으로 확정한다. 요구사항이 분명해지기 전에 그리지 않는다	같은 질문 + 오프라인 지원 여부
Architecture	하위 컴포넌트와 그 사이 데이터 흐름. 예: 캐러셀 = 메인 이미지, 썸네일, 클라이언트 이미지 저장소	MVC, MVVM, Flux, 데이터 계층을 클라이언트에 둔 N-tier 같은 클라이언트 구조(MV* 아키텍처)
Data model	컴포넌트 상태	서버 상태(서버에 저장되는 값) + 클라이언트 전용 상태
Interface	props, 기본값, 이벤트 훅(`onClick`, `onChange`, `onFocus`, `onBlur`)	HTTP API 파라미터와 응답 형태
Optimizations	UX, 성능, 접근성, i18n, 멀티 디바이스, 보안 중 관련 있는 것을 깊게	같다

설계 원칙

상태는 최소로. 다른 상태에서 계산되는 값(items.length로 알 수 있는 isEmpty)은 상태에 넣지 않는다. 인스턴스마다 상태가 독립적이어야 한 페이지에 여러 개를 둘 수 있다. 상태는 최상위에 모으고 하위 컴포넌트는 순수하게 둔다.
API는 개방-폐쇄 원칙. 수정 없이 확장되게 한다(프론트엔드 SOLID). 외형 커스터마이즈는 컴포지션, 렌더 props, className·style 주입으로 연다. 다만 className·style 주입은 내부 구조를 바깥에 묶어 버리는 부작용이 있다.
UI 문자열은 props로 받고 영어 기본값을 둔다. 하드코딩하면 i18n이 막힌다. 순서가 의미를 갖는 UI면 RTL도 고려한다.
성능은 로딩 속도(JS 양, 모듈 분리), 상호작용 응답성(상호작용마다 JS 실행·DOM 갱신 줄이기), 메모리다. 화면에 보이는 것만 렌더링(가상화하되 스크롤 높이는 유지), 뷰포트 안의 것부터 지연 로딩, 다음 것을 미리 로딩(캐러셀이면 다음 한 장이 아니라 다음 N장)이 핵심 기법이다.
UX 기본기: 로딩·에러 상태를 보여 준다. 빈 목록엔 빈 상태를 둔다. 긴 문자열은 잘라 「더 보기」를 둔다. 되돌릴 수 없는 동작엔 확인 단계를 둔다. 비동기 요청 중엔 버튼을 비활성화한다(손 떨림으로 두 번 누르는 사용자도 있다). 검색은 키 입력마다 요청하지 않는다(디바운스).
모바일: 메모리를 아끼고 터치 영역을 키운다.
보안: XSS(innerHTML, dangerouslySetInnerHTML), CSRF, 클릭재킹, 새 창 링크의 rel="noopener".

성능·접근성·i18n을 먼저 꺼내 깊게 말하는 것이 시니어와 주니어를 가른다. 면접 시간에 최적화 항목을 다 다룰 수는 없으니 문제와 관련 깊은 것을 골라 깊게 판다. RADIO는 면접 밖에서도 새 프론트엔드 프로젝트의 기술 설계 문서 뼈대로 쓸 수 있고, 백엔드 시스템에도 그대로 적용된다. 실제 앱 설계 사례는 실시간 채팅 앱의 데이터 흐름, 렌더링 전략은 SPA와 CSR·SSR에 있다.

비헤이비어럴과 레주메

코딩·설계를 잘하고도 비헤이비어럴에서 떨어지는 경우가 있다. 시니어일수록 비중이 크다. 협업, 소통, 갈등 해결, 멘토링을 본다.
준비할 것: 이력서의 모든 항목을 설명할 수 있게 한다. 내가 한 일과 그 결과를 구체적 사례로 말한다. 과거를 스스로 비판하고 배운 점을 말한다. 지금 일에서 좋은 점과 이직 이유를 정리해 둔다. 질문별 답 요소는 인성 면접 준비에 있다.
레주메는 처음부터 만들기보다 검증된 템플릿에서 시작한다. ATS에서 제대로 파싱되는지 확인한다. 내용을 일반 텍스트 파일에 붙여 넣어 빠진 항목, 깨진 글자, 뒤섞인 섹션이 없는지 보거나, OpenResume 같은 무료 파서로 검사한다. 쓰는 법은 합격하는 영문 레주메 작성법, ATS는 미국 개발자 채용 프로세스와 ATS에 있다.

정리

프론트엔드 면접은 도메인 지식과 실전 구현 중심이다. 기본기(CSS 레이아웃, this·클로저·Promise, 이벤트 위임)가 모든 유형의 바탕이다.
유형은 JS 코딩, UI 코딩, 알고리즘, 퀴즈, 시스템 디자인, 비헤이비어럴이고 회사마다 조합이 다르니 먼저 조합을 확인한다.
JS 코딩은 빨리 끝내고 후속 문제를 받는다. 복잡도와 순수 함수를 챙긴다.
UI 코딩은 범위를 먼저 합의하고, 극단적 입력·네트워크·접근성·보안을 짚는다.
시스템 디자인은 RADIO로 대화를 이끌고, 최적화 단계에서 깊이를 보여 준다. 백엔드와 달리 DB·확장·정량 추정보다 렌더링·데이터 가져오기·캐시·컴포넌트 API를 다룬다.

버그 제보