Вы принимаете команду из 12 инженеров за две недели до планирования Q3; руководство ждёт обязательный план через 10 рабочих дней, но в бэклоге 46 неоценённых задач. Какой рабочий артефакт вы подготовите?

Я подготовлю одностраничный квартальный план с явными результатами, мощностью команды, ответственными и диапазонами уверенности. - В дни 1-3 я оценю с техлидом и продакт-менеджером только 12 возможных результатов в размерах S, M и L, а не все 46 задач. - Я заложу для всех 12 инженеров 80% плановой загрузки: 9,6 эквивалента инженера на роудмап и 2,4 на поддержку, отпуска и внеплановую работу по данным прошлого квартала. - В одном документе я зафиксирую три обязательных результата, два дополнительных, владельцев решений и еженедельное обновление уверенности.

Продакт-партнёр предлагает для команды из 9 инженеров OKR на Q4: «выпустить шесть корпоративных функций»; сейчас продление составляет 78%, цель на 12 недель составляет 85%. Как вы перепишете OKR?

Я заменю количество релизов результатом по продлениям, а набор функций оформлю как проверяемую гипотезу, а не цель. - Запаздывающим ключевым результатом станет рост фактической доли продлений с 78% до 85% среди клиентов с окончанием договора в Q4. - Намерение продлить подписку останется отдельным опережающим показателем: рост на 10 процентных пунктов от опроса 1-й недели при снижении связанных обращений на 30%. - Шесть функций останутся инициативами; для двух целевых сценариев нужен уровень недельного использования 60%, а опережающие данные будут проверяться на 4-й и 8-й неделе.

После отпусков у команды из 10 инженеров есть 120 инженер-недель на следующий квартал; продукт просит 100 недель на функции, надёжность требует 30, а инструменты разработки ещё 20. Как вы распределите мощность?

Я распределю мощность по измеримому риску и явно покажу, что не поместится, вместо попытки втиснуть 150 недель в 120. - Я зарезервирую 30 недель на надёжность, потому что реестр рисков связывает эту работу с согласованной доступностью 99,9%. - Сначала я выделю одну неделю на проверку инструментов, а остальные 14 только при экономии минимум 40 часов команды в неделю по телеметрии, что даёт окупаемость примерно за 15 недель. - Предварительно я ограничу функции 75 неделями, покажу снятые 25 недель и верну зарезервированную мощность инструментов, если проверка не достигнет порога.

За последние два квартала внеплановая работа заняла 18% и 27% мощности команды из 11 инженеров; планирование Q1 начинается на следующей неделе, а финансам нужна одна дата поставки. Как задать резерв?

Я заложу резерв 25% и представлю дату поставки как диапазон уверенности, связанный с еженедельным расходом резерва. - Я классифицирую внеплановую работу за прошлые 26 недель на поддержку, комплаенс и запросы зависимых команд, чтобы резерв опирался на повторяющийся спрос. - В обязательный план войдёт 75% мощности; финансам я дам даты P50 и P80, причём внешним обещанием станет P80. - Каждую пятницу я буду проверять расход резерва и за 48 часов пересматривать объём, если скользящая доля внеплановой работы за четыре недели превысит 25%.

Команда из 8 инженеров может выполнить либо 10-недельную миграцию биллинга с сохранением $400 000 выручки, либо три эксперимента роста с оценкой $180 000 каждый, но данные есть только по одному. План Q2 нужен через пять дней. Что вы возьмёте в обязательства?

Я возьму в обязательства миграцию биллинга и ограниченную по времени проверку экспериментов, а не буду считать неподтверждённый рост занятой мощностью. - Я подтвержу с финансами риск потери $400 000 и внесу 10-недельную миграцию в обязательный роудмап с одним ответственным техлидом. - Я выделю одну инженер-неделю на инструментацию и проверку сильнейшего эксперимента в недели 1-2 с письменным порогом не менее $250 000 ожидаемой годовой ценности. - Два других эксперимента останутся необязательными вариантами; распределение изменится на контрольной точке 3-й недели только при достижении порога.

В начале 13-недельного квартала у команды из 14 человек есть четыре результата роудмапа с уверенностью 90%, 70%, 55% и 40%; продажи хотят завтра показать все четыре как обязательные в клиентской презентации. Что вы сделаете?

Я возьму в обязательства только результаты с 90% и 70%, а остальные покажу как варианты с датами и явными условиями подтверждения. - Первые два результата попадут в клиентскую презентацию с текущей уверенностью, окнами поставки и владельцами, но без неподтверждённой метки P80 или точных дат. - Для пункта с 55% я потребую готовый прототип к 3-й неделе, а для пункта с 40% решение зависимости от внешнего API к 4-й неделе. - Я дам продажам еженедельную таблицу уверенности и заранее согласую, что в клиентские обещания входят только пункты с 70% и выше.

Один из результатов Q3 зависит от API другой команды к 6-й неделе; в их плане указана уверенность 60%, а при задержке ваши 9 инженеров потеряют 24 инженер-дня. Что вы добавите в операционную модель?

Я превращу зависимость в совместный этап с ранним контрактным тестом и профинансированным запасным вариантом. - Ко 2-й неделе я согласую схему API и проходящий consumer-driven контрактный тест с одним владельцем от каждой команды. - Я зарезервирую 10 инженер-дней на адаптер к текущему API, а оставшиеся 14 освобожу только после прохождения этапа 2-й недели. - Я запишу зависимость, уверенность 60%, дату решения и запасной вариант в оба квартальных плана и буду проверять их дважды в неделю до 6-й недели.

На 5-й неделе 12-недельного квартала юристы добавляют обязательное требование на 18 инженер-недель со сроком к 11-й неделе; команда из 12 инженеров уже потратила 42% обязательной мощности. Как вы перепланируете работу за 48 часов?

