Вы руководите 4 командами из 46 инженеров в SaaS-компании с ARR $60 млн, которой нужно добавить $12 млн ARR за следующий год и удержать валовую маржу выше 78%. Как вы сформируете инженерный портфель?

Я сначала профинансирую цель по выручке, но явно зарезервирую ресурсы на маржу и надёжность, чтобы рост не поглотил платформу. - Я разложу дефицит $12 млн по инициативам, выделю 24 инженера на две ставки с ожидаемым ARR не менее $4 млн каждая и остановлю любую из них, если через квартал квалифицированный пайплайн останется ниже $1 млн. - Я направлю 10 инженеров на инфраструктуру с согласованной CFO целью сократить годовые облачные расходы на $1,2 млн и сохранить нижнюю границу маржи 78%. - Оставшиеся 12 инженеров займутся удержанием и SLO; каждый EM будет владеть квартальным скоркардом, а я перераспределю ресурсы, если опережающий индикатор любого результата отстанет на 20%.

B2B-продукт с ARR $35 млн теряет 9% продлений enterprise-клиентов, потому что экспорт занимает 18 часов, а у ваших 38 инженеров есть два квартала, чтобы сократить время до 2 часов. Что вы приоритизируете?

Я сделаю задержку экспорта главной программой удержания на два квартала и отложу менее ценные фичи. - Вместе с Sales и Finance я оценю выручку под риском и выделю 12 инженеров, если улучшение продлений на 7 процентных пунктов защищает не менее $2,5 млн ARR. - EM команды данных будет владеть шестинедельным планом проектирования и поставки с этапами p95 времени экспорта в 8, 4 и 2 часа, записанными в портфельном документе. - Я освобожу ресурсы только после того, как p95 будет ниже 2 часов в течение 30 дней, а намерение продлить контракт вырастет минимум на 5 процентных пунктов в следующей когорте.

Компания ожидает от запуска в Европе $6 млн ARR за 18 месяцев, но локализация данных требует участия 3 из 5 команд и около 28 инженеро-месяцев. Как вы решите, включать ли запуск в роадмап?

Я одобрю запуск только тогда, когда коммерческий эффект перекроет полную стоимость разработки и эксплуатации и будет подтверждён реальным спросом. - Я сопоставлю прогноз $6 млн с 28 инженеро-месяцами по $22 000 и $600 000 годовых расходов на региональную инфраструктуру и потребую минимум трёхкратную отдачу за три года. - Единый программный документ свяжет требования к данным, поддержке, безопасности и продукту; три EM будут владеть этапами, а региональный GM будет отвечать за подписанных дизайн-партнёров. - Я профинансирую шесть недель исследования и начну разработку только при наличии 10 клиентов минимум на $2 млн квалифицированного ARR и без открытых критичных пробелов в комплаенсе.

Четыре команды из 44 инженеров тратят 82% времени на фичи, при этом доля неудачных изменений равна 19%, а годовая цель требует ускорить поставку на 25%. Как вы измените распределение ресурсов на следующие два квартала?

На два квартала я переведу портфель на 65% продуктовой разработки, 20% надёжности и 15% производительности разработчиков. - Это примерно 29, 9 и 6 инженеров; я опубликую распределение в квартальном плане, чтобы продуктовые лидеры видели точную цену сокращения фич. - EM направления надёжности будет снижать долю неудачных изменений ниже 10%, а EM платформы сократит медианное время поставки на 25% через три главные проблемы CI и окружений. - Я верну ресурсы в фичи только после того, как оба порога продержатся шесть недель подряд, иначе защищённые инвестиции сохранятся ещё на квартал.

У вас 40 инженеров и $3 млн свободного бюджета на три продуктовые ставки с прогнозом ARR $8 млн, $5 млн и $3 млн, но на следующие 9 месяцев можно укомплектовать только две. Как вы выберете?

Я ранжирую ставки по скорректированной на риск отдаче на инженера и буду финансировать две лучшие поэтапно, а не приму все прогнозы на веру. - Портфельная модель умножит ARR на подтверждённую вероятность и разделит результат на инженеро-месяцы; Finance и Product подпишут допущения и диапазон чувствительности. - Каждая выбранная ставка получит восьминедельный транш из 5 инженеров и документ с этапами по принятию пользователями, технической реализуемости и юнит-экономике. - Ставка потеряет следующий транш, если отклонится более чем на 20% по двум из трёх этапов, а ресурсы уйдут в резерв или третьему варианту.

Домен checkout с годовой выручкой $20 млн требует 14 инженеро-месяцев работы с долгом, чтобы скорость поставки фич не упала на 30% в следующем году. У вашей группы из 42 инженеров есть квартал для обоснования. Что вы сделаете?

Я профинансирую работу с долгом, если короткий этап измерений подтвердит, что предотвращённая стоимость замедления выше вложения в 14 инженеро-месяцев. - Ответственный EM за четыре недели зафиксирует время ожидания, переделки из-за дефектов и усилия на релизы, затем вместе с Finance переведёт прогнозируемые 30% замедления в задержанную выручку и стоимость труда. - Документ решения сравнит примерно $308 000 инженерных затрат по $22 000 за инженеро-месяц со стоимостью возвращённых недель роадмапа и снижения дефектов checkout. - Я одобрю поэтапную работу с целями снизить lead time на 20% и переделки на 30% за восемь недель; если обе цели не достигнуты, оставшийся объём остановится.

Запуск с ARR $4 млн зависит от команд identity, billing и analytics, но их планы создают разрыв критического пути в 7 недель внутри окна в 6 месяцев. Как вы будете управлять программой для 36 инженеров?

Я создам единый план по зависимостям и уберу семинедельный разрыв до объявления внешней даты. - Три EM нанесут поставки, интерфейсы и крайние даты старта на один документ критического пути, а один senior EM будет отвечать за результат в $4 млн. - Я переведу 4 инженеров с некритичной аналитики в identity на 10 недель, если это сократит расчётный разрыв до менее 2 недель и не нарушит действующее обязательство по SLO. - Дата станет твёрдой только после прохождения контрактных тестов всеми критичными интерфейсами и достижения 80% уверенности в графике на контрольной точке за 90 дней.

Legacy-продукт приносит $1,8 млн ARR, но занимает 9 из 48 инженеров и $700 000 годовой инфраструктуры, а клиентов можно перевести за 12 месяцев. Какое портфельное решение вы примете?

