После технического интервью в заметке часто остаётся фраза «сильный инженер, понимает кеширование». Через неделю другой reviewer видит только уверенный рассказ: неизвестно, какие заголовки прозвучали, был ли проверен origin и почему выбран следующий вопрос. Команда начинает спорить о впечатлении, хотя ей нужно восстановить ход решения. Цена ошибки — разные люди получают разные трактовки одной и той же работы.
Разобрать проблему помогает простое правило: не смешивать наблюдение, интерпретацию и решение. Наблюдение отвечает, что действительно было в условии или ответе. Интерпретация говорит, какой узкий вывод разрешён этими данными. Решение назначает только следующий проверяемый шаг. Если между слоями нет ссылки, вывод нужно остановить, а не усиливать формулировку.
Техническое интервью полезно, когда оно проверяет связанный с ролью навык через одинаково понятную задачу. В качестве такого навыка можно выбрать диагностику: отделяет ли человек симптом от причины, называет ли недостающий сигнал и предлагает ли безопасную проверку. Это уже наблюдаемое поведение. Формулировка «системное мышление» слишком широка: по ней нельзя понять, какой ответ считается достаточным.
Структурированный формат задаёт всем кандидатам одни и те же вопросы в одном порядке и использует общую шкалу приемлемых ответов. Так его описывает U.S. Office of Personnel Management. Для инженерной роли это не готовая рубрика, а полезный принцип проектирования: сначала определить рабочую компетенцию, затем выбрать сценарий и только после этого описать уровни ответа.
Для каждой пробы зафиксируйте границы. Она может проверять, например, диагностику HTTP-кеша. Она не может по одному ответу доказать будущую производительность, командное поведение или пригодность к найму. Эти выводы требуют отдельной процедуры, других данных и владельцев решения.
Наблюдение — минимальный проверяемый факт: «в условии указаны Age: 120 и Cache-Control: max-age=0». Наблюдение не объясняет источник ответа и не говорит, что кандидат «хорошо понимает кеширование». Полезно отдельно записать неизвестное: в условии нет ответа origin, значения ETag и момента изменения ресурса.
Интерпретация связывает факт с одним критерием. Допустимо написать: «кандидат заметил признаки промежуточного кеша и запросил данные origin; причина старого ответа пока не установлена». Недопустимо: «кандидат не понимает CDN». Вторая фраза превращает отсутствие одного шага в личностный вывод и не оставляет способа его проверить.
Решение определяет hand-off: запросить заголовки origin, уточнить валидатор или остановить разбор. Оно не должно менять production-конфигурацию и не должно превращать учебную пробу в автоматический score. У каждого решения есть ссылка на интерпретацию, а у интерпретации — на наблюдение. Так спор можно вернуть к первой расходящейся строке.
const record = { observation: { id: 'o1', fact: 'Age: 120; Cache-Control: max-age=0', unknown: ['origin response', 'ETag'] }, interpretation: { criterion: 'separates symptom from cause', evidence: ['o1'], claim: 'intermediary response is possible; cause is unproven' }, decision: { kind: 'request', next: ['origin headers', 'validator'] } }; const traceable = record.interpretation.evidence.includes(record.observation.id); const isSafeNextStep = record.decision.kind === 'request' && record.decision.next.length > 0; console.log({ accepted: traceable && isSafeNextStep });Это самодостаточная модель данных в памяти. Сохраните её в файл и запустите командой node record.mjs: результатом будет { accepted: true }. Если заменить evidence: ['o1'] на evidence: ['o2'], запись перестанет проходить проверку связи. Код не читает интервью, не хранит персональные данные и не оценивает человека; он проверяет только ссылочную целостность примера.
Условие рабочей пробы: «GET /report иногда показывает старые данные. Клиент получил Age: 120 и Cache-Control: max-age=0. Назовите следующий шаг». В нём намеренно нет ответа origin, цепочки прокси, Date, ETag и времени изменения записи. Эти пропуски — часть задачи, а не повод угадывать.
По RFC 9111 поле Age передаёт оценку времени с момента генерации или успешной проверки ответа на origin. Наличие поля означает, что ответ для этого запроса не был сгенерирован или проверен origin; отсутствие поля не доказывает обратного. Директива max-age задаёт, после какого возраста ответ считается устаревшим. Поэтому max-age=0 не равно no-store и само по себе не устанавливает причину сбоя.
Сильный ответ на условие звучит так: «зафиксирую оба заголовка, затем сравню их с ответом origin и проверю валидатор или время формирования». Он не заявляет, что CDN сломан. Слабый ответ — «очищу кеш» или «origin отдаёт старые данные»: первый меняет состояние до проверки, второй выдаёт гипотезу за факт. В рубрике можно отдельно отметить порядок действий и наличие неизвестного.
| Что наблюдаем | Ограниченный вывод | Следующая проверка | Чего нельзя утверждать |
|---|---|---|---|
Age: 120 | Ответ, вероятно, прошёл через кеш; origin не проверен этим фактом | Сравнить цепочку ответа и данные origin | «Именно CDN испортила данные» |
max-age=0 | Свежесть по этой директиве не даёт запаса времени | Проверить остальные директивы и поведение валидатора | «Ответ нельзя хранить» |
Нет Age | Источник ответа неизвестен | Проверить трассировку, заголовки прокси и origin | «Кеш точно не участвовал» |
| В заметке есть «понимает кеширование» | Критерий не связан с evidence | Попросить цитату, действие или строку условия | «Кандидат слабый» |
Таблица разделяет технический протокол и интервьюерский вывод. Заголовки помогают сформулировать следующий вопрос, но не заменяют измерение конкретной системы. Если ресурс зависит от cookies, авторизации, Vary или частного кеша, нужно добавить это в условие и заранее описать допустимый ответ.
Перед разговором полезно проверить, что команда вообще умеет получить нужный сигнал. Для своего тестового endpoint-а выполните запрос без сохранения тела:
TARGET='https://your-test-host.example/report'; curl --http1.1 -sS -D - -o /dev/null $TARGET | grep -Ei '^(age|cache-control|date|etag|vary):'Команда выводит только выбранные заголовки. Адрес your-test-host.example — заполнитель: его нужно заменить на endpoint, для которого у команды есть право чтения. Повторите запрос после изменения тестовой записи и сравните ответы. Если прокси удаляет заголовок или ответ меняется между попытками, запишите это как наблюдение и не приписывайте причину origin.
Проверка кандидата устроена аналогично. Заморозьте входные данные, выдайте одинаковое условие и сохраните текст ответа без пересказа. После этого reviewer заполняет четыре поля: факты, неизвестное, разрешённый claim и следующий запрос. Если в четвёртом поле появилось «изменить TTL» без проверки, это отрицательная ветка рубрики, а не повод спорить о характере человека.
Калибровка нужна не для одинаковых формулировок, а для одинаковой границы доказательств. Два reviewer-а могут предложить разные безопасные проверки и всё равно совпасть по критерию. Расхождение начинается там, где один записывает «Age равен 120», а другой — «данные устарели из-за CDN». Второй перескочил от наблюдения к причинному выводу.
Критерий лучше писать через наблюдаемое поведение. Например: «отделяет признак промежуточного ответа от доказательства причины и запрашивает origin-факт». В нём есть вход, действие и граница. Критерий «знает HTTP» проверяет память о термине, но не показывает порядок расследования.
У каждого уровня полезно иметь контрпример. Для наблюдения это «max-age=0 означает, что ответ нельзя хранить». Для следующего шага — «сразу очистить кеш». Контрпример не нужен, чтобы ловить кандидата на ошибке. Он проверяет, что рубрика действительно отличает факт от неподтверждённого объяснения.
Если claim не ссылается на конкретное наблюдение, единственный корректный результат — запросить недостающий факт или остановить разбор. Нельзя заполнять пробел интонацией, скоростью ответа или впечатлением о seniority. Технический термин, произнесённый без привязки к условию, остаётся сигналом памяти, а не доказательством навыка диагностики.
Не следует давать участнику интервью реальный доступ к production для проверки гипотезы. Учебный сценарий работает на обезличенных и заранее подготовленных данных. Для реальной роли отдельно определите права, обработку записи, срок хранения, доступ к заметкам и процесс запроса разумного accommodation. Эти организационные требования не выводятся из HTTP-примера.
Не следует и автоматизировать кадровое решение поверх этой цепочки. Даже хорошо структурированная запись не устраняет выбор компетенций, ошибки задания и различия условий. Она лишь делает обсуждение проверяемее. Решение о найме должно оставаться у ответственных людей в рамках правил организации и применимого права.
В production-диагностике порядок такой же, но последствия выше. Сначала сохраните наблюдение и scope: URL, метод, время, заголовки и окружение. Затем сравните intermediary и origin. Только после этого выбирайте purge, изменение политики или откат. При наличии авторизации проверьте, не смешаны ли private и shared caches: один и тот же заголовок в публичном примере не описывает всю систему.
Учебный кейс не доказывает, что конкретный endpoint неисправен, и не устанавливает, какой слой вернул тело ответа. Заголовки могут быть изменены промежуточным компонентом. Поведение зависит от метода, URI, request headers, Vary, валидаторов, политики shared cache и возможности revalidation. Для причинного вывода нужны наблюдения из вашей системы, а не только два значения в условии.
Метод не измеряет будущую работу человека и не делает интервью справедливым автоматически. Структурированный вопрос помогает сравнить ответы только при корректно выбранной компетенции, одинаковых условиях и понятной шкале. Если проба не даёт возможности проявить идемпотентность, коммуникацию или работу с отказом, нельзя приписывать отсутствие этих навыков человеку.
Граница готового результата узкая: другой reviewer должен восстановить исходный симптом, увидеть факт, назвать неизвестное и объяснить следующий шаг. Если он может повторить только ярлык «сильный инженер», evidence потеряно. Вернитесь к условию, удалите не подтверждённую причину и добавьте один способ получить недостающий сигнал.
Age, расчёта свежести, Cache-Control и ограничений повторного использования stale-ответа.