Поведенческое интервью

Интервьюер проверяет, умеете ли вы коротко и по делу рассказать о себе и почему подходите на эту роль. Уложитесь в одну-две минуты: настоящее (роль, стек, чем заняты сейчас), прошлое (как к этому пришли, один результат), будущее (почему следующим шагом должна стать именно эта вакансия). Подстройтесь под вакансию: начните с того, что нужно по описанию; учёбу, хобби и пересказ резюме пропустите Один результат с цифрой: ускоренный холодный старт, снижение доли крашей Красные флаги: пересказ резюме по местам работы, монолог на пять минут, ни слова о том, чего вы хотите дальше Пример Настоящее: «Я фронтенд-разработчик, три года на React и TypeScript. Отвечаю за таблицы и фильтры B2B-дашборда аналитики.» Прошлое: «Начинал с вёрстки, потом помог перевести дашборд с Create React App на Vite.» Будущее: «Хочу расти в производительности и дизайн-системах, а эта роль как раз про них.»

Интервьюер проверяет мотивацию и то, не уйдёте ли вы от них по той же причине. Назовите одну честную причину как движение к чему-то (задачи сложнее, продукт крупнее, команда сильнее), а затем две конкретные вещи, которые привлекают вас в этой компании. К чему-то, а не от чего-то: «я перерос свои задачи» или «хочу больше масштаба», но никогда «у меня бесполезный руководитель» Конкретно про них: их продукт, стек, статья в блоге или доклад; «отличная компания» не говорит ничего Сокращение или короткий срок работы: скажите прямо одной фразой и переходите дальше Красные флаги: критика своего работодателя, «только ради денег», незнание компании Пример «Два года я почти в одиночку делаю наш дашборд, и мне не хватает команды, у которой можно учиться. У вас есть команда дизайн-системы и сильная фронтенд-платформа, и расти я хочу именно там.»

Интервьюер проверяет масштаб того, что вы делали, и ваш личный вклад в работу команды. Отвечайте по STAR: ситуация и проблема, ваша задача, ваши действия и их причины, измеримый результат. «Я» для своей части: «мы» только о работе команды; оценивают то, что сделали вы Одно решение подробно: ждите вопроса «почему так, а не X?» Результат в цифрах: crash-free users, время загрузки, конверсия, обращения Красные флаги: технологии без проблемы за ними, архитектура, которую вы не можете объяснить, успех команды, выданный за свой Пример Ситуация: операционисты работали с таблицей на 10 000 строк, которая зависала при каждой смене фильтра Задача: я переделал таблицу Действия: виртуализация строк, фильтрация на сервере, состояние фильтров в URL, чтобы ссылками можно было делиться Результат: фильтрация занимает меньше 200 мс, и компонентом теперь пользуются ещё две команды

Интервьюер проверяет, насколько трезво и честно вы себя оцениваете. Назовите две-три сильные стороны, важные для этой роли, каждую с фактом, и одну настоящую слабую сторону, которая не мешает работе, вместе с тем, что вы с ней уже делаете. Сильные стороны с доказательством: факт из работы, а не прилагательные вроде «ответственный» Настоящая слабость: трудно высказываться на больших встречах, привычка поздно просить о помощи, мало опыта в области, которая для роли не главная Что вы с ней делаете: привычка, которая уже работает, чтобы ответ заканчивался прогрессом Красные флаги: «слабых сторон нет», скрытое хвастовство («я перфекционист») Пример Сильная сторона: «Доступность. Я замечаю проблемы с клавиатурой и скринридером раньше, чем QA.» Слабая сторона: «Я плохо знал бэкенд. Теперь пишу небольшие сервисы на Node и ревьюю код нашего BFF.»

Рекрутер проверяет, вписываетесь ли вы в бюджет и знаете ли свою цену на рынке. Назовите изученную вилку для вашего уровня и рынка, поясните, до или после налогов и в месяц или в год, и добавьте, что итог зависит от задач и всего предложения. Сначала исследование: обзоры зарплат, похожие вакансии, знакомые, которые недавно меняли работу Честная нижняя граница: офферы приходят близко к ней, так что назовите число, которое вас устроит Знайте принятую форму: за рубежом обычно сумма до налогов (gross) в год, в русскоязычных компаниях часто на руки в месяц Спросите их вилку первыми: на этом этапе это нормально, и всё чаще работодатели обязаны называть её заранее Красные флаги: «сколько предложите», цифра с потолка, текущая зарплата, которую вы назвали без вопроса Пример Зарубежная компания: «Для middle фронтенд-разработчика я ориентируюсь на X–Y gross в год. А какая у вас вилка?» Русскоязычный рынок: «Я ориентируюсь на X–Y в месяц на руки. А какая у вас вилка?»