Я проведу письменное перепланирование и профинансирую юридический срок снятием менее ценной работы, а не скрытым ростом загрузки. - В первые 8 часов я запрошу у юристов подписанные критерии приёмки и разделю требование на обязательные и переносимые меры. - Я сопоставлю оставшуюся мощность с 18 неделями спроса, приостановлю наименее ценный результат и сохраню резерв 20%. - За 48 часов я опубликую новую таблицу результатов, вытесненную ценность, даты P80 и согласования продукта и юристов.

Внутренней платформенной команде из 10 инженеров нужно поставить цели на Q1, но прямой метрики выручки нет; ожидание сборки составляет 22 минуты, а платформой еженедельно пользуются 38% из 160 инженеров. Какие OKR вы выберете на 12 недель?

Я привяжу цели к использованию платформы и сэкономленному времени, а надёжность сделаю ограничивающей метрикой. - Я поставлю рост недельного использования с 38% до 60% среди 160 инженеров и определю активного пользователя как завершившего один платформенный сценарий. - Я сокращу медианное ожидание сборки с 22 до 12 минут и посчитаю возвращённые инженер-часы по телеметрии CI. - При росте использования я сохраню доступность платформы 99,9% и ограничу увеличение неуспешных сборок двумя процентами.

После 13-недельного квартала команда из 11 инженеров завершила 7 из 9 пунктов роудмапа, но улучшился только один из трёх клиентских результатов. Что вы включите в квартальный обзор, который нужно представить через 30 минут?

Я начну с разрыва по результатам и использую данные поставки для объяснения решений, а не назову 7 из 9 успехом. - Я покажу базу, цель и факт по всем трём клиентским результатам рядом с девятью выполненными и невыполненными пунктами. - По данным использования и клиентским интервью я отмечу две неверные гипотезы, назначу владельца и двухнедельную проверку для каждой. - В следующий квартал перейдёт только подтверждённая данными работа, а в процесс я добавлю одно изменение, например проверку результатов на 4-й неделе.

Вам нужно написать годовые оценки для 13 инженеров за 15 рабочих дней; шаблон требует описать влияние, поведение и рост, но записи по проектам покрывают только последние четыре месяца. Как собрать защищаемые доказательства?

Я соберу пакет доказательств для каждого инженера и отделю наблюдаемые факты от менеджерской оценки. - Я соберу за 12 месяцев результаты проектов, владение дизайном, вклад в ревью и отзывы клиентов или партнёров в датированную таблицу. - Я попрошу инженера и двух постоянных коллег привести примеры по одной грейдовой матрице, а затем проверю утверждения по артефактам, а не популярности. - Оценки я выставлю только после проверки пробелов с техлидом и отмечу любой вывод, основанный менее чем на двух независимых примерах.

На калибровке 42 инженеров ваша команда из 12 человек предлагает пять высших оценок, тогда как в соседних командах в среднем одна; у вас 20 минут и лимит шесть слайдов. Как вы защитите или измените оценки?

Я сопоставлю каждый случай с общими ориентирами уровня и сохраню только оценки, подтверждённые устойчивым масштабом и влиянием. - На каждом слайде будут ожидания уровня, два датированных примера, измеримый результат и конкретный вклад сотрудника вместо результата всей команды. - Я проверю все пять случаев по той же планке, что и соседние команды, и понижу предложение, если доказательство показывает один яркий эпизод вместо устойчивой работы. - В течение 24 часов я внесу решения калибровки и пробелы в систему оценки, чтобы финальные тексты соответствовали обсуждению.

Инженер среднего уровня просит повышение до senior в следующем цикле через 8 недель; он вёл 6-недельную миграцию, но почти не показал влияния за пределами 2 коллег. Какой план повышения вы составите?

Я объясню, что за восемь недель нельзя искусственно создать устойчивые доказательства уровня senior, и спланирую следующую честную точку оценки без обещания повышения. - Я сопоставлю последние 6-12 месяцев с матрицей senior и запишу, что техническая поставка доказана, а повторяющееся лидерство в межкомандных решениях нет. - Я дам инженеру обычное владение частью роудмапа с двумя партнёрскими командами, но сочту RFC и результат только одним фактом, а не специальным заданием ради повышения или голосованием за популярность. - Я подам кейс лишь после нескольких датированных примеров устойчивого масштаба и влияния следующего уровня; иначе зафиксирую пробел и продолжу план в следующем цикле.

Комитет спрашивает, почему ваш техлид должен перейти на уровень staff после девяти месяцев в роли; пакет ограничен 1200 словами и тремя артефактами. Какие доказательства вы выберете?

Я выберу доказательства устойчивого межкомандного усиления, а не объём кода или уже полученный титул. - Первым артефактом станет RFC, принятый тремя командами, с решениями лида и измеримым эффектом, например снижением времени интеграции на 25%. - Второй артефакт покажет созданную им способность других: например, два инженера за шесть месяцев самостоятельно возглавили последующие дизайны. - Третьим станет решение по роудмапу или риску, где его влияние изменило результат, с отзывами названных стейкхолдеров и данными до и после.

Два менеджера по-разному оценивают инженера общего проекта после 10-недельной инициативы: «соответствует» и «превышает»; калибровка через три дня, а матрица содержит четыре измерения. Как устранить расхождение доказательств?

Я сверю оценки по каждому измерению и общим артефактам до спора об итоговом ярлыке. - Я попрошу обоих менеджеров отдельно оценить четыре измерения и привести датированные примеры поведения из 10-недельного проекта. - По журналу решений, истории ревью и отзывам партнёров я отделю личный вклад инженера от результата проекта. - До калибровки я запишу согласованную оценку, один нерешённый пробел и план наблюдения на следующий цикл в карточке оценки.

За шестимесячный цикл офисные инженеры получили в среднем 4,3, а четыре удалённых инженера 3,4 при похожих данных поставки; калибровка начнётся через неделю. Какой аудит вы проведёте?