Я предложу профинансированное закрытие за 12 месяцев, потому что продукт потребляет больше ресурсов, чем оправдывает его вклад. - Вместе с Finance я сравню $1,8 млн ARR с примерно $2,7 млн годовой стоимости инженеров и $700 000 инфраструктуры и зафиксирую влияние на маржу и альтернативную стоимость. - Я выделю 4 инженеров на инструменты миграции и 2 на поддержку, а product GM будет владеть планом по каждому клиенту и месячной целью переведённого ARR. - Оставшиеся 3 инженера перейдут после миграции 80% ARR; отключение произойдёт при 95%, закрытых договорных обязательствах и остаточной стоимости ниже $100 000.

Product просит 18 из ваших 50 инженеров на AI-ассистента, который должен поднять конверсию на 4% за 6 месяцев, но в оценке нет данных о точности в production и стоимости инференса. Как вы структурируете ставку?

Я не выделю 18 инженеров, пока шестинедельная проверка не подтвердит качество конкретной задачи, приватность и безопасность, экономику и причинный рост конверсии. - Product и Engineering определят офлайн-оценку относительно текущего процесса на размеченных репрезентативных случаях с отдельными метриками для обоснованного выполнения задачи и корректного отказа, доверительными интервалами и нулём критичных сбоев безопасности. - Privacy и Security допустят тест с пользователями только после проверок минимизации, хранения и доступа к данным, prompt injection и утечек без открытых критичных находок; Finance рассчитает стоимость инференса и потребует окупаемость по валовой прибыли за 12 месяцев. - Analytics заранее зафиксирует для A/B-теста основную метрику конверсии, защитные показатели, минимально обнаружимый эффект, статистическую мощность и правило остановки; дополнительные ресурсы откроются только при надёжном эффекте и прохождении порогов стоимости и безопасности.

В середине года портфель из 45 инженеров отстаёт на 15% от цели расширения в $10 млн, а платформенная программа должна сэкономить $900 000 в год через 5 месяцев. Как вы перераспределите следующие два квартала?

Я сохраню платформенную программу, если её окупаемость остаётся убедительной, и перенаправлю менее доходные ресурсы на устранение разрыва по расширению. - Я обновлю портфельную модель фактическими данными воронки и сохраню платформенную команду, если $900 000 экономии превышают оставшуюся стоимость минимум в 2 раза за два года. - Product и соответствующие EM остановят или сократят инициативы ниже 50% планового пайплайна, чтобы высвободить 8 инженеров для двух сильнейших рычагов расширения. - В обновлённом плане будут месячные точки ARR и экономии; новое перераспределение произойдёт, если любой результат отстанет более чем на 10% два месяца подряд.

Вы принимаете 48 инженеров в 4 компонентных командах, и 70% элементов роадмапа требуют передачи работы минимум между 3 командами. Как вы измените владение за 6 месяцев?

Я перейду от компонентных команд к трём устойчивым продуктовым доменам и одной платформенной команде, выполняя переход поэтапно за шесть месяцев. - Я сопоставлю последние 50 элементов роадмапа с клиентскими доменами и поставлю цель, чтобы минимум 70% выпускала одна команда вместо нынешних 30%. - Четыре EM подготовят уставы с API, данными, SLO и правами решений; спорные границы первые 12 недель будут разбираться на еженедельном design-форуме. - Топология принята, когда межкомандные передачи упадут ниже 35%, ни в одной команде не будет больше 12 инженеров, а владение SLO будет определено для 100% сервисов.

Пять продуктовых команд из 52 инженеров тратят 28% ресурсов на повторную разработку CI, аутентификации и наблюдаемости. Вы можете создать одну платформенную команду из 8 человек. Что войдёт в её устав?

Я включу в устав три повторяющиеся возможности с измеримыми результатами для внутренних клиентов, а не бесконечную очередь заявок. - Шестинедельный аудит спроса должен подтвердить минимум 10 эквивалентов инженеров дублирования; EM платформы опубликует поддерживаемые продукты, интерфейсы и исключённые обязанности. - Роадмап первого года нацелен на self-service CI менее чем за 15 минут, стандартную аутентификацию для 90% сервисов и подключение наблюдаемости менее чем за день. - Команда сохраняет возможность только при принятии минимум 4 продуктовыми командами и снижении суммарного дублирования с 28% до менее 12% за два квартала.

У вас в прямом подчинении 4 EM на 56 инженеров; у одного EM 19 подчинённых, у другого 7, а за год компания добавит 8 инженеров. Как вы измените диапазоны управления?

Я создам ещё три роли EM и до выхода всех 8 новых сотрудников распределю будущих 64 инженеров по семи командам. - Семь EM смогут вести по 8-10 инженеров, поэтому сначала я разделю группу из 19 человек, а ещё два внутренних перехода или внешних найма синхронизирую с ростом штата. - Семь EM за 30 дней подготовят уставы команд и схему подчинения, включая обязанности tech lead, чтобы управленческое и техническое владение не пересекались неясно. - Через 90 дней изменение завершено, если у каждого инженера есть постоянный менеджер, ни у одного EM нет более 10 подчинённых, а выполнение ежемесячных 1:1 выше 90%.

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

Я сделаю каждый продуктовый домен исполнимым внутри одного регионального кластера и введу асинхронные записи решений для межрегиональных интерфейсов. - Я нанесу зависимости и перемещу владение так, чтобы минимум 80% ежедневных решений не требовали встреч за пределами шестичасового регионального окна сотрудничества. - Каждый EM будет вести журнал домена со сроком ревью 48 часов; один сменный представитель региона участвует в двухчасовом пересечении для действительно общих решений. - Структура успешна, когда медианное время решения упадёт с 9 до менее 3 дней на восемь недель, а межзональных встреч станет меньше 2 на инженера в неделю.

B2B-сервис работает 24 часа, у него 45 инженеров в UTC-8, UTC+0 и UTC+8, но каждое изменение всё ещё требует одобрения команды UTC-8. Как изменить владение и не снизить SLO 99,95%?

