{
  "index": 82,
  "slug": "editorial-2025-09-field-engineering-interviews",
  "title": "Как калибровать техническое интервью по фактам, а не по впечатлению",
  "excerpt": "Два reviewer-а могут прочитать один технический ответ по-разному. Разбираем, как найти первую точку расхождения на synthetic-пробе, проверить её и остановить опасный переход от учебной записи к выводу о человеке.",
  "contentHtml": "<p>Два reviewer-а читают один технический ответ. Один видит аккуратную гипотезу. Другой — недостаток глубины. Через пять минут спор уже идёт о впечатлении, а не о тексте. В журнале нет ссылки на строку, где началось расхождение.</p>\n<p>Цена ошибки высока. Команда меняет rubric после самого громкого мнения. Кандидат или сотрудник получает вывод, который нельзя проверить. Следующий review повторяет тот же спор. Калибровка не исправляет это обсуждением в конце встречи. Она должна сначала зафиксировать одинаковый вход, независимые факты и границу того, чего проба не показывает.</p>\n<p><strong>Тезис:</strong> технический review калибруется через цепочку «наблюдение → неизвестное → интерпретация → следующий запрос». Reviewer-ы не обязаны прийти к одинаковой интерпретации. Они обязаны показать, на каких фактах она стоит и где заканчивается evidence. Если в записи появляется score, ranking или вывод о личности, процесс должен остановиться.</p>\n<h2>Механизм: разделить факт и объяснение</h2>\n<p>Возьмём учебную карточку с ответом на вопрос об устаревшем API-ответе. В тексте есть <code>max-age=0</code>, маршрут <code>/v1/report</code> и описание симптома. Правило origin-сервера не указано. Это намеренный пробел. Он позволяет проверить, умеет ли reviewer отделить видимое от неизвестного.</p>\n<p>Observation отвечает только на вопрос «что видно в sample?». Например: «В заголовке указан <code>max-age=0</code>». Unknown отвечает на вопрос «чего здесь нет?»: «Правило, по которому origin формирует cache-control, не показано». Interpretation связывает эти записи: «Нужен запрос правила origin; изменение cache policy пока не доказано». Такой порядок не запрещает гипотезы. Он не даёт гипотезе притвориться фактом.</p>\n<table><thead><tr><th>Слой</th><th>Допустимая запись</th><th>Запрещённый скачок</th></tr></thead><tbody><tr><td>Observation</td><td>В sample есть <code>max-age=0</code>.</td><td>«Сервис неправильно настроен».</td></tr><tr><td>Unknown</td><td>Origin rule не показано.</td><td>«Автор не понимает кеширование».</td></tr><tr><td>Interpretation</td><td>Нужно запросить правило origin.</td><td>«Reviewer B глубже разобрался».</td></tr><tr><td>Hand-off</td><td>Запросить один отсутствующий факт.</td><td>Создать score, ranking или hiring outcome.</td></tr></tbody></table>\n<p>Независимость нужна до обсуждения. Каждый reviewer получает тот же <code>sampleId</code>, ту же role rubric и те же критерии. Он сначала пишет факты и неизвестные, затем интерпретацию. Если начать с общей беседы, участники быстро выровняют формулировки, но потеряют момент, где они увидели разное.</p>\n<h2>Конкретный пример: безопасный hand-off</h2>\n<p>Ниже — учебный TypeScript-подобный код. Он работает с объектом в памяти. Он не обращается к сети, не пишет файл и не создаёт оценку человека. В production этот пример ничего не доказывает.</p>\n<pre><code>type ReviewRecord = {\n  sampleId: string;\n  criterionId: string;\n  evidenceRef: string;\n  kind: 'observation' | 'unknown' | 'interpretation' | 'hand-off';\n  text: string;\n};\n\nfunction acceptHandOff(record: ReviewRecord) {\n  const safePrefix = 'hand-off:';\n  const forbidden = /score|ranking|hiring|person|candidate/i;\n\n  if (record.kind !== 'hand-off' || !record.text.startsWith(safePrefix)) {\n    return { accepted: false, action: 'stop-and-repair-boundary' };\n  }\n  if (forbidden.test(record.text)) {\n    return { accepted: false, action: 'stop-and-repair-boundary' };\n  }\n  return { accepted: true, action: 'request-missing-evidence' };\n}\n\nconst next = acceptHandOff({\n  sampleId: 'api-cache-fixed-v1',\n  criterionId: 'evidence-boundary',\n  evidenceRef: 'sample.headers.cache-control',\n  kind: 'hand-off',\n  text: 'hand-off: request the origin cache rule',\n});</code></pre>\n<p>Вызов возвращает учебный запрос недостающего evidence. Он не разрешает менять конфигурацию. Ветка с текстом <code>hiring: reject</code> должна вернуть <code>stop-and-repair-boundary</code>. Это отрицательный путь, а не дополнительная функция: он показывает, что процесс заметил незаконное расширение задачи.</p>\n<p>Проверять нужно не только результат функции. Сверьте четыре поля: один <code>sampleId</code>, существующий <code>evidenceRef</code>, применимый <code>criterionId</code> и допустимый тип hand-off. Пустая ссылка, общий ярлык или другой sample делают запись непроверяемой. В таком случае правильное действие — остановка, а не попытка угадать недостающий факт.</p>\n<figure><img src=\"/assets/editorial/2025/engineering-interviews-2025-evidence-review-loop.svg\" alt=\"Цикл калибровки synthetic-пробы: независимые observation, interpretation, журнал расхождений и ограниченный hand-off\"><figcaption>Учебный цикл возвращает неопределённость в проверяемый запрос. Стрелка stop блокирует personal outcome и production effect.</figcaption></figure>\n<h2>Симптомы и действия</h2>\n<table><thead><tr><th>Симптом</th><th>Причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Reviewer-ы спорят о «глубине».</td><td>Критерий не описывает наблюдаемое поведение.</td><td>Найдите строку sample, на которую ссылается каждый.</td><td>Сузьте criterion до проверяемого признака.</td></tr><tr><td>Оба reviewer-а используют одинаковые слова, но делают разные выводы.</td><td>Они смешали observation и interpretation.</td><td>Перепишите записи в два отдельных поля.</td><td>Запросите недостающий факт вместо решения.</td></tr><tr><td>В hand-off появляется score или ranking.</td><td>Учебная проба пересекла границу оценки человека.</td><td>Проверьте текст и допустимые типы записи.</td><td>Верните <code>stop-and-repair-boundary</code>; не сохраняйте outcome.</td></tr><tr><td>После калибровки меняют сразу sample, rubric и инструкцию.</td><td>Нельзя понять, что исправило расхождение.</td><td>Сопоставьте первую непарную запись с изменённым артефактом.</td><td>Измените один артефакт и повторите тот же sample.</td></tr><tr><td>Reviewer просит данные из сети или реального разговора.</td><td>Проба не содержит нужного evidence и маскирует это.</td><td>Проверьте boundary и список разрешённых источников.</td><td>Остановите прогон или замените sample на явно новый учебный кейс.</td></tr></tbody></table>\n<h2>Порядок короткой calibration session</h2>\n<ol><li><strong>Заморозьте вход.</strong> Создайте synthetic sample с идентификатором, фиксированными литералами и описанием того, чего в нём нет.</li><li><strong>Опишите критерий.</strong> Запишите observable behaviour и исключённые измерения. Слова «сильный», «слабый» и «системный» без признака не подходят.</li><li><strong>Раздайте одинаковые условия.</strong> Передайте reviewer-ам один sample, одну rubric и одинаковый порядок чтения. Не начинайте с общей дискуссии.</li><li><strong>Соберите независимые записи.</strong> Каждый reviewer фиксирует observation, unknown и interpretation с ссылками на evidence.</li><li><strong>Найдите первую развилку.</strong> Сначала сравните sample id и факты. Затем сравните criterion. Только после этого обсуждайте interpretation.</li><li><strong>Классифицируйте расхождение.</strong> Разные факты указывают на проблему sample или чтения. Одинаковые факты и разные трактовки указывают на rubric. Разные hand-off указывают на неясную границу действия.</li><li><strong>Измените один артефакт.</strong> Исправьте sample, criterion или инструкцию, но не все сразу. Старую версию оставьте как учебный контрпример без связи с человеком.</li><li><strong>Повторите тот же прогон.</strong> Убедитесь, что прежняя развилка стала видимой, а hand-off по-прежнему не создаёт score, ranking, personal record или production effect.</li></ol>\n<h2>Когда этот метод не подходит</h2>\n<p>Synthetic-проба проверяет процесс чтения и границу доказательства. Она не измеряет производительность инженера, качество найма, способность работать в команде или результат реального проекта. Нельзя переносить её вывод на человека. Нельзя называть отсутствие расхождения доказательством валидности rubric.</p>\n<p>Один fixed sample быстро устаревает. Изменился API, критерий или рабочая задача — изменился и смысл пробы. Набор из нескольких sample требует отдельного дизайна: иначе команда начнёт сравнивать разные задачи как одну шкалу. Если нужен реальный отбор, его должны спроектировать владельцы процесса с учётом применимых требований. Учебный журнал не заменяет такую процедуру.</p>\n<p>Метод также не спасает от плохого критерия. Если criterion требует «понять намерение автора», его нельзя проверить ссылкой на текст. Если sample скрывает несколько причин, reviewer-ы будут расходиться по делу, а не из-за плохого review. Сначала уменьшите область утверждения. Потом добавляйте сложность.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Сессия готова, если независимые записи можно открыть без устного пояснения и ответить на четыре вопроса: какой sample читали; какой факт увидели; какое неизвестное осталось; почему hand-off разрешён или остановлен. Для каждого расхождения указан один артефакт, который изменили. Повторный прогон использует тот же идентификатор пробы и не создаёт score, ranking, personal outcome, сетевой запрос или production effect.</p>\n<p>Минимальная проверка — прогнать положительную и отрицательную ветки. Положительная ветка принимает только hand-off с ссылкой на существующий evidence и запросом одного недостающего факта. Отрицательная ветка отклоняет текст с оценкой человека, невалидную ссылку и неизвестный критерий. Если хотя бы одна ветка проходит без явного результата, материал не готов к использованию даже как учебный пример.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews\" target=\"_blank\" rel=\"noopener\">U.S. Office of Personnel Management: Structured Interviews</a> — официальное описание одинаковых вопросов, шкалы и стандартов оценки; источник не подтверждает эту учебную модель и не заменяет требования конкретной организации.</li><li><a href=\"https://www.eeoc.gov/regulations-and-guidelines\" target=\"_blank\" rel=\"noopener\">U.S. Equal Employment Opportunity Commission: Regulations and Guidelines</a> — официальный каталог, в котором размещены Uniform Guidelines on Employee Selection Procedures; применимость зависит от юрисдикции и процесса.</li></ul>"
}