Я проведу аудит на эффект видимости и исправлю оценки, не подтверждённые сопоставимыми доказательствами. - Я сравню оценки по месту работы внутри одинакового уровня, стажа, масштаба проекта и четырёх измерений матрицы, а не только сырые средние. - Для каждого инженера я выберу два артефакта и два отзыва стейкхолдеров, включая асинхронный дизайн и поддержку, незаметные на встречах. - На калибровке я покажу обезличенные закономерности и потребую переписать или изменить оценки с разным стандартом доказательств по месту работы.

Ваш единственный техлид перейдёт в другую команду через 12 недель; в команде из 10 инженеров есть два возможных преемника, но ни один не владел квартальным планированием. Какой артефакт преемственности вы создадите?

Я создам 12-недельную карту преемственности с делегированными решениями и явной датой передачи роли. - Я определю пять навыков лида: планирование, качество технических решений, риск поставки, коммуникация со стейкхолдерами и развитие коллег, с наблюдаемыми доказательствами для каждого. - Кандидат A подготовит следующий план, кандидат B проведёт обзор зависимостей, а через четыре недели они поменяются теневыми ролями. - На 8-й неделе я выберу преемника по карте, опубликую четырёхнедельный чек-лист передачи и назначу резерв на следующие шесть месяцев.

Старший инженер хочет стать техлидом за шесть месяцев; его технические решения сильны, но он провёл только один кросс-функциональный обзор для команды из 11 человек. Как проверить готовность?

Я применю шестимесячный план готовности с реальными обратимыми лидерскими задачами и ежемесячной проверкой доказательств. - В месяцы 1-2 инженер проведёт два дизайн-ревью и опубликует решения за 24 часа; результат измеряется ясностью для стейкхолдеров, а не посещаемостью. - В месяцы 3-4 он возьмёт одну зависимость роудмапа с продуктом, дизайном и другой инженерной командой, а текущий лид останется только ревьюером. - В месяцы 5-6 он проведёт часть планирования для четырёх инженеров, после чего я оценю готовность по письменной карте и отзывам минимум пяти партнёров.

Корпоративный цикл оценки занимает у каждого из шести менеджеров около 30 часов раз в полгода, а 35% текстов возвращают из-за отсутствия доказательств. У вас есть один цикл на улучшение системы. Что вы измените?

Я стандартизирую сбор доказательств до написания текстов и в следующем цикле измерю время менеджеров и долю возвратов. - Я введу ежемесячный журнал по четырём измерениям матрицы со ссылками на артефакты и лимитом 10 минут на сотрудника. - За шесть недель до калибровки я проведу проверку полноты пакетов и взаимное ревью 20% выборки по единому чек-листу. - Цели следующего цикла: менее 20 часов менеджера и менее 10% возвратов; любое поле шаблона, не влияющее на решения, будет удалено.

После калибровки сильный инженер среднего уровня второй 6-месячный цикл остаётся на оценке «соответствует» и спрашивает, что отличает «превышает»; матрица содержит 5 широких формулировок. Какой артефакт вы дадите ему за 1 неделю?

Я дам 90-дневный план доказательств с двумя наблюдаемыми результатами, а не длинный список общих ожиданий. - Я сведу пять формулировок к двум текущим пробелам, например самостоятельному устранению зависимости и росту результата двух коллег. - Для каждого пробела я укажу одну 90-дневную задачу, базовую метрику, ожидаемый артефакт и еженедельный источник доказательств. - Мы проверим факты на 30-й, 60-й и 90-й день, явно указав, что выполнение действий не гарантирует следующую оценку.

Вопросы на собеседовании: Инженерный менеджер

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Старший инженерный менеджер.

Смотреть пример резюме: Инженерный менеджер →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

backlogownershipartifacts

Я подготовлю одностраничный квартальный план с явными результатами, мощностью команды, ответственными и диапазонами уверенности.

В дни 1-3 я оценю с техлидом и продакт-менеджером только 12 возможных результатов в размерах S, M и L, а не все 46 задач.
Я заложу для всех 12 инженеров 80% плановой загрузки: 9,6 эквивалента инженера на роудмап и 2,4 на поддержку, отпуска и внеплановую работу по данным прошлого квартала.
В одном документе я зафиксирую три обязательных результата, два дополнительных, владельцев решений и еженедельное обновление уверенности.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат превратить неполные вводные в реалистичный квартальный договор без ложной точности.

okrs

Я заменю количество релизов результатом по продлениям, а набор функций оформлю как проверяемую гипотезу, а не цель.

Запаздывающим ключевым результатом станет рост фактической доли продлений с 78% до 85% среди клиентов с окончанием договора в Q4.
Намерение продлить подписку останется отдельным опережающим показателем: рост на 10 процентных пунктов от опроса 1-й недели при снижении связанных обращений на 30%.
Шесть функций останутся инициативами; для двух целевых сценариев нужен уровень недельного использования 60%, а опережающие данные будут проверяться на 4-й и 8-й неделе.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат связывать инженерную работу с измеримым результатом для клиента и сохранять ответственность.

capacity-planningreliabilitycapacity

Я распределю мощность по измеримому риску и явно покажу, что не поместится, вместо попытки втиснуть 150 недель в 120.

Я зарезервирую 30 недель на надёжность, потому что реестр рисков связывает эту работу с согласованной доступностью 99,9%.
Сначала я выделю одну неделю на проверку инструментов, а остальные 14 только при экономии минимум 40 часов команды в неделю по телеметрии, что даёт окупаемость примерно за 15 недель.
Предварительно я ограничу функции 75 неделями, покажу снятые 25 недель и верну зарезервированную мощность инструментов, если проверка не достигнет порога.

Зачем это спрашивают: Интервьюер оценивает дисциплину распределения мощности и умение показывать альтернативную стоимость на фактах.

Я заложу резерв 25% и представлю дату поставки как диапазон уверенности, связанный с еженедельным расходом резерва.