Я делегирую ограниченные производственные полномочия каждому региону и привяжу одобрение к риску, а не к месту. - EM сервисов определят классы изменений: низкорисковые одобряются локально, а только изменения схемы или безопасности требуют ревью двух регионов за 24 часа. - В каждом регионе должно быть 2 обученных согласующих и 10 успешно проведённых под наблюдением изменений; матрица владения и журнал аудита станут контрольным документом. - UTC-8 прекратит обычные одобрения, когда все регионы удержат долю неудачных изменений ниже 10% и SLO 99,95% в течение 60 дней.

Три команды из 34 инженеров меняют общий сервис заказов, и 40% pull request ждут ревью владельца больше 3 дней. Как вы проведёте границу?

Я отдам одной команде сквозное владение ядром заказов и предоставлю двум другим версионированные контракты. - Я изучу изменения и инциденты за 90 дней, отделю основные инварианты заказа от расширений цены и исполнения и запишу границу в уставе сервиса. - Ответственный EM получает 8 инженеров и SLO ревью в 2 рабочих дня; потребительские команды получают делегированное владение только изолированными модулями с контрактными тестами. - Переход завершён, когда 90% ревью укладываются в 2 дня, восемь недель нет несанкционированных изменений через границу, а lead time потребителей не вырос более чем на 10%.

Четыре продуктовые команды делят 6 инженеров безопасности, а встроенные назначения дублируют 35% работы по годовому роадмапу. Какую топологию вы выберете?

Я создам центральную команду security enablement с закреплёнными связными продуктов, а не навсегда встрою всех 6 специалистов. - Менеджер безопасности зарезервирует 4 инженеров на общие контроли и 2 на сменные восьминедельные продуктовые задачи по бэклогу, где каждый общий контроль нужен минимум 2 командам. - Каждый продуктовый EM отвечает за исправления в домене, а security-команда владеет стандартами, threat model и повторно используемыми инструментами с опубликованными сроками ответа. - Я сохраню модель, если дублирование упадёт с 35% до менее 15%, а 90% высокорисковых ревью будут завершаться за 5 рабочих дней в течение двух кварталов.

Группа вырастет с 36 до 50 инженеров и с 3 до 5 команд за 9 месяцев, но только 2 текущих лида готовы к менеджменту. Как вы выстроите изменение топологии?

Я буду создавать две команды по мере готовности лидерства и найма, а не разделю все домены в первый день. - План персонала откроет одну внешнюю вакансию EM сейчас, подготовит одного внутреннего лида за 90 дней и ограничит временные команды 10 инженерами. - Я сначала разделю домен с наибольшим числом передач после готовности его устава, tech lead и ядра из 6 человек; второе разделение подождёт минимум 8 недель доказательств. - Расширение завершено, когда заполнены 5 мест EM или acting manager, каждая команда имеет документированную границу, а новый сотрудник не остаётся без менеджера более 5 дней.

На следующие 2 квартала у ваших 5 инженерных команд и 47 инженеров есть только 3 product manager. Как вы распределите лидерство и сохраните скорость решений?

Я сгруппирую пять команд в три продуктовых домена и дам каждому PM один результат домена, а не распылю каждого PM на все команды. - Две пары связанных команд будут делить PM и квартальный результат, а пятая команда получит платформенный устав с её EM в роли внутреннего product lead. - Каждый домен запишет права решений PM, EM и tech lead, включая путь эскалации за 48 часов и единый приоритизированный бэклог. - Я пересмотрю модель, если время решения превысит 4 дня, незапланированная работа вырастет выше 20% или парный домен пропустит две месячные точки результата.

В 5 командах и 60 сервисах у 18 сервисов заявлены два владельца, а у 11 нет ни одного; следующий цикл планирования начинается через 6 недель. Что вы сделаете?

Я завершу пересмотр владения сервисами до планирования и не приму обязательства по критичным сервисам без владельцев. - Четыре EM за 3 недели классифицируют все 60 сервисов по бизнес-критичности, SLO, основному владельцу, потребителю и стадии жизненного цикла в едином каталоге. - Двойные заявки разрешаются по праву изменений и операционной ответственности; сервисы tier-1 без владельца получают ресурсы до новой работы, а я отвечаю за окончательные границы. - Планирование откроется, когда 100% tier-1 и 95% всех сервисов имеют одного владельца, путь эскалации и проверенный SLO, а двойных основных владельцев нет.

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

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Директор по разработке.

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

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

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

Вопросы

portfolioportfolio-managementcss

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

Я разложу дефицит $12 млн по инициативам, выделю 24 инженера на две ставки с ожидаемым ARR не менее $4 млн каждая и остановлю любую из них, если через квартал квалифицированный пайплайн останется ниже $1 млн.
Я направлю 10 инженеров на инфраструктуру с согласованной CFO целью сократить годовые облачные расходы на $1,2 млн и сохранить нижнюю границу маржи 78%.
Оставшиеся 12 инженеров займутся удержанием и SLO; каждый EM будет владеть квартальным скоркардом, а я перераспределю ресурсы, если опережающий индикатор любого результата отстанет на 20%.

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

prioritization

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

Вместе с Sales и Finance я оценю выручку под риском и выделю 12 инженеров, если улучшение продлений на 7 процентных пунктов защищает не менее $2,5 млн ARR.
EM команды данных будет владеть шестинедельным планом проектирования и поставки с этапами p95 времени экспорта в 8, 4 и 2 часа, записанными в портфельном документе.
Я освобожу ресурсы только после того, как p95 будет ниже 2 часов в течение 30 дней, а намерение продлить контракт вырастет минимум на 5 процентных пунктов в следующей когорте.

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

roadmapestimationroadmapping

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

Я сопоставлю прогноз $6 млн с 28 инженеро-месяцами по $22 000 и $600 000 годовых расходов на региональную инфраструктуру и потребую минимум трёхкратную отдачу за три года.
Единый программный документ свяжет требования к данным, поддержке, безопасности и продукту; три EM будут владеть этапами, а региональный GM будет отвечать за подписанных дизайн-партнёров.
Я профинансирую шесть недель исследования и начну разработку только при наличии 10 клиентов минимум на $2 млн квалифицированного ARR и без открытых критичных пробелов в комплаенсе.

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

capacity-planningcapacity

На два квартала я переведу портфель на 65% продуктовой разработки, 20% надёжности и 15% производительности разработчиков.

