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

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

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

Интервьюер проверяет масштаб того, что вы делали, и ваш личный вклад в работу команды. Отвечайте по STAR: ситуация и проблема, ваша задача, ваши действия и их причины, измеримый результат. «Я» для своей части: «мы» только о работе команды; оценивают то, что сделали вы Одно решение подробно: ждите вопроса «почему так, а не X?» Результат в цифрах: crash-free users, время загрузки, конверсия, обращения Красные флаги: технологии без проблемы за ними, архитектура, которую вы не можете объяснить, успех команды, выданный за свой Пример Ситуация: холодный старт на бюджетных телефонах, а это наша основная аудитория, занимал почти 3 секунды Задача: я вёл работу над запуском Действия: замеры через Macrobenchmark, Baseline Profile, ленивая инициализация трёх SDK, которые запускались в Application.onCreate Результат: около 1,8 с на самом медленном тестовом телефоне, и бенчмарк в CI держит это значение

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

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

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

Интервьюер проверяет, как вы отлаживаете: как сужаете проблему, какими инструментами пользуетесь и исправляете ли причину, а не симптом. Рассказывайте по STAR и больше всего времени отдайте действиям: гипотезам, тому, как вы их проверяли, и тому, что не даст багу вернуться. Почему было сложно: только на некоторых устройствах, только под нагрузкой, нет стектрейса; скажите это сразу Поиск по шагам: краш-репорты и логи, профайлер, минимальное воспроизведение, git bisect, ложные следы, которые вы отбросили Корневая причина одной фразой: чтобы интервьюер мог уследить за мыслью Профилактика: тест, алерт или правило линтера, добавленные после Красные флаги: банальная опечатка, «не помню», баг, который нашёл коллега, исправление, которое вы не можете объяснить Пример Ситуация: Play Console показывал долю ANR выше порога плохого поведения, почти всё на дешёвых телефонах Задача: расследование взял я Действия: трейсы ANR показали, что главный поток ждёт в QueuedWork при остановке активити: десятки вызовов SharedPreferences.apply() от обёртки над аналитикой, которые медленная память сбрасывала по нескольку секунд. Я объединил записи в пакеты и перенёс эти данные в DataStore Результат: доля ANR снизилась примерно с 0,6% до 0,2%, ниже порога Play в 0,47%

Интервьюер проверяет, как вы справляетесь с фрагментацией Android: сужаете проблему по производителю, модели и версии ОС, воспроизводите её без нужного телефона на руках и исправляете для всех. Расскажите по STAR, и большую часть времени отдайте тому, как вы сужали поиск. Сузьте выборку: Crashlytics и Play Console с фильтрами по производителю, модели, версии Android и версии приложения Воспроизведите: устройство в Firebase Test Lab, телефон коллеги, запись экрана от пользователя Найдите отличие: прошивка производителя, отсутствующий системный экран или приложение, агрессивная экономия батареи, старый WebView Исправьте класс бага: та же защита на всех похожих вызовах, а не только на упавшем Предотвратите: устройства этого производителя добавляются в тестовую матрицу Красные флаги: «на моём Pixel работает», закрыть как «не воспроизводится», исправление только для одной модели Пример «Crashlytics показал ActivityNotFoundException, который на 100% приходил с телефонов Xiaomi: мы открывали системный экран настроек, которого нет в их прошивке. Я воспроизвёл баг на устройстве в Test Lab, обернул запуск интента в try/catch с запасным переходом в общие настройки и проверил остальные неявные интенты в приложении. Две модели Xiaomi попали в нашу матрицу Test Lab.»

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

Интервьюер проверяет ваши решения под давлением: сначала ли вы останавливаете ущерб, понятно ли сообщаете и только потом ли ищете причину. Пройдите по порядку: как заметили всплеск, остановили раскатку, сообщили людям, нашли причину, исправили и что изменилось после. Заметить быстро: алерт на crash-free users по версии, а не случайный взгляд на дашборд Сначала остановить, потом разбираться: на 5% остановка стоит мало, а ожидание стоит пользователей Одно сообщение всем затронутым: масштаб, что вы сделали, когда будет следующий апдейт; поддержке это тоже нужно Исправить и аккуратно продолжить: хотфикс проходит те же этапы Короткий разбор без поиска виноватых: почему тесты и ранние этапы это пропустили, и одно конкретное изменение Красные флаги: докатить до 100% и посмотреть, вдруг само пройдёт, тихое исправление, о котором никто не знает, обвинить автора кода Пример «На 5% доля crash-free users за несколько часов упала с 99,7% до 99,1%. Я остановил раскатку и написал в релизный канал. Краши шли с нового экрана, который восстанавливался после смерти процесса без нужного аргумента. Я исправил это, добавил тест, пересоздающий активити через ActivityScenario.recreate(), и на следующий день мы продолжили раскатку. Ещё мы добавили алерт, чтобы такое падение будило ответственного за релиз.»

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

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

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

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

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

Интервьюер проверяет, говорите ли вы на языке бизнеса и умеете ли расставлять приоритеты, вместо того чтобы просить всё переписать. Переведите долг в цену, которую бизнес уже ощущает (медленные фичи, инциденты, потерянные пользователи), предложите небольшой измеримый план и отчитайтесь о результате. Измерьте боль: время на типичную фичу, баги за релиз в этой части, инциденты, время сборки, умноженное на команду Приоритет по цене: важен долг в коде, который часто меняется; старый стабильный код может оставаться некрасивым Понемногу и постоянно: фиксированная доля каждого спринта или чистка вместе со следующей фичей в этой части, а не заморозка на три месяца Покажите эффект: цифры до и после облегчают следующую просьбу Красные флаги: «код некрасивый» как аргумент, просьба переписать всё, работа, спрятанная в оценки фич Пример «Чистая сборка занимала девять минут. Build scans показали, что на десяти разработчиках мы теряем больше рабочего дня каждую неделю. Эта цифра дала нам два спринта на переход с kapt на KSP и включение configuration cache, и сборка сократилась примерно до четырёх минут.»

Интервьюер проверяет, умеете ли вы вести изменения через доказательства и людей, а не через авторитет или энтузиазм. Покажите, как вы выслушали возражения, проверили идею на малом, измерили результат, упростили старт и сохранили постепенность. Выслушайте возражения: производительность, время на обучение, совместимость с существующими View, найм; на каждое нужен ответ Небольшой пилот с цифрами: один экран, время его разработки, объём и баги, плюс проверка производительности через Macrobenchmark Снизьте цену старта: эталонный экран, договорённости по состоянию и навигации, парная работа над первым экраном каждого разработчика Постепенно и по правилу: новые экраны на Compose, старые только когда их затрагивают; ComposeView и AndroidView на границе Примите «пока нет»: если цифры не в пользу идеи, честное признание строит доверие к следующему предложению Красные флаги: переписать экраны в одиночку за выходные и поставить всех перед фактом, «Google рекомендует» как единственный аргумент Пример «Двое старших коллег опасались за производительность прокрутки в Compose. Я переделал один экран с тяжёлыми списками и измерил обе версии через Macrobenchmark; после добавления стабильных ключей время кадров различалось всего на несколько процентов. Я поделился цифрами и коротким гайдом, сделал в паре с каждым коллегой первый экран, и мы договорились, что новые экраны будут на Compose. Через полгода данные спринтов показали, что новые экраны делаются примерно на треть быстрее.»