Я классифицирую внеплановую работу за прошлые 26 недель на поддержку, комплаенс и запросы зависимых команд, чтобы резерв опирался на повторяющийся спрос.
В обязательный план войдёт 75% мощности; финансам я дам даты P50 и P80, причём внешним обещанием станет P80.
Каждую пятницу я буду проверять расход резерва и за 48 часов пересматривать объём, если скользящая доля внеплановой работы за четыре недели превысит 25%.

Зачем это спрашивают: Интервьюер проверяет, использует ли кандидат историю спроса для устойчивых обязательств вместо сокрытия неопределённости.

experimentsmigrationsestimation

Я возьму в обязательства миграцию биллинга и ограниченную по времени проверку экспериментов, а не буду считать неподтверждённый рост занятой мощностью.

Я подтвержу с финансами риск потери $400 000 и внесу 10-недельную миграцию в обязательный роудмап с одним ответственным техлидом.
Я выделю одну инженер-неделю на инструментацию и проверку сильнейшего эксперимента в недели 1-2 с письменным порогом не менее $250 000 ожидаемой годовой ценности.
Два других эксперимента останутся необязательными вариантами; распределение изменится на контрольной точке 3-й недели только при достижении порога.

Зачем это спрашивают: Интервьюер оценивает портфельное решение при ограниченной мощности и разном качестве доказательств.

roadmaproadmapping

Я возьму в обязательства только результаты с 90% и 70%, а остальные покажу как варианты с датами и явными условиями подтверждения.

Первые два результата попадут в клиентскую презентацию с текущей уверенностью, окнами поставки и владельцами, но без неподтверждённой метки P80 или точных дат.
Для пункта с 55% я потребую готовый прототип к 3-й неделе, а для пункта с 40% решение зависимости от внешнего API к 4-й неделе.
Я дам продажам еженедельную таблицу уверенности и заранее согласую, что в клиентские обещания входят только пункты с 70% и выше.

Зачем это спрашивают: Интервьюер проверяет, защищает ли кандидат доверие к поставке и одновременно даёт коммерческой команде полезную информацию.

api

Я превращу зависимость в совместный этап с ранним контрактным тестом и профинансированным запасным вариантом.

Ко 2-й неделе я согласую схему API и проходящий consumer-driven контрактный тест с одним владельцем от каждой команды.
Я зарезервирую 10 инженер-дней на адаптер к текущему API, а оставшиеся 14 освобожу только после прохождения этапа 2-й недели.
Я запишу зависимость, уверенность 60%, дату решения и запасной вариант в оба квартальных плана и буду проверять их дважды в неделю до 6-й недели.

Зачем это спрашивают: Интервьюер оценивает, управляет ли кандидат зависимостями через артефакты, контрольные точки и мощность, а не через погоню за статусами.

capacity-planningcapacity

Я проведу письменное перепланирование и профинансирую юридический срок снятием менее ценной работы, а не скрытым ростом загрузки.

В первые 8 часов я запрошу у юристов подписанные критерии приёмки и разделю требование на обязательные и переносимые меры.
Я сопоставлю оставшуюся мощность с 18 неделями спроса, приостановлю наименее ценный результат и сохраню резерв 20%.
За 48 часов я опубликую новую таблицу результатов, вытесненную ценность, даты P80 и согласования продукта и юристов.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат прозрачно принять жёсткое ограничение без скрытого превышения обязательств.

monitoring

Я привяжу цели к использованию платформы и сэкономленному времени, а надёжность сделаю ограничивающей метрикой.

Я поставлю рост недельного использования с 38% до 60% среди 160 инженеров и определю активного пользователя как завершившего один платформенный сценарий.
Я сокращу медианное ожидание сборки с 22 до 12 минут и посчитаю возвращённые инженер-часы по телеметрии CI.
При росте использования я сохраню доступность платформы 99,9% и ограничу увеличение неуспешных сборок двумя процентами.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат задавать измеримые результаты для платформенной команды без выдуманной связи с выручкой.

roadmaproadmapping

Я начну с разрыва по результатам и использую данные поставки для объяснения решений, а не назову 7 из 9 успехом.

Я покажу базу, цель и факт по всем трём клиентским результатам рядом с девятью выполненными и невыполненными пунктами.
По данным использования и клиентским интервью я отмечу две неверные гипотезы, назначу владельца и двухнедельную проверку для каждой.
В следующий квартал перейдёт только подтверждённая данными работа, а в процесс я добавлю одно изменение, например проверку результатов на 4-й неделе.

Зачем это спрашивают: Интервьюер проверяет, отличает ли кандидат выпуск от влияния и превращает ли обзор в улучшение системы следующего квартала.

Я соберу пакет доказательств для каждого инженера и отделю наблюдаемые факты от менеджерской оценки.

Я соберу за 12 месяцев результаты проектов, владение дизайном, вклад в ревью и отзывы клиентов или партнёров в датированную таблицу.
Я попрошу инженера и двух постоянных коллег привести примеры по одной грейдовой матрице, а затем проверю утверждения по артефактам, а не популярности.
Оценки я выставлю только после проверки пробелов с техлидом и отмечу любой вывод, основанный менее чем на двух независимых примерах.

Зачем это спрашивают: Интервьюер оценивает, способен ли кандидат подготовить справедливые и проверяемые оценки при неполной памяти и разной видимости работы.

calibration

Я сопоставлю каждый случай с общими ориентирами уровня и сохраню только оценки, подтверждённые устойчивым масштабом и влиянием.

На каждом слайде будут ожидания уровня, два датированных примера, измеримый результат и конкретный вклад сотрудника вместо результата всей команды.
Я проверю все пять случаев по той же планке, что и соседние команды, и понижу предложение, если доказательство показывает один яркий эпизод вместо устойчивой работы.
В течение 24 часов я внесу решения калибровки и пробелы в систему оценки, чтобы финальные тексты соответствовали обсуждению.