Это примерно 29, 9 и 6 инженеров; я опубликую распределение в квартальном плане, чтобы продуктовые лидеры видели точную цену сокращения фич.
EM направления надёжности будет снижать долю неудачных изменений ниже 10%, а EM платформы сократит медианное время поставки на 25% через три главные проблемы CI и окружений.
Я верну ресурсы в фичи только после того, как оба порога продержатся шесть недель подряд, иначе защищённые инвестиции сохранятся ещё на квартал.

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

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

Портфельная модель умножит ARR на подтверждённую вероятность и разделит результат на инженеро-месяцы; Finance и Product подпишут допущения и диапазон чувствительности.
Каждая выбранная ставка получит восьминедельный транш из 5 инженеров и документ с этапами по принятию пользователями, технической реализуемости и юнит-экономике.
Ставка потеряет следующий транш, если отклонится более чем на 20% по двум из трёх этапов, а ресурсы уйдут в резерв или третьему варианту.

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

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

Ответственный EM за четыре недели зафиксирует время ожидания, переделки из-за дефектов и усилия на релизы, затем вместе с Finance переведёт прогнозируемые 30% замедления в задержанную выручку и стоимость труда.
Документ решения сравнит примерно $308 000 инженерных затрат по $22 000 за инженеро-месяц со стоимостью возвращённых недель роадмапа и снижения дефектов checkout.
Я одобрю поэтапную работу с целями снизить lead time на 20% и переделки на 30% за восемь недель; если обе цели не достигнуты, оставшийся объём остановится.

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

program-managementlaunches

Я создам единый план по зависимостям и уберу семинедельный разрыв до объявления внешней даты.

Три EM нанесут поставки, интерфейсы и крайние даты старта на один документ критического пути, а один senior EM будет отвечать за результат в $4 млн.
Я переведу 4 инженеров с некритичной аналитики в identity на 10 недель, если это сократит расчётный разрыв до менее 2 недель и не нарушит действующее обязательство по SLO.
Дата станет твёрдой только после прохождения контрактных тестов всеми критичными интерфейсами и достижения 80% уверенности в графике на контрольной точке за 90 дней.

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

portfolioportfolio-management

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

Вместе с Finance я сравню $1,8 млн ARR с примерно $2,7 млн годовой стоимости инженеров и $700 000 инфраструктуры и зафиксирую влияние на маржу и альтернативную стоимость.
Я выделю 4 инженеров на инструменты миграции и 2 на поддержку, а product GM будет владеть планом по каждому клиенту и месячной целью переведённого ARR.
Оставшиеся 3 инженера перейдут после миграции 80% ARR; отключение произойдёт при 95%, закрытых договорных обязательствах и остаточной стоимости ниже $100 000.

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

estimation

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

Product и Engineering определят офлайн-оценку относительно текущего процесса на размеченных репрезентативных случаях с отдельными метриками для обоснованного выполнения задачи и корректного отказа, доверительными интервалами и нулём критичных сбоев безопасности.
Privacy и Security допустят тест с пользователями только после проверок минимизации, хранения и доступа к данным, prompt injection и утечек без открытых критичных находок; Finance рассчитает стоимость инференса и потребует окупаемость по валовой прибыли за 12 месяцев.
Analytics заранее зафиксирует для A/B-теста основную метрику конверсии, защитные показатели, минимально обнаружимый эффект, статистическую мощность и правило остановки; дополнительные ресурсы откроются только при надёжном эффекте и прохождении порогов стоимости и безопасности.

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

portfolioportfolio-managementprogram-management

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

Я обновлю портфельную модель фактическими данными воронки и сохраню платформенную команду, если $900 000 экономии превышают оставшуюся стоимость минимум в 2 раза за два года.
Product и соответствующие EM остановят или сократят инициативы ниже 50% планового пайплайна, чтобы высвободить 8 инженеров для двух сильнейших рычагов расширения.
В обновлённом плане будут месячные точки ARR и экономии; новое перераспределение произойдёт, если любой результат отстанет более чем на 10% два месяца подряд.

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

roadmapownershipcomponents

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

Я сопоставлю последние 50 элементов роадмапа с клиентскими доменами и поставлю цель, чтобы минимум 70% выпускала одна команда вместо нынешних 30%.
Четыре EM подготовят уставы с API, данными, SLO и правами решений; спорные границы первые 12 недель будут разбираться на еженедельном design-форуме.
Топология принята, когда межкомандные передачи упадут ниже 35%, ни в одной команде не будет больше 12 инженеров, а владение SLO будет определено для 100% сервисов.

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

capacity-planningauthobservability

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

Шестинедельный аудит спроса должен подтвердить минимум 10 эквивалентов инженеров дублирования; EM платформы опубликует поддерживаемые продукты, интерфейсы и исключённые обязанности.
Роадмап первого года нацелен на self-service CI менее чем за 15 минут, стандартную аутентификацию для 90% сервисов и подключение наблюдаемости менее чем за день.
Команда сохраняет возможность только при принятии минимум 4 продуктовыми командами и снижении суммарного дублирования с 28% до менее 12% за два квартала.

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

Я создам ещё три роли EM и до выхода всех 8 новых сотрудников распределю будущих 64 инженеров по семи командам.

Семь EM смогут вести по 8-10 инженеров, поэтому сначала я разделю группу из 19 человек, а ещё два внутренних перехода или внешних найма синхронизирую с ростом штата.
Семь EM за 30 дней подготовят уставы команд и схему подчинения, включая обязанности tech lead, чтобы управленческое и техническое владение не пересекались неясно.
Через 90 дней изменение завершено, если у каждого инженера есть постоянный менеджер, ни у одного EM нет более 10 подчинённых, а выполнение ежемесячных 1:1 выше 90%.

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

roadmaproadmapping

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

Я нанесу зависимости и перемещу владение так, чтобы минимум 80% ежедневных решений не требовали встреч за пределами шестичасового регионального окна сотрудничества.
Каждый EM будет вести журнал домена со сроком ревью 48 часов; один сменный представитель региона участвует в двухчасовом пересечении для действительно общих решений.
Структура успешна, когда медианное время решения упадёт с 9 до менее 3 дней на восемь недель, а межзональных встреч станет меньше 2 на инженера в неделю.

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

sloownership

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

