{
  "index": 84,
  "slug": "editorial-2025-09-practice-engineering-interviews",
  "title": "Инженерное интервью: как проверить работу с неполным входом",
  "excerpt": "Вместо экзамена по терминам используйте короткую техническую задачу с одним симптомом, неполным входом и наблюдаемыми критериями. Статья показывает, как отделить факт от гипотезы, проверить отрицательный путь и понять, готова ли такая проба.",
  "contentHtml": "<p>Интервьюер спрашивает: «Что такое stale-while-revalidate?» Собеседник уверенно отвечает. Через несколько минут разговор заканчивается, но главный рабочий вопрос остаётся без ответа: что он сделает, если API вернул устаревший ответ, причина неизвестна, а изменение может затронуть клиентов?</p>\n<p>Симптом плохого интервью появляется сразу. В одной записи остаётся «хорошо знает HTTP», в другой — «не задал уточняющих вопросов». Нельзя восстановить, какой факт прозвучал и на чём основан вывод. Цена ошибки — спор о впечатлении вместо данных. Команда может принять знание термина за умение безопасно искать причину, а потом получить поспешное изменение TTL без проверки источника ответа.</p>\n<p>Тезис прост: инженерное интервью должно показывать маршрут от симптома к следующему безопасному действию. Для этого нужна короткая рабочая проба с одним неполным входом и заранее заданными наблюдаемыми критериями. Если вход не подтверждает причину, правильный ответ — назвать неизвестное и запросить конкретный факт. Уверенная догадка не заменяет проверку.</p>\n<h2>Механизм: разделите факт, гипотезу и действие</h2>\n<p>Хорошая техническая запись состоит из трёх слоёв. Факт описывает то, что действительно дано. Гипотеза объясняет, что может стоять за симптомом. Действие показывает, какой сигнал нужно получить дальше и что пока нельзя менять. Смешение слоёв превращает предположение в якобы установленную причину.</p>\n<pre><code>const observation = {\n  fact: 'Cache-Control: max-age=0',\n  source: 'fixed-response-header',\n  unknown: 'origin rule и владелец маршрута не заданы'\n};\n\nconst nextStep = {\n  action: 'запросить origin rule read-only способом',\n  stop: 'не менять TTL без источника причины'\n};</code></pre>\n<p>Заголовок в примере — факт. Он не доказывает, что origin сломан, кэш настроен неправильно или новый TTL исправит ответ. Следующий шаг тоже ограничен: получить один технический факт без изменения состояния. Именно это показывает работу с неопределённостью. Память о директиве HTTP здесь вторична.</p>\n<h2>Как устроить короткую рабочую пробу</h2>\n<p>Дайте один симптом и несколько заранее известных значений: заголовок ответа, имя маршрута и условие остановки. Не давайте репозиторий, сеть, персональные данные или настоящую историю изменений. Учебный пример ниже использует только фиксированные значения в памяти. Он показывает форму технического разговора и не описывает реального собеседника или настоящую систему.</p>\n<figure><img src=\"/assets/editorial/2025/engineering-interviews-2025-rubric-work-sample.svg\" alt=\"Схема инженерной пробы: ограниченный вход ведёт от симптома к факту, неизвестному и запросу следующего доказательства.\" loading=\"lazy\" /><figcaption>Ограниченный вход ведёт к наблюдаемому факту и следующему запросу. Он не даёт оснований менять систему или делать вывод о человеке.</figcaption></figure>\n<p>Критерий формулируйте через действие. Фраза «сильный инженер» слишком широкая: разные люди вложат в неё разные признаки. «Называет факт, неизвестное и источник следующей проверки» — наблюдаемый критерий. «Отделяет проверку без изменения состояния от изменения» — ещё один. «Связывает симптом с действием короткой цепочкой» — третий.</p>\n<div class=\"table-scroll\"><table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Ответ помечен stale, а разговор сразу переходит к TTL</td><td>Гипотезу приняли за факт</td><td>Попросить назвать источник заголовка и недостающие данные</td><td>Сохранить наблюдение; не менять политику кэширования</td></tr><tr><td>Два слушателя по-разному описывают один ответ</td><td>Критерий задан оценочным прилагательным</td><td>Заменить его фразой, шагом или артефактом</td><td>Сравнивать одинаковые наблюдения</td></tr><tr><td>Собеседник просит открыть настоящий сервис</td><td>Проба вышла за заданную границу</td><td>Проверить список разрешённых данных и условие остановки</td><td>Вернуться к фиксированному входу</td></tr><tr><td>После ответа появляется «подходит / не подходит»</td><td>Техническое наблюдение смешали с выводом о человеке</td><td>Найти персональный вывод и его основание</td><td>Убрать вывод; оставить технический вопрос</td></tr></tbody></table></div>\n<h2>Пример: положительный и отрицательный путь</h2>\n<p>Изолированный учебный модуль принимает только фиксированную карточку. Он проверяет структуру входа, связь между наблюдением и объяснением, разрешённые данные и форму следующего запроса. Вызов ниже не выставляет балл и не создаёт рекомендации.</p>\n<pre><code>import {\n  createFixedInterviewInput,\n  inspectEngineeringInterview,\n} from './upgrade-2025-09.mjs';\n\nconst input = createFixedInterviewInput('fixed-valid-v1');\nconst report = inspectEngineeringInterview(input);\n\nconsole.log(report.accepted); // true\nconsole.log(report.reasons.length === 0); // true</code></pre>\n<p>Положительная ветка оставляет только запрос недостающего технического факта. Она не возвращает числовую оценку и не говорит, каким является человек. В реальной беседе такой результат означает: причина ещё не установлена, поэтому нужен следующий источник данных.</p>\n<p>Отрицательная ветка должна останавливать разговор. Если объяснение ссылается на несуществующее наблюдение, карточка просит открыть настоящий репозиторий или в записи появляется вывод о человеке, граница нарушена.</p>\n<pre><code>const broken = createFixedInterviewInput(\n  'fixed-unsupported-interpretation-v1'\n);\nconst rejected = inspectEngineeringInterview(broken);\n\nconsole.log(rejected.accepted); // false\nconsole.log(rejected.reasons);  // ['interpretation-not-traceable']\n// Сначала восстановите ссылку на наблюдаемый факт.</code></pre>\n<p>Отказ полезнее красивого объяснения без основания. Он показывает, где закончились данные. Учебный код работает только с фиксированными значениями. Он не читает файлы, сеть, аудио, персональные данные или внешние сервисы.</p>\n<h2>Какие критерии не дублируют друг друга</h2>\n<p>Три критерия нужны для трёх разных ошибок. Граница доказательства ловит выдуманную причину: заголовок увидели, а правило origin не видели. Безопасность следующего шага ловит поспешное изменение: из симптома сразу сделали новую политику кэша. Техническая коммуникация ловит потерю связи между симптомом и проверкой: вместо маршрута остаётся набор терминов.</p>\n<p>Для каждого критерия запишите контрпример. Для границы доказательства это «max-age=0 значит, что origin сломан». Для безопасности — «сразу выставим новый TTL». Для коммуникации — «это сложная инвалидизация кэша». Контрпример проверяет сам критерий. Если его нельзя описать без биографии, интонации или предполагаемого мотива, критерий не относится к технической работе.</p>\n<p>Не объединяйте «знает HTTP» и «знает Cache-Control» в разные пункты. Оба проверяют память о термине. Лучше спросить, какой факт нужен для следующего шага. Человек может не вспомнить точное название директивы, но заметить, что одного заголовка недостаточно. Это более полезное наблюдение для задачи с неопределённостью.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Назовите границу.</strong> Запишите, что проба проверяет и чего не проверяет.</li><li><strong>Оставьте один симптом.</strong> Уберите детали, которые не нужны для формулировки неизвестного.</li><li><strong>Запишите факт отдельно.</strong> Укажите literal, источник и неизвестное. Не добавляйте причину в поле факта.</li><li><strong>Свяжите критерий с наблюдением.</strong> Для каждого пункта назовите фразу, шаг или артефакт, который можно увидеть.</li><li><strong>Зафиксируйте остановку.</strong> Прекратите пробу, если следующий шаг требует незаданного доступа, реальных данных или догадки о намерениях.</li><li><strong>Проверьте отрицательный путь.</strong> Убедитесь, что неподтверждённая причина, изменение состояния и вывод о человеке прекращают упражнение.</li><li><strong>Сформулируйте следующий запрос.</strong> Передайте только недостающий технический факт или причину остановки.</li></ol>\n<h2>Почему вопросы по терминам дают ложную экономию</h2>\n<p>Термин легко спросить и легко записать. Но ответ «это механизм обновления кэша» почти ничего не говорит о выборе действия. Инженер может правильно помнить определение и всё равно не выяснить, где сформирован заголовок, какой компонент владеет маршрутом и как отменить изменение.</p>\n<p>Рабочая проба требует больше подготовки. Нужно убрать лишние подсказки, описать одинаковый вход и заранее определить, какое наблюдение считается достаточным. Зато она показывает ход решения. Ответ «этого заголовка недостаточно; сначала нужен origin rule» оставляет техническую цепочку. Ответ «поменяем TTL» показывает скачок от симптома к изменению.</p>\n<p>Одна проба имеет узкую область действия. Она не измеряет всю инженерную компетентность, не заменяет проверку требований роли и не доказывает справедливость отбора. Для другой роли нужны другие симптомы и другие границы. Сопоставлять можно только записи с одинаковым входом и одинаковыми критериями.</p>\n<h2>Ограничения и критерий готовности</h2>\n<p>Фиксированные значения не являются данными кандидата. Учебный результат не является решением о найме. Поведение на одной карточке нельзя переносить на проект без отдельной проверки. Внешние источники ниже объясняют структурированный формат интервью и смысл заголовка HTTP; они не подтверждают конкретную рубрику или эффект этой учебной модели.</p>\n<p>Проба готова, если по одной записи можно ответить на четыре вопроса: какой симптом дан, какой факт наблюдался, чего не хватает и почему следующий шаг безопасен. Дополнительный критерий проверяемости: на допустимом входе остаётся запрос недостающего факта, а на каждом запрещённом входе появляется конкретная причина остановки. Если запись требует догадки, оценки личности или доступа к настоящей системе, проба не готова.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews\" target=\"_blank\" rel=\"noopener noreferrer\">U.S. Office of Personnel Management: Structured Interviews</a> — официальное описание структурированного интервью, одинаковых вопросов и общей шкалы. Источник поддерживает принцип сопоставимых условий, но не подтверждает эту инженерную карточку.</li><li><a href=\"https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews/guide/\" target=\"_blank\" rel=\"noopener noreferrer\">U.S. Office of Personnel Management: Structured Interview Guide</a> — официальный практический материал о разработке и проведении структурированного интервью. Он не является доказательством результата конкретной команды.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Cache-Control header</a> — справка по директивам заголовка HTTP. Она объясняет синтаксис и семантику заголовка, но не устанавливает причину stale-ответа в учебном примере.</li></ul>"
}