Интервьюер проверяет ваш интерес и то, что для вас важно; «вопросов нет» звучит как равнодушие. Подготовьте три-четыре вопроса о самой работе (команда, как выпускают релизы, что значит успех на этой роли) и выберите те, что подходят человеку перед вами. Работа: «Чем я буду заниматься первые три месяца?», «Кто делает код-ревью и сколько человек в команде?» Как выпускают: частота релизов, тестирование, дежурства, техдолг и кто решает, когда им заниматься Успех: «Как через полгода вы поймёте, что я хорошо справляюсь?» По собеседнику: процессы у тимлида, планы продукта у руководителя, условия у рекрутера Красные флаги: нет ни одного вопроса, вопросы об отпуске на техническом интервью Пример «У вас Next.js или одностраничное приложение и как оно деплоится?» «Кто владеет дизайн-системой и как команды в неё контрибьютят?»

Интервьюер проверяет, как вы отлаживаете: как сужаете проблему, какими инструментами пользуетесь и исправляете ли причину, а не симптом. Рассказывайте по STAR и больше всего времени отдайте действиям: гипотезам, тому, как вы их проверяли, и тому, что не даст багу вернуться. Почему было сложно: только на некоторых устройствах, только под нагрузкой, нет стектрейса; скажите это сразу Поиск по шагам: краш-репорты и логи, профайлер, минимальное воспроизведение, git bisect, ложные следы, которые вы отбросили Корневая причина одной фразой: чтобы интервьюер мог уследить за мыслью Профилактика: тест, алерт или правило линтера, добавленные после Красные флаги: банальная опечатка, «не помню», баг, который нашёл коллега, исправление, которое вы не можете объяснить Пример Ситуация: после перевода страниц товаров на серверный рендеринг в Next.js Sentry заполнился ошибками гидратации, а дата доставки мигала Задача: взялся я Действия: страдали только пользователи не из часового пояса сервера: дата форматировалась через toLocaleDateString() на сервере и ещё раз в браузере, и HTML расходился. Я вынес форматирование в одну функцию с фиксированными локалью и timeZone, чтобы обе стороны выдавали один и тот же текст Результат: ошибки гидратации исчезли, а end-to-end тесты теперь запускаются в часовом поясе, отличном от серверного

Интервьюер проверяет, измеряете ли вы производительность, а не гадаете, и предотвращаете ли следующую просадку, а не только чините эту. Расскажите по STAR: как она проявилась, как нашли причину профайлером, как исправили и какую защиту добавили. Где проявилось: Core Web Vitals реальных пользователей, бюджет в Lighthouse CI, жалоба пользователя Измерьте причину: React Profiler для рендеров, панель Performance для долгих задач, анализатор бандла для размера Исправьте причину: контекст, который перерисовывает всё, тяжёлая библиотека в основном бандле, список без виртуализации Защита от следующей: лимит размера бандла или бюджет производительности в CI, алерт на полевую метрику Красные флаги: обернуть всё в useMemo без замеров, «на моём MacBook быстро», нет цифр до и после Пример «После релиза INP на странице поиска по данным реальных пользователей вырос примерно со 150 мс до 400 с лишним. React Profiler показал, что каждое нажатие клавиши перерисовывает всю страницу: новое значение фильтра добавили в контекст на уровне корня. Я перенёс состояние поля вниз, в сам блок поиска, и разделил контекст. INP вернулся примерно к 150 мс, а в мониторинг мы добавили алерт на INP.»

Интервьюер проверяет ответственность: признаёте ли вы ошибку, быстро ли ограничиваете ущерб и меняете ли процесс, чтобы она не повторилась. Выберите настоящую ошибку с ограниченными последствиями, расскажите по STAR, а последнюю часть отдайте тому, что изменили. Признайте прямо: «я выкатил», а не «так получилось»; не вините QA или ревьюера, который пропустил Сначала ограничьте ущерб: кому и как быстро вы сообщили, откат или хотфикс, сколько пользователей задело Исправьте систему: тест, проверка в CI, правило ревью или алерт; «буду внимательнее» исправлением не считается Красные флаги: «я не ошибаюсь», история, где виноват кто-то другой, катастрофа без выводов, мелкая опечатка, выбранная, чтобы не рисковать Пример «После деплоя у части пользователей открывалась пустая страница с ChunkLoadError. CDN кэшировал index.html на сутки, и вернувшиеся посетители получали старый HTML со ссылками на JavaScript-чанки, которые мы только что удалили. Я откатил релиз, сбросил кэш CDN и выставил для index.html заголовок Cache-Control: no-cache, а ассеты с хешем остались immutable. Теперь мы храним ассеты предыдущего релиза неделю и показываем предложение перезагрузить страницу, если чанк не загрузился.»

