{
  "index": 82,
  "slug": "editorial-2025-09-field-engineering-interviews",
  "title": "Как калибровать техническое интервью по фактам, а не по впечатлению",
  "excerpt": "Практический разбор калибровки технического интервью: как разделить наблюдение, неизвестное и трактовку, найти первую точку расхождения и не превратить учебную пробу в необоснованный вывод о человеке.",
  "contentHtml": "<p>Два инженера разбирают один и тот же ответ о протухшем API-кеше. Один пишет: «в заголовке есть <code>max-age=0</code>». Второй сразу заключает: «автор не умеет работать с кешированием». Спор начинается не с текста и не с проверяемого критерия, а с впечатления. Через пять минут команда уже обсуждает, кто из рецензентов «глубже понял» ответ.</p>\n<p>Такая ошибка ломает сам объект калибровки. Учебная проба должна показать, одинаково ли рецензенты читают заданный признак и одинаково ли понимают рубрику. Она не должна тайком превращаться в рейтинг человека. Поэтому сначала фиксируем один вход, затем отделяем наблюдение от неизвестного и только после этого разрешаем трактовку. Любой переход к личностному выводу или решению по человеку — стоп-сигнал.</p>\n<p><strong>Главный вопрос статьи:</strong> как обнаружить первую точку расхождения и вернуть разговор к evidence — конкретному фрагменту, который можно открыть и проверить. Ниже — учебный контракт записи, запускаемый пример на Node.js, таблица диагностики и границы применимости.</p>\n<h2>Симптом: рецензенты спорят не о строке, а о «глубине»</h2>\n<p>Начните с маленькой фиксированной пробы. В ней есть ответ на вопрос об API, один фрагмент заголовка и явно пропущенное правило сервера. Например, в sample указано <code>cache-control: max-age=0</code>, но не показано, кто и по какой конфигурации сформировал этот заголовок. Отсутствующий факт — часть входа, а не приглашение его додумывать.</p>\n<p>Запись первого рецензента может выглядеть так: «<code>sample.headers.cache-control</code> содержит <code>max-age=0</code>; правило origin не представлено; нужно запросить его». Это наблюдение, неизвестное и следующий запрос. Запись «сервис неправильно настроен» уже выходит за пределы пробы: заголовок виден, причина его появления — нет.</p>\n<p>До общей встречи сохраните идентификатор пробы, версию рубрики и ссылки на evidence. Рецензенты читают один и тот же набор и пишут независимо. Если обсуждение начнётся раньше фиксации записей, участники синхронизируют формулировки и сотрут сам момент расхождения.</p>\n<h2>Механизм: четыре разных типа записи</h2>\n<p>Калибровка становится проверяемой, когда у записи есть один тип и одна функция. <em>Observation</em> описывает то, что можно открыть в sample. <em>Unknown</em> называет отсутствующее условие. <em>Interpretation</em> связывает факт с гипотезой, но помечает её как гипотезу. <em>Hand-off</em> передаёт ровно один безопасный запрос на следующий факт.</p>\n<table><thead><tr><th>Тип</th><th>Что хранит</th><th>Пример</th><th>Что нельзя выводить</th></tr></thead><tbody><tr><td>Observation</td><td>Точное наблюдение со ссылкой</td><td><code>sample.headers.cache-control</code> равно <code>max-age=0</code></td><td>Сервис настроен неверно</td></tr><tr><td>Unknown</td><td>Недостающий факт или условие</td><td>Правило origin не показано</td><td>Автор не знает кеширование</td></tr><tr><td>Interpretation</td><td>Гипотеза, привязанная к фактам</td><td>Нужно проверить источник заголовка</td><td>Рецензент умнее другого</td></tr><tr><td>Hand-off</td><td>Один следующий запрос</td><td><code>request: origin cache rule</code></td><td>Score, ranking или решение по человеку</td></tr></tbody></table>\n<p>Здесь «ссылка» — не обязательно URL. Это стабильный путь к полю фикстуры, номер строки ответа или идентификатор артефакта. Ссылка должна приводить к существующему объекту. Пустой ярлык вроде <code>ответ кандидата</code> не позволяет повторить проверку и потому не является evidence.</p>\n<p>Не смешивайте калибровку с оценкой качества самого критерия. Фраза «проверяет системное мышление» недостаточна, пока не описано наблюдаемое действие: например, «называет отсутствующее условие и формулирует следующий безопасный запрос». Сначала проверяем, можно ли увидеть признак в тексте. Потом обсуждаем, нужен ли этот признак для конкретной роли.</p>\n<h2>Контракт hand-off: что разрешено передать дальше</h2>\n<p>Безопасный hand-off имеет четыре обязательных поля: <code>sampleId</code>, <code>criterionId</code>, <code>evidenceRef</code> и короткий текст запроса. Валидатор обязан сверить их со справочниками текущей пробы. Одного префикса <code>hand-off:</code> недостаточно: такой префикс может стоять у любой строки, включая запрещённое решение.</p>\n<p>В этом примере разрешены только два критерия и две ссылки, заранее перечисленные в фикстуре. Проверка возвращает причину отказа, а не бросает её в общий лог. Это позволяет увидеть, почему запись остановилась: неизвестный критерий, отсутствующий evidence или попытка передать личный outcome.</p>\n<figure><img src='/assets/editorial/2025/engineering-interviews-2025-evidence-review-loop.svg' alt='Схема калибровки фиксированной пробы: одинаковый sample проходит независимые наблюдения, затем журнал расхождений и ограниченный hand-off; личностный вывод блокируется' /><figcaption>Сначала фиксируется общий вход, затем сравниваются независимые записи. Неизвестное превращается в запрос доказательства, а выход к решению по человеку блокируется.</figcaption></figure>\n<h2>Воспроизводимый пример на Node.js</h2>\n<p>Скопируйте код в файл <code>calibration.mjs</code> и запустите на Node.js 18 или новее. Пример не обращается к сети, не читает персональные данные и не оценивает реального человека. Он проверяет только форму записи в памяти; это полезная защита границы, но не доказательство валидности интервью.</p>\n<pre><code>const allowedCriteria = new Set(['evidence-boundary', 'next-check']);\nconst allowedEvidence = new Set([\n  'sample.headers.cache-control',\n  'sample.response.api-version',\n]);\nconst forbiddenWords = ['score', 'ranking', 'hiring', 'candidate', 'person'];\n\nfunction validateHandOff(record) {\n  const errors = [];\n  const text = typeof record?.text === 'string' ? record.text : '';\n\n  if (record?.kind !== 'hand-off') errors.push('kind');\n  if (!record?.sampleId) errors.push('sampleId');\n  if (!allowedCriteria.has(record?.criterionId)) errors.push('criterionId');\n  if (!allowedEvidence.has(record?.evidenceRef)) errors.push('evidenceRef');\n  if (!text.startsWith('request: ')) errors.push('request-prefix');\n  if (forbiddenWords.some((word) =&gt; text.toLowerCase().includes(word))) {\n    errors.push('personal-or-decision-outcome');\n  }\n\n  return errors.length === 0\n    ? { accepted: true, action: 'request-missing-evidence', errors: [] }\n    : { accepted: false, action: 'stop-and-repair-boundary', errors };\n}\n\nconst cases = [\n  {\n    name: 'valid request',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'evidence-boundary',\n      evidenceRef: 'sample.headers.cache-control',\n      kind: 'hand-off',\n      text: 'request: origin cache rule',\n    },\n    accepted: true,\n  },\n  {\n    name: 'unknown evidence',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'evidence-boundary',\n      evidenceRef: 'sample.guess.about-author',\n      kind: 'hand-off',\n      text: 'request: origin cache rule',\n    },\n    accepted: false,\n  },\n  {\n    name: 'personal outcome',\n    record: {\n      sampleId: 'api-cache-fixed-v1',\n      criterionId: 'next-check',\n      evidenceRef: 'sample.response.api-version',\n      kind: 'hand-off',\n      text: 'request: candidate ranking',\n    },\n    accepted: false,\n  },\n];\n\nconst results = cases.map(({ name, record, accepted }) =&gt; {\n  const result = validateHandOff(record);\n  return { name, expected: accepted, actual: result.accepted, result };\n});\n\nconsole.log(JSON.stringify(results, null, 2));\nif (results.some(({ expected, actual }) =&gt; expected !== actual)) {\n  process.exitCode = 1;\n}</code></pre>\n<p>Проверка запуска:</p>\n<pre><code>node --check calibration.mjs\nnode calibration.mjs</code></pre>\n<p>Ожидаемый результат — первая запись принята с действием <code>request-missing-evidence</code>, две следующие отклонены с действием <code>stop-and-repair-boundary</code>. Ключевой отрицательный тест — <code>candidate ranking</code>: даже существующие идентификаторы не разрешают передать личный outcome. Если убрать проверку <code>evidenceRef</code> или список запрещённых слов, тесты перестанут охранять заявленную границу.</p>\n<p>В реальном сервисе справочники должны быть частью версии конкретной пробы, а не глобальными константами. Полезно также валидировать типы, длину текста, владельца артефакта и права доступа. Эти поля намеренно не реализованы здесь: добавление их без контракта проекта создало бы видимость универсального решения.</p>\n<h2>Как найти первую точку расхождения</h2>\n<p>Сравнивайте записи слева направо, от менее интерпретируемого к более интерпретируемому. Сначала убедитесь, что совпали <code>sampleId</code> и версия рубрики. Затем откройте каждую ссылку evidence и выпишите наблюдение дословно. После этого сравните unknown. Только при совпадающих фактах переходите к interpretation и hand-off.</p>\n<table><thead><tr><th>Первая разница</th><th>Вероятная причина</th><th>Проверка</th><th>Исправление</th></tr></thead><tbody><tr><td><code>sampleId</code> или версия rubric</td><td>Рецензенты получили разные входы</td><td>Сверить идентификаторы и хеши фикстуры</td><td>Повторить прогон на одном входе</td></tr><tr><td>Observation</td><td>В тексте неоднозначный фрагмент или его по-разному прочитали</td><td>Открыть одну и ту же ссылку и записать видимые символы</td><td>Уточнить sample или инструкцию чтения</td></tr><tr><td>Unknown</td><td>Критерий скрывает недостающее условие</td><td>Проверить, названо ли отсутствие явно</td><td>Добавить поле unknown и не заполнять его догадкой</td></tr><tr><td>Interpretation</td><td>Одинаковые факты связывают с разными гипотезами</td><td>Найти предложение, где появляется причинный вывод</td><td>Записать гипотезу и один тест, не менять сразу всю rubric</td></tr><tr><td>Hand-off</td><td>Граница действия не описана</td><td>Прогнать положительный и запрещённый текст через валидатор</td><td>Оставить только запрос evidence или остановку</td></tr></tbody></table>\n<p>Один цикл должен менять один артефакт. Если одновременно переписать sample, rubric и инструкцию рецензента, следующий результат не объяснит, что устранило расхождение. Старую версию сохраняйте как обезличенную учебную фикстуру с понятным статусом, а не как запись о конкретном собеседнике.</p>\n<h2>Короткая процедура калибровочной сессии</h2>\n<ol><li><strong>Опишите границу.</strong> Запишите, что проба проверяет: например, поиск отсутствующего условия в API-ответе. Отдельно запишите, чего она не измеряет.</li><li><strong>Заморозьте вход.</strong> Дайте всем один <code>sampleId</code>, одну версию текста и одну версию рубрики. Зафиксируйте отсутствие нужных фактов.</li><li><strong>Соберите независимые записи.</strong> До встречи каждый рецензент указывает observation, unknown и interpretation со ссылками на поля или строки.</li><li><strong>Сравните факты.</strong> Проверьте идентификаторы, ссылки и буквальное содержимое evidence. Не обсуждайте личные качества и общий «уровень» ответа.</li><li><strong>Назовите первую развилку.</strong> Отметьте, на каком поле записи впервые расходятся. Это рабочая единица исправления.</li><li><strong>Выберите один следующий тест.</strong> Если не хватает правила origin, запросите правило origin. Не подменяйте этот запрос изменением конфигурации или выводом о человеке.</li><li><strong>Измените один артефакт.</strong> Исправьте только sample, критерий или инструкцию. Свяжите новую версию с причиной изменения.</li><li><strong>Повторите прогон.</strong> Используйте тот же идентификатор и проверьте обе ветки: разрешённый запрос evidence и запрещённый личный outcome.</li></ol>\n<h2>Когда метод не подходит</h2>\n<p>Фиксированная проба проверяет согласованность чтения и качество границы evidence. Она не измеряет производительность инженера, будущую работу в команде, результат реального проекта или вероятность успеха на должности. Отсутствие расхождения на одном sample не доказывает, что rubric валидна для всех задач.</p>\n<p>Для реального отбора нужны отдельные решения владельцев процесса: анализ работы, набор релевантных критериев, одинаковые условия, правила хранения записей и проверка применимых требований. OPM описывает structured interview как метод с заранее заданными одинаковыми вопросами и общей шкалой; это полезная опорная идея, но не готовый регламент для частной команды и не совет по законодательству конкретной страны.</p>\n<p>Юридическая применимость особенно зависит от юрисдикции и способа использования результата. Страница EEOC перечисляет федеральные правила США, включая 29 CFR 1607 — Uniform Guidelines on Employee Selection Procedures. Российская, европейская или другая процедура требует собственной правовой проверки. Учебный валидатор из этой статьи не заменяет юриста, HR-политику, оценку доступности или требования к защите персональных данных.</p>\n<p>Метод также не исправляет плохой вопрос. Если ответ можно получить случайным угадыванием, если отсутствуют ключевые входы или если критерий требует «понять намерение автора», рецензенты будут расходиться по содержательной причине. Сначала уменьшите утверждение до наблюдаемого действия, затем добавляйте сложность и новые пробы.</p>\n<h2>Критерий готовности</h2>\n<p>Калибровка готова к повторному использованию, если независимая запись отвечает на четыре вопроса без устного пояснения: какой вход читали; какой факт открыт по ссылке; что осталось неизвестным; почему следующий hand-off принят или остановлен. Для каждого расхождения назван один изменённый артефакт. Положительный запуск возвращает только запрос недостающего evidence. Отрицательные запуски отклоняют несуществующую ссылку, неизвестный критерий и попытку создать личное решение.</p>\n<p>Храните рядом версию sample, версию rubric и результаты отрицательных тестов. Тогда следующий рецензент сможет воспроизвести не только успешный путь, но и причину остановки. Это делает калибровку техническим процессом с проверяемыми границами, а не голосованием за самое убедительное впечатление.</p>\n<h2>Проверяемые источники</h2>\n<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> — официальное описание метода: job-related competencies, одинаковые заранее заданные вопросы, единая шкала и стандарты приемлемого ответа. Это источник по федеральному контексту США, а не универсальный шаблон найма.</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> — официальный каталог правил EEOC; на странице отдельно указаны 29 CFR 1607 и Uniform Guidelines on Employee Selection Procedures. Применимость зависит от юрисдикции и конкретного процесса.</li></ul>"
}