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

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

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

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

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

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

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

Интервьюер проверяет, что выбор был осознанным и что ограничения Flutter вы знаете по опыту, а не из статей. Назовите причину в одной-двух фразах, а затем расскажите один реальный случай, когда пришлось уйти в натив или обходить фреймворк, и как вы с этим справились. Честная причина: одна кодовая база на две платформы при маленькой команде, hot reload, собственный дизайн, одинаковый везде; личная причина тоже подходит, если она правдива Реальное ограничение: виджеты на домашнем экране, нативный SDK без плагина, фоновая работа, platform views, размер приложения Что вы сделали: платформенный канал или небольшой плагин, нативный экран или изменение дизайна Баланс: правильный инструмент для этого продукта с известной ценой, а не религия Красные флаги: «Flutter умеет всё», сравнение из статей без собственного опыта за ним, полное незнание Kotlin и Swift Пример «Мы выбрали Flutter, потому что трём разработчикам нужно было выпускаться в оба стора. Ограничил он нас на виджете для домашнего экрана iOS: WidgetKit требует SwiftUI в отдельном расширении. Я написал виджет на Swift, передавал данные из приложения через App Group и обновлял его из Dart через небольшой method channel. Ушла неделя, в основном на изучение WidgetKit, и я научился проверять платформенные возможности до того, как их обещать.»

Интервьюер проверяет, как вы отлаживаете: как сужаете проблему, какими инструментами пользуетесь и исправляете ли причину, а не симптом. Рассказывайте по STAR и больше всего времени отдайте действиям: гипотезам, тому, как вы их проверяли, и тому, что не даст багу вернуться. Почему было сложно: только на некоторых устройствах, только под нагрузкой, нет стектрейса; скажите это сразу Поиск по шагам: краш-репорты и логи, профайлер, минимальное воспроизведение, git bisect, ложные следы, которые вы отбросили Корневая причина одной фразой: чтобы интервьюер мог уследить за мыслью Профилактика: тест, алерт или правило линтера, добавленные после Красные флаги: банальная опечатка, «не помню», баг, который нашёл коллега, исправление, которое вы не можете объяснить Пример Ситуация: список каталога подтормаживал на бюджетных Android-телефонах, об этом писали в отзывах Задача: мой код, значит, и баг мой Действия: на реальном слабом телефоне в profile-режиме DevTools показал медленные кадры растеризации: фото декодировались в полном размере ради превью в 100 пикселей, а каждая карточка лежала внутри виджета Opacity. Я задал cacheWidth по размеру превью и заменил Opacity полупрозрачным цветом Результат: медленных кадров стало меньше 3% вместо примерно 20%, а тест времени кадра на реальном устройстве теперь запускается перед каждым релизом

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

Интервьюер проверяет, как вы действуете под давлением и понимаете ли, что одна кодовая база на Dart всё равно означает две сборки. Расскажите по STAR: как узнали, как ограничили ущерб, как держали людей в курсе, в чём была причина и что изменили в процессе релиза. Обнаружение: краш-репорты и показатели сторов в разбивке по платформе и версии Ограничить ущерб: остановить раскатку в Play или поставить на паузу phased release в iOS; выключить фичу, если она за удалённым флагом Коммуникация: одно сообщение команде и поддержке с масштабом проблемы и временем следующего апдейта Причина обычно ниже Dart: правила R8, нативный код плагина, записи в Info.plist или манифесте, минимальная версия ОС После: релизные сборки проверяются на реальных устройствах обеих платформ перед каждой раскаткой Красные флаги: «тестируем только на iOS, код же общий», свалить вину на автора плагина и на этом остановиться Пример «Релиз падал на входе только на Android и только в релизной сборке. При раскатке на 5% Crashlytics показал это в течение часа; я остановил раскатку и написал в релизный канал. R8 удалил класс, который нативный SDK загружал через рефлексию. Я добавил keep-правило, исправление вышло в тот же день, а CI теперь перед каждой раскаткой прогоняет smoke-тест на релизном APK.»

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

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

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

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

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

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

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