EM сервисов определят классы изменений: низкорисковые одобряются локально, а только изменения схемы или безопасности требуют ревью двух регионов за 24 часа.
В каждом регионе должно быть 2 обученных согласующих и 10 успешно проведённых под наблюдением изменений; матрица владения и журнал аудита станут контрольным документом.
UTC-8 прекратит обычные одобрения, когда все регионы удержат долю неудачных изменений ниже 10% и SLO 99,95% в течение 60 дней.

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

code-review

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

Я изучу изменения и инциденты за 90 дней, отделю основные инварианты заказа от расширений цены и исполнения и запишу границу в уставе сервиса.
Ответственный EM получает 8 инженеров и SLO ревью в 2 рабочих дня; потребительские команды получают делегированное владение только изолированными модулями с контрактными тестами.
Переход завершён, когда 90% ревью укладываются в 2 дня, восемь недель нет несанкционированных изменений через границу, а lead time потребителей не вырос более чем на 10%.

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

roadmaproadmapping

Я создам центральную команду security enablement с закреплёнными связными продуктов, а не навсегда встрою всех 6 специалистов.

Менеджер безопасности зарезервирует 4 инженеров на общие контроли и 2 на сменные восьминедельные продуктовые задачи по бэклогу, где каждый общий контроль нужен минимум 2 командам.
Каждый продуктовый EM отвечает за исправления в домене, а security-команда владеет стандартами, threat model и повторно используемыми инструментами с опубликованными сроками ответа.
Я сохраню модель, если дублирование упадёт с 35% до менее 15%, а 90% высокорисковых ревью будут завершаться за 5 рабочих дней в течение двух кварталов.

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

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

План персонала откроет одну внешнюю вакансию EM сейчас, подготовит одного внутреннего лида за 90 дней и ограничит временные команды 10 инженерами.
Я сначала разделю домен с наибольшим числом передач после готовности его устава, tech lead и ядра из 6 человек; второе разделение подождёт минимум 8 недель доказательств.
Расширение завершено, когда заполнены 5 мест EM или acting manager, каждая команда имеет документированную границу, а новый сотрудник не остаётся без менеджера более 5 дней.

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

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

Две пары связанных команд будут делить PM и квартальный результат, а пятая команда получит платформенный устав с её EM в роли внутреннего product lead.
Каждый домен запишет права решений PM, EM и tech lead, включая путь эскалации за 48 часов и единый приоритизированный бэклог.
Я пересмотрю модель, если время решения превысит 4 дня, незапланированная работа вырастет выше 20% или парный домен пропустит две месячные точки результата.

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

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

Четыре EM за 3 недели классифицируют все 60 сервисов по бизнес-критичности, SLO, основному владельцу, потребителю и стадии жизненного цикла в едином каталоге.
Двойные заявки разрешаются по праву изменений и операционной ответственности; сервисы tier-1 без владельца получают ресурсы до новой работы, а я отвечаю за окончательные границы.
Планирование откроется, когда 100% tier-1 и 95% всех сервисов имеют одного владельца, путь эскалации и проверенный SLO, а двойных основных владельцев нет.

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

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