Интервьюер проверяет, умеете ли вы не соглашаться, не портя рабочие отношения. Возьмите настоящее рабочее разногласие, часто техническое или на код-ревью, и покажите, как вы перевели его от мнений к общим критериям, что решили и как работали вместе после. Говорите рано и напрямую: длинную ветку комментариев переведите в короткий созвон или разговор один на один Сначала поймите их позицию: честно перескажите её, прежде чем доказывать свою Сначала критерии, потом решение: цифры, договорённости команды, быстрый прототип; если согласия всё равно нет, решает владелец решения, а вы его принимаете Проиграть нормально: история, где вы приняли чужой подход, показывает зрелость Красные флаги: «у меня не было конфликтов», коллега в роли злодея, сразу к руководителю, победа ценой отношений Пример «Я хотел Tailwind для нового раздела приложения, а коллега предпочитал CSS Modules, которые у нас уже были. Мы сверстали одну и ту же страницу обоими способами и спросили команду. CSS Modules выиграли за счёт единообразия, я принял это и помог написать общий файл токенов. Проиграть это голосование ничего не стоило, а затянуть спор стоило бы.»

Интервьюер проверяет, реалистично ли вы планируете и поднимаете ли риск сразу, как только его видите, а не в день дедлайна. Расскажите, как вы декомпозируете и оцениваете работу, а затем историю, где вы заметили срыв срока заранее, вовремя предупредили и предложили варианты. Декомпозиция: куски от половины дня до двух дней, включая тесты, ревью, QA и релиз, о которых часто забывают Неизвестное отдельно: ограниченный по времени спайк на всё, что вы ещё не делали; называйте диапазон, а не одно число Сравнение с прошлым: сколько на самом деле заняли похожие задачи Если срок срывается: скажите тимлиду или продакту в тот же день, с вариантами: урезать объём, сдвинуть дату, добавить людей; никогда не сидите молча по ночам в надежде успеть Красные флаги: «я всегда успеваю», оценка без декомпозиции, сообщение о срыве в день релиза Пример «У лендинга для кампании была жёсткая дата. На второй день анимированный первый экран сломался в Safari и съел день отладки. Я сразу сказал продакту и предложил на запуск статичный первый экран, а анимацию через неделю. Мы запустились вовремя, а анимация вышла в следующем спринте.»

Интервьюер проверяет, думаете ли вы о продукте и умеете ли возражать аргументами, а не молча делать или отказываться. Покажите, что вы спросили о цели, принесли доказательства цены, предложили альтернативу, которая ведёт к той же цели, и приняли итоговое решение. Сначала спросите о цели: требование часто лишь один из путей к ней, и есть путь дешевле Принесите доказательства: запись экрана на реальном устройстве, замер, гайдлайн платформы, оценку каждого варианта Предложите альтернативу: «X к пятнице не успеем, но Y даст большую часть результата» Уважайте решение: когда владелец продукта решил, видя все компромиссы, вы делаете это хорошо Красные флаги: «я делаю, что скажут», отказ без альтернативы, решать вопрос через голову продакта Пример «Дизайнер хотел бесконечную прокрутку в результатах поиска. Я показал, что кнопка „Назад“ будет терять позицию, до футера невозможно будет добраться, а поисковики увидят только первую страницу. Я предложил кнопку „Показать ещё“ с номером страницы в URL. Мы проверили оба варианта на пяти пользователях, и выиграла кнопка.»

Интервьюер проверяет, умеете ли вы превратить дизайн-систему в компоненты, которым доверяют обе стороны, и справляться с разрывом между макетом и браузером. Опишите общий источник правды, цикл ревью с дизайнерами и историю, где вы разрешили разногласие. Одинаковые имена с обеих сторон: переменные Figma экспортируются как дизайн-токены (CSS custom properties); никаких hex-значений в компонентах Storybook как место встречи: дизайнеры смотрят настоящий компонент во всех состояниях, а не скриншот Визуальные регрессионные тесты: скриншоты в Chromatic или Playwright ловят непреднамеренные изменения на ревью Правило для единичных случаев: новый вариант попадает в библиотеку или меняется дизайн; никаких копий в папках фич Реальность браузера: фокус с клавиатуры, скринридеры, длинный переведённый текст, масштабирование и узкие экраны, которые в макетах показывают редко Красные флаги: «делаю ровно как в Figma» или наоборот, изменение дизайна без согласования Пример «Дизайнеры нарисовали состояния фокуса только для половины компонентов, и пользователи клавиатуры не видели, где находятся. Я собрал все пробелы на одной странице Storybook и показал её на еженедельной встрече. Мы договорились об одном токене для обводки фокуса, я применил его по всей библиотеке, и состояния фокуса вошли в наш чеклист компонента.»

