Подготовка к собеседованию — Frontend-разработчик
Колода из 262+ карточек с вопросами для собеседования по направлению «Frontend-разработчик» — по темам и уровню сложности, с повторениями по вашим оценкам. Посмотрите несколько карточек ниже, затем выберите доступ, чтобы учить всё направление по расписанию в стиле Anki (SM-2).
Новым подписчикам месяца или года может быть доступен бесплатный пробный период 7 дней. Условия и сумму подтвердит страница оплаты.
С чего начать
Нужны основы HTML/CSS и JavaScript и опыт создания небольшого браузерного интерфейса. Примеры React и TypeScript предполагают, что вы можете читать код компонентов.
Первый проход: HTML и CSS → JavaScript. Начните с базовых вопросов в этих модулях, затем продолжайте по плану. К сложным и senior-вопросам возвращайтесь по требованиям вакансии; все карточки доступны с самого начала.
Общие темы могут входить в несколько направлений и сохраняют одну историю повторений. План ниже отмечает общие основы и профильные модули; выбирайте глубину под свою вакансию.
Что внутри
Все темы направления, сгруппированные так, как вы будете их учить.
HTML и CSS
19 карточекПрофильный модуль
JavaScript
33 карточкиПрофильный модуль
TypeScript
18 карточекПрофильный модуль
React и фреймворки
30 карточекПрофильный модуль
Браузер и производительность
17 карточекПрофильный модуль
Доступность
12 карточекПрофильный модуль
Веб-безопасность
8 карточекПрофильный модуль
Сборка, тулинг и тестирование
12 карточекПрофильный модуль
DevOps и инфраструктура
9 карточекОбщие основы
Системный дизайн фронтенда
13 карточекПрофильный модуль
Основы CS
53 карточкиОбщие основы
Поведенческое интервью
38 карточекОбщие основы
Примеры вопросов
Несколько карточек из колоды — откройте ответ, затем выберите доступ, чтобы учить весь набор по расписанию.
Что такое семантическая вёрстка и зачем она нужна (доступность, SEO, поддержка)?
Что такое семантическая вёрстка и зачем она нужна (доступность, SEO, поддержка)?
Короткий ответ: Семантическая вёрстка — это использование HTML-тегов по их смыслу (<nav>, <article>, <button>), а не <div> на всё подряд. Браузер и вспомогательные технологии понимают структуру документа, что даёт доступность, SEO и читаемый код.
Подробно:
- Доступность (a11y) — скринридеры строят дерево доступности по тегам:
<nav>,<main>,<h1>дают навигацию по ориентирам и заголовкам.<div>-суп озвучивается как бесструктурный текст. - SEO — поисковики выделяют
<article>,<h1>–<h6>,<time>как сигналы структуры и важности контента. - Поддерживаемость —
<header>/<footer>/<aside>самодокументируют разметку; не нужно читать классы, чтобы понять роль блока. - Бесплатное поведение —
<button>фокусируется и реагирует на Enter/Space,<a>навигируется,<details>сворачивается — без JS.
<!-- ❌ div-суп -->
<div class="nav"><div class="link" onclick="go()">Главная</div></div>
<!-- ✅ семантика -->
<header>
<nav aria-label="Основная">
<a href="/">Главная</a>
</nav>
</header>
<main>
<article>
<h1>Заголовок статьи</h1>
<time datetime="2026-06-30">30 июня 2026</time>
</article>
</main>
⚠️ Частая ошибка: делать кликабельный <div onclick> вместо <button> — теряются фокус, клавиатура и роль для скринридера.
Что такое хойстинг и чем отличаются var, let и const с точки зрения области видимости и TDZ?
Что такое хойстинг и чем отличаются var, let и const с точки зрения области видимости и TDZ?
Короткий ответ: Хойстинг — это подъём объявлений в начало их области видимости на этапе компиляции. var поднимается и инициализируется как undefined (функциональная область видимости), а let/const поднимаются, но остаются в TDZ (temporal dead zone) до строки объявления и имеют блочную область видимости.
Подробно:
- var — функциональная область видимости, доступна как
undefinedдо объявления, можно переобъявлять. - let — блочная область видимости, в TDZ до объявления, переприсваивание разрешено.
- const — как
let, но без переприсваивания (само значение объекта при этом мутабельно). - TDZ — обращение к
let/constдо объявления бросаетReferenceError, а не возвращаетundefined.
console.log(a); // undefined — var поднят
var a = 1;
console.log(b); // ReferenceError — b в TDZ
let b = 2;
| Область видимости | До объявления | Переприсваивание | |
|---|---|---|---|
| var | функция | undefined |
да |
| let | блок | TDZ → ошибка | да |
| const | блок | TDZ → ошибка | нет |
⚠️ Частая ошибка: считать, что let/const «не поднимаются». Они поднимаются — но обращение к ним до инициализации падает из-за TDZ.
Зачем нужен TypeScript поверх JavaScript и что такое структурная (утиная) типизация?
Зачем нужен TypeScript поверх JavaScript и что такое структурная (утиная) типизация?
Короткий ответ: TypeScript добавляет статическую проверку типов поверх JS: ошибки ловятся в редакторе и на этапе сборки, а не в рантайме. Типизация в нём структурная — совместимость определяется формой объекта (набором полей), а не именем типа или явным implements.
Подробно:
- Что даёт TS — автодополнение и навигация, безопасный рефакторинг, самодокументируемые контракты, отлов опечаток и
undefinedдо запуска. - Структурная vs номинальная — в Java/C# типы совместимы по имени (номинальная типизация). В TS — если объект имеет нужные поля, он подходит, даже если создан без знания о целевом типе.
- Стирание типов — типы существуют только при компиляции, в рантайме это обычный JS. Нельзя проверить тип через
instanceofдля интерфейса.
interface Point { x: number; y: number }
function len(p: Point): number {
return Math.hypot(p.x, p.y);
}
// объект не объявлял implements Point, но подходит по форме
const v = { x: 3, y: 4, label: "v" };
len(v); // OK — структурная типизация: лишнее поле label не мешает
⚠️ Частая ошибка: считать, что TS защищает в рантайме. Данные из API нужно валидировать (zod и т.п.) — компилятор верит вашим аннотациям на слово.
Что такое JSX и во что он компилируется?
Что такое JSX и во что он компилируется?
Короткий ответ: JSX — это синтаксический сахар над вызовами функции создания элементов. Компилятор (Babel/SWC) превращает его в вызовы jsx-runtime (или React.createElement в старом transform), которые возвращают обычные JS-объекты — описания UI, а не реальные DOM-узлы.
Подробно:
- Это выражение, а не HTML — JSX компилируется в JavaScript и встраивается везде, где допустимо выражение.
- Новый JSX-transform (React 17+) — импортирует
jsx/jsxsизreact/jsx-runtime, поэтомуimport Reactради JSX больше не нужен. - Возвращает объект-элемент — вида
{ type, key, props }; реальный DOM появляется только при рендере. - Регистр имеет значение — тег с заглавной буквы — компонент, со строчной — DOM-элемент.
const el = <button className="btn" onClick={fn}>Save</button>;
// новый transform компилирует это в:
import { jsx } from "react/jsx-runtime";
const el = jsx("button", { className: "btn", onClick: fn, children: "Save" });
⚠️ Частая ошибка: считать JSX строкой или HTML. На деле это JS: пишут className, а не class, а атрибуты — в camelCase (onClick, tabIndex).
Чем отличаются cookies, localStorage, sessionStorage и IndexedDB и что где хранить?
Чем отличаются cookies, localStorage, sessionStorage и IndexedDB и что где хранить?
Короткий ответ: Cookie — маленькие (около 4 КБ каждая), браузер сам отправляет их с подходящими HTTP-запросами; сервер может сделать cookie HttpOnly (невидимой для JS), Secure, SameSite и задать срок жизни — поэтому они для сессий. localStorage — около 5 МБ на origin, живёт до очистки, общий для всех вкладок origin, синхронный API только для строк. sessionStorage — то же, но на одну вкладку: переживает перезагрузку и исчезает при закрытии вкладки. IndexedDB — асинхронная база для больших структурированных данных (объекты, Blob), доступна и в воркерах.
Подробно:
| Cookie | localStorage | sessionStorage | IndexedDB | |
|---|---|---|---|---|
| Срок жизни | Expires/Max-Age или сессия |
до очистки | до закрытия вкладки | до очистки |
| Объём | ~4 КБ на cookie | ~5 МБ | ~5 МБ | по квоте, много |
| Уходит на сервер | да, автоматически | нет | нет | нет |
| Область | домен + путь | origin, все вкладки | origin, одна вкладка | origin |
| API | заголовки / document.cookie |
синхронный, строки | синхронный, строки | асинхронный, объекты |
- Токены —
localStorageчитается любым XSS-скриптом; сессию надёжнее держать в cookieHttpOnly; Secure; SameSite. - Синхронизация вкладок — событие
storageприходит в другие вкладки того же origin. - Не гарантия — браузер может вытеснить данные при нехватке места, а Safari удаляет записанное скриптами хранилище сайта после 7 дней без взаимодействия пользователя.
localStorage.setItem("prefs", JSON.stringify({ theme: "dark" })); // только строки
const prefs = JSON.parse(localStorage.getItem("prefs") ?? "{}");
sessionStorage.setItem("wizardStep", "2"); // эта вкладка, переживёт reload
window.addEventListener("storage", (e) => { // срабатывает в ДРУГИХ вкладках
if (e.key === "prefs") applyPrefs(e.newValue);
});
// Сессионную cookie ставит сервер, JS её не видит:
// Set-Cookie: sid=…; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
⚠️ Частая ошибка: класть объект напрямую: localStorage.setItem("u", { a: 1 }) сохранит строку "[object Object]". Сериализуйте через JSON.stringify.
Что такое доступность (accessibility, a11y) и почему она важна?
Что такое доступность (accessibility, a11y) и почему она важна?
Короткий ответ: Доступность (a11y) — это проектирование продуктов так, чтобы ими могли пользоваться люди с нарушениями зрения, слуха, моторики и когнитивными особенностями. Она важна по трём причинам: этической (люди), деловой (шире аудитория) и юридической (WCAG, ADA, European Accessibility Act).
Подробно:
- Люди — около 15% населения живёт с какой-либо инвалидностью; временные (сломанная рука) и ситуативные (яркое солнце, шумное метро) ограничения касаются всех.
- Бизнес — больше пользователей, лучше SEO (семантика = понятная структура), меньше отказов.
- Закон — WCAG 2.x де-факто стандарт; в США — ADA/Section 508, в ЕС — EAA; иски за недоступные сайты реальны.
| Нарушение | Барьер | Решение |
|---|---|---|
| Зрение | не видит экран | скринридер, контраст, alt |
| Слух | не слышит звук | субтитры, транскрипты |
| Моторика | не пользуется мышью | доступность с клавиатуры |
| Когнитивные | сложный интерфейс | простой язык, ясная структура |
⚠️ Частая ошибка: считать доступность «фичей для меньшинства» — на деле она улучшает UX для всех (эффект срезанного бордюра).
Готовы лучше запоминать?
Посмотрите пример, выберите направление и настройте регулярную практику под свою подготовку.
Вопросы об этом направлении
Как готовиться к собеседованию на «Frontend-разработчик»?
Учите концепции, которые придётся объяснять, а не только те, что умеете кодить. Направление «Frontend-разработчик» в RecallDeck даёт 262+ отобранных вопросов и возвращает каждый по расписанию в стиле Anki (SM-2), основанному на ваших оценках — чтобы тренировать вспоминание и объяснение. Дополняйте повторения кодингом и пробными собеседованиями.
Какие темы охватывает направление «Frontend-разработчик»?
Направление «Frontend-разработчик» разбито на ключевые области, которые реально проверяют на таких собеседованиях, — по темам и уровню сложности (Concept, Junior, Middle, Senior). Полный план и примеры вопросов можно посмотреть выше до входа.
Помогает ли интервальное повторение в подготовке к «Frontend-разработчик»?
Да. Активное вспоминание и честная самооценка помогают закреплять знания. RecallDeck назначает повторения карт по направлению «Frontend-разработчик» на основе ваших оценок: знакомые карты возвращаются реже, а сложные получают больше практики.
Можно попробовать направление «Frontend-разработчик» до оплаты?
Новым подписчикам месячного или годового тарифа может быть доступен пробный период 7 дней со всем направлением «Frontend-разработчик» и всеми функциями. Право на него и сумму подтвердит страница оплаты; при повторной подписке списание может быть сразу. Отмените подписку онлайн до конца пробного периода, чтобы избежать первого списания. У вечного доступа пробного периода нет.