21
Два новых EM теперь руководят командами по 8 инженеров внутри вашей группы из 38 человек, а квартальное планирование начнётся через 10 недель. Как вы будете развивать их, не забирая решения обратно?
quarterly-planning
22
Один из ваших 4 EM через 6 месяцев уйдёт в плановый отпуск на 4 месяца, а его команда из 12 человек владеет 40% запуска стоимостью $5 млн. Как вы подготовите преемника?
succession-planninglaunches
23
Четыре EM оценивают 41 инженера, но одна команда ставит 45% высших оценок, а остальные три в среднем 12%; пересмотр компенсаций через 5 недель. Как вы проведёте калибровку?
compensation
24
Шесть из 44 инженеров предложены на повышение до senior в 4 командах, но бюджет цикла поддерживает только 3 повышения, а пакеты нужны через 30 дней. Как вы примете решение?
promotion
25
Организации из 50 инженеров нужны ещё 2 EM в течение 12 месяцев, но только 1 из 7 senior-инженеров проявил интерес к менеджменту. Как вы создадите запас лидеров?
26
Вы одобряете 70% межкомандных решений для 4 EM и 43 инженеров, из-за чего медианное ожидание равно 6 дням; в этом квартале нужно снизить его ниже 2 дней. Что вы делегируете?
cross-teamdelegation
27
Четыре EM в группе из 46 инженеров проводят по 11 часов в неделю на пересекающихся статусных встречах, а 22% квартальных зависимостей обнаруживаются после начала работы. Как вы измените управленческий ритм?
dependencies
28
Два из ваших 3 EM пришли из нетехнических ролей и руководят 30 инженерами платформы с SLO 99,95%; архитектурные ревью начнутся через 8 недель. Как вы разовьёте достаточное техническое суждение?
slo
29
Через 9 месяцев вы можете перейти в новый домен, но ни один из 4 EM пока не может вести весь портфель из 52 инженеров дольше 2 недель. Как вы подготовите преемника?
portfolioportfolio-management
30
В одной из 5 команд работают 7 из 10 senior-инженеров группы, а в двух командах с роадмапом на $7 млн есть только по одному; до планирования 45 дней. Как вы сбалансируете запас лидеров?
roadmaproadmapping
31
Ваши 4 команды из 40 инженеров запрашивают 16 сотрудников на следующий год, но Finance ограничивает рост 10 позициями и ждёт $8 млн дополнительного ARR. Как вы построите план штата?
headcount-planning
32
Вам нужно нанять 12 инженеров за 6 месяцев, но текущая воронка даёт 1 принятое предложение на 40 кандидатов, а интервьюеры могут провести только 24 полных интервью в месяц. Какие ресурсы вы запланируете?
capacity-planningcapacityfunnel
33
У группы из 50 инженеров годовой бюджет $13 млн, а Finance просит сократить расходы на 7% без уменьшения 4 обещанных продуктовых результатов. Где вы будете искать сначала?
34
Девятимесячной программе комплаенса нужны 6 инженеров; подрядчики стоят $210 в час, а штатные сотрудники $220 000 в год с полной нагрузкой, но выходят через 5 месяцев. Какую структуру найма вы выберете?
program-management
35
Пять команд оценивают создание внутреннего developer portal в 14 инженеро-лет; вендор стоит $900 000 в год плюс $350 000 внедрения за 3 года. Как вы решите, строить или покупать?
procurementestimation
36
Стоимость вендора наблюдаемости для 55 сервисов вырастет с $600 000 до $1,1 млн в год, а open-source альтернатива требует 5 инженеров на 8 месяцев и $180 000 хостинга ежегодно. Что вы сделаете?
procurementobservability
37
Восемь инженерных вендоров стоят $2,4 млн в год для 4 команд, а 3 контракта продлеваются через 90 дней без назначенных владельцев и порогов использования. Как вы установите управление?
procurementgovernance
38
Вы можете разместить 8 новых ролей в Нью-Йорке по $260 000 полной стоимости или в Варшаве по $145 000, но командам нужны 4 общих часа, а все текущие менеджеры находятся в Нью-Йорке. Что вы предложите?
39
Предлагаемая команда интеграций из 10 человек стоит $2,2 млн в год и должна открыть $5 млн ARR, но только 6 клиентов на $1,4 млн подписали письма о намерениях. Как вы оцените P&L?
40
Ваш трёхлетний план увеличивает engineering с 38 до 58 человек, зарплаты будут расти на 6% в год, а Finance ограничивает темп расходов третьего года $15 млн. Как вы проверите реализуемость?
41
Четыре команды и 48 инженеров создают 25 архитектурных предложений в квартал, но ревью занимает медианные 18 дней, а 30% предложений открываются снова после начала реализации. Как вы измените RFC?
governancearchitecturedecision-making
42
В 5 командах и 70 репозиториях только 38% соответствуют базовым требованиям безопасности и тестирования компании, а за 2 квартала нужно достичь 90% без центральной команды переписывания. Что вы сделаете?
testing
43
Тридцать шесть продуктовых инженеров развёртывают сервисы в Kubernetes, но ревью платформы обязательно для каждого изменения и добавляет 4 дня к lead time в 9 дней. Как вы замените ревью ограничителями?
kubernetesdeploymentguardrails
44
Ваши 5 команд сообщают частоту развёртываний от ежедневной до ежемесячной, но определения различаются, а CEO хочет портфельный обзор DORA через 60 дней. Что вы опубликуете?
portfolioportfolio-managementdeployment
45
У 60 сервисов в 4 командах 22 разных цели доступности от 99% до 99,99%, и только 15 используют бюджеты ошибок; за 2 квартала нужно ввести портфельное управление SLO. Что вы сделаете?
portfolioportfolio-managementreliability
46
Организация из 50 инженеров должна поддержать трёхкратный объём транзакций за 30 месяцев, снизить стоимость инфраструктуры на транзакцию на 25% и сохранить доступность 99,95%. Как вы построите технический роадмап?
roadmaptransactionsroadmapping
47
Через два года после обязательного внедрения event sourcing для всех транзакционных сервисов его используют 31 из 44 сервисов, lead time изменений ухудшился на 35%, а 6 из последних 9 инцидентов были связаны со сложностью повторного воспроизведения. Как вы отзовёте широко принятый стандарт?
incidentsdecision-makingtransactions
48
Пять команд поддерживают 17 версий внутренних API, что стоит около 11 инженеро-месяцев в квартал, и за 12 месяцев нужно сократить это вдвое. Какой общий стандарт жизненного цикла вы введёте?
estimationapi
49
В 4 командах CI стоит $720 000 в год, p95 сборки равен 42 минутам, и каждая команда использует свой процесс релиза; Finance хочет экономию 20% за 9 месяцев. Какой стандарт вы введёте?
releasesconcurrency
50
Ваши 4 команды владеют 9 базами данных и 3 системами событий; дублирование данных добавляет $480 000 годовых расходов, а новый аналитический продукт должен выйти через 24 месяца со свежестью данных менее 5 минут. Какой роадмап вы зададите?
roadmapsystem-designconsistency
51
Пять команд и 48 инженеров прошли 10 недель из 24-недельной программы биллинга, но завершили лишь 35% обещанного объёма против плановых 55%, а от запуска зависят продления на $6 млн. Что вы сделаете в ближайшие 72 часа?
program-managementscope-managementlaunches
52
Запуск продукта четырёх команд идёт по графику и должен состояться через шесть недель, но production-пилот показывает $100 месячной выручки и $140 переменных расходов на облако и поддержку на клиента; в развёртывании участвуют 3000 клиентов по контрактам. Что вы сделаете?
launchesreleases
53
В вашем портфеле пять команд, 52 инженера и 420 инженерных недель на следующий квартал, но утверждённые инициативы требуют 570. Одна защищает $8 млн ARR, одна экономит $1,2 млн в год, а у трёх ставок на рост нет подписанных клиентов. Как вы расставите приоритеты?
portfolioportfolio-managementcapacity-planning
54
Три из пяти ваших команд заблокированы identity-платформой другого директора: её API опаздывает на 5 недель, 26 инженеров теряют 40% ёмкости, а запуск для клиента на $4 млн состоится через 7 недель. Что вы сделаете на этой неделе?
launchescapacity-planningapi
55
Клиент из топ-10 с ARR $2,8 млн эскалирует после того, как четыре команды дважды пропустили одну и ту же дату интеграции; он угрожает не продлеваться через 30 дней и требует ежедневного доступа к инженерам. Как вы ответите?
escalation
56
В программе комплаенса из четырёх команд и 36 инженеров до юридического срока осталось 8 недель, но аудит показал реализацию лишь 62% из 140 контролей, а текущий план прогнозирует 78%. Штрафы могут достигнуть $5 млн. Что вы измените сейчас?
program-managementestimation
57
Пять команд обещали общий запуск через 12 недель, но два EM показывают зелёный статус, хотя у 18 из 31 передачи между командами нет даты приёмки, а надёжность контрольных точек равна 64%. Что вы сделаете до обзора с руководством?
milestonesdependenciesplanning
58
Программа из четырёх команд и 44 инженеров потратила $3,2 млн из бюджета $4 млн, завершена на 45%, а из девятимесячного плана осталось 4 месяца. Спонсор просит сохранить исходные объём и дату. Что вы порекомендуете?
program-managementscope-managementsponsor
59
До запуска общей миграции данных пяти команд осталось 6 недель; ошибки сверки составляют 3,8% при лимите 0,1%, две команды предлагают разные исправления, а от точности счетов зависит $12 млн ARR. Что вы решите?
launchesmigrationsreact
60
Через 7 месяцев программа платформы для разработчиков из пяти команд достигла 22% внедрения против цели 60%, стоит $450 000 в месяц и требует ещё $2 млн для завершения. Продуктовые команды не видят ускорения поставки. Продолжите ли вы её?
program-managementdecision-making
61
Один из четырёх EM руководит 11 из ваших 46 инженеров, пропустил 7 из 10 квартальных обязательств, имеет 27% нежелательной текучести, а два senior-инженера сообщают о шести месяцах без полезной обратной связи. Что вы сделаете?
feedbackattrition
62
Два EM, управляющие 24 из ваших 50 инженеров, уже 8 недель спорят о владении общим сервисом; 14 инцидентов перебрасывались между командами, а MTTR вырос с 45 до 110 минут. Как вы решите проблему?
incidentsownershipincident-management
63
Skip-level интервью в трёх из пяти ваших команд показали, что 9 из 21 инженера не могут назвать главный приоритет, хотя все три EM сообщают о здоровой синхронизации и уверенности 90%. Как вы используете эти данные?
alignment
64
Ваш сильнейший EM увольняется с уведомлением за 6 недель, управляет двумя из пяти команд и 19 из 47 инженеров, а ни один преемник не соответствует более чем 60% критериев роли. До критического запуска 10 недель. Что вы сделаете?
launchesperformance-rubric
65
Внешний EM, нанятый для одной из четырёх команд, увольняется через 90 дней; вовлечённость упала на 14 пунктов, три senior-инженера проходят собеседования в других компаниях, а поиск стоил $85 000. Что вы сделаете дальше?
engagementhiring
66
Principal-инженер, работающий с четырьмя командами, начал напрямую назначать задачи 17 инженерам и отменять приоритеты EM; архитектурные решения ускорились, но надёжность контрольных точек упала с 88% до 69%. Как вы восстановите границу?
milestonesplanningreliability
67
EM, управляющий 13 из ваших 55 инженеров, три месяца показывал зелёный статус программы, но аудит обнаружил ручное изменение прогноза, а реальная дата опаздывает на 9 недель. Под риском $1,5 млн ARR. Что вы сделаете?
program-management
68
Вы принимаете пять EM и 58 инженеров; у одного EM нежелательная текучесть 41% за 12 месяцев, но команда выполнила 96% роадмапа, а VP называет его лучшим менеджером. Как вы его оцените?
roadmapownershiproadmapping
69
Два из четырёх ваших EM закрывают вакантные роли, каждый управляет 20 инженерами, и оба сообщают о 60-часовой неделе 10 недель подряд. Найм займёт 4 месяца, а критическая программа должна завершиться через 9 недель. Что вы измените?
program-managementhiring
70
Staff-инженер и EM спорят, кто должен вести миграцию трёх команд и 35 инженеров; staff владеет техническим направлением, EM отвечает за дату, а конфликт задержал решения на 3 недели. Кто будет лидером?
conflict-managementmigrations
71
CFO требует за 30 дней сократить инженерный бюджет на 20% в ваших пяти командах и 60 инженерах; зарплаты составляют 82% затрат, подрядчики стоят $1,1 млн, а в роадмапе есть обязательства на $9 млн ARR. Что вы предложите?
roadmaproadmapping
72
До конца квартала вы должны убрать 9 из 45 ролей в четырёх командах, при этом одна команда поддерживает 70% выручки, а у продукта другой внедрение 8%. Как вы распределите сокращение?
decision-making
73
В матричной организации пять EM подчиняются функциональным директорам, а три продуктовых GM назначают работу; 54 инженера получают конфликтующие приоритеты, 32% работы меняется посреди цикла, а у двух запусков не было одного ответственного владельца. Как вы устраните двойную ответственность?
launchesconflict-management
74
Через три месяца после реорганизации четырёх команд и 40 инженеров число межкомандных тикетов выросло на 65%, p75 lead time увеличился с 12 до 19 дней, а вовлечённость упала на 9 пунктов. COO просит дать больше времени. Что вы сделаете?
engagementcross-teamreorganization
75
Finance просит за 6 месяцев закрыть одну из двух инженерных площадок ради экономии $2,4 млн в год; на меньшей работают 18 из 52 инженеров, она владеет двумя критическими сервисами, а 7 сотрудников могут уйти. Что вы порекомендуете?
76
После объявления реорганизации 11 из 48 инженеров в четырёх командах признаны сотрудниками с высоким риском ухода, включая всех трёх экспертов по базам данных; замена займёт 9 месяцев и поставит под риск $7 млн ARR. Что вы сделаете за 2 недели?
retentiondatabaserisk-management
77
CPO хочет направить 35 из ваших 50 инженеров на функцию с ожидаемыми $4 млн ARR, а CTO требует 20 на надёжность после расхода error budget на 180% два квартала подряд. Эти распределения несовместимы. Что вы порекомендуете?
reliability
78
Совет директоров собирается через 48 часов после переноса миграции платформы четырьмя командами на два квартала; от неё зависят $6 млн экономии и продление клиента на $10 млн, а уверенность в новой дате равна 55%. Как вы сообщите о риске?
risk-managementmigrationscommunication
79
Ваши пять команд тратят $2,7 млн в год на 22 подрядчиков, а Finance требует сэкономить $1,5 млн за 60 дней; 8 подрядчиков имеют production-доступ к выручкообразующим сервисам, ещё 6 работают над запуском через 10 недель. Кого вы сократите?
launches
80
Вы должны объединить две площадки в одну и сократить штат на 15% среди 56 инженеров, но местные консультации требуют 45 дней, а клиентская миграция должна завершиться через 70 дней. CEO хочет объявление и имена на следующей неделе. Что вы сделаете?
headcount-planningmigrations
81
Sev-1 затрагивает checkout, identity и billing в четырёх командах и 43 инженерах; потери выручки составляют $180 000 в час, единого владельца сбоя нет, а 25 человек уже в одном звонке. Что вы сделаете в первые 15 минут?
82
Межрегиональный сбой длится 70 минут, три команды проверяют конфликтующие меры, поддержка получила 4000 тикетов, а CEO просит подключиться к командованию инцидентом. Как вы проведёте следующий час?
risk-managementincident-managementincidents
83
Портфельная репетиция аварийного восстановления четырёх команд провалена: 7 из 18 сервисов tier-1 превышают целевые 4 часа восстановления, 5 не могут доказать потерю данных менее чем за 15 минут, а клиентские контракты содержат разные обязательства. Как вы установите RTO, RPO и тестирование?
portfolioportfolio-managementtesting
84
В пяти командах за прошлый квартал закрыты только 3 из 11 действий после Sev-1, четыре инцидента повторили известные причины, а EM говорят, что сроки не оставляют времени. Как вы исправите культуру?
incidentsestimationincident-management
85
Security обнаружила активно эксплуатируемую зависимость в 27 сервисах пяти команд; 8 сервисов обрабатывают платёжные данные, патч существует, а уведомление требуется за 72 часа. Product просит подождать выходных. Что вы сделаете?
dependenciesconcurrency
86
Аудит за 12 дней до сертификации обнаружил административный доступ без MFA в 9 из 34 систем четырёх команд; сертификация защищает контракты на $14 млн, а исправление может задержать два запуска. Как вы ответите?
launchessystem-design
87
Миграция платформы пяти команд достигает 40% трафика, после чего ошибка растёт с 0,2% до 4,7%, а откат потеряет 6 часов реплицированных записей без сверки. Под риском $300 000 выручки в день. Что вы сделаете?
migrationsreplicationrollback
88
Трёхчасовой Sev-1 в трёх командах затронул 18 корпоративных клиентов и нарушил 60-минутный SLA уведомления; Sales хочет отдельные звонки инженеров, пока восстановление не завершено. Как вы организуете коммуникацию?
soft-skills
89
Два Sev-1 начинаются с разницей 10 минут в сервисах четырёх команд; один блокирует 65% выручки, второй затрагивает внутреннюю выплату зарплаты 6000 сотрудникам через 5 часов. У вас один опытный командир инцидентов. Как вы распределите руководство?
incident-managementincident-commandincidents
90
После трёх межкомандных сбоев за 8 недель предлагаемая работа по надёжности стоит 14 инженерных месяцев и задерживает функцию на $2 млн на 6 недель; тот же режим отказа уже принёс $900 000 потерь. Что вы решите?
cross-teamprioritizationreliability
91
У вас 10 рабочих дней на оценку цели поглощения с 38 инженерами; 45% её ARR $12 млн работает на недокументированной платформе, отчётам безопасности 18 месяцев, а у трёх ключевых руководителей нет условий удержания. Что вы порекомендуете?
retention
92
Через 30 дней после поглощения вы управляете пятью командами и 57 инженерами; дублирующиеся продукты стоят $3 млн в год, риск текучести приобретённой команды равен 35%, а клиенты требуют 12 месяцев поддержки. Что вы сделаете сначала?
attritionrisk-management
93
Четыре команды потратили 9 месяцев и $2,6 млн на внутренний workflow engine; он опаздывает на 5 месяцев, а поставщик теперь покрывает 85% потребностей за $480 000 в год и может мигрировать за 4 месяца. Отмените ли вы решение строить?
procurement
94
Через 18 месяцев после выбора поставщика вместо разработки годовая стоимость выросла с $700 000 до $2,1 млн, p95 latency превышает договорные 300 мс на 40%, а выход требует 30 инженерных месяцев трёх команд. Что вы сделаете?
procurementmigrationslatency
95
Ваши 50 инженеров работают в четырёх командах в Калифорнии, Польше и Сингапуре; время решений удвоилось до 6 дней, 38% одного региона считают встречи исключающими, а дефекты передачи выросли на 45%. Как вы исправите культурный дрейф?
defectsiac
96
В пяти командах доля прохождения одного и того же собеседования senior-инженера колеблется от 18% до 62%, принятие офферов равно 54%, а нежелательная текучесть первого года достигла 22%. Нужно нанять 15 человек за два квартала. Что вы измените?
attrition
97
После привязки бонусов к частоте деплоя четыре команды увеличили деплои на 80%, но change-failure rate вырос с 9% до 21%, а команды начали дробить коммиты для раздувания счётчика. Что вы сделаете до проверки бонусов?
deployment
98
CRO просит скрыть известное завышение счетов на 2% для 14 000 клиентов до закрытия квартала, потому что исправление сейчас уменьшит признанную выручку на $1,8 млн. Четыре команды могут исправить это за 10 дней. Что вы сделаете?
99
Менеджер сообщает, что руководитель попросил одну из пяти команд использовать данные о местоположении клиентов для неутверждённой модели продаж; затронуто 8 млн записей, покрытие согласиями неизвестно, демонстрация через 6 дней. Что вы сделаете?
coverage
100
Вы управляете пятью командами и 60 инженерами во время кризиса в конце квартала: Sev-1 угрожает $500 000 в день, патч безопасности нужен за 48 часов, CFO требует сократить затраты на 15%, а единственный квалифицированный EM сообщил о семейной чрезвычайной ситуации. Что вы решите в ближайший час?

