Собеседование на англоязычном рынке · Interviewing for the English-speaking market · урок 1 · 12 мин

Как отвечать на технический вопрос

Answering a technical question

Пройдено

Зачем

После урока у тебя будет одна структура ответа на любой технический вопрос вида «почини», «докажи», «что сделаешь первым» и список типичных ошибок, на которых срезаются кандидаты. На техническом раунде в US и UK оценивают не только знание, но и ход мысли вслух: собеседующий слушает, как ты разбираешь задачу, и копает follow-up вопросами.

Сначала части вопроса

Длинный вопрос почти всегда состоит из двух-трёх частей: «что делать по порядку и почему offline-оценка этого не поймала», «найди причину и выкати исправление на Kubernetes». Частая ошибка — блестяще ответить на первую часть и забыть вторую. Поэтому первая фраза ответа называет части: «So there are two parts here: why it happened and how we ship the fix safely». Это занимает 5 секунд, показывает структуру и даёт тебе чек-лист: по ходу ответа ты закрываешь каждую часть.

Если вопрос неясен, уточни одно-два условия: масштаб, язык пользователей, есть ли traces. Уточнение — нормальная часть ответа, но не способ потянуть время: два вопроса, не пять.

Диагноз раньше исправления

Первый рефлекс многих — сразу предложить исправление: «добавлю правило в prompt», «добавлю ещё одного агента». Сильный кандидат сначала говорит, какое доказательство найдёт место сбоя: «First I'd look at the trace (запись всех шагов запроса) to see whether the right document was in the context». Для RAG (поиска с генерацией) это путь с конца: был ли верный факт в context модели → если нет, есть ли он в индексе → если нет, что сломалось при ingestion (загрузке и нарезке документов). Каждый шаг — проверка с ожидаемым результатом, а не догадка.

Где живёт гарантия

Второй вопрос к любому решению: это совет или гарантия? Prompt, правило в skill (инструкции для агента) и строка в wiki — советы: модель может их нарушить. Гарантия живёт в коде: фильтр в запросе к индексу, права в tool, подтверждение в harness, блокирующая проверка в CI. Правило выбора инструмента:

crisp rule (чёткое правило: доступ, версия документа, подтверждение) → код;
fuzzy meaning (размытый смысл: вежлив ли ответ, обоснован ли он источником) → LLM-as-judge (модель-судья);
качество самого judge → люди.

Обратная ошибка — применять свежий урок везде: «сделать невозможным в коде» верно для доступа, но неверно для оценки смысла.

Как доказать: четыре части и пример

Любое утверждение — «B лучше», «исправление работает», «агент никогда не раскрывает чужие данные» — это забег. Проверь, что забег тот, что он честный и что финиш назначен до старта. Ответ из четырёх частей:

Exact claim — точное утверждение: лучше в чём, для кого, на каком языке.
What you run — какие задачи, откуда, сколько, что одинаково для обеих сторон.
Decide beforehand — какой результат значит «да», а какой «нет», записанный до прогона. Решение после прогона позволяет найти причину поверить в то, во что уже хотелось.
What could fool you — хотя бы один способ, которым тест выглядит хорошо при ложном утверждении.

И вопрос до всех четырёх: можно ли сделать это верным by design (архитектурой), а не тестом?

Пример: «новый reranker улучшил ответы». Reranker — модель, которая переупорядочивает найденные документы перед генерацией.

Claim: новый reranker поднимает NDCG@5 (метрику качества порядка в первых пяти результатах) на вопросах клиентов на английском и на арабском.
Run: 200 реальных вопросов на каждом языке с разметкой нужных документов; тот же индекс, тот же retriever, меняется только reranker. Сравнение paired (по тем же вопросам), чтобы разброс вопросов не смешался с эффектом.
Decide: принимаем, если NDCG@5 растёт хотя бы на 0,03 в каждом языке, а доля ответов, подтверждённых источником, не падает. Порог 0,03 должен быть больше шума: заранее смотрим, насколько метрика скачет на bootstrap-выборках (повторных случайных выборках из тех же вопросов).
Fool: вопросы писал автор нового reranker; один язык тянет среднее; judge предпочитает длинные ответы.

Arithmetic для «никогда» тоже надо знать: rule of three (правило трёх) — при 0 провалов в n независимых попытках верхняя граница 95-процентного интервала ≈ 3/n. 300 попыток без провала → «реже 1%», 3 000 → «реже 0,1%», 30 000 → «реже 0,01%». Не называй одно число на любой вопрос: каждое утверждение требует своего теста.

Думать вслух и держать время

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

Секунды	Что звучит
0–10	части вопроса
10–40	какое доказательство найдёт сбой
40–80	исправление и где живёт его гарантия
80–110	как докажешь, что исправление работает
110–120	честная граница или риск, который остаётся

