После технического интервью в заметке часто остаётся одна фраза: «сильный инженер, хорошо понимает кеширование». Через неделю другой reviewer читает ту же запись и видит только уверенный рассказ без проверки инвалидации. Восстановить ход разговора уже нельзя. Команда спорит о впечатлении, а не о факте. Цена ошибки — разные кандидаты получают разные трактовки одной и той же работы, а слабый сигнал превращается в решение.
Проблема возникает не потому, что reviewer плохо помнит разговор. В одну запись смешивают три операции. Сначала нужно зафиксировать, что человек сделал или сказал. Затем — объяснить, какой узкий вывод из этого следует. И только после этого — выбрать следующий проверяемый шаг. Если пропустить первый слой, техническое слово маскирует догадку.
Хорошее инженерное интервью не пытается измерить «системное мышление» одним вопросом. Оно создаёт небольшую рабочую задачу с известными границами. Reviewer смотрит не на сходство ответа с эталоном, а на цепочку: симптом, наблюдение, ограничение, действие и проверка результата. Такая цепочка не делает решение объективным автоматически. Она делает спор локальным: можно показать строку, на которой возникло расхождение.
В этой статье рабочая проба учебная. Она не предсказывает результат реального найма и не заменяет требования конкретной роли. Её задача — показать, как сохранить техническое evidence и не выдать интерпретацию за факт. В реальном процессе такую пробу нужно проверить на соответствие работе, заранее согласовать критерии и отдельно определить правила хранения данных.
Наблюдение отвечает только на вопрос «что видно в условии или ответе». Например: «в ответе указан заголовок Cache-Control: max-age=0». Это не объяснение причины. Оно не доказывает, что данные устарели, и не показывает, что origin вернул новый ответ.
Интерпретация связывает наблюдение с одним критерием. Допустимая формулировка: «кандидат заметил клиентскую настройку кеша, но причина stale-ответа пока не установлена». Недопустимая формулировка — «не понимает кеширование»: в ней нет ни границы вывода, ни способа проверки.
Действие выбирает следующий шаг. В учебном примере это запрос недостающего факта: «уточнить, меняется ли заголовок на origin и какой возраст ответа видит клиент». Это не оценка человека и не изменение production-конфигурации. Если интерпретация не ссылается на наблюдение, действие должно быть stop.
const observation = { fact: 'Cache-Control: max-age=0', unknown: 'origin response is unknown' }; const interpretation = { evidence: ['observation-1'], claim: 'symptom is observed; cause is not proven' }; const handOff = interpretation.evidence.length ? 'request: check origin' : 'stop: interpretation-not-traceable';Код выше — учебная модель без сети, файлов и реального интервью. Он не выставляет балл и не делает вывод о человеке. Его смысл — показать ссылочную целостность: у интерпретации есть наблюдение, а у действия есть проверяемая причина.
Пусть условие звучит так: «GET /report иногда показывает старые данные. В клиентском ответе есть Age: 120 и Cache-Control: max-age=0. Назовите следующий шаг диагностики». Условия намеренно неполные. Они показывают симптом и два заголовка, но не дают ответа от origin, конфигурацию CDN или момент изменения данных.
Слабая запись выглядит убедительно: «кандидат сразу понял, что кеш сломан». Она приписывает причину по одному симптому. Сильная запись короче: «назвал Age: 120; заметил max-age=0; запросил ответ origin и время его формирования». В ней видны факт, неизвестное и действие. Если кандидат предлагает очистить кеш до проверки origin, reviewer отмечает порядок действий только по заранее определённому критерию.
Отрицательный путь важен. Если reviewer пишет «не понимает CDN», но не указывает, какого наблюдения не хватило, запись нельзя передать дальше. Нужно вернуться к фактам: какой вопрос прозвучал, какой заголовок был назван, что осталось неизвестным. Это защита от вывода, который невозможно повторно проверить.
| Симптом | Возможная причина | Проверка | Действие |
|---|---|---|---|
| В заметке есть общий ярлык | Наблюдение смешали с интерпретацией | Попросить цитату или действие из ответа | Переписать запись как факт и unknown |
| Reviewer-ы спорят о решении | Они использовали разные критерии | Сравнить criterion до вывода | Зафиксировать одну развилку |
| Ответ предлагает очистить кеш сразу | Симптом приняли за источник | Проверить origin, Age и время изменения | Запросить данные, не менять систему |
| Интерпретация не имеет ссылки | В запись попала догадка | Найти observation для claim | Остановить hand-off |
Калибровка не означает, что два reviewer-а обязаны написать одинаковый текст. Она проверяет, видят ли они одну границу evidence. Сначала каждый читает одну пробу отдельно. Затем сравнивают первую расходящуюся строку. Если один записал «Age равен 120», а другой — «кеш устарел», расхождение найдено: второй перескочил через неизвестное. Если факты совпали, но действия различаются, вопрос относится к критерию, а не к памяти о разговоре.
Такой порядок снижает стоимость обсуждения. Reviewer-ы говорят не «ты слишком строгий», а «здесь claim не следует из observation». Это не гарантирует одинакового решения. Оно даёт короткий путь к месту, где нужно уточнить условие, критерий или ответ.
Проба должна напоминать реальную инженерную работу, но проверять один ограниченный навык. Для задачи про кеширование достаточно дать симптом, несколько заголовков и скрыть один важный факт. Если добавить origin response, CDN policy, трассировку и журнал деплоя, reviewer уже оценивает объём подсказок и скорость чтения. Слишком широкая задача превращает интервью в угадывание ожидаемого рассказа.
Критерий должен описывать действие, которое можно увидеть. «Понимает распределённые системы» слишком широк. «Разделяет симптом клиента и источник ответа; запрашивает недостающий origin-факт» допускает проверку. Слова «глубокий», «зрелый» и «сильный» нельзя делать единственным содержанием записи.
Нельзя задним числом добавлять к пробе критерий, которого она не проверяла. Если команда хочет оценивать идемпотентность, нужно добавить условие, где повтор запроса имеет последствия. Если хочет проверить наблюдаемость, нужно дать доступный сигнал и определить достаточный ответ. Иначе reviewer приписывает человеку отсутствие навыка, хотя проба не давала возможности его показать.
Разделение слоёв не устраняет субъективность. Reviewer всё ещё выбирает, какую цитату считать достаточной, а автор проб выбирает условие. Модель не измеряет будущую производительность, командное взаимодействие или качество работы в другой среде. Она не оправдывает автоматическое ранжирование и не даёт основания хранить больше персональных данных.
Заголовок HTTP — это сигнал, а не полная причинная модель кеша. Реальное поведение зависит от клиента, промежуточного кеша, валидаторов, времени ответа и политики источника. Поэтому учебный пример показывает порядок диагностики, но не доказывает, что конкретная система неисправна. Прежде чем менять конфигурацию, нужно проверить факты в самой системе и иметь безопасный откат.
Если в записи появились персональные сведения, решение о найме, production-change или claim без ссылки, процесс должен остановиться. Допустимый hand-off — запросить технический факт, уточнить условие или пересобрать критерий. Нельзя превращать отсутствие evidence в отрицательный вывод о человеке.
Материал и проба готовы к ограниченному учебному прогону, если другой reviewer может ответить на четыре вопроса: какой был симптом, какой факт наблюдали, что осталось неизвестным и почему выбран следующий шаг. Дополнительная проверка проста: удалите интерпретации и оставьте observations. Если действие всё ещё выглядит очевидным, в нём спрятана причина без доказательства. Перепишите его в запрос к отсутствующему факту.
Готовность не означает production-результат и не подтверждает качество отбора. Она означает только воспроизводимую форму записи на заданной учебной пробе. Для реального процесса владельцы роли должны отдельно проверить содержание задачи, юридические требования, доступ к данным и правила хранения.