Интервьюер проверяет, умеете ли вы слышать критику, не защищаясь, и сказать коллеге о проблеме, не задев его. Расскажите, как вы делаете и то и другое, и подкрепите историей, где обратная связь изменила вашу работу. Принимать: дослушать, попросить конкретный пример, поблагодарить и позже вернуться с тем, что вы изменили Давать: наедине, вскоре после события, о поведении и его последствиях, а не о человеке («в этом PR не было тестов, и баг дошёл до QA»), с предложением На код-ревью: объяснять почему, отделять блокирующие замечания от мелочей, отмечать хорошее Красные флаги: «негативной обратной связи у меня не бывает», спор с каждым пунктом, обратная связь только через руководителя, резкие публичные комментарии Пример «Дизайнер сказала, что мои компоненты часто отличаются от макета на несколько пикселей и ей приходится заводить на это баги. Я стал сравнивать компонент в Storybook с фреймом в Figma до открытия PR, и такие баги почти прекратились.»

Интервьюер проверяет, умножаете ли вы результат команды, а не только свой. Расскажите конкретную историю: в чём был затык у человека или команды, что вы делали регулярно (парное программирование, ревью, задачи с растущей сложностью, общие практики) и какой результат можно показать. Начните с его пробела: спросите и понаблюдайте, что на самом деле мешает; общая лекция не помогает Учите на реальной работе: сделайте задачу вместе, затем дайте похожую сделать самому; на ревью объясняйте и давайте ссылки, а не переписывайте код Растите самостоятельность: задачи чуть выше уровня и место для мелких ошибок там, где они дёшевы Масштабируйте на команду: чеклист, правило линтера, шаблон PR, короткий внутренний доклад, записанные решения Результат: человек сам выпустил фичу, раундов ревью стало меньше, онбординг сократился Красные флаги: «я просто сам исправляю их код», менторство как раздача указаний, нет примера Пример «Джуниор использовала useEffect для всего, включая производное состояние, и её страницы перерисовывались по кругу. Мы работали в паре над её задачами, я дал ей страницу документации React об эффектах, без которых можно обойтись, и поручил рефакторинг одной формы как её собственную задачу. Потом она провела короткую сессию для команды, а правила линтера для хуков мы сделали ошибками вместо предупреждений.»

Интервьюер проверяет, говорите ли вы на языке бизнеса и умеете ли расставлять приоритеты, вместо того чтобы просить всё переписать. Переведите долг в цену, которую бизнес уже ощущает (медленные фичи, инциденты, потерянные пользователи), предложите небольшой измеримый план и отчитайтесь о результате. Измерьте боль: время на типичную фичу, баги за релиз в этой части, инциденты, время сборки, умноженное на команду Приоритет по цене: важен долг в коде, который часто меняется; старый стабильный код может оставаться некрасивым Понемногу и постоянно: фиксированная доля каждого спринта или чистка вместе со следующей фичей в этой части, а не заморозка на три месяца Покажите эффект: цифры до и после облегчают следующую просьбу Красные флаги: «код некрасивый» как аргумент, просьба переписать всё, работа, спрятанная в оценки фич Пример «Половина нашей кодовой базы была типизирована как any. Sentry показывал, что большинство ошибок на фронтенде составляют обращения к свойствам undefined, которые поймали бы типы. Я предложил включать strict папка за папкой через отдельный tsconfig, начиная с оформления заказа и с проверкой в CI для нового кода. За два месяца ошибок в оформлении заказа стало примерно на две трети меньше.»

Интервьюер проверяет, умеете ли вы вести долгое изменение через команду и бизнес, а не только запустить кодмод. Покажите причину для бизнеса, пошаговый план, как фичи продолжали выходить, как вы вовлекли людей и результат в цифрах. Причина, которую примет бизнес: медленные сборка и дев-сервер, устаревший инструмент (Create React App объявлен deprecated), фича, которую иначе не сделать Постепенно, по замыслу: маршруты Pages Router и App Router могут жить в одном приложении Next.js; новая сборка может идти в CI рядом со старой, пока её не заменит Фичи продолжают выходить: без заморозки; маршрут или пакет переезжает, когда его затрагивает фича, а для остального есть срок Вовлеките людей: пилот, письменный гайд, кодмоды там, где они есть, парная работа, один ответственный за вопросы Измеряйте: время сборки, старт дев-сервера, размер бандла и Core Web Vitals до и после Красные флаги: ветка «всё разом», живущая месяцами, миграция ради моды, нет плана отката Пример «Дев-сервер на CRA стартовал 40 секунд, а hot reload занимал несколько секунд. Я замерил это, умножил на команду и получил спринт на пилот с Vite. Я переносил приложение в ветке, которая жила один спринт и каждый день ребейзилась, скриптом переименовал переменные окружения с REACT_APP_ на VITE_ и написал одностраничный гайд. Дев-сервер теперь стартует примерно за 2 секунды, продакшен-сборка сократилась с 6 минут до меньше чем одной, и работа над фичами ни разу не останавливалась.»