Если не знаешь ответа, скажи это и рассуждай от того, что знаешь: «I haven't used that tool, but here's how I'd reason about it». Выдумка опаснее пробела: follow-up её найдёт.

Типичные ошибки и честная граница

Пять привычек, которые стоят баллов:

Исправление до диагноза.
Гарантия в prompt вместо кода.
Заученное число вместо теста под утверждение.
Свежий урок на всё подряд.
Ответ на половину вопроса.

Шестая — бросить верную идею под давлением. Собеседующий говорит «а если tools миллион?», и кандидат отказывается от выбора tools по описанию. Правильно — держать идею и менять механизм: описания уходят в поисковый индекс, а не в context.

Наконец, честная граница опыта: «I haven't run this in production; in my own project I did X, and at your scale I'd do Y». Это сильнее, чем выдуманный опыт, который рассыплется на первом follow-up. Уложись в 2 минуты и остановись: follow-up — не знак провала, а приглашение показать глубину там, где собеседующему интересно.

Схема

части вопросаevidence firstгде гарантия

claimчто прогоняюпорог до прогоначто обманет

честная граница опыта2 минутыfollow-up

Термины · Key terms

evidence first: сначала доказательство, которое найдёт место сбоя
crisp rule: чёткое правило, которое проверяет код
fuzzy meaning: размытый смысл, который оценивает judge
by design: верно благодаря архитектуре, а не тестам
decision rule: порог «да» или «нет», записанный до прогона
paired comparison: сравнение двух систем на одних и тех же задачах
reranker: модель, которая переупорядочивает найденные документы
NDCG@5: метрика качества порядка в первых пяти результатах
rule of three: 0 провалов в n попыток → верхняя граница ≈ 3/n
follow-up: уточняющий вопрос собеседующего после ответа

Сделай сам

Примени четыре части метода к утверждению «новый chunking (нарезка документов) улучшил ответы на вопросы о тарифах»: четыре строки — claim, run, decide, fool. Затем одна строка: можно ли часть этого сделать by design.

Обсуди с тьютором: прочитай ответ вслух и попроси тьютора задать один follow-up, который ломает твой пункт «decide».

Проверь себя · ответ под вопросом

1Назови четыре части метода доказательства и вопрос, который задают до них.

Exact claim, what you run, decide beforehand, what could fool you. До них — можно ли сделать утверждение верным архитектурой, а не тестом. Чёткие правила уходят в код, размытый смысл — к judge, проверка judge — к людям.

2Почему порог решения записывают до прогона?

Решение после прогона позволяет подогнать трактовку под желаемый вывод: найти срез, где «стало лучше». Записанный заранее порог делает тест честным и понятным для других. Это же требование второй линии в банке.

3Что сказать, если в 3 000 попыток утечек ноль?

По правилу трёх это даёт только верхнюю границу около 1 на 1 000 с уверенностью 95%, а не «никогда». Для большого трафика это может быть много. Поэтому гарантию дают архитектурой, а тест измеряет остаток.

Interview questions · US / UK

1Our RAG assistant quoted a wrong fee to a customer. Walk me through what you do.

Strong answer: names the parts (diagnose, fix, prove); works backwards from the trace: was the right chunk in context, was it indexed, did ingestion break the table or digits; checks for an older document version competing; fix in code (effective-date filter, fee lookup tool), not a prompt rule; proof with a regression set and monitoring.

2Prove to me that model B is better than model A for our use case.

Strong answer: turns it into an exact claim (better at what, for whom, per language); our own tasks from real traffic weighted to past failures, same prompts and tools, several runs per task, paired comparison; decision rule written beforehand including "no worse on policy breaks"; names what could fool us; shadow mode before customers.

3Follow-up: you said zero failures in 300 runs. Is that enough to say it never happens?

Strong answer: no; rule of three gives an upper bound near 1%, at 95% confidence; for "never" at scale you need design guarantees (permissions, filters, confirmations in code); tests then measure residual risk; number of runs must match the claim and the traffic.

Ключевые фразы · Say it aloud

So there are two parts here.Тут две части.
First I'd look at the trace to see what the model actually saw.Сначала посмотрю trace: что модель на самом деле видела.
That rule goes in code, not in the prompt.Это правило — в код, а не в prompt.
I'd write the decision rule before running anything.Порог решения запишу до прогона.
Here's what could fool us.Вот что может нас обмануть.
Zero in three thousand bounds the rate; it doesn't prove never.Ноль из трёх тысяч ограничивает частоту, но не доказывает «никогда».
I haven't run this in production, but here's how I'd do it.В production этого не делал, но вот как сделал бы.

Материалы

Anthropic — A statistical approach to model evaluations — error bars, paired differences, power analysis (8 минут)
Anthropic — Demystifying evals for AI agents — tasks, trials, graders, pass@k и pass^k (15 минут)
Hamel Husain — Your AI Product Needs Evals — три уровня оценки и чтение traces (15 минут)