Зачем это спрашивают: Интервьюер проверяет защиту решений на фактах и готовность исправить завышение оценок внутри своей команды.

promotionmigrations

Я объясню, что за восемь недель нельзя искусственно создать устойчивые доказательства уровня senior, и спланирую следующую честную точку оценки без обещания повышения.

Я сопоставлю последние 6-12 месяцев с матрицей senior и запишу, что техническая поставка доказана, а повторяющееся лидерство в межкомандных решениях нет.
Я дам инженеру обычное владение частью роудмапа с двумя партнёрскими командами, но сочту RFC и результат только одним фактом, а не специальным заданием ради повышения или голосованием за популярность.
Я подам кейс лишь после нескольких датированных примеров устойчивого масштаба и влияния следующего уровня; иначе зафиксирую пробел и продолжу план в следующем цикле.

Зачем это спрашивают: Интервьюер оценивает честную поддержку, применение грейдовой матрицы и соответствие задачи реальному пробелу для повышения.

promotionartifacts

Я выберу доказательства устойчивого межкомандного усиления, а не объём кода или уже полученный титул.

Первым артефактом станет RFC, принятый тремя командами, с решениями лида и измеримым эффектом, например снижением времени интеграции на 25%.
Второй артефакт покажет созданную им способность других: например, два инженера за шесть месяцев самостоятельно возглавили последующие дизайны.
Третьим станет решение по роудмапу или риску, где его влияние изменило результат, с отзывами названных стейкхолдеров и данными до и после.

Зачем это спрашивают: Интервьюер оценивает понимание влияния уровня staff и умение собрать краткий кейс на повышение.

calibrationperformance-rubric

Я сверю оценки по каждому измерению и общим артефактам до спора об итоговом ярлыке.

Я попрошу обоих менеджеров отдельно оценить четыре измерения и привести датированные примеры поведения из 10-недельного проекта.
По журналу решений, истории ревью и отзывам партнёров я отделю личный вклад инженера от результата проекта.
До калибровки я запишу согласованную оценку, один нерешённый пробел и план наблюдения на следующий цикл в карточке оценки.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат выравнивать оценки через доказательства, а не через авторитет или усреднённый компромисс.

calibration

Я проведу аудит на эффект видимости и исправлю оценки, не подтверждённые сопоставимыми доказательствами.

Я сравню оценки по месту работы внутри одинакового уровня, стажа, масштаба проекта и четырёх измерений матрицы, а не только сырые средние.
Для каждого инженера я выберу два артефакта и два отзыва стейкхолдеров, включая асинхронный дизайн и поддержку, незаметные на встречах.
На калибровке я покажу обезличенные закономерности и потребую переписать или изменить оценки с разным стандартом доказательств по месту работы.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат обнаружить и исправить эффект близости конкретным процессом оценки.

succession-planningartifactsquarterly-planning

Я создам 12-недельную карту преемственности с делегированными решениями и явной датой передачи роли.

Я определю пять навыков лида: планирование, качество технических решений, риск поставки, коммуникация со стейкхолдерами и развитие коллег, с наблюдаемыми доказательствами для каждого.
Кандидат A подготовит следующий план, кандидат B проведёт обзор зависимостей, а через четыре недели они поменяются теневыми ролями.
На 8-й неделе я выберу преемника по карте, опубликую четырёхнедельный чек-лист передачи и назначу резерв на следующие шесть месяцев.

Зачем это спрашивают: Интервьюер проверяет, создаёт ли кандидат непрерывность лидерства через наблюдаемую работу, а не неформальное предпочтение.

cross-functionalcross-teamhealth-checks

Я применю шестимесячный план готовности с реальными обратимыми лидерскими задачами и ежемесячной проверкой доказательств.

В месяцы 1-2 инженер проведёт два дизайн-ревью и опубликует решения за 24 часа; результат измеряется ясностью для стейкхолдеров, а не посещаемостью.
В месяцы 3-4 он возьмёт одну зависимость роудмапа с продуктом, дизайном и другой инженерной командой, а текущий лид останется только ревьюером.
В месяцы 5-6 он проведёт часть планирования для четырёх инженеров, после чего я оценю готовность по письменной карте и отзывам минимум пяти партнёров.

Зачем это спрашивают: Интервьюер оценивает, развивает ли кандидат лида через настоящий масштаб и доказательства, а не повышение до появления опыта.

review-cyclesystem-design

Я стандартизирую сбор доказательств до написания текстов и в следующем цикле измерю время менеджеров и долю возвратов.

Я введу ежемесячный журнал по четырём измерениям матрицы со ссылками на артефакты и лимитом 10 минут на сотрудника.
За шесть недель до калибровки я проведу проверку полноты пакетов и взаимное ревью 20% выборки по единому чек-листу.
Цели следующего цикла: менее 20 часов менеджера и менее 10% возвратов; любое поле шаблона, не влияющее на решения, будет удалено.

Зачем это спрашивают: Интервьюер проверяет проектирование процесса, который снижает нагрузку оценок без потери качества решений.

calibrationperformance-rubricsolid

Я дам 90-дневный план доказательств с двумя наблюдаемыми результатами, а не длинный список общих ожиданий.

Я сведу пять формулировок к двум текущим пробелам, например самостоятельному устранению зависимости и росту результата двух коллег.
Для каждого пробела я укажу одну 90-дневную задачу, базовую метрику, ожидаемый артефакт и еженедельный источник доказательств.
Мы проверим факты на 30-й, 60-й и 90-й день, явно указав, что выполнение действий не гарантирует следующую оценку.

Зачем это спрашивают: Интервьюер оценивает, превращает ли кандидат обратную связь калибровки в конкретный план роста без обещания оценки.

Закрытые вопросы

