Ответы: AI-лидерство¶
English · Русский · AI Interview Atlas › Треки и роли
Письменные ответы на приоритетные вопросы трека в том же порядке и нумерации, что и в разделе «С чего начать». Сначала ответьте сами: здесь один из хороших ответов, а не единственно верный, и интервьюер слушает ваши рассуждения, а не совпадение формулировок.
Ответы готовы: 82 из 82.
Содержание¶
- Безопасность, защита и governance
- 1. Ассистент читает внешнюю почту, ищет внутренние документы и отправляет ответы. Как атакующий может изменить его поведение и как ограничить ущерб?
- 2. Как вы организуете безопасное внедрение AI-модели в промышленную эксплуатацию?
- 3. Как вы организуете безопасность потребительского продукта на основе генеративного AI?
- 4. Какие защитные меры нужны AI-системе, действующей от имени пользователя?
- 5. Расскажите о ситуации, когда сроки вступили в противоречие с требованиями безопасности. Как вы приняли решение?
- 53. Продуктовая команда просит исключение из правила безопасности AI для одного корпоративного клиента. Как оценить, согласовать и ограничить срок такого исключения?
- 68. Как вы сопоставите улучшение качества модели и снижение её интерпретируемости?
- 81. Перед запуском ассистента с доступом к инструментам: как вы организуете состязательное тестирование и что позволит утверждать чистый результат?
- Стратегия и метрики AI-продукта
- 6. Как бы вы улучшили ChatGPT для корпоративных клиентов?
- 7. Модель существенно мощнее, но стоит в десять раз дороже. Как решить, какой продукт на ней создавать?
- 8. Как определить, полезна ли LLM для предложенной продуктовой задачи?
- 9. Спроектируйте ассистента на основе Gemini для студентов университета.
- 10. Пользователи жалуются, что Gemini уверенно даёт неверные ответы. Что вы измените?
- 11. Как вы расставите приоритеты функций AI-ассистента для письма в Microsoft Word?
- 12. Как вы измерите успех AI-функции в продукте Microsoft?
- 13. Какую главную метрику вы выберете для AI-поиска и какими ограничениями её дополните?
- 14. Вовлечённость в уведомления растёт, а общее время в продукте не меняется. Как вы объясните результат?
- 15. Выберите AI-агента или продукт, которым пользуетесь, и предложите самое полезное улучшение.
- 41. Объясните продуктовые компромиссы при выборе модели.
- 42. Какие бизнес-сценарии подходят для AI-агентов и как их сравнить?
- 43. Как вы установите цену корпоративного AI-продукта, какие затраты обязательно учтёте и как кастомизация под каждого клиента влияет на маржинальность?
- 44. В чём AI-сервис ответов лучше обычного поиска, а в чём уступает? Что вы улучшите первым?
- 65. Что вы будете делать, если MVP корпоративного AI-продукта слишком дорого или долго делать?
- 66. Кто в дискавери корпоративного AI-продукта является «персоной», где вы найдёте B2B-респондентов и как поймёте, что проблему стоит решать?
- 74. Использование AI-продукта растёт, но достоверного улучшения результата клиента нет, а затраты на проверку увеличиваются. Спонсор хочет ещё квартал инвестиций. По каким данным вы расширите, сузите, приостановите или закроете продукт и что сделаете для текущих пользователей?
- AI-платформа и операционная модель
- 16. Определите стратегию внутренней AI-платформы и распределите ответственность за её метрики успеха.
- 17. Как поддерживать несколько поставщиков моделей, если в отдельных средах разрешена только часть моделей?
- 45. Как оценивать корпоративного AI-ассистента, если ваша команда не может просматривать данные клиента?
- 69. Спроектируйте сервис, в котором несколько команд запрашивают общий набор данных без доступа к исходным записям.
- 71. Вы отвечаете за портфель AI-инвестиций следующего квартала. Бюджет сокращён на 30%; конкурируют коммерческий пилот, обязательный проект контроля рисков и общая инфраструктура оценки. Как вы перераспределите деньги и людей и согласуете решение с руководством?
- 72. Как владелец инвестиций решите, продлевать ли управляемый AI-сервис или финансировать внутреннюю замену. Через шесть месяцев цена поставщика удвоится, а экспорт данных не воспроизводит поведение сервиса. Какое решение и план выхода вы утвердите?
- 77. Несколько продуктовых команд работают через один внутренний AI-шлюз. Как сделать так, чтобы трафик, данные и кеши одной команды не влияли на другую?
- 78. Провайдер объявил, что версия модели, от которой зависят ваши продукты, будет отключена через три месяца. Как вы проведёте переход во всех командах, которые её используют?
- 79. Расходы на инференс общей AI-платформы за квартал удвоились, и ни одна команда не признаёт счёт своим. Как сделать расходы относимыми и управляемыми?
- 80. Задержка и доступность вашей AI-платформы зависят от внешнего провайдера моделей. Что вы пообещаете внутренним командам и как будете это обещание выполнять?
- Руководство инженерными командами
- 18. Как вы будете действовать, если инженер не соответствует ожиданиям по результатам работы?
- 19. Как вы будете действовать, если сильный инженер своим поведением регулярно создаёт конфликты с коллегами?
- 20. Расскажите, как развивалась карьера человека, которого вы наставляли.
- 21. Что вы делаете, когда команда не согласна с предложенным вами направлением?
- 22. Расскажите о сложном организационном изменении, которым вы управляли и при котором уходили сильные инженеры. Как вы действовали?
- 23. Как вы стабилизируете инженерную команду после смены руководства?
- 24. Расскажите, как вы нашли ценную возможность и убедили группу людей её реализовать.
- 46. Команда внедрила AI-инструменты программирования, но ревьюерам трудно проверять изменения. Как вы разовьёте недостающие навыки?
- 47. Расскажите о своём последнем стратегически важном найме инженера. Как вы определили планку и оценили, решил ли найм исходную задачу?
- 48. Как вы задаёте стандарты инженерного качества в команде?
- 49. Исследователям нужно продолжать эксперименты, а продуктовым инженерам — выпустить надёжный сервис. Как вы распределите ответственность и передачу работы?
- 59. Какой самой большой командой вы руководили и как при таком масштабе менялись ваши обязанности?
- 60. Расскажите о споре в команде, который вы разрешили, сохранив обоснованные доводы обеих сторон.
- 61. Двум продуктовым командам нужна общая AI-инфраструктура, но ни одна не может выделить инженера. Как организовать работу без обещаний платформы, под которые нет людей?
- 73. Вы руководите тремя инженерными менеджерами, которые ведут общую AI-инициативу. Двое обвиняют друг друга в пробеле оценки качества, а исполнительный спонсор уже обещал дату запуска. Как вы восстановите ответственность, не подменяя руководителей команд?
- 76. Кандидаты используют AI-ассистентов на технических интервью. Как вы перестроите процесс, чтобы он по-прежнему давал пригодный сигнал для найма?
- 82. Организация внедрила AI-инструменты для разработки, и руководство хочет знать, дали ли они результат. Как вы ответите на этот вопрос убедительно?
- Программы и delivery
- 25. Расскажите о самом сложном продуктовом запуске, которым вы руководили.
- 26. За три недели до запуска LLM-функции оценка выявила много галлюцинаций в пограничных сценариях. Что вы предпримете?
- 27. Расскажите о крупном межфункциональном проекте: неопределённости, препятствиях и задержках.
- 28. Как вы организуете обновление устройств Alexa, уже установленных у пользователей дома?
- 50. Как вы спланируете AI-программу, если её основная исследовательская гипотеза может не подтвердиться?
- 51. Инженерная команда, эксплуатация и риск-функция расходятся в оценке готовности запуска. Как принять решение, основания которого можно проверить?
- 56. Представьте крупную инициативу, которой вы руководили: что сработало, что нет и чему вы научились.
- 57. Расскажите о техническом просчёте, из-за которого задержался проект.
- 58. Команда-поставщик данных не успевает к контрольной дате AI-программы. Как вы пересмотрите план и сообщите о последствиях?
- 75. Во время AI-развёртывания поставщик меняет поведение модели, и вредные действия затрагивают клиентов. Немедленно вернуть прежнюю модель невозможно. Как руководитель программы вы организуете сдерживание инцидента, работу с клиентами и обоснованный повторный запуск?
- Прикладные и клиентские сценарии
- 29. Клиент хочет автоматизировать обработку страховых требований с помощью AI. Что вы сделаете за первые две недели?
- 30. Руководитель клиента хочет закрыть AI-пилот из-за постоянных ошибок. Что вы сделаете в ближайшие 48 часов?
- 31. Клиент настаивает на дообучении своей модели на обращениях в поддержку, а вы считаете, что хватит поиска по данным. Как действовать?
- 32. Базовую модель работающего агента отключат через 60 дней. Как вы проведёте миграцию без потери качества?
- 33. Клиент жалуется, что чат-бот на восьми GPU слишком медленный и дорогой. У вас неделя работы с ним; как её использовать?
- 34. Компания хочет за четыре недели запустить ответы по двум миллионам внутренних файлов без вывода данных за пределы VPC. Как определить объём пилота?
- 52. Контакт-центр хочет заменить телефонное меню голосовыми агентами. Как вы проведёте проект?
- 70. Корпоративный клиент сообщает, что Claude галлюцинирует в ассистенте с поиском по базе знаний. Как вы начнёте разбор ошибок?
- Платежи и регулируемые отрасли
- 35. Торговый агент может инициировать платежи. Как доказать, что каждый платёж соответствует реальному разрешению пользователя?
- 36. AI-агент поддержки инициировал возврат, после чего платёжный API не ответил вовремя. Как восстановить работу без двойного возврата?
- 37. Банк хочет внедрить AI-ассистента, предлагающего сотрудникам решения по обращениям. Какие данные и меры контроля нужны перед расширением запуска?
- 62. Клинический AI-сервис обрабатывает аудио, расшифровки и записи с защищённой медицинской информацией. Как это влияет на архитектуру и использование сторонних API моделей?
- Поведенческие вопросы и ценности
- 38. Почему вы хотите работать в Anthropic и в чём не согласны с её подходом?
- 39. Расскажите о своей ошибке, её последствиях и последующих изменениях в работе.
- 40. Расскажите о случае, когда вы были не согласны с человеком, но не смогли его убедить.
- 54. Расскажите о противоречащих приоритетах участников проекта и о том, как вы согласовали действия.
- 55. Расскажите об обратной связи, которую было трудно услышать, и о том, как вы её использовали.
- Практический кодинг
- Агенты, инструменты и протоколы
- Дизайн AI-систем
1. Ассистент читает внешнюю почту, ищет внутренние документы и отправляет ответы. Как атакующий может изменить его поведение и как ограничить ущерб?¶
System design · Безопасность, защита и governance · Чек-лист
Главная уязвимость здесь в том, что текст входящего письма попадает в тот же контекст, что и инструкции, а полномочия ассистента шире, чем права отправителя: письмо просит найти внутренний документ и переслать его наружу, и модель послушно выполняет. Лечится это не формулировкой промпта, а разделением уровней: содержимое недоверенной почты остаётся данными, а права на поиск и отправку живут в слое инструментов, который не читает письмо как команду. Я бы сузил набор инструментов, ограничил получателей текущим тредом и известными адресами, потребовал явного подтверждения человеком при выходе за них и вложениях. Проверял бы корпусом писем с косвенными инъекциями и попытками утечки, считая долю исходящих сообщений с данными выше уровня доступа. Полностью риск не снимается: фильтры инъекций ошибаются, а утечка возможна и через разрешённый канал.
Читать: OWASP Top 10 for LLM Applications · The lethal trifecta for AI agents: private data, untrusted content, and external communication · Prompt injection (series)
2. Как вы организуете безопасное внедрение AI-модели в промышленную эксплуатацию?¶
System design · Безопасность, защита и governance · Чек-лист
Безопасное внедрение означает, что каждый шаг расширения — это решение конкретного человека по критериям, записанным до того, как пришли результаты. Назначение и последствия, которые мы не принимаем, я бы превратил в проверки на eval-наборе с порогами, чтобы планка выпуска существовала раньше, чем кто-то привяжется к дате. Ответственность разделяю намеренно: один владелец проводит оценку, остаточный риск принимает тот, кто отвечает за последствия продукта, а не тот, кого оценивают по сроку запуска, а дежурный может остановить выкатку без всякого совещания. Расширение идёт ступенями — внутренние пользователи, небольшая доля трафика, дальше шире — с порогами остановки по размеченной выборке живого трафика: вредные ответы, жалобы, эскалации. Неочевидная цена в том, что малые ступени медленно замечают редкий вред, поэтому ступень заканчивается, когда через неё прошло достаточно трафика, чтобы редкий сбой успел проявиться, а не через фиксированное число дней. Граница: откат не отзывает отправленные сообщения и не отменяет совершённые действия, а правка промпта или обновление индекса меняют поведение не меньше новой модели, поэтому проходят ту же процедуру допуска.
Читать: AI Risk Management Framework · Site Reliability Engineering · Anthropic's Responsible Scaling Policy
3. Как вы организуете безопасность потребительского продукта на основе генеративного AI?¶
Продуктовый кейс · Безопасность, защита и governance · Чек-лист
Требования к безопасности должны идти от того, кто реально пользуется продуктом и какой вред для этих людей правдоподобен: общий список запретов отказывает обычным пользователям там, где не нужно, и всё равно пропускает конкретный риск. Поэтому я бы описал модель злоупотреблений для каждой группы: подросток, который ищет способы навредить себе, взрослый, вытягивающий опасные инструкции через ролевую игру, кто-то, кто генерирует контент для травли конкретного человека. Каждый слой останавливает своё: продуктовое ограничение убирает возможность целиком — надёжно, но дорого для законного использования; поведение модели закрывает серую зону и работает вероятностно; жалобы показывают схемы, которых ещё нет в eval-наборе; эскалация человеку нужна на кризисных сигналах, где ошибочный автоматический ответ обходится дорого. Измерял бы долю вредных ответов и необоснованных отказов на выборке с двойной разметкой, стратифицированной по сегментам и языкам, с намеренно увеличенным числом примеров из малых групп, чтобы их доли вообще было видно. Новая тяжёлая схема из жалоб сразу закрывается грубым продуктовым блоком, а потом уже исправлением модели и пополнением eval-набора. Граница: продукт редко знает возраст и намерения пользователя, а средние значения прячут вред, сосредоточенный в небольшой группе.
Читать: AI Risk Management Framework · OWASP Top 10 for LLM Applications
4. Какие защитные меры нужны AI-системе, действующей от имени пользователя?¶
System design · Безопасность, защита и governance · Чек-лист
Ключевое различие такое: модель предлагает действие, а разрешает его система, и это разные подсистемы. Полномочия ограничиваются пользователем, ресурсом и операцией — агент действует не шире прав того, от чьего имени работает, а токен выдаётся под конкретную операцию, а не под всю учётную запись. Значимые и необратимые действия показываются человеку понятной формулировкой: что именно, кому, на какую сумму. Политика проверяется в момент исполнения на стороне сервиса, потому что проверка внутри промпта обходится текстом. Дополнительно нужны журнал действий со сквозным идентификатором, лимиты расходов и частоты, а также план восстановления после частичного выполнения, где компенсирующая операция важнее слепого повтора. Граница применимости в усталости от подтверждений: если спрашивать обо всём, люди перестают читать, поэтому подтверждать стоит дорогое и необратимое.
Читать: OWASP Top 10 for LLM Applications · Designing robust and predictable APIs with idempotency
5. Расскажите о ситуации, когда сроки вступили в противоречие с требованиями безопасности. Как вы приняли решение?¶
Поведенческий · Безопасность, защита и governance · Чек-лист
Такой вопрос лучше отвечать как разбор решения о риске, а не как рассказ о подвиге. Возьмите реальный эпизод и начните с угрозы: что конкретно могло произойти, кого затронуло бы и какими данными вы располагали на тот момент, включая то, чего не знали. Дальше назовите альтернативы, которые рассматривали всерьёз — сузить запуск, включить для части пользователей, добавить ручную проверку, сдвинуть срок — и скажите, кто имел полномочия принять остаточный риск и как вы эскалировали. Интервьюер слушает именно это: отделяете ли вы своё мнение от чужого решения и знаете ли, кто владелец риска. Частая ошибка — герой, который всех спас, или безличное решение без автора. Заканчивайте честным результатом, включая то, что пошло не так, и изменениями в контроле, которые остались после истории.
Читать: AI Risk Management Framework
6. Как бы вы улучшили ChatGPT для корпоративных клиентов?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Улучшение корпоративного ассистента начинается с выбора сегмента и одного рабочего процесса, а не со списка возможностей. Я бы искал регулярную задачу, где ответ уже существует внутри компании, но его дорого найти и собрать — например, подготовка ответа по внутренним регламентам, — и описал бы конкретного пользователя и место, где он буксует. Дальше честное сравнение: если задача решается поиском, шаблоном или правилами, модель не нужна. Для корпоративных клиентов решают не демонстрации, а интеграция и доверие — вход через корпоративные учётные записи, наследование прав от источника, журналирование, требования к хранению и обработке данных. Пилот я бы ограничил заранее объявленным результатом: время на задачу, доля задач, доведённых до конца без переделки, ограничения по качеству и условие расширения. Слабое место пилотов в том, что энтузиасты не предсказывают поведение при обязательном внедрении.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications · Rules of Machine Learning
7. Модель существенно мощнее, но стоит в десять раз дороже. Как решить, какой продукт на ней создавать?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Решает не абстрактная мощность, а наличие задач, где прирост качества делает допустимой работу, которую раньше нельзя было доверить модели: там, где раньше требовалась обязательная проверка человеком, а теперь достаточно выборочной. Считать надо не цену токена, а стоимость успешно завершённого процесса с учётом повторов, проверки и цены ошибки. По токенам три попытки дешёвой модели всё равно стоят меньше одной попытки модели, которая в десять раз дороже, поэтому дорогая выигрывает там, где дешёвая не дотягивает до планки ни с каким числом повторов, или там, где в счёте преобладают время проверки человеком и цена ошибки. Платите вы задержкой, сложностью и зависимостью от одного поставщика. Я бы измерил эту стоимость на своём наборе задач, проверил готовность платить на узком сегменте и включил выборочную маршрутизацию: дорогая модель только на сложных или дорогих по ошибке случаях, дешёвая как основа. Ограничение в том, что если пользователь не замечает разницы в результате, никакой прирост качества не окупается, а цены и возможности моделей меняются быстрее продуктовых планов.
Читать: Rules of Machine Learning · Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
8. Как определить, полезна ли LLM для предложенной продуктовой задачи?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
LLM оправдана там, где входные данные слишком разнородны для правил, а ошибка дешева или перехватывается до того, как навредит, и выясняю я это, отталкиваясь от задачи, а не от модели: что человек пытается сделать, как это делается сегодня, сколько стоит ошибка и кто её увидит. Неочевидный компромисс — покрытие против вариативности: модель справляется со свободным текстом и нестандартными документами, которые правила не разберут, но один и тот же вход может дать разные ответы, а её сбои нельзя заранее перечислить, как сбои правила. Где ценность в точной воспроизводимости, модель в лучшем случае интерфейс поверх детерминированной системы. Дальше проверяю доступ к данным, можно ли определить и разметить правильный результат, и бюджет задержки. Сравниваю LLM с лучшим простым базовым решением на размеченных реальных случаях, считая важную ошибку с весом её цены, плюс стоимость и задержку на задачу, а правило отказа формулирую заранее. Если правильный результат нельзя определить или разметить, вывод — пока без LLM: сначала нужно научиться измерять.
Читать: Rules of Machine Learning · Building Effective AI Agents
9. Спроектируйте ассистента на основе Gemini для студентов университета.¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Я бы отказался от универсального помощника и выбрал один сегмент с одной регулярной потребностью — скажем, студенты первого курса, готовящиеся к экзамену по конкретному предмету, — а источником сделал бы материалы курса, а не интернет целиком. Сценарий строится вокруг понимания: ассистент разбирает ошибку, задаёт встречные вопросы и показывает место в материалах, а не выдаёт готовый текст задания; неуверенность проговаривается прямо, а списывание рассматривается как основная модель злоупотребления и ограничивается продуктово, с учётом правил академической честности. Измерять я бы стал успешность задачи, пользу для обучения на отложенной проверке знаний и только затем удержание. Именно здесь и проходит граница: удержание может расти от вреда, потому что ассистента, решающего задания за студента, любят, хотя учебный результат он ухудшает, и без учебной метрики это незаметно.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications · AI Risk Management Framework
10. Пользователи жалуются, что Gemini уверенно даёт неверные ответы. Что вы измените?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Сначала я бы перестал считать это одной проблемой и разобрал жалобы на причины: модель не знает факта, поиск принёс не то или ничего, либо ответ подан так, что уверенность не соответствует основанию. Это три разных исправления. Опора на источники уменьшает выдумки, но добавляет задержку и переносит качество на поиск; отказ отвечать может снизить воздействие неверных ответов, но раздражает, когда срабатывает не по делу; изменения интерфейса вроде показа цитат и пометки непроверенного стоят дёшево и меняют доверие, не трогая модель. Поэтому сравнивал бы эти варианты на одном наборе задач, а не по ощущениям, и следил бы за долей утверждений без подтверждения источником, полезным выполнением задач и регрессиями по сегментам. Калибровка согласует уверенность с наблюдаемой правильностью, но не исправляет фактические ошибки. Отказы и интерфейс меняют воздействие ошибок, а предупреждения могут игнорироваться.
Читать: AI Risk Management Framework · Demystifying evals for AI agents
11. Как вы расставите приоритеты функций AI-ассистента для письма в Microsoft Word?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Приоритизация начинается с разбиения письма на разные задачи: черновик с нуля, переписывание готового куска, сокращение, правка тона и грамматики, сведение нескольких документов. Для каждой я бы нашёл место, где человек буксует сегодня, и сопоставил ожидаемую пользу, риск качества, трудоёмкость и зависимости вроде прав доступа к документу. Риск здесь несимметричен: подсказка рядом с текстом дешева в ошибке, а массовая правка чужого документа дорога, поэтому вперёд выходят задачи с видимым и обратимым результатом на выделенном фрагменте. Первый релиз стоит сделать узким и измерять не объём сгенерированного, а принятую пользователем помощь: доля вставленного и сохранившегося в документе спустя время, доля отката. Ограничение в том, что принятие не равно качеству — люди соглашаются с правкой, чтобы не спорить, поэтому нужна отдельная проверка качества текста.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications · Rules of Machine Learning
12. Как вы измерите успех AI-функции в продукте Microsoft?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Успех — это наблюдаемо выполненная задача, а модельные метрики объясняют, почему он меняется, но не доказывают пользу. Возьмём функцию, которая готовит черновики ответов: успех — черновик, отправленный с небольшой правкой. Дальше я бы развёл слои: внедрение — доля пользователей с доступом к функции, которые её попробовали, удержание — доля тех, кто пользуется ею спустя недели, качество задачи — доля отправленных черновиков и объём правки или удалений, задержка по p95 и стоимость на отправленный черновик, а оценки на eval-наборе лежат ниже как диагностика. Настоящий компромисс — в способе сравнения: контрольная группа без функции — единственный чистый способ установить причину, но она лишает часть людей пользы и требует недель, чтобы увидеть удержание, а сравнение до и после дёшево, но смешано с эффектом новизны и сезонностью. Против накрутки каждая метрика объёма получает парную метрику качества, которая падает при раздувании объёма: засчитайте показ за использование — внедрение вырастет, а доля отправленных упадёт. Ограничение: даже чистый эксперимент не видит эффектов доверия, которые проявляются месяцами, а результаты, которые используются вне продукта, требуют выборочной оценки людьми.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
13. Какую главную метрику вы выберете для AI-поиска и какими ограничениями её дополните?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Главной метрикой я бы сделал долю сессий с полезно завершённой поисковой задачей, а не клики и не время на странице, потому что и то и другое растёт при плохом ответе. Наблюдать завершение приходится косвенно: пользователь не переформулировал запрос, выполнил следующее действие, а если открыл источник, то не вернулся сразу. В сервисе ответов сам по себе переход к источнику неоднозначен: это может быть и проверка ответа, и признак того, что ответа не хватило, а довольный пользователь может вообще никуда не переходить, поэтому такие сигналы калибруют по разметке людьми. Любая единственная метрика толкает в крайность, поэтому её дополняют ограничениями: доля утверждений без подтверждения источником, безопасность, задержка и стоимость запроса — ухудшение любого из них отменяет прирост. Отдельно объясняю знаменатель: считаем сессии или запросы, что делаем с ботами и повторами, как сегментируем по языку и типу задачи. В навигационных и развлекательных запросах завершение плохо определимо, и там метрика вводит в заблуждение.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
14. Вовлечённость в уведомления растёт, а общее время в продукте не меняется. Как вы объясните результат?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Первая гипотеза — замещение: уведомления, возможно, не создают активность, а переносят её из органических заходов, поэтому суммарное время не меняется. Но прежде чем объяснять поведение, я бы проверил измерение: совпадают ли определения вовлечённости и времени, не выросли ли просто показы, не смешаны ли когорты новых и старых пользователей и был ли это эксперимент с контролем или сравнение до и после. Дальше содержательный вопрос: приводят ли уведомления к действиям, которых без них не было, или к тем же самым, просто раньше. Смотреть надо отключения и отписки, жалобы, удовлетворённость и удержание на длинном горизонте, потому что краткосрочный рост кликов часто оплачивается потерей канала. Наконец, неизменное время само по себе не означает отсутствия пользы: продукт мог стать полезнее при меньшем времени, и это нормальный исход.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
15. Выберите AI-агента или продукт, которым пользуетесь, и предложите самое полезное улучшение.¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Возьмите продукт, которым пользуетесь достаточно часто, чтобы не раз видеть, как он подводит вас в реальной работе, и выберите сбой, на обход которого у вас уходит больше всего сил. Интервьюер оценивает, опирается ли ваше суждение на наблюдаемую проблему с частотой и ценой, а не на функцию, которую вам хотелось бы, поэтому скажите, как часто это случается, сколько стоит во времени или переделанной работе и что вы делаете вместо этого. Затем покажите приоритизацию: назовите два-три других улучшения и расставьте их по частоте, цене и тому, у скольких пользователей, по всей видимости, та же проблема, честно отметив, чем ваше использование нетипично. Закончите самым дешёвым способом проверить гипотезу — часто это макет или человек, изображающий нужное поведение за интерфейсом, — с одним критерием успеха, заданным заранее, и побочным эффектом, за которым будете следить: почти любое исправление чего-то стоит: задержки, приватности или лишних шагов. Типичная ошибка — список пожеланий или выдуманные внутренние метрики. Снаружи эффект напрямую не измерить, так и скажите и назовите прокси-метрику, которую можно наблюдать, например повторные запросы или брошенные сессии.
Читать: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
16. Определите стратегию внутренней AI-платформы и распределите ответственность за её метрики успеха.¶
Продуктовый кейс · AI-платформа и операционная модель · Чек-лист
Стратегия внутренней платформы начинается с наблюдения, что несколько команд делают одно и то же: получают доступ к моделям, собирают оценку, настраивают журналирование, разбираются с секретами и персональными данными. Платформа берёт повторяющееся и оставляет командам уникальное, иначе превращается в узкое место. Метрики я бы развёл по уровням: платформа отвечает за надёжность и востребованность — доступность и SLO шлюза, время от идеи до работающего прототипа, доля команд, выбравших её добровольно, стоимость запроса; бизнес-результат остаётся за командами-потребителями, потому что иначе за него не отвечает никто. Практически стоит выбрать один сценарий и поддержать его целиком, явно назвать, чего платформа не делает, и заранее назначить срок пересмотра инвестиций. Если у внутренних команд нет права выбрать альтернативу, показатель использования перестаёт что-либо доказывать.
Читать: Site Reliability Engineering · Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
17. Как поддерживать несколько поставщиков моделей, если в отдельных средах разрешена только часть моделей?¶
System design · AI-платформа и операционная модель · Чек-лист
Разрешённый список среды должен быть частью выбора модели, а не примечанием в документации. Маршрут вычисляется из класса данных, юрисдикции и политики конкретной среды: приложение запрашивает возможность вроде длинного контекста или работы с изображениями, а платформа подбирает допустимую модель и умеет объяснить, почему именно её. Переносимый интерфейс поверх поставщиков прячет форму вызова, но различия прятать нельзя — длина контекста, поддержка инструментов, формат структурированного ответа, поведение guardrails расходятся, и вера во взаимозаменяемость оборачивается регрессиями в продакшене. Поэтому возможности объявляются явно и проверяются общим eval-набором на каждом разрешённом маршруте. Резервный переход допустим только внутри разрешённого множества, а при отсутствии легального маршрута запрос отклоняется с понятной ошибкой вместо тихого ухода к другому поставщику. Плата — меньше гибкости и постоянная поддержка матрицы сред.
Читать: Architect multitenant solutions on Azure · AI Risk Management Framework
18. Как вы будете действовать, если инженер не соответствует ожиданиям по результатам работы?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Сначала я уточню ожидаемые результаты для этой роли и соберу конкретные примеры отставания: репутация или один сорванный срок ещё не объясняют проблему. В личном разговоре попрошу инженера описать ситуацию и проверю, не мешают ли неясные приоритеты, отсутствие доступа, перегрузка или недостаток навыков. Мы договоримся, что будет считаться улучшением, какую поддержку предоставлю я и когда вернёмся к оценке. Зафиксирую договорённость и буду давать своевременную обратную связь по тем же критериям, отмечая также прогресс. Если разрыв сохранится, вместе с ответственным кадровым специалистом пройду установленный процесс организации, рассмотрев соответствие роли и доступную поддержку. Сохраню конфиденциальность и не стану обещать исход, который не могу гарантировать. У команды при этом должны оставаться понятные ожидания по работе: помощь одному человеку не означает незаметную передачу его неограниченной нагрузки коллегам.
Читать: [re:Work] Google's New Manager Training Slides
19. Как вы будете действовать, если сильный инженер своим поведением регулярно создаёт конфликты с коллегами?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Я разделю ценный результат инженера и поведение, которое наносит вред, затем соберу конкретные примеры и выслушаю участников. Техническое несогласие само по себе не является нарушением: обоснованное возражение требует другого ответа, чем постоянные перебивания, сокрытие информации или личные нападки. На личной встрече объясню наблюдаемые последствия и обозначу, что сотрудничество входит в оценку работы, в том числе для самого сильного специалиста. Мы согласуем конкретные изменения, поддержку, например коучинг, и срок проверки. Также проверю, не поощряют ли такое поведение командные стимулы или неясные права принятия решений, и исправлю эти условия. Дальнейшая оценка должна опираться на наблюдаемые результаты и взаимодействие, не превращая коллег в публичное жюри. Если вредное поведение продолжится, воспользуюсь установленным кадровым процессом организации. Сохранение индивидуального результата не оправдывает бессрочный ущерб для всей остальной команды.
Читать: [re:Work] Google's New Manager Training Slides
20. Расскажите, как развивалась карьера человека, которого вы наставляли.¶
Поведенческий · Руководство инженерными командами · Чек-лист
Выбирайте человека, чей рост виден по свидетельствам, не зависящим от вашего мнения: зона ответственности, которую он теперь ведёт, решения, которые принимает без вас, оценка людей вне вашей линии подчинения. Начните с его цели и разрыва до следующего уровня, как он проявлялся в работе, а не со своей роли. Затем скажите, какой была помощь, потому что наставничество и спонсорство — разные вещи: вопросы и советы, которые помогали ему самому выбирать действия, или то, что вы выдвигали его на заметную работу. Интервьюер оценивает компромисс, который за этим стоит: задача на вырост может провалиться у всех на виду, а рост приходит, когда передаёшь решение, а не только задачу, поэтому назовите, где вы сознательно не вмешались и чего это стоило — скажем, более медленного или менее аккуратного результата. Чётко разделите заслуги: результаты — от его имени, ваша часть — скромнее, и проверьте себя одним вопросом: описал бы он вашу поддержку так же? Типичная ошибка — наставник, который решал всё сам. Закончите тем, с чем человек справляется сейчас и не справлялся тогда, и тем, что вы с тех пор делаете иначе.
Читать: [re:Work] Google's New Manager Training Slides
21. Что вы делаете, когда команда не согласна с предложенным вами направлением?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Сначала выясняю, о чём именно спор: о фактах, о прогнозе или о приоритетах — иначе обсуждение идёт по кругу. Прошу назвать предположения, на которых держится моё предложение, и беру самое сильное возражение, формулируя его вслух лучше, чем это сделал автор: если оно рассыпается, направление крепче, если нет — менять решение надо мне. Там, где спор упирается в неизвестную величину, дешевле не спорить, а поставить ограниченный эксперимент или прототип с заранее согласованным критерием; плата за это — время, поэтому срок фиксирую сразу. Дальше прямо говорю, чьё это решение: обсуждение открытое, ответственность моя. Решение, причины и отвергнутые варианты записываю в design-документ вместе с условиями пересмотра. Такой порядок избыточен, когда решение дёшево и обратимо: тогда быстрее попробовать, чем согласовывать.
Читать: Design Docs at Google
22. Расскажите о сложном организационном изменении, которым вы управляли и при котором уходили сильные инженеры. Как вы действовали?¶
Поведенческий · Руководство инженерными командами · Чек-лист
Выберите реальное организационное изменение, во время которого сильные инженеры действительно ушли, и назовите то, чем управляли лично вы. Объясните цель изменения и известные вам причины ухода; отделите обратную связь сотрудников от собственных предположений. Покажите последствия для оставшейся команды: нагрузку, доверие и обязательства по поставке. Затем разберите свои действия: проведённые разговоры, пересмотренные обещания, уточнённые зоны ответственности или изменённые практики. Выплата за удержание или новая встреча — действие, а не доказательство успеха. Приведите действительно доступные последующие наблюдения: новые уходы, показатели нагрузки или обратную связь, — и признайте другие возможные причины результата. Завершите тем, что теперь сделали бы раньше или иначе. Если вы не управляли такой ситуацией, прямо скажите об этом и предложите ближайший подходящий опыт, обозначив отличие: не нужно выдумывать уходы сотрудников или приписывать себе чужие полномочия.
Читать: Organizational Change Management
23. Как вы стабилизируете инженерную команду после смены руководства?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Первые недели трачу на слушание, а не на реформы: встречи один на один с командой и ключевыми партнёрами, вопросы о том, что мешает работать сегодня и чего люди опасаются завтра. Смена руководителя сама по себе снижает предсказуемость, поэтому любое раннее крупное изменение читается как угроза, даже вполне разумное. Дальше возвращаю ясность: какие приоритеты действуют сейчас, кто какие решения принимает, какие встречи и отчёты остаются, а какие исчезают. Срочные риски для поставки и для людей закрываю сразу, не дожидаясь полной картины. Потом делаю немного изменений, каждое с объяснением причины, и через фиксированный срок проверяю эффект по срокам, инцидентам, оттоку и прямым отзывам. Такой темп не годится, если команда уже в кризисе: там сначала останавливают падение, а слушают по ходу.
Читать: Organizational Change Management
24. Расскажите, как вы нашли ценную возможность и убедили группу людей её реализовать.¶
Поведенческий · Руководство инженерными командами · Чек-лист
Стройте ответ вокруг самой возможности, а не вокруг своей убедительности. Сначала объясните, что вы заметили и почему это было ценно: какой сигнал в данных, обращениях или метриках, какого порядка эффект вы ожидали и на каком основании. Дальше самое важное: у каждого участника был свой план на квартал, поэтому расскажите, чьи приоритеты вы задевали, какие возражения звучали и как предложение менялось от чужого вклада — коалиция держится на соавторстве, а не на уговорах. Хороший инструмент здесь письменный документ с вариантами, рисками и открытыми вопросами: спорят с текстом, а не со слухами. Затем приведите, что было реально сделано и какой вышел эффект, и честно обозначьте границы своего влияния: где решали другие и что не получилось. Ошибка — история, в которой вы убедили всех сразу и без потерь.
Читать: Design Docs at Google · Site Reliability Engineering
25. Расскажите о самом сложном продуктовом запуске, которым вы руководили.¶
Поведенческий · Программы и delivery · Чек-лист
Выбирайте запуск с решением, которое вели вы и которое могло пойти иначе, а сложным его делали зависимости вне вашего контроля, а не объём работы или переработки. Рамку дайте коротко — цель, жёсткие ограничения по срокам, качеству или регулированию, критический путь, — а историю команды, инструменты и полную хронологию вырежьте. Интервьюер отделяет ваш вклад от вклада команды, поэтому о своих решениях говорите в первом лице единственного числа, о работе команды — во множественном, и ждите уточняющих вопросов именно здесь. Затем разберите одно решение: варианты, что вы знали, чем пожертвовали и как его приняли те, кому оно чего-то стоило. Скажите, как определяли готовность до даты: критерии выпуска, план отката, дежурство. Закончите свидетельствами: какие критерии выполнены или нет в тех величинах, что обещали заранее, и одно изменение процесса, которое вы перенесли в следующие запуски, с признаком того, что оно сработало. Типичные ошибки — обзор, где вы ни разу ничего не решаете, и победный отчёт, где ни одна ставка не оказалась неверной.
Читать: Site Reliability Engineering · Design Docs at Google
26. За три недели до запуска LLM-функции оценка выявила много галлюцинаций в пограничных сценариях. Что вы предпримете?¶
Прикладной сценарий · Программы и delivery · Чек-лист
Первым делом перестаю обсуждать дату и выясняю характер риска: насколько тяжелы последствия такой ошибки, как часто она возникает на реальном распределении запросов, кого именно задевает и насколько надёжна сама оценка — маленький или нерепрезентативный eval-набор умеет и преувеличивать проблему, и прятать её. Потом сравниваю варианты по одной шкале вреда и стоимости: сузить функцию до сценариев, где она надёжна, добавить проверку человеком или честный отказ, лечить причину в поиске и промптах, перенести запуск. Каждый вариант чем-то платит: сужение бьёт по ценности, человек в контуре — по скорости и цене. Дальше назначаю владельца решения о запуске, письменные критерии готовности и план коммуникаций для пользователей и поддержки. Всё это не поможет, если ошибка в пограничном сценарии необратима: там запуск обсуждать нечего.
Читать: AI Risk Management Framework · Demystifying evals for AI agents
27. Расскажите о крупном межфункциональном проекте: неопределённости, препятствиях и задержках.¶
Поведенческий · Программы и delivery · Чек-лист
Проверяют здесь не выносливость, а то, как вы меняете способ работы по мере того, как картина проясняется. Начните с карты: какие результаты вы обещали, от чего они зависели и кто персонально отвечал за каждую зависимость — отвечают люди, а не команды. Дальше возьмите одно препятствие и покажите механику: по какому сигналу вы его заметили, а не узнали постфактум, что изменили в плане, порядке работ или уровне эскалации и чем при этом пожертвовали. Отдельно разведите три вещи: что сделано, какой это дало эффект и как он соотносится с исходной целью — если цель не достигнута, так и скажите. Частая ошибка — длинный рассказ про координацию, где нет ни одного решения. Заканчивайте тем, что теперь делаете раньше: обычно это ранняя проверка самой хрупкой зависимости.
Читать: Design Docs at Google · Site Reliability Engineering
28. Как вы организуете обновление устройств Alexa, уже установленных у пользователей дома?¶
System design · Программы и delivery · Чек-лист
Обновление устройств, которые стоят у людей дома, это не деплой, а операция в чужой среде: разные модели и версии прошивки, слабый Wi-Fi, розетка, выключенная посреди установки. Поэтому начинаю с состава: что меняется, какие устройства затронуты, сохраняется ли совместимость протоколов со старыми версиями, сколько весит пакет и когда его загружать, чтобы не мешать пользователю. Дальше выпуск волнами: свои устройства, небольшая группа, затем расширение по когортам с проверкой состояния после установки и метрикой вернувшихся в строй, а не только доставленных. Установка должна быть атомарной, с резервным образом и автоматическим возвратом на прежнюю версию при неудачном запуске или проверке состояния. Отдельно фиксирую пороги остановки выпуска, владельца решения об откате и что увидит поддержка. Против дефекта в самом механизме обновления это не спасает: может потребоваться сервис.
Читать: Site Reliability Engineering
29. Клиент хочет автоматизировать обработку страховых требований с помощью AI. Что вы сделаете за первые две недели?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Две недели дают один ограниченный процесс и решение, продолжать ли, а не прототип автоматизации выплат. Первую неделю я бы провёл с сотрудниками, которые разбирают заявления, и разложил процесс на шаги — приём, извлечение данных из документов, проверка покрытия, маршрутизация, решение по выплате, сама выплата — с объёмом, временем обработки и долей исключений на каждом, чтобы увидеть, куда на самом деле уходит время. Первым кандидатом обычно оказываются приём и сортировка документов, а не решение по выплате: ошибку извлечения поймает сотрудник дальше по процессу, и исправить её дёшево, а необоснованный отказ ложится на страхователя и несёт юридические риски, поэтому отказы остаются за человеком, а у необоснованного отказа, переплаты и задержки свои пороги. Вторая неделя уходит на базовую линию по прошлым заявлениям: время обработки, точность извлечения на дважды проверенной выборке, доля простых заявлений, которые могли бы пройти без ручной обработки. У пилота появляются критерии приёмки по каждому типу заявлений и владелец в подразделении урегулирования. Если нет истории решений или доступа к системе учёта заявлений, за две недели получится оценка и план по данным, и сказать об этом сразу — это и есть результат.
Читать: Building Effective AI Agents · AI Risk Management Framework
30. Руководитель клиента хочет закрыть AI-пилот из-за постоянных ошибок. Что вы сделаете в ближайшие 48 часов?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
В первые часы признаю проблему прямо, без объяснений, почему так вышло: доверие уже потеряно, и спор о формулировках добьёт его окончательно. Дальше прошу конкретику — не «работает плохо», а десяток реальных случаев с запросом, полученным ответом и тем, каким он должен был быть. Только так разделяются три разные болезни: недоступные или грязные данные, дефекты самой системы вроде поиска и промптов, и несовпадение ожиданий с тем, на что функция вообще способна. Одновременно ограничиваю ущерб: отключаю самые опасные сценарии, ставлю проверку человеком или честный отказ там, где уверенности нет. К концу вторых суток предлагаю короткий проверочный этап с зафиксированным набором случаев, сроком и критериями продолжения или остановки. Если корень в ожиданиях, честнее закрыть пилот, чем чинить симптомы.
Читать: Site Reliability Engineering · Demystifying evals for AI agents
31. Клиент настаивает на дообучении своей модели на обращениях в поддержку, а вы считаете, что хватит поиска по данным. Как действовать?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Начинаю не со спора об архитектуре, а с вопроса, какую задачу клиент решает собственной моделью: нужно другое поведение и формат, нужны знания, которых нет в контексте, нужна другая цена запроса или нужен контроль над весами и размещением. Эти четыре потребности лечатся по-разному. Дообучение хорошо закрывает первую и может закрыть третью, если научить узкой задаче модель поменьше, но знания оно фиксирует на момент обучения, стареет вместе с обращениями в поддержку и перенимает ошибки, которые допускали в них операторы, тогда как поиск по данным обновляется правкой источника. Дальше собираю представительный набор задач из их же тикетов с ожидаемыми ответами и честно сравниваю подходы на нём, включая гибридный. И до рекомендации проговариваю цену владения: разметка, качество данных, повторное обучение при смене базовой модели, оценка, миграция. Если требование идёт от регулятора или от изоляции данных, спор о качестве неуместен.
Читать: Rules of Machine Learning · Building Effective AI Agents
32. Базовую модель работающего агента отключат через 60 дней. Как вы проведёте миграцию без потери качества?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Шестьдесят дней не сдвинуть, а скрытая зависимость в том, что оценка должна появиться раньше выбора кандидата, поэтому первая неделя уходит на измерительный инструмент, а не на пробы моделей. Качество агента принадлежит не модели, а модели вместе с промптами, схемами инструментов и парсерами, подогнанными под её привычки, поэтому преемник проседает не оттого, что слабее, а оттого, что иначе оформляет вызовы инструментов, отказывает в других местах или понимает инструкции буквальнее. Я бы зафиксировал eval-набор из записанного трафика и известных сбоев и прогнал его в теневом режиме на кандидатах, с порогами по срезам, а не одним средним. Компромисс — глубина против запасного варианта: тщательно перенести промпты на одного преемника — лучшее качество; держать живым второго кандидата дороже, но после отключения старой модели это единственный путь отката. Переход идёт от теневого режима к небольшой доле и дальше, в рабочие часы, с заранее предупреждёнными клиентами. Граница: если какой-то срез к согласованной дате не дотягивает до прежнего уровня, я решаю, что урезать, и говорю об этом прямо, а для задач без объективной проверки закладываю время на разбор людьми.
Читать: Demystifying evals for AI agents · Site Reliability Engineering
33. Клиент жалуется, что чат-бот на восьми GPU слишком медленный и дорогой. У вас неделя работы с ним; как её использовать?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Неделю начинаю с измерений, а не с идей: какой реальный профиль нагрузки, как распределены задержки по процентилям, а не в среднем, из чего складывается время ответа — поиск, prefill, decode, внешние вызовы, — какая утилизация восьми GPU и сколько стоит одна успешно решённая задача пользователя. Обычно жалоба клиента именно про последнюю величину, а не про цену токена. Дальше профилирую и только потом выбираю рычаг: батчинг и параметры сервинга, модель поменьше или квантование, сокращение контекста и более точный поиск, стриминг и кеш для ощущаемой скорости. Порядок такой, потому что сервинг часто недогружен и его настройка не меняет ответов, а модель поменьше или квантованная их меняет и требует полной повторной оценки качества. Каждое изменение проверяю на той же записанной нагрузке с ограничениями по качеству и надёжности. Если узкое место в источниках данных или в самом сценарии, оптимизация инференса не поможет.
Читать: Site Reliability Engineering · Rules of Machine Learning
34. Компания хочет за четыре недели запустить ответы по двум миллионам внутренних файлов без вывода данных за пределы VPC. Как определить объём пилота?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Четыре недели и два миллиона файлов — это разговор про выбор, а не про полноту. Сначала сужаю: какие коллекции документов действительно нужны, у кого есть права на них сейчас, какие сервисы разрешены внутри периметра и какие полтора десятка вопросов сотрудников стоят дороже всего. Права доступа не постобработка: индекс должен хранить метки, а поиск фильтровать по правам спрашивающего, иначе пилот сам станет каналом утечки. Дальше беру представительную часть данных, а не случайную: в ней должны быть свежие и устаревшие документы, дубликаты, разные форматы, потому что именно они ломают качество ответов. Сквозной путь реализую целиком, пусть и на узком срезе. Заранее согласую приёмочные проверки, владельца эксплуатации и то, чего пилот не докажет: нагрузку, полное покрытие и стоимость на всём объёме.
Читать: Architect multitenant solutions on Azure · AI Risk Management Framework
35. Торговый агент может инициировать платежи. Как доказать, что каждый платёж соответствует реальному разрешению пользователя?¶
System design · Платежи и регулируемые отрасли · Чек-лист
Платёж должен опираться на отдельное проверяемое разрешение, а не на то, что агент так понял пользователя. Намерение выражается явным объектом с ограничениями — сумма или лимит, получатель, валюта, срок действия, условия — и подписывается так, что его можно предъявить позже; именно на этом построен AP2, где подписанные мандаты связывают согласие пользователя с конкретной покупкой и платежом и дают непротиворечивый след. Полномочия проверяются в момент исполнения на стороне платёжной части: если сумма или получатель вышли за границы разрешения, нужно новое подтверждение, а не догадка агента. Аудиторский след хранит, что пользователь одобрил, что агент предложил и что исполнилось. Важно различать подтверждение полномочий и завершение расчётов: авторизация не означает, что деньги дошли. Подпись подтверждает подписанта и неизменность мандата; подлинное согласие требует доверенного процесса одобрения. Лимиты и возможность отзыва всё равно нужны.
Читать: AP2 - Agent Payments Protocol Documentation · Agentic Commerce Protocol · Universal Commerce Protocol (UCP)
36. AI-агент поддержки инициировал возврат, после чего платёжный API не ответил вовремя. Как восстановить работу без двойного возврата?¶
System design · Платежи и регулируемые отрасли · Чек-лист
Таймаут не означает, что возврат не прошёл, поэтому неизвестный исход я бы рассматривал как задачу сверки, а не как повод повторить вызов. Каждой операции присваивается стабильный идентификатор, созданный до первого обращения, а намерение сохраняется в своей базе раньше, чем уходит запрос, иначе повтор не с чем связать. Повтор идёт с тем же ключом идемпотентности по контракту поставщика, с экспоненциальной задержкой и случайным разбросом; если ответ снова неоднозначен, статус выясняется запросом состояния или сверкой выгрузок, а не вторым возвратом. Учитывать нужно конечный срок жизни ключей, одновременные попытки с одним ключом и изменение суммы, которое делает запрос уже другой операцией. Проверил бы поведение при параллельных повторах и путь ручной эскалации. Сквозного выполнения ровно один раз не бывает: это повтор с дедупликацией и последующей сверкой.
Читать: Designing robust and predictable APIs with idempotency
37. Банк хочет внедрить AI-ассистента, предлагающего сотрудникам решения по обращениям. Какие данные и меры контроля нужны перед расширением запуска?¶
Прикладной сценарий · Платежи и регулируемые отрасли · Чек-лист
До расширения нужно зафиксировать, какие решения ассистент затрагивает, кого из клиентов они касаются и где проходит граница его полномочий: он предлагает, сотрудник решает, и это должно быть правдой в интерфейсе, а не декларацией. Данные я бы собрал двух видов — набор реальных обращений с известным правильным исходом, включая редкие и дорогие ошибки, и поведение сотрудников: доля принятых и отклонённых рекомендаций, отмены и исправления после принятия. Механизм здесь неприятный: подсказка смещает внимание, и согласие быстро становится формальным, поэтому качество подсказки измеряется вместе с качеством решений людей. Дальше назначаются владельцы, мониторинг, порядок эскалации и поэтапное расширение по сегментам с готовой остановкой, а применимые требования юрисдикции проверяются отдельно с юристами. Качество на исторических обращениях не предсказывает поведение при новых продуктах и незнакомых схемах мошенничества.
Читать: AI Risk Management Framework · Supervisory Letter SR 11-7 on guidance on Model Risk Management
38. Почему вы хотите работать в Anthropic и в чём не согласны с её подходом?¶
Самопрезентация · Поведенческие вопросы и ценности · Чек-лист
Мотивацию стройте на проверяемой конкретике: назовите публикацию, продукт или решение компании, которое вы разбирали, и объясните, как оно связано с вашей работой и тем, чем вы хотите заниматься дальше. Общие слова про миссию звучат у всех и ничего не сообщают о вас. Вторая половина вопроса важнее первой: несогласие должно быть настоящим, с внятным основанием, и обязательно с ответом на вопрос, какие данные или результаты изменили бы вашу позицию — это отличает суждение от позы. Предмет спора берите по существу работы, а не безопасную мелочь и не обвинение. Заканчивайте тем, как вы собираетесь работать, сохраняя разногласие: в чём ваш вклад, как вы доносите возражение внутри и почему выполняете решение, принятое не в вашу пользу. Перед разговором обновите факты по публичным материалам компании.
Читать: Careers
39. Расскажите о своей ошибке, её последствиях и последующих изменениях в работе.¶
Поведенческий · Поведенческие вопросы и ценности · Чек-лист
Берите ошибку, которая действительно стоила денег, времени или доверия, иначе ответ прозвучит как скрытое хвастовство. Начните с решения: что вы выбрали, какими данными располагали тогда и почему это выглядело разумным — так собеседник видит ваше мышление, а не только исход. Дальше последствия и восстановление, без размазывания вины по обстоятельствам и коллегам: разбор без поиска виноватых означает честный анализ причин, а вовсе не отказ от собственной ответственности. Самая частая ошибка ответа — формулировка вроде «слишком много брал на себя», которая маскирует достоинство под недостаток. Заканчивайте изменением, которое осталось с вами: другое правило принятия решений, проверка перед выпуском, привычка писать разбор, — и признаком того, что оно сработало, например похожей ситуацией, которая пошла уже иначе.
Читать: Postmortem Culture: Learning from Failure
40. Расскажите о случае, когда вы были не согласны с человеком, но не смогли его убедить.¶
Поведенческий · Поведенческие вопросы и ценности · Чек-лист
Главное в этом ответе то, что было после спора, а не сам спор. Изложите обе позиции честно и в сильной форме: если чужая выглядит глупо, собеседник решит, что вы плохо слушали. Приведите свои аргументы и то, как вы их доносили — в разговоре, письменным документом, через данные. Затем ясно скажите, кто принял решение и почему это было его право, и опишите, как вы поддержали согласованные действия: возражают до решения, после — выполняют, не саботируя вполголоса. Назовите результат, даже если он подтвердил вашу правоту, но без торжества. Обозначьте и границу: чего вы делать не стали бы и в какой ситуации пошли бы на эскалацию. Заканчивайте выводом, обычно про то, чего не хватило в аргументации или к кому стоило прийти раньше.
Читать: Leadership Principles
41. Объясните продуктовые компромиссы при выборе модели.¶
Знания · Стратегия и метрики AI-продукта · Чек-лист
Задачу и критерий прохождения я бы зафиксировал до любых прогонов, на реальных примерах продукта, потому что разрыв на лидербордах на собственном распределении может сократиться или перевернуться. Для каждого кандидата измерил бы долю прохождения, стоимость прошедшего ответа с учётом повторов и времени людей на исправление сбоев и p95 задержки от начала до конца, с поиском и вызовами инструментов, — именно этого ждёт пользователь. Неочевидный компромисс связан с рассуждающими моделями: они могут поднять долю прохождения и всё равно проиграть по стоимости и задержке, потому что токены рассуждения оплачиваются как выходные и тратятся до начала ответа. В пакетной обработке такая модель может победить, а для интерактивного сценария оказаться неприемлемой, поэтому направлять к ней только трудные случаи часто лучше, чем выбирать одну модель на всё. Дальше ограничения работают как фильтры, а не как веса: где модель можно развернуть, какие данные ей можно отправлять и хранит ли их провайдер, как часто версии меняются и выводятся из эксплуатации. Если ограничения проходит только одна модель, сравнивать нечего, и настоящая работа — держать оценку готовой к её следующей версии.
Читать: Reasoning models
42. Какие бизнес-сценарии подходят для AI-агентов и как их сравнить?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Я ранжирую сценарии по нескольким свойствам, а не по энтузиазму. Объём и повторяемость, потому что выгода возникает на каждом исполнении; проверяемый результат, чтобы успех можно было подтвердить без человека, читающего всё; допустимость ошибки, поскольку агент иногда будет неправ и вопрос в цене этого; и обратимость действий. Триаж поддержки, бэк-офисная работа с данными и задачи «найти и обобщить» обычно проходят хорошо; необратимое и регулируемое — обычно нет. Сравнение, на котором я настаиваю, — против более дешёвого варианта: одного промпта, фиксированного процесса или обычной автоматизации. Автономия стоит своих денег лишь тогда, когда путь действительно различается от случая к случаю: агенты дороже на задачу и добавляют надзор, аудит и разбор инцидентов, которых не видно в демо. Поэтому пилот я бы начал с самого трудного измеримого куска и считал минуты человека, ушедшие на исправления, а не только выполненные задачи.
Читать: Building Effective AI Agents
43. Как вы установите цену корпоративного AI-продукта, какие затраты обязательно учтёте и как кастомизация под каждого клиента влияет на маржинальность?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Цена корпоративного AI-продукта — вопрос маржи, замаскированный под вопрос ценности, поэтому я начинаю со структуры затрат на аккаунт: инференс, включая повторы и токены самой оценки качества; поиск, индексация и хранение их корпуса; стоимость работы людей на внедрении, поддержке и разборе инцидентов; инженерное время на поддержание их конфигурации. Затем метрика цены: оплата за места предсказуема для покупателя, но отвязывает выручку от использования, а оплата за потребление следует за затратами и пугает закупки, поэтому частый ответ — платформенный платёж плюс тарифицируемое использование с обязательным минимумом. Маржа же по-настоящему исчезает в кастомизации. Индивидуальная интеграция или набор оценок под клиента — не разовая работа, а повторяющееся обязательство, которое заново вскрывается при каждом обновлении модели, поэтому я бы продавал её отдельно или отказывался до продуктизации. Смотреть я бы стал на валовую маржу по каждому аккаунту, а не на смешанную: средние скрывают убыточных клиентов.
Читать: What We Learned from a Year of Building with LLMs (Part I)
44. В чём AI-сервис ответов лучше обычного поиска, а в чём уступает? Что вы улучшите первым?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Сравнивать имеет смысл только по задачам. Сервис ответов выигрывает там, где работа пользователя — синтез: ответ размазан по нескольким источникам, нужно сравнение, тема незнакома и её пока не выразить ключевыми словами; один проход заменяет пять вкладок. Обычный поиск по-прежнему сильнее в навигации, где пользователь знает адрес и ссылка быстрее абзаца, в запросах, требующих самого свежего состояния, и везде, где источник человек должен оценить сам, потому что ответ стирает, кто это сказал и когда. Характерный провал — уверенный синтез на слабых доказательствах, чего поиск никогда и не обещал. Поэтому первым я бы улучшал атрибуцию: ссылки на уровне утверждений, проверяемые одним взглядом, и видимую свежесть, с метриками — доля утверждений в выборке, которые процитированный источник действительно подтверждает, и как часто пользователи всё равно переформулируют запрос. Если ответ верен, но непроверяем, корпоративные и исследовательские пользователи ему не поверят.
Читать: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
45. Как оценивать корпоративного AI-ассистента, если ваша команда не может просматривать данные клиента?¶
System design · AI-платформа и операционная модель · Чек-лист
Если я не вижу данные, я переношу измерение туда, где они живут, и забираю оттуда только числа. Стенд оценки работает внутри среды клиента, считает баллы, категории сбоев и счётчики, а наружу отдаёт агрегаты с минимальным размером ячейки — никогда примеры и расшифровки. Разметку делают их люди, а не мои: я даю рубрику и план выборки, а затем проверяю согласованность между их ревьюерами, потому что рубрика, применяемая по-разному, хуже отсутствия рубрики. Рядом я собираю прокси-набор из публичных или синтетических документов, похожих на их корпус, — именно на нём идёт ежедневная работа. Компромисс честный: прокси-данные упускают ровно то распределение, которое ломается в продакшене, а агрегаты сообщают, что категория сбоит, не показывая почему. Поэтому я отдельно договариваюсь об узком канале эскалации: обезличенный или согласованный клиентом пример, когда дефект требует диагностики, вместо постоянного доступа.
Читать: Demystifying evals for AI agents
46. Команда внедрила AI-инструменты программирования, но ревьюерам трудно проверять изменения. Как вы разовьёте недостающие навыки?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Пробел не в умении пользоваться инструментом: ревью проектировалось под изменения, которые человек писал постепенно, а теперь получает большие правдоподобные диффы, которых никто не набирал руками. Поэтому я бы сначала починил ответственность: автор отвечает за изменение независимо от того, чем оно создано, а pull request, который никто не может объяснить, не идёт на ревью. Конкретно: автор формулирует замысел, тесты, закрепляющие поведение, и что проверил сам; ревьюеров учат читать тесты раньше реализации, смотреть граничные случаи и ветки ошибок, где сгенерированный код слабее всего, и отклонять изменение, слишком большое для осмысления. Я бы держал изменения небольшими и вкладывался в тесты как в устойчивую проверку: человек не успеет прочитать всё, что выдаёт генератор. Но тесты, сгенерированные вместе с кодом, могут закрепить то же неверное понимание задачи, поэтому опираться на них можно только после того, как их сверили с заявленным замыслом. Измерял бы пропущенные дефекты, долю откатов и время ревью, но никогда не охват использования инструмента — оно ничего не говорит о понимании.
Читать: Designing AI resistant technical evaluations
47. Расскажите о своём последнем стратегически важном найме инженера. Как вы определили планку и оценили, решил ли найм исходную задачу?¶
Поведенческий · Руководство инженерными командами · Чек-лист
Возьмите последний реальный стратегически важный найм и объясните, какая компетенция была нужна организации, вместо изложения общей кадровой философии. Назовите свои полномочия: вы могли отвечать за роль, проектировать оценку или проводить интервью, не принимая окончательного решения. Объясните, почему в той ситуации найм оказался предпочтительнее обучения, временного привлечения эксперта или сокращения объёма работы. Сформулируйте планку через задачи, которые предстояло выполнять человеку, и доказательства, которыми последовательно проверяли готовность к ним. Покажите существенный компромисс, например между немедленным знанием предметной области и способностью создать новую компетенцию, не раскрывая данные кандидатов. Затем опишите адаптацию и наблюдаемые результаты найма. Если человек пришёл недавно, прямо скажите, что стратегический эффект пока неизвестен. Если такого найма не было, обозначьте это и разберите ближайшее кадровое решение, не превращая участие в ответственность за весь процесс.
Читать: [re:Work] Google's New Manager Training Slides
48. Как вы задаёте стандарты инженерного качества в команде?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Стандарт, живущий на вики-странице, — это предпочтение; стандарт, живущий в пути по умолчанию, — реальность. Поэтому я начинаю с наблюдаемых результатов: пропущенные дефекты, доля откатов, время восстановления, задержка ревью, покрытие тестами рискованных участков — и договариваюсь, что считается хорошим, иначе ревью превращается в спор о стиле. Затем соразмеряю требование риску: правка текста и изменение платёжного пути не должны проходить один и тот же барьер, иначе барьер начнут обходить. Всё, о чём договорились, уходит в инструменты, шаблоны, линтеры и CI, чтобы простой путь был и правильным. Писал бы я это вместе с сильными инженерами, а не за них: навязанный извне стандарт исполняют для вида, а не соблюдают, — и пересматривал бы его по цифрам: барьер, который никогда ничего не ловит, — чистые издержки.
Читать: Site Reliability Engineering
49. Исследователям нужно продолжать эксперименты, а продуктовым инженерам — выпустить надёжный сервис. Как вы распределите ответственность и передачу работы?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Это две разные планки, а не две степени строгости, поэтому я разделяю их структурно. Исследование оценивается по скорости получения знаний и может быть неаккуратным, недокументированным и брошенным; эксплуатация оценивается по надёжности и имеет владельца, которого будят. Границей становится контракт передачи: стабильный интерфейс, свидетельства оценки на согласованном наборе и названный владелец, который её принимает; ничто не попадает в релизный путь просто потому, что интересно. За этой границей продуктовая команда держит версионирование, гейты и путь отката, поэтому исследовательское изменение — кандидат, а не свершившийся факт. Я бы сохранил один общий набор оценок, которому доверяют обе стороны: такие споры обычно идут именно о доказательствах. Настораживает меня картина, когда исследователи бессрочно дежурят по собственному прототипу: это тихо заканчивает исследования и служит сигналом либо довести прототип до продакшена, либо от него отказаться.
Читать: Rules of Machine Learning
50. Как вы спланируете AI-программу, если её основная исследовательская гипотеза может не подтвердиться?¶
Прикладной сценарий · Программы и delivery · Чек-лист
Я планирую неопределённость, а не сроки. Первый шаг — записать гипотезу настолько точно, чтобы она могла оказаться ложной, и выстроить работу так, чтобы самый дешёвый опровергающий эксперимент шёл первым: программа, узнавшая на девятом месяце, что её основное допущение неверно, восемь месяцев потратила впустую. Контрольные точки поэтому определяются тем, какую неизвестность они снимают, а не сданными артефактами, и к каждой прилагается заранее согласованное правило решения: какой результат продолжает работу, какой разворачивает её, какой останавливает. Договориться об условии остановки до того, как все вложились, — и есть главный приём: потом это превращается в референдум о чьей-то компетентности. Я бы параллельно финансировал резервный путь, чтобы было что выпустить при неподтверждении гипотезы, и докладывал прогресс как снятую неопределённость. Программа, отчитывающаяся только процентом готовности, не управляется.
Читать: Design Docs at Google
51. Инженерная команда, эксплуатация и риск-функция расходятся в оценке готовности запуска. Как принять решение, основания которого можно проверить?¶
Прикладной сценарий · Программы и delivery · Чек-лист
Расхождение в оценке готовности обычно сводится к расхождению в критериях, которые никто не записал, поэтому я перестаю собирать согласования и начинаю переводить возражения в проверяемые утверждения. Каждая команда называет, что должно быть верно для запуска: доля ошибок ниже заявленного порога, отработанный runbook, извлекаемый аудиторский след — и прилагает подтверждающие данные. Большая часть конфликта растворяется уже здесь: эксплуатация и риск-функция спорят не о цифрах, а беспокоятся о разных режимах отказа. Затем я до встречи явно фиксирую права решения: кто решает, с кем обязательно советуются и у кого действительно есть право вето — ограниченное политикой, а не общим дискомфортом. Всё нерешённое оформляется как принятый остаточный риск с названным владельцем, мерой снижения и датой пересмотра, чтобы решение можно было проверить. Вето, за которым нет критерия, — и есть то, что нужно разрешить.
Читать: AI Risk Management Framework
52. Контакт-центр хочет заменить телефонное меню голосовыми агентами. Как вы проведёте проект?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Я бы определял охват по типам обращений, а не заменял меню целиком. Взять распределение причин звонков и выбрать несколько обращений, которые дают основной объём и имеют проверяемое разрешение; длинный хвост оставить на прежнем пути, потому что голосовой агент, плохо делающий всё, хуже меню. Мерой успеха должна быть честная доля самостоятельных решений — звонки, действительно закрытые без человека, а не просто завершённые, — и я бы отслеживал повторные звонки в течение суток: именно там проявляется фиктивная автономность. Перевод на оператора — полноценная проектная задача, а не ветка отказа: он несёт расшифровку и то, что уже было предпринято, и никогда не возвращает звонящего в цикл. Дальше готовность эксплуатации до запуска: цели по задержке, обработка перебиваний, мониторинг брошенных звонков и откат к меню. Пилот я бы сделал на одном обращении в одном регионе и расширял по данным.
Читать: Building Effective AI Agents
53. Продуктовая команда просит исключение из правила безопасности AI для одного корпоративного клиента. Как оценить, согласовать и ограничить срок такого исключения?¶
Прикладной сценарий · Безопасность, защита и governance · Чек-лист
Сначала я спрашиваю, от чего это правило вообще защищает: часть просьб направлена на снятие контроля, чьё назначение никто уже не помнит, а часть — разумные запросы, заблокированные неудачной реализацией. Ещё я спрашиваю, кто понесёт вред при ослаблении правила: почти никогда это не та команда, что просит. Если риск реален, ответом обычно оказывается не бинарное исключение, а более узкий путь: компенсирующая мера, суженная область, проверка человеком вместо автоматической блокировки, журналирование, делающее остаточный риск наблюдаемым. Всё, что выдаётся, ограничивается этим клиентом и этим применением, а не участком кода в целом: исключение в общем коде незаметно становится новым поведением по умолчанию. У него появляется названный ответственный владелец со стороны бизнеса, а не инженер, который это реализовал, дата истечения и пересмотр, способный отказать в продлении. Ловушка, которой надо избегать, — вечное временное исключение, поэтому число открытых исключений я бы показывал руководству постоянно.
Читать: AI Act
54. Расскажите о противоречащих приоритетах участников проекта и о том, как вы согласовали действия.¶
Поведенческий · Поведенческие вопросы и ценности · Чек-лист
Берите конфликт, где обе стороны были правы: история, в которой одна сторона просто ошибалась, проверяет ваши суждения о людях, а не умение согласовывать. Назовите, по какой цели оценивали каждого участника, — обычно именно там и лежит источник расхождения, и произнести это вслух означает сделать большую часть работы: обязательство перед клиентом, цель по надёжности и срок по комплаенсу бывают действительно несовместимы, и никто при этом не ведёт себя плохо. Затем покажите, как вы сделали видимым сам выбор между целями: варианты, их цену и то, чьей цели каждый из них вредил, вместо поиска компромисса, о котором никто не просил. Будьте конкретны в решении и в том, чем пожертвовали, включая собственный приоритет, если так и было. Завершите свидетельством, что договорённость держалась: письменная фиксация, к которой потом возвращались, метрика, принятая обеими сторонами, — и избегайте финала, где все просто согласились после ваших объяснений.
Читать: Organizational Change Management
55. Расскажите об обратной связи, которую было трудно услышать, и о том, как вы её использовали.¶
Поведенческий · Поведенческие вопросы и ценности · Чек-лист
Проверяют, можете ли вы и сейчас услышать эту критику, поэтому изложите обратную связь в тех словах, в которых её действительно дали. Смягчённые версии вроде «мне сказали больше коммуницировать» выдают, что вы её так и не приняли. Признать первую реакцию — нормально и делает ответ достоверным: большинство сначала защищается и только потом размышляет. Важен следующий шаг: что вы пошли и проверили — спросили других, видят ли они то же самое, или поискали подтверждение в собственных результатах, — вместо того чтобы принять или отвергнуть на основании слов одного человека. Затем назовите конкретное изменение, чем оно уже, тем лучше, и более поздний случай, по которому видно, что оно закрепилось. Избегайте двух финалов: где обратная связь в итоге оказалась несправедливой и где вы просто стали больше стараться, — ни один из них не показывает, что что-то изменилось.
Читать: [re:Work] Google's New Manager Training Slides
56. Представьте крупную инициативу, которой вы руководили: что сработало, что нет и чему вы научились.¶
Самопрезентация · Программы и delivery · Чек-лист
Выбирайте инициативу, где вы отвечали за результат, а не за отдельное направление, и начните с исходной цели в том виде, в каком её ставили, — объём, срок, метрика: честная оценка сравнивает итог именно с ней, а не с тем, что в итоге выпустили. Дальше оценивайте по двум осям. Планирование: какие допущения оказались неверны — о спросе, об оценке трудоёмкости, о зависимости. Исполнение: где команда плохо реализовала хороший план или, наоборот, вытащила слабый. Интервьюер слушает, умеете ли вы их различать, потому что выводы из них разные. Сделайте раздел о том, что не сработало, содержательным: одно ваше собственное решение, которое вы бы сейчас отменили, и во что оно обошлось. Типичная ошибка — список неудач из того, что с вами случилось, вроде реорганизации или подрядчика. Если рассказываете со слайдами, отдайте неудачам столько же места, сколько успехам: уточняющие вопросы пойдут туда, где вы были расплывчаты. Заканчивайте результатом относительно исходной цели, включая разрыв, и практикой, которую поменяли после.
Читать: Postmortem Culture: Learning from Failure
57. Расскажите о техническом просчёте, из-за которого задержался проект.¶
Поведенческий · Программы и delivery · Чек-лист
Выбирайте просчёт, который был техническим и действительно вашим: допущение, что компонент выдержит рост нагрузки, что интеграция займёт неделю, что формат данных стабилен. Проверяют, умеете ли вы точно найти ошибочное допущение, поэтому сформулируйте его той фразой, в которую тогда верили, и объясните, почему при тогдашних данных оно выглядело разумным. Дальше часть, которую большинство пропускает: когда появились первые признаки, что оно неверно, и сколько времени прошло, прежде чем вы отреагировали? Часто именно в этом зазоре, а не в исходной ошибке, и набирается основная задержка. Конкретно назовите, сколько времени это стоило и на кого легло. Слабый финал — «стал закладывать запас в оценки»: запас не исправляет неверное допущение. Сильный называет изменение в том, как вы планируете: первым проверять самое рискованное техническое допущение коротким прототипом или записывать допущения в design-документ с датой проверки, — и более поздний проект, где это вовремя поймало проблему.
Читать: Postmortem Culture: Learning from Failure · Design Docs at Google
58. Команда-поставщик данных не успевает к контрольной дате AI-программы. Как вы пересмотрите план и сообщите о последствиях?¶
Прикладной сценарий · Программы и delivery · Чек-лист
Сначала выясняю, что именно сдвинулось: опоздание данных скрывает очень разные ситуации — весь набор или один источник, разметка или сырые записи, неделя или задержка без понятного срока, и насколько я доверяю новой дате, учитывая, как команда уложилась в прошлую. Дальше провожу сдвиг по критическому пути. Наш срок двигается, только если работа, которой нужны эти данные, лежит на нём; стенд оценки, код пайплайна и пилот на частичной или синтетической выборке часто можно продолжать, так что реальное влияние бывает меньше, чем кажется по первому сообщению, — или больше, если разметка и обучение идут строго последовательно. Спонсорам приношу варианты, каждый со своей ценой: переставить работы, запуститься на частичных данных с названным риском по качеству, сократить объём или перенести срок, — и кто принимает решение. Единую дату передачи заменяю промежуточными точками, например ранней поставкой схемы и образца данных. Граница: если сдвиг вызван конфликтом приоритетов, перепланирование его не исправит — вопрос уходит к тому, кто задаёт приоритеты обеим командам.
Читать: Dependency Mapping
59. Какой самой большой командой вы руководили и как при таком масштабе менялись ваши обязанности?¶
Самопрезентация · Руководство инженерными командами · Чек-лист
Назовите число точно и со структурой: сколько прямых подчинённых, были ли среди них руководители, общая численность и за что отвечала организация. Раздувание за счёт функционального подчинения или подрядчиков рассыпается на первом уточняющем вопросе. Настоящий вопрос — вторая половина: что менялось в вашей работе по мере роста. Когда людей несколько, можно знать каждое проектное решение; когда под вами руководители — нельзя, поэтому назовите, что вы перестали делать сами: смотреть каждое изменение, вести каждый инцидент, собеседовать каждого кандидата, — и что пришло на замену: делегированные права на решения, письменные стандарты, ритм работы, встречи через уровень, несколько метрик, которые вы действительно читали. Интервьюер слушает, соответствовали ли ваши механизмы масштабу, а частый провал — большая команда, которой управляют как маленькой, и вы в роли узкого места. Если самая большая команда была небольшой, так и скажите и говорите о сложности: несколько функций, часовых поясов или заинтересованных сторон. Закончите сигналом, по которому было видно, работает модель или нет, и тем, что вы поменяли в ответ.
Читать: [re:Work] Google's New Manager Training Slides
60. Расскажите о споре в команде, который вы разрешили, сохранив обоснованные доводы обеих сторон.¶
Поведенческий · Руководство инженерными командами · Чек-лист
Выбирайте спор, где обе стороны защищали что-то настоящее, например скорость выпуска и удобство эксплуатации, а не тот, где кто-то просто ошибался: вопрос о том, чтобы сохранить обоснованные опасения, а не выбрать победителя. Изложите каждую позицию в сильнейшей форме. Интервьюер слушает переход от позиций к потребностям: чего каждый боялся, если победит другой. Позиции конфликтуют гораздо чаще, чем потребности, и когда потребности видны, нередко находится вариант, закрывающий обе, — поэтапный выпуск, ограничитель со сроком, обратимый первый шаг. Подчеркните, что это не деление пополам: оно обычно оставляет оба опасения закрытыми наполовину, и именно такой поверхностный компромисс здесь проверяют. Скажите, кто принимал решение и что бы вы сделали, если бы потребности действительно противоречили друг другу. Частая ошибка — роль мудрого посредника, чья идея всё решила. Заканчивайте свидетельствами: что в итоге сделали, остались ли закрыты оба опасения и как эти двое работали вместе дальше.
Читать: [re:Work] Google's New Manager Training Slides
61. Двум продуктовым командам нужна общая AI-инфраструктура, но ни одна не может выделить инженера. Как организовать работу без обещаний платформы, под которые нет людей?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Предотвратить нужно платформу, объявленную раньше, чем появились люди для её поддержки: команды начинают от неё зависеть, она деградирует, а за её сбои не отвечает никто. Поэтому сначала определяю, что действительно общее — доступ к моделям, стенд оценки, журналирование с маскированием, — и что каждая команда сделала бы сама: квартал дублирования бывает дешевле преждевременной общей зависимости, которая связывает два роадмапа. Если потребность действительно общая, ёмкость должна откуда-то взяться, и честных вариантов немного: выделить ставки, явно забрать долю из планов обеих команд или назначить одну команду владельцем, а другую — клиентом на письменно зафиксированных условиях. Рабочая группа добровольцев в этот список не входит. Дальше узкий устав: владелец, что входит в зону ответственности и что нет, ожидаемые сроки реакции, порядок запроса изменений и триггер для выделенной команды, например третий потребитель или растущая нагрузка на поддержку. Если ни одна команда не готова отдать часть плана, это вопрос приоритетов для их общего руководителя, а не задача оргдизайна.
Читать: Team Topologies
62. Клинический AI-сервис обрабатывает аудио, расшифровки и записи с защищённой медицинской информацией. Как это влияет на архитектуру и использование сторонних API моделей?¶
System design · Платежи и регулируемые отрасли · Чек-лист
Защищённая медицинская информация меняет порядок работы: прежде чем выбирать модель, я бы нанёс на карту все места, куда попадают данные, потому что на каждую копию распространяются те же обязательства. Это аудио, расшифровки и сгенерированные записи, но также логи, трассировки, кеши, очереди повторов, наборы для оценки и обращения в поддержку — обычно утечка случается именно там. Сторонний API модели допустим только как разрешённая обработка: договор, явно покрывающий медицинские данные, ограничивающий срок хранения, запрещающий обучение на них и фиксирующий, где они хранятся и у кого есть доступ. Без этого данные туда не уходят, а значит, может понадобиться другой поставщик или своя модель с более дорогой эксплуатацией. Дальше минимизация: каждый шаг получает только нужное, идентификаторы убираются там, где задача позволяет, а промпты и ответы не попадают в общее журналирование. Инструменты маскирования пропускают данные, поэтому измерил бы их пропуски на размеченной выборке и до запуска проверил удаление и аудит доступа. Согласие на запись и применимые обязательства зависят от юрисдикции и роли каждой стороны, поэтому их подтверждают юристы, а не архитектура.
Читать: OWASP Top 10 for LLM Applications
63. Отрефакторите небольшую плохо структурированную программу с проходящими тестами. Объясните первое изменение и сохранение наблюдаемого поведения.¶
Кодинг · Практический кодинг · Чек-лист
Прежде чем что-то трогать, я бы договорился, что здесь считается наблюдаемым поведением: возвращаемые значения, сообщения об ошибках, побочные эффекты вроде записанных файлов или порядка вывода, — и проверил, действительно ли проходящие тесты это фиксируют. Проходящие тесты защищают только то, что проверяют, поэтому там, где покрытие тонкое, сначала добавил бы характеризующие тесты, которые записывают, что код делает сейчас, включая странные случаи, которые так и хочется исправить. Первое изменение должно быть маленьким, механическим и легко откатываемым: обычно выделить функцию из самого длинного блока или дать имя магическому значению, затем прогнать тесты. Каждый шаг — отдельный коммит, и рефакторинг я никогда не смешиваю с изменением поведения: иначе упавший тест не скажет, что именно сломалось; найденную ошибку исправляю отдельно, со своим тестом. Каждый шаг обосновываю ценой, которую он убирает, — правилом, повторённым в трёх местах, логикой, которую нельзя проверить изолированно, — а не вкусом. Если код скоро заменят или он почти не меняется, самый дешёвый рефакторинг — никакого.
Читать: Working Inside Existing Systems · Refactoring
64. Спроектируйте агента, создающего и обновляющего наряды в действующей ERP без дублирования или незаметного искажения операций.¶
System design · Агенты, инструменты и протоколы · Чек-лист
Я бы не пускал модель на путь записи в ERP: она выдаёт типизированную команду — создать или обновить наряд с явными полями, — а детерминированный код проверяет её по бизнес-правилам до любой записи: оборудование существует, переход статуса разрешён, открытого наряда на эту работу ещё нет. Дубли предотвращает стабильный бизнес-ключ, выведенный из исходного события, а не из формулировки модели и используемый как ключ идемпотентности, поэтому повторный вызов инструмента или перезапущенный агент находит существующий наряд, а не создаёт второй. Обновление несёт версию записи, которую прочитало, и отклоняется при конфликте: планировщик мог изменить наряд в промежутке, а молчаливая перезапись вслепую — именно тот путь, которым искажения проходят незамеченными. После таймаута агент сначала ищет запись по этому ключу и лишь потом повторяет. Каждая запись журналирует предложение, проверенную команду и ответ ERP; тестировал бы дубли событий, одновременные правки и искусственные таймауты. Проверка отсекает недопустимые состояния, но не правдоподобно неверные вроде корректного наряда не на то оборудование, поэтому значимые изменения требуют подтверждения.
Читать: Designing robust and predictable APIs with idempotency
65. Что вы будете делать, если MVP корпоративного AI-продукта слишком дорого или долго делать?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Слишком дорогой MVP обычно означает, что его делают как маленький продукт, а не как эксперимент, поэтому я бы вернулся к тому, что нам нужно узнать. Выписал бы допущения: проблема стоит того, чтобы за её решение платить; модель достигает нужного качества на документах этого клиента; данные действительно можно получить; процесс примет результат; покупатель проведёт продукт через проверку безопасности, — и ранжировал бы их по неопределённости и цене ошибки. В корпоративном AI самое рискованное редко интерфейс; обычно это доступ к данным и качество на реальных данных. Для каждого допущения — самая дешёвая проверка, способная его опровергнуть: прогнать модель офлайн на выборке данных клиента, ручной пилот, где недостроенную часть делают люди, обязательство партнёра по разработке на платный пилот. Заранее договорился бы, какой результат оправдывает разработку. Цена такого подхода: эти проверки не доказывают ни масштаб, ни стоимость интеграции; когда главный риск — сама интеграция, самая дешёвая честная проверка — тонкий сквозной срез у одного клиента.
Читать: Rules of Machine Learning
66. Кто в дискавери корпоративного AI-продукта является «персоной», где вы найдёте B2B-респондентов и как поймёте, что проблему стоит решать?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
В корпоративном сегменте нет одной персоны: есть пользователь, который делает работу, спонсор, который владеет бюджетом и целевой метрикой, и те, кто может заблокировать покупку, — безопасность, юристы, ИТ, владелец данных. Им нужно разное, и AI-продукт нередко погибает на блокирующих, а не у пользователей, поэтому дискавери должно охватить всех, лучше — несколько ролей внутри одной компании, чтобы увидеть, как на самом деле принимаются решения. Респондентов ищут там, где уже есть доверие: текущие клиенты и их аккаунт-менеджеры, переговоры отдела продаж, партнёры и интеграторы, бывшие коллеги. Холодные рассылки в основном доходят до тех, у кого есть свободное время. Чтобы понять, стоит ли проблему решать, смотрю не на заявленную боль, а на поведение: сколько уже тратят на обходные пути — люди, таблицы, подрядчик, — как часто это случается и готов ли спонсор вложить что-то дефицитное: доступ к данным, время экспертов, платный пилот. Интерес без обязательства — не свидетельство. А несколько крупных клиентов могут создать видимость всеобщей проблемы, поэтому проверил бы, повторяется ли она в разных сегментах.
Читать: How to recruit UX Research participants
67. Спроектируйте модерацию, сочетающую специализированные классификаторы и LLM при ограничениях задержки и нагрузки на проверяющих.¶
System design · Дизайн AI-систем · Чек-лист
Начинал бы с политики, а не с моделей: классы риска по вреду, и для каждого — соотношение цены ошибочного удаления и пропущенного нарушения, потому что именно эти допуски определяют всё остальное. Тяжесть решает и то, где модерация стоит относительно бюджета задержки: самые опасные классы удерживаются до проверки, а малозначимые можно публиковать и проверять асинхронно. Дальше каскад. Быстрые специализированные классификаторы оценивают всё; уверенные случаи с обеих сторон решаются автоматически; зона неопределённости уходит к LLM, которая читает текст политики и контекст, — медленнее и дороже, но лучше справляется с нюансами и с изменениями политики, для которых ещё нет обучающих данных; к людям попадают только тяжёлые случаи, оставшиеся спорными. Компромисс сидит в порогах: расширение зоны неопределённости повышает долю верных решений, но увеличивает задержку, стоимость и нагрузку на проверяющих, поэтому пороги задаю по классам по точности и полноте на размеченном наборе, а апелляции и отменённые проверяющими решения возвращаю как новую разметку. LLM-этап читает контент, написанный противником, поэтому им можно манипулировать, а размеченный набор устаревает по мере того, как противник адаптируется.
Читать: A Holistic Approach to Undesired Content Detection in the Real World · Llama Guard: LLM-based Input-Output Safeguard for Human-AI Conversations
68. Как вы сопоставите улучшение качества модели и снижение её интерпретируемости?¶
Прикладной сценарий · Безопасность, защита и governance · Чек-лист
Я бы не стал взвешивать это абстрактно, потому что интерпретируемость — не одно свойство: вопрос в том, для чего нам нужны объяснения в этом применении. Если решение надо объяснить человеку, которого оно касается, дать ему возможность оспорить его или передать на проверку независимому специалисту — кредитование, найм, клиническая сортировка, — то потеря этого может сделать лучшую модель непригодной при любой точности. Если модель ранжирует рекомендации, объяснения в основном нужны для отладки, и это закрывается другими средствами. Поэтому выигрыш сравниваю с последствиями ошибки и с мерами контроля, не опирающимися на внутреннее устройство модели: мониторинг результатов по сегментам, проверка человеком значимых случаев, более простая модель-конкурент в резерве. Объяснения постфактум помогают, но описывают приближение, а не реальное вычисление модели, поэтому как доказательство они слабее, чем кажутся. Я бы проверил, что улучшение держится на важных срезах, а не только в среднем: выигрыш непрозрачной модели может скрывать ухудшение для какой-то подгруппы, которое мы уже не сможем диагностировать. Там, где объяснение — требование, а не пожелание, никакой прирост качества его не покупает.
Читать: Supervisory Letter SR 11-7 on guidance on Model Risk Management · AI Risk Management Framework
69. Спроектируйте сервис, в котором несколько команд запрашивают общий набор данных без доступа к исходным записям.¶
System design · AI-платформа и операционная модель · Чек-лист
Главное решение — что считать допустимым результатом: запрет доступа к исходным записям не становится политикой, пока не сказано, какие выходные данные разрешены. Для каждой команды и цели я бы определил поля, агрегаты и минимальный размер группы, ниже которого результат скрывается. Напрямую к хранилищу команды не обращаются: они отправляют запросы сервису, который аутентифицирует вызывающего, применяет политику заявленной цели, переписывает запрос, чтобы соблюсти ограничения по строкам и столбцам, и проверяет результат перед выдачей. Неочевидная утечка идёт через агрегаты: два разрешённых запроса, разность которых выделяет одного человека, или одна и та же маленькая группа, нарезанная многократно. Поэтому добавил бы подавление малых ячеек, ограничения на пересекающиеся запросы, а для самых чувствительных данных — дифференциальную приватность, то есть откалиброванный шум в рамках бюджета приватности, который сильнее всего бьёт по точности на малых сегментах. Каждый запрос журналируется с вызывающим и целью, а проверял бы я попытками повторно идентифицировать людей через разрешённый интерфейс. Если команде действительно нужен анализ на уровне записей, честнее деидентифицированная выгрузка или контролируемая среда, где код выполняется рядом с данными, чем растягивать API агрегатов.
Читать: Guidelines for Evaluating Differential Privacy Guarantees (SP 800-226)
70. Корпоративный клиент сообщает, что Claude галлюцинирует в ассистенте с поиском по базе знаний. Как вы начнёте разбор ошибок?¶
Прикладной сценарий · Прикладные и клиентские сценарии · Чек-лист
Галлюцинация — это симптом, поэтому начал бы с конкретных случаев, нескольких десятков, если они есть, и для каждого с полной трассировкой: вопрос, что вернул поиск, собранный промпт и ответ. Без трассировок разговор идёт о впечатлениях. Дальше раскладываю каждый случай по одной из трёх корзин, потому что лечатся они по-разному. Ошибка поиска: нужный фрагмент существовал, но не попал в выдачу, или попал устаревший либо противоречивый документ. Неподтверждённая генерация: нужный фрагмент был в контексте, но ответ что-то к нему добавил или ему противоречит. Расхождение ожиданий: в корпусе ответа нет или пользователь ждал суждения, а не поиска; но и тогда заполнить пробел вместо того, чтобы сказать, что источники этого не покрывают, — часть дефекта. Показал бы клиенту распределение в цифрах, сначала занялся самой крупной корзиной и сохранил случаи как регрессионный набор. Ограничение: среди присланных примеров непропорционально много ярких провалов, поэтому прежде чем заявлять об улучшении, я бы измерил и случайную выборку обычного трафика.
Читать: Your AI Product Needs Evals
71. Вы отвечаете за портфель AI-инвестиций следующего квартала. Бюджет сокращён на 30%; конкурируют коммерческий пилот, обязательный проект контроля рисков и общая инфраструктура оценки. Как вы перераспределите деньги и людей и согласуете решение с руководством?¶
Прикладной сценарий · AI-платформа и операционная модель · Чек-лист
Сначала я уточню, к чему относится сокращение на 30% и какие обязательства нельзя изменить в пределах квартала. Для обязательного контроля нужен жизнеспособный минимальный объём; само название не оправдывает все предложенные функции. Сравню варианты портфеля по будущим затратам, подтверждённой пользе, неопределённости, зависимостям и реально доступным навыкам. Общая инфраструктура оценки может быть нужна двум другим проектам, поэтому одинаковое сокращение всех бюджетов способно уничтожить больше пользы, чем остановка одной инициативы. Предложу конкретное распределение с перечнем прекращаемой или откладываемой работы, переходными затратами и владельцами затронутых обязательств. Обсуждение с руководством должно показать упущенные возможности и остаточные риски, определить, кто вправе принять каждый компромисс, и завершиться записанным решением. Необязательное финансирование буду выдавать этапами по мере появления подтверждений и заранее задам повод пересмотреть выбор. Прошлые расходы объясняют ситуацию, но сами по себе не оправдывают новые инвестиции.
Читать: The Green Book (2026) · Product Management - Leadership
72. Как владелец инвестиций решите, продлевать ли управляемый AI-сервис или финансировать внутреннюю замену. Через шесть месяцев цена поставщика удвоится, а экспорт данных не воспроизводит поведение сервиса. Какое решение и план выхода вы утвердите?¶
Прикладной сценарий · AI-платформа и операционная модель · Чек-лист
Я сравню продление, пересмотр условий, частичную замену и внутреннюю разработку на одном горизонте планирования. В оценку войдут найм или вытесненная инженерная работа, проверка качества, интеграция, эксплуатация и период параллельной работы. Закупочная функция уточнит реальные даты уведомления и продления, а техническая команда проверит самое трудное допущение о переносимости на типичных сценариях. Одного экспорта данных недостаточно, если нельзя восстановить промпты, поведение поиска, инструменты или материалы оценки. До перевода клиентов замена должна пройти согласованные пороги качества задачи и эксплуатационной готовности. Утвержу вариант с наиболее обоснованной ценностью при этих ограничениях: возможно, временное продление с последовательным снижением зависимости. Решение включает владельца, выделенную ёмкость миграции, предел расходов и резерв непрерывности на случай непрохождения приёмки. План выхода без профинансированных людей и продемонстрированного первого переноса остаётся только намерением, а не готовой возможностью организации.
Читать: Managing technical lock-in in the cloud · Cost Optimization Pillar — AWS Well-Architected Framework
73. Вы руководите тремя инженерными менеджерами, которые ведут общую AI-инициативу. Двое обвиняют друг друга в пробеле оценки качества, а исполнительный спонсор уже обещал дату запуска. Как вы восстановите ответственность, не подменяя руководителей команд?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Я установлю, какого результата оценки не хватает, о чём договорились раньше и какие решения каждый менеджер действительно мог принимать. Ближайшая задача — закрыть риск, но перехват всех задач скроет проблему взаимодействия руководителей. Назначу ответственного за общий результат, согласую вклады команд и условия эскалации с менеджерами, оставив им планирование и выполнение внутри команд. Одновременно представлю спонсору несколько вариантов с подтверждениями: сузить запуск, перенести дату или принять только те риски, которые уполномоченный владелец действительно вправе принять. Обещание даты — ограничение для пересмотра, а не доказательство готовности. С каждым менеджером отдельно разберу его вклад в конфликт и изменю стимулы или границы, которые его поддерживали. Признаком успеха станет не только закрытый текущий пробел, но и следующее межкомандное решение, принятое через согласованный порядок без моего вмешательства в работу команд.
Читать: Director, Engineering · Communication · Team Topologies
74. Использование AI-продукта растёт, но достоверного улучшения результата клиента нет, а затраты на проверку увеличиваются. Спонсор хочет ещё квартал инвестиций. По каким данным вы расширите, сузите, приостановите или закроете продукт и что сделаете для текущих пользователей?¶
Продуктовый кейс · Стратегия и метрики AI-продукта · Чек-лист
Я отделю использование от дополнительной пользы клиенту и посчитаю стоимость успешного результата с учётом ручной проверки, поддержки и переделок. Для сравнения нужен обоснованный существующий процесс или вариант без AI; важно учитывать отбор пользователей, чтобы не приписать продукту успех тех, кто и раньше справлялся. До вывода о всеобщей неудаче поищу сегмент с реальной пользой. Если одна оставшаяся неизвестность способна изменить решение, предложу ограниченный эксперимент с пределом расходов, сроком и порогами, заранее согласованными с владельцем решения. Иначе ещё один квартал лишь откладывает выбор. Остановка требует плана для текущих пользователей: уведомления, альтернативного процесса, ответственного за поддержку и надлежащего обращения с данными. Зафиксирую также, какие новые подтверждения позволят вернуться к продукту. Цель — сохранить пользу клиентам и полученные знания, прекращая необоснованные расходы, а не защитить первоначальный запуск любой ценой.
Читать: Patterns of Trustworthy Experimentation: Pre-Experiment Stage · Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications · User Needs + Defining Success
75. Во время AI-развёртывания поставщик меняет поведение модели, и вредные действия затрагивают клиентов. Немедленно вернуть прежнюю модель невозможно. Как руководитель программы вы организуете сдерживание инцидента, работу с клиентами и обоснованный повторный запуск?¶
Прикладной сценарий · Программы и delivery · Чек-лист
Я запущу процесс реагирования и проверю, что назначен один руководитель инцидента с понятными эксплуатационными полномочиями. Моя роль руководителя программы — координировать зависимости и решения, а не отдавать несогласованные технические команды. Если прежняя модель недоступна, сдерживание может означать отключение действий, ограничение трафика или перевод клиентов на проверенный ручной процесс. Сохраню версии модели и конфигурации, следы действий и данные о затронутой группе, а клиентские владельцы наладят регулярные точные сообщения. Эскалация поставщику должна искать ограниченное решение без необоснованных обещаний срока восстановления. Сдерживание ещё не доказывает восстановление: нужны регрессионные проверки и проверки безопасности на типичных случаях, достаточная ёмкость резервного процесса и решение уполномоченного лица о запуске. Возвращать функциональность следует постепенно, с порогами остановки и владельцами мониторинга. После инцидента разбор должен охватить обнаружение изменений поставщика, обратимость действий и непрерывность работы, с назначенными и запланированными исправлениями.
Читать: Site Reliability Engineering · Postmortem Culture: Learning from Failure · AI Risk Management Framework
76. Кандидаты используют AI-ассистентов на технических интервью. Как вы перестроите процесс, чтобы он по-прежнему давал пригодный сигнал для найма?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Я начну с работы, которую предстоит выполнять нанятому человеку: постановки задачи, проверки незнакомого изменения, диагностики сбоя и объяснения решения. Затем выделю старые задания, которые теперь преимущественно измеряют доступ к ассистенту. Для каждого этапа нужны явные правила: инструменты можно разрешить в реалистичной работе, ограничить ради отдельного самостоятельного навыка или предоставить в контролируемой среде. Кандидаты должны узнать правила заранее и получить сопоставимый доступ. Я буду оценивать наблюдаемую логику, проверку, исправления и ответственность, добавляя изменение условий, которое показывает понимание результата. До запуска задания пройдут действующие инженеры и подготовленные интервьюеры; расхождения оценок необходимо разобрать. После запуска буду отслеживать опыт кандидатов и результаты дальнейшей работы, признавая, что небольшая выборка только нанятых людей не доказывает прогностическую точность. Цель — обоснованное решение о найме, а не соревнование с возможностями ассистентов.
Читать: Designing AI resistant technical evaluations · AI Interview Success: An Interviewer's Inside Guide
77. Несколько продуктовых команд работают через один внутренний AI-шлюз. Как сделать так, чтобы трафик, данные и кеши одной команды не влияли на другую?¶
System design · AI-платформа и операционная модель · Чек-лист
Я решаю вопрос изоляции по каждому общему ресурсу, а не один раз для шлюза целиком. Общие ресурсы — квота провайдера, мощность самого шлюза, кеши промптов и эмбеддингов, логи запросов и данные оценки. Каждый арендатор получает свои ключи, квоту и ограничение частоты, поэтому шторм повторов у одной команды ухудшает работу только этой команды; без персональных лимитов один инцидент съедает общую квоту. Кеши по умолчанию разделяются по арендаторам. Общий кеш префиксов не передаёт чужой текст, но попадание в кеш быстрее промаха, поэтому по времени ответа видно, встречался ли префикс раньше; там, где сами промпты чувствительны, этот канал стоит закрыть. В логах лежат промпты и ответы, поэтому доступ к трассировкам я ограничиваю арендатором и задаю срок хранения, а агрегированная телеметрия стоимости и задержек остаётся общей. Изоляцию проверяю нагрузкой на одного арендатора, наблюдая за остальными. Строгая изоляция стоит попаданий в кеш и денег; если все арендаторы — одно юридическое лицо с одной политикой данных, я скажу это прямо и ослаблю её осознанно.
Читать: Architect multitenant solutions on Azure · Prompt caching · Scaling your API with rate limiters
78. Провайдер объявил, что версия модели, от которой зависят ваши продукты, будет отключена через три месяца. Как вы проведёте переход во всех командах, которые её используют?¶
Прикладной сценарий · AI-платформа и операционная модель · Чек-лист
Срок задан извне, и риск здесь в расписании, а не в технологии, поэтому я начинаю с реестра: какие сервисы, промпты, базовые оценки и дообученные модели ссылаются на эту версию и на что именно каждый из них опирается. Версия модели — это зависимость, и отношение к ней как к значению в конфигурации — обычный путь к незаметной деградации. Каждая команда-владелец прогоняет свои оценки на замене до любого переключения: новая версия меняет поведение, поэтому промпты, форматы вывода и пороги обычно требуют доработки, и эта доработка входит в переход, а не следует за ним. Сервисы я перевожу по одному под флагом, пока старая версия ещё отвечает, чтобы откат был настоящим, и развожу во времени самые рискованные и самые нагруженные случаи. Не менее важно, что останется после: закреплённые версии, поддерживаемый реестр и владелец у каждой интеграции. Сложнее там, где у дообученной модели нет аналога на новой версии: тогда настоящий план — переобучение, а не переход.
Читать: Managing technical lock-in in the cloud · Rules of Machine Learning
79. Расходы на инференс общей AI-платформы за квартал удвоились, и ни одна команда не признаёт счёт своим. Как сделать расходы относимыми и управляемыми?¶
Прикладной сценарий · AI-платформа и операционная модель · Чек-лист
Никто не владеет числом, которого не видит, поэтому отнесение расходов идёт раньше контроля. На шлюзе я помечаю каждый вызов командой, функцией и средой, а затем показываю рядом с общей суммой стоимость запроса и стоимость успешно решённой задачи; честнее вторая единица, потому что более дешёвая модель, которая чаще ошибается, способна увеличить счёт. Дальше ищу, что изменилось. У удвоения разные причины — рост трафика, удлинение промптов или найденного контекста, переход на более сильную модель, повторы после таймаутов, прогоны оценок, отнесённые на продакшен, — и у каждой своё лечение: кеширование стабильного префикса, сокращение контекста, маршрутизация простых задач на меньшую модель, исправление политики повторов. После этого каждая команда получает бюджет и оповещение, которыми владеет, и понятный способ попросить больше. Жёсткого потолка без исключений я избегаю: он не убирает потребность, а переносит её в аккаунты, за которыми никто не следит. Обычно достаточно показывать расходы; перекладывать их на команды стоит лишь там, где команда действительно управляет своим объёмом.
Читать: Cost Optimization Pillar — AWS Well-Architected Framework · Prompt caching
80. Задержка и доступность вашей AI-платформы зависят от внешнего провайдера моделей. Что вы пообещаете внутренним командам и как будете это обещание выполнять?¶
System design · AI-платформа и операционная модель · Чек-лист
Я обещаю сквозной показатель, который платформа действительно удержит, и формулирую его в том, что чувствует вызывающая сторона: задержка на высоком перцентиле и доля запросов, завершившихся с пользой, измеренные на нашей границе, а не взятые со страницы доступности провайдера. Доступность, которой я не управляю, обещанием быть не может, поэтому цель опирается на собственные механизмы: таймаут под срок вызывающей стороны, ограниченный бюджет повторов, меньшая резервная модель, упрощённый, но честный ответ и очередь для работы, которая может подождать. С повторами нужно быть осторожным: наивные повторы во время перегрузки провайдера добавляют нагрузку системе, которая уже отказывает. Резервный путь меняет качество ответа, поэтому у него должна быть своя оценка, а вызывающая сторона должна видеть, каким путём её обслужили. Я публикую бюджет ошибок, описываю, что происходит после его исчерпания, и прямо называю отказы, которые остаются вне моего контроля. Если команде нужна более сильная гарантия, ответ — второй провайдер или зарезервированная мощность, и то и другое стоит денег.
Читать: Site Reliability Engineering · Scaling your API with rate limiters
81. Перед запуском ассистента с доступом к инструментам: как вы организуете состязательное тестирование и что позволит утверждать чистый результат?¶
System design · Безопасность, защита и governance · Чек-лист
Я иду от ущерба, а не от приёмов, и от двух разных атакующих: пользователя, который пытается заставить продукт сделать недопустимое, и недоверенного текста, который читает модель, — страницы, документа, результата инструмента, — содержащего инструкции. Второй важнее, когда у ассистента есть инструменты: там ущерб — это действие, а не фраза. Покрытие даёт сочетание автоматической генерации множества вариантов с людьми, которые систему не строили, и запись всех попыток, а не только удачных: тогда набор можно прогнать на следующей версии и обсуждать покрытие предметно. Находки уходят названным владельцам вместе с исправлениями, и я отличаю заблокированный класс атак от одной формулировки, которая перестала срабатывать. Честное итоговое утверждение узкое: атаки, которые мы пробовали, на этой версии в основном не прошли. Это не доказательство безопасности — полного решения против внедрения инструкций сегодня нет, — поэтому оно должно опираться на минимальные права и подтверждение значимых действий.
Читать: OWASP Top 10 for LLM Applications · AI Risk Management Framework · Prompt injection (series)
82. Организация внедрила AI-инструменты для разработки, и руководство хочет знать, дали ли они результат. Как вы ответите на этот вопрос убедительно?¶
Прикладной сценарий · Руководство инженерными командами · Чек-лист
Сначала я делаю вопрос отвечаемым, потому что за «дали ли результат» прячутся четыре разных утверждения: быстрее поставка, больше выпущенных изменений, выше качество, меньше рутины. Им нужны разные данные, и двигаться они могут в разные стороны: больше влитого кода при большей доле неудачных изменений — не победа. Я показываю результаты, которые чувствует заказчик, — время от задачи до поставки и долю неудачных изменений, — а не принятые подсказки и сгенерированные строки: те измеряют принятие инструмента и растут просто от его использования. Любому числу нужна база сравнения: чище всего её даёт поэтапное внедрение, иначе — сопоставимые команды или те же команды до и после с прямо названными мешающими факторами: найм, реорганизация, сезонность, крупная миграция. Я также измеряю, куда переехали усилия: сгенерированный код перекладывает нагрузку на ревью, и выигрыш в написании, который возвращается очередью на ревью, выигрышем не является. Опросы разработчиков — слабое свидетельство сэкономленного времени, но хорошее свидетельство того, где трение. Я прямо говорю, что такая схема решить не может, вместо намёка на причинность.
Читать: Patterns of Trustworthy Experimentation: Pre-Experiment Stage · Rules of Machine Learning