Вопросы

13У вас в прямом подчинении 4 EM на 56 инженеров; у одного EM 19 подчинённых, у другого 7, а за год компания добавит 8 инженеров. Как вы измените диапазоны управления?

15B2B-сервис работает 24 часа, у него 45 инженеров в UTC-8, UTC+0 и UTC+8, но каждое изменение всё ещё требует одобрения команды UTC-8. Как изменить владение и не снизить SLO 99,95%?

16Три команды из 34 инженеров меняют общий сервис заказов, и 40% pull request ждут ревью владельца больше 3 дней. Как вы проведёте границу?

17Четыре продуктовые команды делят 6 инженеров безопасности, а встроенные назначения дублируют 35% работы по годовому роадмапу. Какую топологию вы выберете?

18Группа вырастет с 36 до 50 инженеров и с 3 до 5 команд за 9 месяцев, но только 2 текущих лида готовы к менеджменту. Как вы выстроите изменение топологии?

19На следующие 2 квартала у ваших 5 инженерных команд и 47 инженеров есть только 3 product manager. Как вы распределите лидерство и сохраните скорость решений?

20В 5 командах и 60 сервисах у 18 сервисов заявлены два владельца, а у 11 нет ни одного; следующий цикл планирования начинается через 6 недель. Что вы сделаете?

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