21
За шесть месяцев нужно добавить пять инженеров к команде из 10 человек: двух senior backend, двух middle full-stack и одного SRE; рекрутинг поддерживает 18 интервью в неделю. Какой план найма вы опубликуете?
hiring
22
Воронка найма middle backend за четыре месяца показывает 400 найденных кандидатов, 120 скринингов рекрутера, 60 интервью менеджера, 24 onsite, 6 офферов и 3 принятия. За следующие 12 недель нужны четыре выхода. Где вы вмешаетесь?
funnelhiring-funnelhiring
23
За восемь недель 72% кандидатов прошли технический скрининг, но только 18% прошли onsite из четырёх интервью; заметки в среднем содержат 40 слов и часто говорят «недостаточно senior». Что вы измените до следующего понедельника?
24
Вы проектируете структурированный цикл для middle backend, который через три месяца должен владеть сервисом на 2000 запросов в секунду; цикл ограничен четырьмя интервью по 45 минут. Что вы включите?
design
25
Для роли senior frontend восемь интервьюеров предлагают проверить 17 компетенций за пять этапов, но отток кандидатов резко растёт после 3,5 часа. Цикл нужно утвердить за два дня. Как его сократить?
testing
26
За два дня до цикла из четырёх этапов кандидат на роль data engineer просит дополнительное время и материалы для скринридера; шесть интервьюеров опасаются снижения планки. Что вы сделаете?
27
12 инженеров впервые войдут в панель интервью в ближайшие 6 недель; цель найма составляет 8 кандидатов в неделю, и стажёр не может решать один. Какую программу калибровки вы проведёте?
program-managementhiringcalibration
28
После 30 кандидатов один интервьюер пропускает 80% технических скринингов, а остальные четверо в среднем 45%; все используют один 45-минутный вопрос. У вас пять дней до следующего блока интервью. Что вы сделаете?
29
На 25-минутный разбор четыре интервьюера принесли оценки 4, 3, 2 и 2 для кандидата staff; две карточки отправили после просмотра чужих оценок. Как вы проведёте решение?
30
У предпочитаемого кандидата senior engineer есть конкурирующий оффер с базой $190 000; ваш утверждённый диапазон заканчивается на $180 000, но за 48 часов можно менять бонус за выход до $20 000, опционы и дату старта. Какой оффер вы соберёте?
31
Желаемый кандидат выбирает между двумя офферами за семь дней; в заметках указано, что рост и техническое владение важнее разницы в деньгах 5%. Команда из 12 человек может предложить новый сервис, но его роудмап не утверждён. Как вы закроете кандидата?
roadmapownershiproadmapping
32
В этом квартале есть бюджет на одного сотрудника: senior engineer может увеличить мощность поставки примерно на 15%, а отдельный SRE способен вдвое сократить 12 инженер-часов еженедельной рутины по надёжности. Вакансия закроется через 10 дней. Какую роль вы откроете?
capacity-planningreliabilitycapacity
33
У команды из 13 инженеров за последние 90 дней одна поставка в неделю, lead time 18 дней, доля неуспешных изменений 22% и восстановление 9 часов; продукт просит план улучшения поставки на следующий квартал. Какие цели вы зададите?
deployment
34
Дашборд показывает средний lead time 8 дней, но за последние 60 дней медиана составляет 4 дня, а P85 равен 21 дню по 140 рабочим элементам. Что вы представите на месячном обзоре?
35
У команды из 11 инженеров 31 задача в работе, медианное время цикла выросло с 6 до 11 дней за восемь недель, а продукт сопротивляется остановке новых стартов. Какую WIP-политику вы предложите на четыре недели?
36
За последние шесть двухнедельных итераций команда из 10 инженеров завершила 52%, 91%, 64%, 87%, 58% и 83% плана; финансам нужен прогноз на 90 дней к пятнице. Как вы его построите?
iteration
37
Для 85 завершённых задач за прошлый месяц активное написание кода занимало медианно 2 дня, но весь цикл 12 дней; ожидание ревью составило 4 дня, тестирования 3. Какое изменение вы профинансируете на следующие шесть недель?
38
Основной CI-пайплайн для 12 инженеров занимает 35 минут на P50 и недетерминированно падает в 8% запусков; можно выделить двух инженеров на четыре недели. Какой план контроля вы утвердите?
ci-cd
39
Команда выпускается раз в 10 дней, хотя CI проходит за 18 минут; анализ 50 изменений показывает медианное ожидание 6 дней после одобрения из-за пакетных релизов. Какую политику вы проверите за месяц?
releasesbatch
40
Доля неуспешных изменений выросла с 9% до 17% на 120 поставках за восемь недель, а частота поставок удвоилась; руководство хочет вернуться к еженедельным релизам. Какую альтернативу вы предложите на следующий месяц?
releasesdeployment
41
У команды из 13 инженеров список из 70 пунктов технического долга, а продукт готов выделить максимум 20% из 130 инженер-недель следующего квартала. Как выбрать 26 недель?
42
После превращения времени цикла в цель команда из 9 инженеров раздробила работу на мелкие тикеты, и медиана упала на 40%, но клиентский lead time два месяца остаётся 16 дней. Как исправить дашборд?
43
Три инженера подали RFC на 18 страниц для сервиса с ожидаемыми 5000 запросов в секунду; восемь ревьюеров оставили 94 комментария за 10 дней, но решение не записано. Какой процесс RFC вы введёте для следующего обзора?
decision-makingconcurrency
44
За три дня до запуска аутентификации Security находит пробел в отзыве сессий, устранение которого займёт четыре недели; временные контроли снижают, но не убирают риск захвата аккаунта. Кто отвечает за остаточный риск?
risk-managementlaunchesauth
45
На квартальном планировании команда находит 16 технических рисков для 12-недельного роудмапа, от устаревающего SDK до ёмкости базы; руководству нужен одностраничный реестр к пятнице. Какие поля и ритм вы используете?
capacity-planningquarterly-planningroadmap
46
Роудмап команды из 10 инженеров содержит девять этапов на 14 недель и зависит от проверки безопасности, схемы команды данных и песочницы вендора; у двух зависимостей нет дат. Как сделать роудмап исполнимым?
milestonesprocurementplanning
47
Команда должна за три недели выбрать API-провайдера почты для 8 млн сообщений в месяц, доступности 99,95%, хранения данных в ЕС и потолка $6000 в месяц. Как оценить трёх вендоров?
procurementapidecision-making
48
Продление observability-вендора дорожает с $48 000 до $72 000 в год; у команды из 14 человек бюджет на инструменты $60 000, а используются только 6 из 15 лицензированных функций. Продление через 30 дней. Что вы сделаете?
procurementobservability
49
У команды из 11 инженеров есть $90 000 свободного годового бюджета; в середине года потрачено $52 000, а новые запросы на тестовые устройства, обучение и подрядчика составляют $55 000. Как распределить оставшиеся $38 000 за две недели?
50
Вендор анализа кода стоит $24 000 в год и обещает заменить 10 инженер-часов ручного ревью в неделю; закупкам нужна рекомендация за 15 рабочих дней, а в бюджете инструментов осталось $30 000. Какой процесс решения вы проведёте?
procurementconcurrency
51
На 7-й неделе 12-недельного роадмапа ваша команда из 10 инженеров завершила 40% обещанного объёма, а критический путь отстаёт на две недели. Что вы сделаете?
schedulingdependenciesscope-management
52
Через два дня после успешных интеграционных тестов партнёр выпустил неверсионированное изменение API и удалил обязательное поле; теперь 8% запросов падают, а запуск через пять дней. Как вы отреагируете?
integrationapideployment
53
Product хочет обязательную дату миграции 40 ТБ клиентских данных, но тесты не превышали 2 ТБ, а простой, поведение резидентности и время отката неизвестны. Что вы пообещаете?
rollback
54
Вы сообщили об 80% уверенности в запуске к концу квартала, но обнаруженная проблема интеграции снижает реальную вероятность до 35%, а до даты осталось 24 дня. Что вы сообщите?
probabilitycommunicationlaunches
55
Руководитель требует от вашей команды из 12 человек выпустить за шесть недель проект, оценённый в десять недель, потому что он поддерживает цель продаж на $2 млн. Как вы отработаете давление?
soft-skillsestimation
56
Стратегический клиент с 12% ARR просит отдельную ветку продукта с уникальными правилами авторизации и отчётности; команда оценивает создание в 18 инженер-недель, а поддержку в 10 недель ежегодно. Что вы сделаете?
estimationauth
57
За десять дней до запуска тестирование находит 14 дефектов, включая два с риском повреждения данных, а Marketing уже купил кампанию за $180 000. Как вы примете решение о релизе?
launchesreleasestesting
58
В каждом из последних пяти двухнедельных спринтов команда переносила 30% плана, но оценки не изменились. Как вы исправите планирование?
agileestimation
59
Support передаёт Engineering 35 обращений в месяц; каждое в среднем меняет руки трижды, а инженеры тратят шесть часов на восстановление потерянного клиентского контекста. Как исправить передачу?
escalation
60
За 48 часов до релиза остаются три блокера: 4% ошибок оплаты, незавершённая автоматизация отката и одно отсутствующее событие аналитики. Как вы проведёте решение о запуске?
releasescommunicationrollback
61
За восемь недель инженер не выполнил 5 из 8 обязательств, допустил четыре дефекта в продакшене и требует вдвое больше времени на ревью, чем коллеги. Как вы начнёте активное управление результативностью?
performance-managementperformancedefects
62
После шести недель коучинга инженер по-прежнему выполняет только 50% согласованных ожиданий. HR просит разработать 30-дневный PIP. Что вы в него включите?
coachingdesignpip
63
На калибровке компенсации вы рекомендуете инженеру повышение на 7% за выросший масштаб, но комиссия снижает его до 2%, а её таблица пропускает шесть месяцев обязанностей исполняющего лида. Как оспорить решение?
calibrationcompensationscope-management
64
Senior-инженер с пятилетним опытом на вашем продукте увольняется, и в команде из десяти человек остаётся только ещё один специалист, понимающий биллинг. Что вы сделаете в первые две недели?
65
Новый senior-сотрудник работает 60-й день, пропустил три этапа адаптации и настроил против себя двух ревьюеров, пренебрегая правилами репозитория. Что вы сделаете?
milestonesplanningonboarding
66
После роста рыночных вилок новых middle-инженеров нанимают в пределах 2% от senior-инженеров с тремя годами сильных результатов; несколько действующих сотрудников говорят о внутренней несправедливости. Что вы сделаете?
performance
67
После подачи пакетов на повышение комиссия добавляет обязательное наставничество на уровне всей организации как критерий senior, хотя его не было в опубликованной матрице цикла. Что вы сделаете?
mentoringpromotionperformance-rubric
68
Инженер оспаривает оценку ниже ожиданий, потому что закрыл на 25% больше тикетов, чем медиана команды, хотя данные ревью показывают постоянные переделки и две пропущенные обязанности владельца. Что вы скажете?
ownership
69
Senior-инженер пропустил две обязанности владельца роудмапа, но аудит нагрузки находит 14 часов в неделю неназначенной координации шести команд, которой нет в его целях. Как вы отреагируете?
roadmapownershiproadmapping
70
Двое из 11 инженеров попадают в активное управление результативностью в одном квартале, из-за чего обещанный релиз рискует потерять около 20% ёмкости. Как вы будете управлять людьми и поставкой?
risk-managementreleasesperformance
71
Для платформы данных на 40 ТБ нужно выбрать разделение по клиентам или регионам; резидентность конфликтует со сквозной аналитикой, а перенос клиентов дорожает после 20% миграции. Как вы решите?
migrationspartitioningconflict-management
72
Новый сценарий биллинга должен на следующей неделе расшириться с 10% до 50% клиентов, но у Support нет runbook, тегов обращений, тренировки в песочнице или владельца эскалации. Что вы сделаете?
escalationrunbooks
73
Design просит три недели на полировку взаимодействий, но у Engineering девять дней до срока по доступности, затрагивающей 18% пользователей. Как вы решите?
estimationdesigna11y
74
Data сообщает о росте конверсии на 6%, но Engineering находит, что эксперимент исключил 22% мобильного трафика из-за ошибки события. Product хочет запуск завтра. Что вы сделаете?
experimentslaunches
75
Два senior-инженера оба считают себя владельцами общего сервиса, а их конфликтующие изменения вызвали три отката за месяц. Как вы перезапустите владение?
ownershipconflict-managementrollback
76
После трёх аварий одни и те же три надёжных инженера взяли 36 внерабочих часов, а шестеро коллег ни одного; на следующей неделе новый рискованный запуск. Как справедливо распределить аварийную работу?
risk-managementlaunches
77
На четырёх архитектурных встречах два удалённых инженера говорили менее 5% времени, а три senior в офисе приняли все решения. Как сделать следующее решение инклюзивным, не затягивая его бесконечно?
architecture
78
Ваш техлид проигнорировал обратную связь коллег в трёх RFC подряд, и два senior-инженера перестали комментировать. Как вы вмешаетесь?
feedbackdesign
79
PM трижды обещал клиентам даты без инженерных оценок, создав 25% изменений спринта. Как вы восстановите рабочее соглашение?
agilepromisesestimation
80
Product, Design и Engineering за две недели до запуска считают главными разные проблемы: активацию, удобство и crash rate 1,8%. Как вы примете одно решение?
activationdesignlaunches
81
Ошибки checkout растут с 0,4% до 35% через десять минут после деплоя, затрагивая заказы примерно на $20 000 в минуту. Что вы сделаете как менеджер?
deployment
82
Ротация из восьми инженеров получает 18 значимых алертов в неделю, включая шесть с полуночи до 6 утра, и двое хотят уйти из on-call. Что вы измените?
on-call
83
Критичный инцидент длится шесть часов, смена incident commander в одном часовом поясе заканчивается, восстановление не завершено, а входящей команде не хватает контекста. Как передать командование?
incident-managementincident-commandincidents
84
На постмортеме логи деплоя показывают изменение в 14:02, клиентские ошибки начинаются в 14:07, сообщение в чате появляется в 14:11, а два инженера по-разному помнят порядок. Как восстановить временную шкалу?
postmortemdeploymentincidents
85
В прошлом квартале команда выпустила 12 регрессионных дефектов, из них 7 пришли из одного legacy-модуля ценообразования. Какое действие по надёжности вы предпримете?
pricingdefectsreliability
86
Ваш сервис показывает доступность 99,5% при обязательстве перед клиентами 99,9%, а Product хочет направить всех десятерых инженеров на функцию с прогнозом $500 000 ARR. Как вы распределите ёмкость?
capacity-planningcapacity
87
В прошлом месяце 70% алертов не требовали действий, но инженеры всё равно подтверждают каждый за пять минут. Как безопасно снизить alert fatigue?
alerting
88
Два senior-инженера обрабатывают 60% ночных инцидентов в команде из девяти человек, потому что остальным не хватает прав и уверенности. Как вы сбалансируете on-call?
incident-managementon-callincidents
89
Канареечный деплой получает 10% трафика и за восемь минут повышает ошибки API с 0,3% до 4%, но команда функции просит ещё 20 минут на изучение логов. Что вы решите?
deployment-strategiesapideployment
90
До запуска не успевают провести тест регионального переключения, но задержка нарушит срок перед клиентом; руководство просит временно принять риск надёжности. Какую записку вы потребуете?
risk-managementlaunchesreleases
91
В одной продуктовой области 12 инженеров разделены на два пода, но 65% работы ждёт одних и тех же трёх backend-специалистов. Как вы проведёте реорганизацию?
reorganization
92
Заморозка найма убирает две запланированные позиции из команды из десяти инженеров, снижая ожидаемую ёмкость на 18% после объявления роадмапа. Что вы измените?
capacity-planninghiringroadmap
93
Вы должны сократить операционный бюджет области на 15% за 30 дней без увольнений, а контракты с вендорами составляют 40% расходов. Как вы поступите?
procurement
94
Критичный identity-вендор недоступен три часа, блокируя 28% входов, а его статус-страница не даёт времени восстановления. Что вы сделаете?
procurement
95
VP начинает ранжировать отдельных инженеров по частоте деплоев, и один инженер в ответ дробит изменения на 20 крошечных деплоев в неделю. Как вы исправите неверное использование DORA-метрики?
deploymentmonitoring
96
Четырёхнедельный эксперимент с заменой code review на обязательное парное программирование увеличил lead time с 2,5 до 4,5 дня, а удовлетворённость команды упала с 7,8 до 5,9 из 10. Что вы сделаете?
experimentscode-reviewprogram-management
97
После двух пропущенных клиентских дат на 18 и 24 дня Product больше не доверяет вашему восьминедельному прогнозу. Как вы восстановите доверие стейкхолдера?
stakeholder-managementstakeholder-trustcommunication
98
После реорганизации pulse-оценка ясности падает с 8,1 до 6,0 из 10, а 7 из 12 инженеров не могут назвать владельца своего сервиса. Что вы измените?
reorganization
99
Основной вендор тестирования дважды за 30 дней был недоступен, заблокировав релизы суммарно на 19 часов, но его замена стоит шесть инженерных недель. Что вы решите?
procurementreleases
100
В продукте 180 feature flags, 47 просрочили дату удаления, у 19 нет владельца, а сочетание двух старых флагов вызвало продакшен-инцидент. Как восстановить жизненный цикл флагов?
incident-managementincidentsfeature-flags