Собеседование 1С: вопрос → индивидуальный ответ

Назовите конфигурации, их редакции и свою роль в каждой. Хороший ответ: «Работал с УТ 11.5 и БП 3.0; в УТ отвечал за заказы, склад и HTTP-интеграции, в БП — за обмен и печатные формы. Версии и режим совместимости уточню по проектной документации, чтобы не назвать их по памяти неверно».

Практический пример. «В УТ 11.5 я дорабатывал резервирование и обмен заказами, в БП 3.0 — загрузку банковских документов; режимы совместимости сверю по релизным файлам».

Комментарий интервьюера. попросите кандидата назвать не только конфигурацию, но и конкретные изменённые объекты и границы личной ответственности.

Выберите три задачи, для которых можете доказать личный вклад. Для каждой кратко назовите исходную проблему, именно ваше решение, альтернативы и проверяемый результат; не приписывайте себе работу всей команды.

Практический пример. выберите интеграцию, оптимизацию проведения и обновление типовой — для каждой покажите артефакт или метрику, подтверждающую именно ваш вклад.

Комментарий интервьюера. уточните, кто принял архитектурное решение, кто написал код и кто измерил результат — эти роли нередко смешивают.

Масштаб описывают подтверждаемыми метриками: активные и одновременные пользователи, размер БД, число документов или запросов в пике, p95 операции. Если цифры не сохранились, прямо скажите это и объясните, каким мониторингом они измерялись.

Практический пример. «Размер БД 1,8 ТБ взят из мониторинга СУБД, пик 420 сеансов — из консоли кластера, p95 проведения — из ЦУП».

Комментарий интервьюера. хорошие цифры имеют источник, дату и единицу измерения; приблизительную оценку кандидат должен так и обозначить.

Пример структуры: «Проведение занимало p95 18 секунд. По ТЖ и плану MS SQL нашли чтение 12 млн строк из-за отбора после виртуальной таблицы. Перенесли отбор в параметры, добавили подходящий индекс и получили p95 2,4 секунды на том же сценарии».

Практический пример. при деградации отчёта кандидат показывает исходный запрос, событие ТЖ, фактический план и две цифры чтений до и после.

Комментарий интервьюера. если отсутствует измерение результата, история подтверждает активность, но не успешность оптимизации.

Расскажите об инженерной ошибке без самооправдания: что решили, почему решение казалось разумным, как проявился ущерб, как подтвердили причину и что изменили в процессе. Ценность ответа — в выводе и предотвращении повторения.

Практический пример. длинный HTTP-вызов оставили внутри транзакции и получили блокировки; после инцидента внедрили outbox и конкурентный тест.

Комментарий интервьюера. зрелый кандидат объясняет системную причину и изменение процесса, а не ищет виноватого коллегу.

Чётко отделите роль от должности: какие решения принимали, чей код проверяли, за какой контур отвечали и кому передавали результат. «Участвовал» без границ ответственности — слабый ответ.

Практический пример. «Как ведущий я утверждал схему регистров и принимал review, но настройку CI выполнял DevOps-инженер».

Комментарий интервьюера. точное признание чужого вклада повышает достоверность остальных заявлений кандидата.

Опишите конкретный конфликт требований и способ его разрешения: зафиксировали бизнес-цель, показали варианты с последствиями, согласовали владельца решения и критерий приёмки. Не сводите ответ к оценке характера заказчика.

Практический пример. склад требовал запрет отрицательных остатков, продажи — возможность предзаказа; решение разделило физический остаток и обеспечение заказа.

Комментарий интервьюера. спросите, как было зафиксировано решение и кто принял остаточный бизнес-риск.

Невнедрённый проект допустим. Объясните проверяемые причины — смена приоритетов, неподтверждённая экономика, качество данных, отсутствие владельца процесса — и что вы сделали для снижения потерь.

Практический пример. миграцию остановили после пробного прогона, показавшего неприемлемое качество НСИ; команда сохранила карту данных и результаты сверки.

Комментарий интервьюера. важно отличить обоснованную остановку от проекта, брошенного без диагностики и передачи результатов.

Назовите виды документов: постановка, архитектурное решение, контракт API, инструкция выпуска и эксплуатации. Хороший документ содержит контекст, границы, данные, ошибки, безопасность, критерии приёмки и способ отката.

Практический пример. контракт HTTP содержит JSON-схему, статусы ошибок, идемпотентный ключ, тайм-ауты и пример запроса/ответа.

Комментарий интервьюера. попросите показать, как документ помогает тестировщику и дежурному инженеру, а не только автору кода.

Оценку строят из исследования, реализации, миграции, тестирования и выпуска, явно записывая допущения. После выполнения сравнивают план и факт; отклонение используют для корректировки модели оценки, а не скрывают.

Практический пример. исследование оценивается отдельно в 1–2 дня, после него диапазон разработки уточняется с учётом миграции и регрессии.

Комментарий интервьюера. кандидат должен уметь объяснить прошлое отклонение оценки фактами, не списывая всё на «непредсказуемую 1С».

Сначала уточняют бизнес-цель, акторов, входы, исключения, объёмы, права, конкурентность и критерий готовности. Затем отделяют исследовательскую часть, предлагают минимальный проверяемый вариант и фиксируют допущения.

Практический пример. перед оценкой нового обмена уточняют суточный объём, допустимую задержку, владельца справочника и поведение при повторе сообщения.

Комментарий интервьюера. сильный кандидат задаёт вопросы, меняющие архитектуру; слабый сразу перечисляет объекты, не выяснив цель.

Перескажите процесс своими словами, нарисуйте состояния и примеры входов/выходов, затем попросите владельца процесса подтвердить. Полезны проверочные сценарии, включая отмену, повтор, заднее число и параллельные действия.

Практический пример. после интервью с заказчиком разработчик рисует состояния заказа и просит разобрать отмену после частичной отгрузки.

Комментарий интервьюера. проверочные исключения лучше выявляют понимание процесса, чем пересказ его обычного счастливого пути.

Выберите код, ценность которого можно объяснить: ясная граница ответственности, тестируемость, отказоустойчивость и измеримый эффект. Покажите также компромисс — например, больше служебных записей ради идемпотентного обмена.

Практический пример. сервис проведения принимает простой контракт, не зависит от формы, покрыт тестом движений и имеет один контролируемый вход.

Комментарий интервьюера. попросите назвать компромисс выбранного дизайна; отсутствие недостатков обычно означает поверхностную оценку.

Назовите только реально используемые инструменты и задачи, которые они решают: анализ ТЖ, массовое сравнение данных, генерация поставки, тестовый запуск. Отдельно объясните версионирование и совместимость собственных библиотек.

Практический пример. собственный анализатор ТЖ хранится в Git, имеет версию формата и тест на обезличенном фрагменте журнала.

Комментарий интервьюера. универсальная обработка без владельца, тестов и совместимости часто является новым техническим долгом.

Честный ответ лучше попытки охватить всё: назовите слабую тему, риск для проекта и способ компенсации — документация, консультация эксперта, прототип и review. Senior отличается управлением незнанием.

Практический пример. «Слабо знаю регистр расчёта; перед задачей сверю модель с методистом, сделаю прототип зависимостей и попрошу review специалиста по ЗУП».

Комментарий интервьюера. оцените не сам пробел, а способность кандидата обнаружить его до production и организовать проверку.

Основная конфигурация — редактируемое описание; конфигурация базы данных — применённая версия, по которой работает ИБ. Также могут существовать конфигурация поставщика и расширения, поэтому сначала уточните смысл слова «конфигурация».

Практический пример. разработчик изменил основную конфигурацию, но пользователи увидят это только после обновления конфигурации базы данных.

Комментарий интервьюера. попросите отдельно объяснить конфигурацию поставщика и расширение — это выявляет механическое заучивание двух терминов.

Платформа предоставляет язык, выполнение, метаданные, работу с БД, клиенты и инфраструктурные механизмы. Прикладная конфигурация описывает бизнес-сущности, интерфейс и алгоритмы; по её метаданным платформа создаёт структуры хранения.

Практический пример. добавление измерения регистра описывается в метаданных, а физические таблицы и индексы создаёт платформа при реструктуризации.

Комментарий интервьюера. хороший ответ не сводит платформу к «интерпретатору языка», а связывает её с хранением и выполнением.

Толстый клиент поддерживает максимальный набор возможностей и обычное приложение; тонкий ориентирован на управляемое приложение и переносит значительную работу на сервер; веб-клиент исполняется в браузере через веб-сервер. Точные ограничения зависят от версии платформы.

Практический пример. метод, использующий файловую систему клиента, может работать в толстом клиенте и быть недоступным в веб-клиенте; бизнес-логику переносят на сервер.

Комментарий интервьюера. уточните конкретное ограничение целевой версии, но не требуйте помнить весь список возможностей клиентов.

Нажатие обрабатывается клиентским кодом формы; при необходимости сериализуются параметры и выполняется серверный вызов в кластере; сервер обращается через платформу к СУБД и возвращает сериализуемый результат. Поэтому серия мелких вызовов обычно хуже одного пакетного.

Практический пример. вместо 200 серверных вызовов при обходе строк форма отправляет массив ссылок одной процедуре, а сервер возвращает готовую таблицу результата.

Комментарий интервьюера. попросите кандидата указать, где сериализуются параметры и каким инструментом он увидит число вызовов.

Директивы компиляции определяют, где доступна процедура: клиент, сервер, сервер без контекста и соответствующие варианты. Перечень и асинхронные возможности следует называть для целевой версии, а не смешивать разные релизы.

Практический пример. процедура &НаСервереБезКонтекста получает только явные параметры и не обращается к реквизитам формы.

Комментарий интервьюера. кандидат должен различать директиву компиляции и право удалённого вызова экспортного метода.

Свойство «Вызов сервера» разрешает клиенту вызывать экспортные серверные методы общего модуля. Такой метод становится удалённым интерфейсом и обязан самостоятельно проверять входные данные и права.

Практический пример. экспортная функция с «Вызов сервера» принимает ссылку заказа, но повторно проверяет доступ пользователя и не доверяет клиентской сумме.

Комментарий интервьюера. спросите, почему такой метод является частью поверхности атаки и что запрещено отдавать клиенту.

Серверный модуль доступен серверному коду, клиентский — клиентскому, клиент-серверный компилируется в обоих контекстах, но может использовать только общий для них набор типов и методов. Контекст выбирают по данным и ответственности, а не ради удобства вызова.

Практический пример. функция форматирования даты находится в клиент-серверном модуле и использует только типы, доступные в обоих контекстах.

Комментарий интервьюера. если внутри появляется запрос, модуль уже не является честно клиент-серверным и ответственность стоит разделить.

Повторное использование кэширует результат экспортной функции общего модуля на предусмотренный срок. Оно безопасно лишь для результата, который допустимо считать неизменным; иначе пользователь получит устаревшее значение.

Практический пример. список неизменяемых кодов валют кэшируется на сеанс, а текущий остаток товара — нет, потому что быстро устаревает.

Комментарий интервьюера. попросите назвать событие, после которого кэшированное значение станет неверным, и последствия для пользователя.

Передаются только сериализуемые платформой значения. Выборку запроса или объект с серверным контекстом передавать нельзя; данные преобразуют в массив структур, данные формы либо помещают во временное хранилище.

Практический пример. серверная выборка запроса обходится на сервере и превращается в массив структур; сам объект выборки клиенту не возвращается.

Комментарий интервьюера. хороший ответ связывает допустимость типа с сериализацией и объёмом сетевой передачи.

Небольшую таблицу можно преобразовать в данные формы или массив структур; большую — поместить во временное хранилище и передать адрес. Выбор зависит от объёма, времени жизни и необходимости редактирования на клиенте.

Практический пример. таблица из 20 строк возвращается массивом структур, файл на 200 МБ помещается во временное хранилище и передаётся по адресу.

Комментарий интервьюера. уточните срок жизни данных и поведение при разрыве клиентского сеанса.

ЗначениеВДанныеФормы преобразует прикладное значение в модель данных управляемой формы, обратный метод восстанавливает прикладное значение. Это не способ обойти границу клиент–сервер: контекст выполнения и допустимые типы всё равно важны.

Практический пример. данные табличной части формы преобразуются в объект документа на сервере только перед выполнением предметной операции.

Комментарий интервьюера. преобразование не должно служить способом таскать целый объект между клиентом и сервером без необходимости.

Контекстный вызов передаёт состояние формы и тяжелее по сериализации. Вызов без контекста получает только явные параметры, меньше связан с UI и обычно проще для тестирования.

Практический пример. ПолучитьКурсНаСервере() без контекста принимает дату и валюту; контекстный вариант дополнительно сериализовал бы всю форму.

Комментарий интервьюера. попросите измеримый критерий выбора, а не только рекомендацию «без контекста быстрее».

Граница сериализации — переход, на котором значение преобразуется для передачи между процессами/клиентом и сервером. Она запрещает часть типов и делает объём передаваемых данных частью производительности API.

Практический пример. выборку запроса нельзя пересечь через границу, поэтому сервер возвращает DTO из строки, числа и ссылки.

Комментарий интервьюера. кандидат должен учитывать изменение контракта DTO при обновлении и не раскрывать внутренний объект целиком.

Нужно уточнить вид кэша: клиентский кэш приложения, кэш метаданных, повторное использование функций, кэш СУБД или данные формы. У них разные владельцы, сроки жизни и способы диагностики.

Практический пример. устаревшее значение может быть результатом повторного использования функции, клиентского кэша формы или кэша плана СУБД — способы проверки различаются.

Комментарий интервьюера. вопрос проверяет способность сначала классифицировать кэш, а не сразу советовать удалить каталог пользователя.

Клиентский кэш очищают удалением соответствующего каталога, запуском с очисткой кэша либо созданием нового каталога ИБ — точные способы зависят от клиента и ОС. Это диагностический шаг, а не лечение воспроизводимого дефекта конфигурации.

Практический пример. ошибка исчезла после запуска с чистым пользовательским кэшем, но затем воспроизвелась снова — значит, очистка лишь замаскировала дефект заполнения данных.

Комментарий интервьюера. очистку кэша засчитывайте как диагностический эксперимент, а не универсальное исправление.

При старте выполняются модули приложения и начальная инициализация сеанса. Тяжёлые запросы и сетевые вызовы здесь умножаются на число входов, поэтому оставляют минимальный код и откладывают необязательную работу.

Практический пример. синхронный запрос к внешнему сервису из обработчика начала работы добавлял пять секунд каждому входу; его заменили отложенным фоновым обновлением.

Комментарий интервьюера. спросите, какие части инициализации действительно обязательны до показа интерфейса.

Безопасный режим ограничивает опасные операции внешнего кода. Привилегированный режим позволяет серверному коду обходить проверки прав; его область должна быть минимальной, а вход — проверенным.

Практический пример. внешней обработке разрешено читать выбранный файл, но привилегированный серверный метод не принимает произвольный текст запроса.

Комментарий интервьюера. кандидат должен объяснить направление доверия и минимизацию области повышенных полномочий.

Файловый режим использует собственный движок БД в файле, клиент-серверный — кластер 1С и внешнюю СУБД. Отличаются масштабирование, блокировки и планы запросов; результаты производительности нельзя переносить без проверки.

Практический пример. запрос на файловой базе читает локальный кэш за 0,2 секунды, а на PostgreSQL получает иной план и сетевые ожидания; результаты сравнивают заново.

Комментарий интервьюера. опасный ответ — обещание одинакового поведения и блокировок во всех вариантах работы.

Кластер распределяет сеансы и серверные вызовы. Рабочий сервер — узел кластера, рабочий процесс исполняет код, сеанс представляет подключение пользователя или фоновой работы; точная топология видна в консоли администрирования.

Практический пример. фоновые задания вынесены в отдельный рабочий процесс с требованиями назначения, а пользовательские вызовы имеют резерв на втором сервере.

Комментарий интервьюера. попросите показать, что произойдёт при отказе выбранного рабочего сервера.

Фоновые и регламентные задания выполняются серверной частью. Регламентное задаёт расписание, а конкретный запуск исполняется как фоновое задание.

Практический пример. регламентное задание каждую ночь создаёт фоновое выполнение метода очистки очереди; повторный параллельный запуск блокируется ключом операции.

Комментарий интервьюера. кандидат должен различать расписание и экземпляр выполнения, включая его права и параметры.

Справочник хранит сущность с устойчивой ссылкой; документ моделирует событие во времени и обычно может формировать движения. Выбор определяется предметным смыслом, а не наличием даты.

Практический пример. договор — справочник, если это долговечная сущность; подписание договора — документ-событие с датой и движениями.

Комментарий интервьюера. спросите, как изменится выбор, если требуется хранить версии и юридические события.

Ссылочный объект имеет идентичность и объектное поведение; записи регистра адресуются ключом и отбором и не имеют обычной прикладной ссылки. Табличная техника удобна для массового чтения, объектная — для поведения и записи сущности.

Практический пример. реквизиты тысячи товаров читаются запросом, а один товар изменяется через объект, чтобы сработали проверки записи.

Комментарий интервьюера. хороший ответ учитывает поведение объекта, а не только различие «есть ссылка/нет ссылки».

Нет, стандартным регистратором регистра является документ, если регистр подчинён регистратору. Справочник может участвовать как измерение или реквизит, но не становится системным регистратором.

Практический пример. справочник Склады является измерением регистра товаров, а документ Перемещение — его регистратором.

Комментарий интервьюера. не принимайте ответ «можно программно сделать всё» — вопрос о системной модели регистратора.

ПВХ описывает расширяемые виды характеристик и допустимые типы значений. Справочник хранит обычные сущности; использовать ПВХ для стабильного набора реквизитов избыточно.

Практический пример. цвета и размеры как изменяемые пользователем характеристики описываются ПВХ; контрагенты остаются обычным справочником.

Комментарий интервьюера. попросите объяснить, где будут храниться сами значения характеристик, а не только их виды.

Табличная часть принадлежит одному объекту и записывается с ним. Регистр выбирают для самостоятельной истории, многомерных срезов или данных, общих для множества объектов.

Практический пример. строки заказа принадлежат документу и живут в табличной части, а статусы всех заказов во времени удобно анализировать через регистр сведений.

Комментарий интервьюера. спросите о транзакции удаления владельца и массовом отчёте по данным.

Подходит периодический регистр сведений: город — измерение, дата замера — период, температура — ресурс. Периодичность выбирают по требуемой частоте, чтобы ключ допускал все реальные замеры.

Практический пример. для почасовых замеров периодичность «час» потеряет второй замер внутри часа; при такой потребности нужен более точный период или дополнительное измерение.

Комментарий интервьюера. оценивайте понимание уникального ключа, а не только угадывание названия объекта.

Константа уместна для одного значения на область данных. Если значение зависит от организации, пользователя, периода или другого разреза, нужен регистр сведений.

Практический пример. основная валюта базы — константа, а валюта по каждой организации — регистр сведений с измерением Организация.

Комментарий интервьюера. попросите назвать последствия ошибочного выбора константы при появлении второй организации.

Перечисление — закрытый набор, изменяемый разработчиком. Справочник нужен, когда элементы создаются пользователями, имеют реквизиты, иерархию или собственный жизненный цикл.

Практический пример. фиксированные состояния Черновик/Согласован подходят перечислению; пользовательский перечень причин отказа — справочнику.

Комментарий интервьюера. хороший ответ упоминает обновляемость набора и наличие дополнительных реквизитов.

Журнал документов даёт единый просмотр документов разных типов. Он не является отдельным хранилищем бизнес-фактов.

Практический пример. журнал показывает заказы, реализации и возвраты в одном списке, но каждая строка физически принадлежит исходному документу.

Комментарий интервьюера. уточните, можно ли добавить в журнал собственную запись без создания документа.

Определяемый тип централизованно задаёт состав типа для множества реквизитов. Изменение определения согласованно меняет типизацию всех подключённых полей.

Практический пример. определяемый тип ДокументОснование используется в нескольких объектах; добавление нового документа выполняется в одном определении.

Комментарий интервьюера. попросите оценить влияние расширения составного типа на физическое хранение и запросы через точку.

Общий реквизит добавляет сквозное поле выбранным объектам и может участвовать в разделении данных. Нужно учитывать его влияние на физическую схему, индексы и доступ.

Практический пример. общий реквизит ОрганизацияОбластиДанных добавлен разделяемым объектам и участвует в изоляции арендаторов.

Комментарий интервьюера. кандидат должен различать техническое разделение областей и прикладной RLS внутри одной области.

Параметр сеанса хранит значение в контексте текущего сеанса и часто используется RLS. Начальное значение задаётся серверным обработчиком установки параметров; вычисление должно быть быстрым и доверенным.

Практический пример. при старте сеанса сервер определяет группы доступа пользователя и сохраняет их идентификатор в параметре для шаблона RLS.

Комментарий интервьюера. спросите, почему нельзя принимать значение параметра сеанса из поля клиентской формы.

Функциональная опция управляет доступностью функций и интерфейса, а параметр задаёт разрез её значения. Она не заменяет права доступа.

Практический пример. функциональная опция скрывает производственный раздел, когда учёт производства выключен, но права на документы всё равно задаются ролями.

Комментарий интервьюера. опасный ответ — считать невидимую команду достаточной защитой данных.

Модуль объекта содержит события и поведение конкретного экземпляра. Модуль менеджера содержит операции уровня типа, не требующие загруженного объекта.

Практический пример. проверка заполнения и запись элемента находятся в модуле объекта, а поиск/создание по внешнему ключу — в модуле менеджера или предметном сервисе.

Комментарий интервьюера. попросите объяснить тестируемость и повторное использование выбранного размещения.

Обработчики жизненного цикла экземпляра находятся в модуле объекта. В модуле менеджера размещают экспортные функции и специальные события, относящиеся к менеджеру, но не ПередЗаписью экземпляра.

Практический пример. ПередЗаписью элемента не переносится в модуль менеджера; менеджер может предоставить фабричный метод, который создаёт и записывает объект.

Комментарий интервьюера. вопрос выявляет путаницу между статическими операциями типа и жизненным циклом экземпляра.

Объектная техника загружает объект и запускает его поведение при записи. Табличная техника запросов читает выбранные поля множества строк и не изменяет результат напрямую.

Практический пример. отчёт по 200 тысячам товаров строят запросом, а изменение одного товара выполняют объектом, чтобы прошли проверки и подписки.

Комментарий интервьюера. попросите назвать случай, когда загрузка объекта ради чтения нескольких полей создаст лишние затраты.

Ссылка идентифицирует сущность; объект содержит изменяемое состояние; менеджер выполняет операции уровня типа; выборка последовательно читает результат; список предоставляет данные для отображения и отбора. Их нельзя считать взаимозаменяемыми.

Практический пример. ссылка заказа передаётся как идентификатор, объект загружается для записи, менеджер создаёт новый заказ, выборка читает результат запроса последовательно.

Комментарий интервьюера. кандидат должен объяснить назначение каждого представления, а не только перечислить методы получения.

Предопределённый элемент описан в конфигурации и имеет устойчивое имя. После обновления его наличие обеспечивает платформа в рамках правил предопределённых данных; обращаться лучше по предопределённому имени, а не искать по представлению.

Практический пример. предопределённый элемент ОсновнойСклад получают по имени предопределённых данных, а не через НайтиПоНаименованию("Основной").

Комментарий интервьюера. уточните поведение при переименовании пользователем и после обновления конфигурации.

Обычное удаление контролируется ссылочной целостностью прикладного уровня и механизмом пометки/удаления. Прямое физическое исчезновение может оставить битые ссылки; поэтому удаление выполняют штатными средствами с контролем ссылок.

Практический пример. перед удалением контрагента система ищет ссылки из договоров и документов; при наличии запрещает удаление либо выполняет согласованную замену.

Комментарий интервьюера. прямой SQL DELETE должен быть назван недопустимым, потому что обходит платформенные инварианты.

NULL означает отсутствие значения в табличном результате; Неопределено — значение языка; пустая ссылка — валидное пустое значение ссылочного типа; битая ссылка содержит идентификатор отсутствующего объекта.

Практический пример. левое соединение даёт NULL, незаполненный реквизит формы — Неопределено, пустой контрагент — пустую ссылку, а удалённый объект оставляет битую ссылку.

Комментарий интервьюера. попросите показать отдельную проверку каждого состояния в запросе или коде.

Подписка подключает общий обработчик к событию объектов без изменения их модулей. Опасности — скрытая связность, тяжёлое массовое срабатывание и зависимость от порядка нескольких обработчиков.

Практический пример. подписка после записи заказа регистрирует событие интеграции для нескольких типов документов, не изменяя их модули.

Комментарий интервьюера. спросите, сколько раз обработчик сработает при массовой загрузке и как избежать скрытого тяжёлого запроса.

Нельзя строить бизнес-логику на предполагаемом порядке нескольких независимых подписок. Если порядок критичен, создают один координирующий обработчик с явной последовательностью и тестами.

Практический пример. две подписки изменяют один регистр в разном порядке; их заменяют одной координирующей процедурой с явной последовательностью.

Комментарий интервьюера. сильный ответ не опирается на случайно наблюдавшийся порядок вызовов.

Критерий отбора объединяет поиск объектов разных типов по логически общим полям. Он удобен для «связанных документов», но состав объектов и полей задаётся метаданными.

Практический пример. критерий СвязанныеДокументы ищет заказы, реализации и оплаты по общему реквизиту основания.

Комментарий интервьюера. уточните, какие объекты попадут в поиск после добавления нового типа документа и кто поддерживает критерий.

Бизнес-процесс нужен для маршрута, задач, адресации и переходов. Для простого линейного жизненного цикла достаточно состояния документа, если не требуется отдельное управление исполнителями.

Практический пример. согласование с параллельными исполнителями требует бизнес-процесса; простой статус Подготовлен/Закрыт можно хранить в документе.

Комментарий интервьюера. попросите назвать стоимость избыточного бизнес-процесса и риск самодельного маршрута на статусах.

Бизнес-процессы моделируют маршрут обработки; точки маршрута создают задачи адресованным исполнителям. Их применяют для согласований и процессов, где важны этапы, исполнители и контроль завершения.

Практический пример. точка маршрута создаёт задачи руководителю и юристу, переход выполняется после завершения обеих ветвей.

Комментарий интервьюера. кандидат должен различать состояние бизнес-процесса и пользовательскую задачу исполнителя.

Управляемая форма — декларативная модель интерфейса с разделением клиентского представления и серверной работы. Её данные не тождественны прикладному объекту и могут преобразовываться между моделями.

Практический пример. форма заказа хранит данные формы документа и вычисляемый реквизит подсказки, которого нет в объекте базы.

Комментарий интервьюера. попросите объяснить, какие данные реально передадутся при серверном контекстном вызове.

Реквизит формы — поле модели формы; данные формы — специальные представления объектов и коллекций, пригодные для клиент-серверного интерфейса. Они могут содержать только нужную форме часть прикладного состояния.

Практический пример. табличная часть объекта преобразуется в таблицу данных формы, где пользователь редактирует строки до серверной записи.

Комментарий интервьюера. проверяйте понимание того, что данные формы не являются серверным объектом с методами записи.

ПередЗаписью выполняется до записи и может её отменить; ПриЗаписи — после успешного шага записи в соответствующем контексте. Нужно уточнять, идёт речь о форме или модуле объекта, потому что их события различаются.

Практический пример. в ПередЗаписью проверяют обязательный внешний номер и могут установить отказ; в ПриЗаписи регистрируют уже состоявшийся факт.

Комментарий интервьюера. уточните модуль события и транзакцию — одинаковое имя в форме и объекте не означает одинаковый контекст.

Типовая цепочка включает клиентские события формы, серверную подготовку, ПередЗаписью объекта, запись и ПриЗаписи, затем события формы. Точный порядок и транзакционность следует проверять для конкретного способа записи.

Практический пример. клиентская форма инициирует запись, сервер формы подготавливает объект, модуль объекта проверяет инвариант, затем подписка создаёт запись аудита.

Комментарий интервьюера. не требуйте заученной цепочки без указания способа записи; важнее правильное место обязательной проверки.

Из формы меняют данные формы, а для серверной бизнес-операции преобразуют их или получают объект на сервере. Нужно избегать повторного чтения объекта и множества мелких серверных вызовов.

Практический пример. пользователь меняет 50 строк на клиенте, затем одна серверная процедура преобразует данные и вызывает предметный сервис записи.

Комментарий интервьюера. спросите, как избежать повторного чтения того же объекта и потери изменений формы.

На сервере одним вызовом получить требуемые поля запросом или функцией и вернуть простую структуру. Разыменование на клиенте может вызвать неявный серверный обмен и не должно использоваться в цикле.

Практический пример. вместо Заказ.Контрагент.ИНН в цикле сервер одним запросом получает ИНН для всех ссылок и возвращает структуру соответствий.

Комментарий интервьюера. хороший ответ связывает обращение через точку с неявными вызовами и составными типами.

ПриИзменении срабатывает только при интерактивной работе формы. Импорт, обмен, HTTP и серверный код обходят его, поэтому обязательный инвариант проверяется на сервере при записи или в бизнес-сервисе.

Практический пример. форма запрещает отрицательное количество интерактивно, но загрузка JSON обходит форму; серверная проверка всё равно отклоняет запись.

Комментарий интервьюера. кандидат, оставляющий контроль только в UI, не учитывает интеграции и фоновые процессы.

Команда описывает действие и доступность в интерфейсе, обработчик выполняет клиентскую часть и при необходимости вызывает сервер. Общая команда подключается к нескольким формам/объектам по параметризации.

Практический пример. команда Пересчитать собирает параметры на клиенте и одним вызовом запускает серверный расчёт, затем обновляет отображаемые поля.

Комментарий интервьюера. уточните права на серверную операцию и поведение при повторном нажатии.

Команда — исполняемое действие интерфейса; группа команд определяет размещение и порядок группы действий. Группа сама не реализует бизнес-операцию.

Практический пример. команда ПечатьЭтикетки выполняет действие, а группа Печать лишь определяет её место рядом с другими печатными командами.

Комментарий интервьюера. вопрос простой, но выявляет смешение интерфейсной компоновки и бизнес-логики.

Свойства элементов меняют в обработчиках формы, а список выбора формируют на сервере или через параметры выбора. Обязательные ограничения нельзя оставлять только визуальным фильтром.

Практический пример. при выборе склада список ячеек ограничивается параметром связи, но сервер при записи повторно проверяет принадлежность ячейки складу.

Комментарий интервьюера. параметр выбора улучшает UX, однако не должен считаться защитой целостности.

Причины: разные права и RLS, настройки списка/отчёта, объём доступных данных, сетевой маршрут, клиент и кэш. Сравнивать нужно один сценарий с ТЖ и одинаковыми параметрами, а не ощущения пользователей.

Практический пример. у менеджера RLS добавляет тяжёлое соединение по 200 организациям, а у администратора его нет; один список даёт разные планы.

Комментарий интервьюера. попросите сравнить одинаковую операцию под теми же настройками, а не два разных пользовательских сценария.

Объединять мелкие запросы в один серверный контракт, передавать только необходимые данные, использовать вызовы без контекста и локально обновлять UI. Количество переходов измеряют замером и ТЖ.

Практический пример. 30 вызовов получения цены заменяются одним ПолучитьЦены(СписокНоменклатуры), возвращающим соответствие.

Комментарий интервьюера. уточните, не стал ли новый пакетный ответ чрезмерно большим и как измерить компромисс.

Динамический список получает данные запросом, исполняемым серверной частью. Пользовательские отборы, RLS и поля представления влияют на итоговый SQL и план.

Практический пример. динамический список заказов добавляет пользовательский отбор по организации, а RLS — условие доступных подразделений; итоговый SQL анализируют вместе.

Комментарий интервьюера. кандидат должен понимать, что текст запроса списка — не всегда окончательный запрос СУБД.

Убрать лишние поля и разыменования, перенести селективные условия раньше, проверить RLS и индексы, ограничить динамическое чтение. Результат подтверждают планом СУБД и замером списка.

Практический пример. поле представления составного регистратора удалили из списка, отбор перенесли раньше и получили Index Seek вместо чтения всего регистра.

Комментарий интервьюера. попросите назвать план и метрику до/после, а не принять «стало быстрее на глаз».

Небольшие двоичные данные сериализуют допустимым типом, большие помещают во временное хранилище и передают адрес. Для очень больших файлов используют потоковую обработку, если её поддерживает выбранный API версии.

Практический пример. скан 300 КБ возвращается как двоичные данные, архив 2 ГБ загружается потоком во временное хранилище.

Комментарий интервьюера. уточните лимит размера, очистку временных данных и защиту от загрузки произвольного файла.

Временное хранилище держит значение на сервере и выдаёт адрес. Оно уменьшает повторную передачу больших данных, но требует учитывать владельца и срок жизни адреса.

Практический пример. сформированный сервером PDF помещается во временное хранилище, клиент получает адрес и скачивает содержимое один раз.

Комментарий интервьюера. спросите, что произойдёт, если адрес использовать из другого сеанса или после истечения срока жизни.

Обещания позволяют описать продолжение асинхронной операции без вложенных обработчиков оповещения. Конкретный набор асинхронных методов зависит от версии платформы.

Практический пример. асинхронный диалог выбора файла возвращает обещание, а продолжение запускает загрузку без блокировки клиентского интерфейса.

Комментарий интервьюера. кандидат должен отличить асинхронность клиентского API от фонового выполнения серверной бизнес-операции.

Запустить фоновую/длительную операцию, сразу вернуть идентификатор, периодически получать прогресс и затем результат. Ошибка должна быть сохранена и показана пользователю без зависания формы.

Практический пример. пересчёт себестоимости запускается фоново, форма показывает 37%, пользователь может закрыть её и позже открыть результат по идентификатору.

Комментарий интервьюера. уточните хранение ошибки, отмену и повторное подключение к уже работающей операции.

Структура удобна для известного набора строковых ключей, доступных как свойства. Соответствие — словарь с произвольными допустимыми ключами; выбор определяется контрактом доступа.

Практический пример. параметры API {Дата, Организация} удобно передать структурой, а кэш объектов по ссылке — соответствием.

Комментарий интервьюера. попросите объяснить допустимые ключи и поведение при попытке добавить неизвестное свойство.

Массив — последовательность; список значений добавляет представления и UI-свойства; таблица значений — строки/колонки; дерево — иерархия. Для быстрого поиска по ключу обычно подходит соответствие.

Практический пример. порядок файлов хранится в массиве, варианты выбора — списком значений, плоский результат — таблицей, структура подразделений — деревом.

Комментарий интервьюера. выбор коллекции должен вытекать из операций над ней, а не из личной привычки.

Последовательный поиск в массиве обычно линейный O(n), поиск по хеш-ключу соответствия в среднем близок к O(1). Платформа не обещает все внутренние детали реализации, поэтому это оценка модели, а не контракт времени.

Практический пример. поиск 50 тысяч ссылок в массиве для каждой строки заменяют соответствием, сокращая миллионы сравнений.

Комментарий интервьюера. оценку O(1) следует называть средней моделью, а не гарантией внутренней реализации платформы.

Изменяемая коллекция может быть изменена через переданную ссылку на значение, поэтому вызывающий код увидит изменения содержимого. Для безопасного контракта явно копируют данные либо запрещают изменение соглашением.

Практический пример. процедура получила таблицу значений и добавила колонку; вызывающий увидел изменение, хотя сама переменная параметра не заменялась.

Комментарий интервьюера. уточните разницу между копированием ссылки на изменяемое значение и глубокой копией содержимого.

Без Знач процедура может заменить переменную-параметр вызывающего кода; Знач это запрещает. Оно не гарантирует глубокого копирования содержимого изменяемой коллекции.

Практический пример. параметр Знач Массив нельзя переназначить у вызывающего кода, но элементы переданной коллекции могут оставаться изменяемыми.

Комментарий интервьюера. попросите кандидата подтвердить спорную деталь коротким экспериментом в целевой версии.

Процедура выполняет действие и не возвращает значение оператором Возврат; функция вычисляет и возвращает значение. Функция с неожиданными побочными эффектами ухудшает понятность контракта.

Практический пример. РассчитатьСумму() возвращает число без побочных эффектов, а ЗаписатьЗаказ() выполняет действие и оформляется процедурой.

Комментарий интервьюера. функция, которая незаметно пишет данные, усложняет чтение, повтор и тестирование.

Переменные модуля доступны процедурам экземпляра этого модуля и живут в его контексте. На сервере нельзя использовать их как надёжное глобальное состояние между вызовами или процессами.

Практический пример. переменная серверного общего модуля не используется как единый счётчик для всего кластера, потому что рабочие процессы имеют разные контексты.

Комментарий интервьюера. спросите, где хранить согласованное общее состояние нескольких процессов.

Для чисел можно сложить и вычесть, но есть риск переполнения; для строк трюк требует разделителя и ломается на данных. Практический ответ: использовать третью переменную — это яснее и безопаснее.

Практический пример. для строк разной длины арифметический трюк неприменим, поэтому рабочее решение использует временную переменную Т = А; А = Б; Б = Т.

Комментарий интервьюера. оценивайте способность отвергнуть искусственное ограничение ради читаемого production-кода.

Для закрытых интервалов пересечение есть, если Максимум(A1, B1) <= Минимум(A2, B2). Для открытых границ равенство допустимо только когда обе соприкасающиеся границы включены.

Практический пример. интервалы [1,3] и (3,5] не пересекаются, потому что точка 3 исключена вторым интервалом; два закрытых интервала пересеклись бы.

Комментарий интервьюера. попросите нормализовать обратные границы и явно определить включённость концов.

Год високосный, если делится на 400 либо делится на 4 и не делится на 100. Код:

Возврат Год % 400 = 0 Или (Год % 4 = 0 И Год % 100 <> 0);.

Практический пример. Возврат Год % 400 = 0 Или (Год % 4 = 0 И Год % 100 <> 0); // 2000 — да, 1900 — нет.

Комментарий интервьюера. тесты должны включать обычный год, кратный 4, кратный 100 и кратный 400.

Например, сортировка слиянием имеет O(n log n) и требует дополнительную память; quicksort в среднем O(n log n), в худшем O(n²). В рабочем коде лучше штатная сортировка, если она покрывает тип данных.

Практический пример. сортировка слиянием делит массив, сортирует половины и сливает их за O(n log n), сохраняя стабильность.

Комментарий интервьюера. для прикладной задачи кандидат должен предпочесть штатную сортировку, если нет особого требования.

Даты сравнивают как даты в единой временной интерпретации, числа — после согласования точности и округления, строки — с учётом регистра и локали. Не преобразуйте типы в представление ради сравнения.

Практический пример. денежные суммы округляются установленным правилом до сравнения, а даты интеграции приводятся к согласованной временной зоне.

Комментарий интервьюера. строковое представление даты или числа не должно использоваться как универсальный ключ сравнения.

Исключение перехватывают там, где можно отменить транзакцию, добавить контекст или выполнить компенсацию. Неизвестную ошибку после очистки состояния передают выше командой повторного вызова исключения.

Практический пример. при ошибке записи обработчик отменяет транзакцию, добавляет номер входящего сообщения и повторно вызывает исключение.

Комментарий интервьюера. спросите, какую ошибку можно обработать локально, а какую необходимо передать владельцу операции.

Пустой блок скрывает повреждение данных и превращает ошибку в ложный успех. Минимум нужно восстановить согласованное состояние, зарегистрировать контекст и решить, можно ли продолжать.

Практический пример. Исключение КонецПопытки превращает неуспешную отправку в статус «готово», после чего сообщение безвозвратно удаляется из очереди.

Комментарий интервьюера. кандидат должен показать, как сохранить ошибку и не допустить ложного успеха.

Записывают операцию, безопасные идентификаторы объектов, пользователя/сеанс, текст и подробное представление ошибки, корреляционный идентификатор. Пароли, токены и лишние персональные данные журналировать нельзя.

Практический пример. журнал содержит OrderId, MessageId, сеанс и подробное представление ошибки, но маскирует токен Authorization.

Комментарий интервьюера. попросите разделить сообщение пользователю и технические данные для расследования.

Не искать для каждой строки вторую таблицу линейным циклом. Постройте соответствие по ключу либо выполните соединение одним запросом; это меняет типичную сложность с O(n²) на близкую к O(n).

Практический пример. две таблицы по 10 тысяч строк соединяются запросом или через соответствие, а не ста миллионами последовательных сравнений.

Комментарий интервьюера. попросите оценить память дополнительного индекса и измерить выигрыш на реальном размере.

Рефлексия оправдана для универсальных библиотечных механизмов, где тип заранее неизвестен. В обычной предметной логике явные типы проще, быстрее проверяются и безопаснее при обновлении.

Практический пример. универсальная печать получает метаданные реквизитов динамически; расчёт скидки использует явную структуру типов и не нуждается в рефлексии.

Комментарий интервьюера. чрезмерная универсальность переносит ошибки из времени разработки в runtime.

Проверить свойство регистра в коллекции метаданных: режим записи/подчинение регистратору определяется метаданными конкретного регистра. Точное имя свойства следует сверить в синтакс-помощнике целевой версии.

Практический пример. обработка читает коллекцию метаданных регистра и проверяет режим записи, прежде чем создавать менеджер отдельной записи.

Комментарий интервьюера. точное имя свойства можно посмотреть; важнее понимание, что решение определяется метаданными, а не именем регистра.

Запрос декларативно выбирает поля множества записей и выполняется таблично. Объектный доступ загружает сущность с поведением и нужен для её изменения и записи.

Практический пример. отчёт получает код и наименование 100 тысяч товаров запросом, а переименование одного элемента выполняет через объект справочника.

Комментарий интервьюера. запрос не должен использоваться как средство прямого изменения полученного набора.

Внутреннее соединение оставляет совпадения; левое сохраняет все строки слева; правое — справа; полное — обе стороны, заполняя отсутствующую часть NULL.

Практический пример. левое соединение сохраняет все товары и показывает NULL для отсутствующей цены; внутреннее исключило бы товары без цены.

Комментарий интервьюера. попросите предсказать число строк при связи один-ко-многим, а не только назвать четыре вида соединений.

ОБЪЕДИНИТЬ удаляет дубликаты, что требует дополнительной обработки. ОБЪЕДИНИТЬ ВСЕ просто складывает наборы и обычно быстрее, если дедупликация не нужна.

Практический пример. объединение архивных и текущих операций использует ОБЪЕДИНИТЬ ВСЕ, если источники гарантированно не пересекаются.

Комментарий интервьюера. кандидат должен объяснить стоимость удаления дубликатов и случаи, когда оно действительно необходимо.

Логически сначала формируется источник и соединения, затем ГДЕ, группировка, ИМЕЮЩИЕ, выражения результата и сортировка. Физический оптимизатор может переставить операции, сохраняя семантику.

Практический пример. фильтр по организации логически применяется до группировки продаж, а условие СУММА(Выручка) > 100000 — после неё.

Комментарий интервьюера. физический план может переставлять операции, поэтому не путайте логическую семантику с порядком исполнения СУБД.

Сначала агрегируйте обе таблицы по номенклатуре, затем соедините по номенклатуре. Если нужен полный перечень из обеих таблиц — используйте полное соединение либо таблицу всех ключей и два левых соединения; отсутствующие показатели замените через ЕСТЬNULL.

Практический пример. сначала агрегируют количество и сумму отдельно по номенклатуре, затем соединяют два маленьких результата, заменяя отсутствующее значение через ЕСТЬNULL.

Комментарий интервьюера. уточните, нужно ли сохранить ключи только первой таблицы или полный набор из обеих — это меняет вид соединения.

Запрос вернёт число строк таблицы справочника, потому что для каждой строки суммируется единица. При пустой таблице агрегат может вернуть NULL, поэтому для гарантированного нуля применяют ЕСТЬNULL(СУММА(1), 0).

Практический пример. на справочнике из пяти элементов СУММА(1) вернёт 5, а на пустом источнике результат защищают выражением ЕСТЬNULL(..., 0).

Комментарий интервьюера. кандидат должен объяснить агрегатную семантику и отдельно подумать о пустом наборе.

В новых версиях можно использовать поддерживаемую языком запросов нумерацию/оконную функцию, если она доступна в целевой версии. Универсальный старый вариант — выгрузить упорядоченный результат и добавить номер при обходе; порядок обязан быть явно задан.

Практический пример. результат явно сортируют по дате и ссылке, после чего присваивают номера; без второй части порядка одинаковые даты дают нестабильную нумерацию.

Комментарий интервьюера. спросите, поддерживает ли целевая версия оконные функции, и не принимайте непроверенный синтаксис как универсальный.

Надёжный способ: сначала получить максимальный период по ключу, затем соединить с исходными данными по ключу и периоду. Для периодического регистра сведений чаще правильнее СрезПоследних с условием по измерениям.

Практический пример. максимальную дату статуса получают по заказу, затем соединяют с исходным регистром по заказу и дате; дубликаты на одной дате требуют дополнительного ключа.

Комментарий интервьюера. хороший ответ замечает проблему нескольких записей с одинаковым максимальным периодом.

ГДЕ фильтрует исходные строки до группировки, ИМЕЮЩИЕ — уже сформированные группы и агрегаты. Условие по обычному полю лучше помещать в ГДЕ, чтобы раньше сократить данные.

Практический пример. ГДЕ Организация=&Организация уменьшает строки продаж до группировки, а ИМЕЮЩИЕ СУММА(Сумма)>100000 отбирает итоговые группы.

Комментарий интервьюера. попросите перенести условие между секциями и объяснить, когда изменится результат, а не только скорость.

Сравнение с NULL не даёт обычного истинного результата, поэтому используют ЕСТЬ NULL. Арифметика с отсутствующим значением обычно распространяет NULL; заменяйте его только там, где бизнес-смысл действительно равен нулю.

Практический пример. товар без цены после левого соединения имеет NULL; выражение Цена + 10 также остаётся неопределённым, пока цена не заменена осмысленным значением.

Комментарий интервьюера. кандидат должен различать «нет записи цены» и «цена равна нулю» — это разные бизнес-факты.

ЕСТЬNULL(Выражение, Замена) подменяет табличный NULL. Пустая ссылка — реальное типизированное значение и проверяется сравнением с пустой ссылкой соответствующего типа; это разные состояния.

Практический пример. ЕСТЬNULL(Цена,0) заменяет отсутствие присоединённой строки, а Контрагент = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка) проверяет заполненность ссылки.

Комментарий интервьюера. смешение этих проверок часто приводит к неверному отбору и должно быть обнаружено на примере.

Используют ТИПЗНАЧЕНИЯ() и сравнение с ТИП(...), либо ВЫРАЗИТЬ для безопасного сужения составного типа. Точный синтаксис проверяют в синтакс-помощнике версии платформы.

Практический пример. перед чтением реквизита документа составное поле проверяют через ТИПЗНАЧЕНИЯ, затем сужают ВЫРАЗИТЬ к нужному документу.

Комментарий интервьюера. попросите объяснить поведение для другого типа и для NULL, а не принимать выражение как безопасное само по себе.

ВЫРАЗИТЬ(Поле КАК Документ.Заказ) сообщает конкретный тип составной ссылки. Это уменьшает число потенциальных соединений при обращении через точку и делает намерение явным.

Практический пример. ВЫРАЗИТЬ(Регистратор КАК Документ.Реализация).Дата создаёт соединение только с таблицей реализаций при согласованном условии типа.

Комментарий интервьюера. если поле содержит другие регистраторы, кандидат должен показать, как они будут обработаны без ложных данных.

Для составного типа платформа может присоединить таблицы каждого возможного ссылочного типа. В результате простой реквизит через точку превращается в несколько соединений и ухудшает план.

Практический пример. составной регистратор допускает десять документов, и получение .Контрагент через точку порождает соединения с таблицами всех совместимых типов.

Комментарий интервьюера. сильный кандидат сначала ограничит тип и набор, а затем подтвердит итоговый SQL технологическим журналом.

Разыменование — получение реквизита объекта по ссылочному полю. В запросе оно транслируется в соединение с таблицей целевого объекта, а при составном типе — потенциально с несколькими таблицами.

Практический пример. запрос Заказ.Контрагент.ИНН последовательно разыменовывает две ссылки и добавляет соответствующие соединения к таблицам заказа и контрагента.

Комментарий интервьюера. попросите предложить денормализацию или предварительную выборку только после измерения реальной стоимости.

Каждая итерация повторяет подготовку и выполнение запроса и часто сетевой переход. Один пакетный запрос или временная таблица обычно читает данные набором и лучше использует оптимизатор.

Практический пример. 10 тысяч строк вызывают 10 тысяч запросов цены; один запрос по списку ссылок возвращает те же данные за одно выполнение.

Комментарий интервьюера. оцените число выполнений, а не только суммарное время одного запроса в замере.

Допустим, если число итераций гарантированно мало, запрос дешёвый, наборное решение непропорционально сложно и это подтверждено замером. Такое решение следует явно ограничить и прокомментировать.

Практический пример. цикл из трёх фиксированных организаций с редким административным запросом оставили после замера, потому что усложнение пакетного варианта не окупалось.

Комментарий интервьюера. кандидат должен назвать жёсткую верхнюю границу и доказательство, иначе исключение превратится в оправдание плохого кода.

Подзапрос логически является частью общего выражения, а временная таблица материализует результат и может использоваться повторно или индексироваться. Материализация имеет собственную стоимость, поэтому не всегда быстрее.

Практический пример. подзапрос последней цены используется один раз, а временная таблица списка товаров индексируется и участвует в трёх последующих пакетах.

Комментарий интервьюера. спросите о стоимости записи и индексации временной таблицы — материализация не бесплатна.

Когда таблица достаточно велика и далее многократно соединяется/отбирается по одному ключу. Индекс маленькой одноразовой таблицы может стоить дороже сохранённого чтения.

Практический пример. временная таблица из 200 тысяч ключей соединяется с движениями несколько раз, поэтому индекс по ключу окупается; для 20 строк он только добавит работу.

Комментарий интервьюера. решение должно подтверждаться фактическим планом и числом повторных чтений.

Менеджер временных таблиц удерживает их между несколькими запросами. Пакет выполняет последовательность операторов и позволяет создать временную таблицу, а затем использовать её в следующих частях.

Практический пример. первый запрос помещает разрешённые товары во временную таблицу, второй считает остатки, третий — цены, используя один менеджер временных таблиц.

Комментарий интервьюера. уточните время жизни менеджера и очистку при исключении, чтобы кандидат не считал таблицу постоянной.

В клиент-серверном варианте временные данные обслуживаются серверной частью и СУБД в рамках менеджера временных таблиц; в файловом — движком платформы. Жизненный цикл ограничен менеджером/соединением и выполнением, а не пользовательским сеансом навсегда.

Практический пример. после уничтожения менеджера следующий запрос уже не видит созданную временную таблицу, даже если пользовательский сеанс продолжается.

Комментарий интервьюера. физическое размещение различается по режимам, поэтому не требуйте единственного имени каталога или tempdb для всех вариантов.

Селективные условия по измерениям передают параметром виртуальной таблицы, чтобы ограничить исходные движения до расчёта результата. Внешний ГДЕ может отфильтровать уже вычисленный большой набор.

Практический пример. условие склада внутри Остатки(&Дата, Склад=&Склад) ограничивает расчёт, тогда как внешний ГДЕ может получить остатки всех складов и отбросить их позже.

Комментарий интервьюера. попросите кандидата сравнить планы обеих форм на реальном регистре, поскольку оптимизатор иногда проталкивает условие самостоятельно.

Функция над колонкой часто делает условие несаргируемым: индекс нельзя использовать для прямого поиска. Лучше вычислить границы параметра, например отбирать дату диапазоном вместо функции НАЧАЛОПЕРИОДА(Дата).

Практический пример. вместо ГОД(Дата)=2026 задают диапазон Дата >= &НачалоГода И Дата < &НачалоСледующего, пригодный для поиска по индексу.

Комментарий интервьюера. хороший ответ употребляет понятие саргируемого условия или точно объясняет его без жаргона.

Каждая виртуальная таблица может агрегировать большой набор движений, после чего результаты соединяются. Сначала ограничьте параметры и при необходимости материализуйте небольшой промежуточный набор.

Практический пример. остатки и цены сначала рассчитываются для всей номенклатуры и соединяются, создавая огромные промежуточные наборы; список товаров нужно ограничить заранее.

Комментарий интервьюера. спросите, можно ли сначала материализовать небольшой перечень ключей и передать его в обе виртуальные таблицы.

ПОМЕСТИТЬ сохраняет результат на сервере во временной таблице и не передаёт его клиенту. Получение выборки сериализует/возвращает данные вызывающему коду.

Практический пример. ПОМЕСТИТЬ ВТТовары сохраняет серверный промежуточный набор; Выполнить().Выгрузить() переносит результат в память встроенного языка.

Комментарий интервьюера. кандидат должен учитывать как сетевую передачу, так и память рабочего процесса при большой выгрузке.

Левое соединение с правой таблицей и условие Правая.Ключ ЕСТЬ NULL формирует антисоединение. Оно часто понятнее и безопаснее НЕ В, особенно при возможном NULL.

Практический пример. все товары соединяют слева с продажами и выбирают строки, где Продажи.Товар ЕСТЬ NULL, получая товары без продаж.

Комментарий интервьюера. уточните уникальность правой таблицы; дубликаты могут размножить строки до проверки отсутствия.

Если множество НЕ В содержит NULL, трёхзначная логика может сделать результат неожиданно пустым. Исключите NULL явно или используйте антисоединение.

Практический пример. подзапрос НЕ В вернул один NULL, и ни один товар не удовлетворил условию; фильтрация NULL или антисоединение восстанавливает смысл.

Комментарий интервьюера. попросите объяснить трёхзначную логику, а не запомнить запрет НЕ В без причины.

ДЛЯ ИЗМЕНЕНИЯ сообщает о намерении менять прочитанные данные внутри транзакции и влияет на блокировки. Без узкого условия и подходящего индекса можно заблокировать слишком большую область.

Практический пример. запрос ДЛЯ ИЗМЕНЕНИЯ без склада прочитал весь регистр и заблокировал конкурентное проведение; узкое условие и индекс ограничили область.

Комментарий интервьюера. кандидат должен связать текст запроса, режим блокировок и физический план, а не считать конструкцию заменой анализа.

Зафиксировать сценарий → найти запрос по ТЖ → получить SQL и фактический план → сравнить оценочные и реальные строки → проверить фильтры, RLS и индексы → изменить одну причину → повторить замер.

Практический пример. ТЖ показал запрос 8 секунд, фактический план — ошибочную оценку 20 вместо 3 млн строк; после обновления статистики изменился порядок соединений.

Комментарий интервьюера. спросите, как исключить влияние прогрева кэша и параллельной нагрузки при сравнении.

Только по фактическому плану СУБД: ищут Index Seek/Scan или соответствующие операции конкретной СУБД и число прочитанных строк. Наличие индекса в метаданных не доказывает его использование.

Практический пример. наличие индекса по контрагенту не помогло условию с функцией; фактический план показал Scan и 12 млн прочитанных строк.

Комментарий интервьюера. ответ «индекс есть» без плана и фактических чтений не подтверждает использование.

Кардинальность — оценка числа строк на шагах плана. Ошибка оценки заставляет оптимизатор выбрать неподходящий порядок соединений, метод join или способ доступа.

Практический пример. оптимизатор ожидал одну строку после RLS, получил 500 тысяч и выбрал вложенные циклы вместо более подходящего хеш-соединения.

Комментарий интервьюера. кандидат должен назвать возможные причины ошибки оценки — статистика, корреляция полей, параметры или сложное условие.

Распределение значений и актуальность статистики определяют селективность параметра. Один план может быть хорош для редкого значения и плох для массового; это проверяют на реальных параметрах.

Практический пример. план для редкой организации эффективен через индекс, а для организации с 80% данных выгоднее сканирование; один кэшированный план не универсален.

Комментарий интервьюера. попросите предложить проверку на нескольких характерных параметрах, а не только на своём пользователе.

Сравнивают время p50/p95, CPU, логические/физические чтения, число строк на шагах, ожидания блокировок и пропускную способность. Данные, нагрузка и сценарий до/после должны быть сопоставимы.

Практический пример. после переписывания запроса время упало на тёплом кэше, но суммарные чтения выросли; под нагрузкой новая версия оказалась хуже.

Комментарий интервьюера. набор метрик должен включать ресурсы и конкурентный сценарий, иначе локальное ускорение может быть ложным.

Если структура известна, создайте макет или программно сформируйте табличный документ: области заголовка, строки и итогов, затем заполните параметры при обходе таблицы. Для пользовательской аналитики предпочтительнее СКД.

Практический пример. макет содержит области заголовка и строки, код выводит строку для каждого элемента таблицы и итог после цикла; оформление не смешивается с расчётом данных.

Комментарий интервьюера. спросите, почему для настраиваемой аналитики СКД будет сопровождаемее ручной отрисовки.

Да, ответ должен назвать реальные задачи: отчёты, расшифровки, варианты, программное формирование. Далее объясните один сложный случай и как контролировали сформированный запрос.

Практический пример. кандидат описывает отчёт по валовой прибыли со своими наборами данных, расшифровкой до документа и программно поставляемым вариантом.

Комментарий интервьюера. уточните одну реальную проблему СКД и способ диагностики сформированного запроса.

Схема компоновки — декларативное описание данных, ресурсов, настроек и макетов. Система компоновки — набор объектов, который применяет настройки к схеме и формирует результат.

Практический пример. XML схемы хранит поля и настройки, компоновщик макета создаёт исполняемый макет, процессор компоновки формирует результат.

Комментарий интервьюера. кандидат должен различать статическое описание и объекты конкретного исполнения отчёта.

Набор данных получает строки; связи объединяют наборы; вычисляемое поле выводится из выражения; ресурс агрегируется; параметр влияет на запрос или компоновку. Ошибка — считать ресурс просто колонкой отчёта.

Практический пример. продажи — набор данных, организация — параметр, сумма — ресурс, маржа — вычисляемое поле, связь с планом продаж объединяет второй набор.

Комментарий интервьюера. попросите указать этап вычисления поля и допустимость агрегации, потому что от этого зависит корректность итога.

Отбор набора данных попадает ближе к источнику и сокращает чтение. Пользовательский отбор может применяться позднее; критичный фильтр больших данных нужно протолкнуть в запрос.

Практический пример. ограничение организации в запросе читает только её продажи, а пользовательский отбор уже готового отчёта может обрабатывать значительно больший набор.

Комментарий интервьюера. важно различить семантическую необходимость пользовательской настройки и техническое проталкивание критичного фильтра.

Создать настройки компоновки, инициализировать компоновщик макета, процессор компоновки и процессор вывода, затем вывести в табличный документ. Конкретные имена конструкторов сверяются по синтакс-помощнику.

Практический пример. регламентное задание формирует отчёт без формы, применяет сохранённый вариант СКД и записывает табличный документ в файл.

Комментарий интервьюера. спросите, как передать параметры, получить расшифровку и обработать ошибку фонового формирования.

В схеме задают собственный макет области и связывают его с элементом структуры вывода. Программно можно обработать результат/макет, но чрезмерная постобработка усложняет поддержку вариантов.

Практический пример. собственный макет выделяет просроченные строки цветом и добавляет юридический подвал, не меняя запрос набора данных.

Комментарий интервьюера. чрезмерная программная постобработка результата может разрушить пользовательские варианты и должна быть обоснована.

Расшифровка хранит идентификатор элемента и набор исходных значений/полей. По клику система получает эти данные и выполняет стандартное либо пользовательское действие.

Практический пример. клик по сумме клиента передаёт в расшифровку клиента и период, после чего открывается список исходных реализаций.

Комментарий интервьюера. уточните права на расшифровываемые данные — отображённый агрегат не даёт автоматического доступа к каждой строке.

СКД может породить тяжёлые соединения, лишние представления, повторные наборы и поздние отборы. Анализируют фактически сформированный запрос и план, а не только визуальную схему.

Практический пример. связь двух наборов один-ко-многим размножила продажи до агрегации и одновременно ухудшила результат и нагрузку.

Комментарий интервьюера. хороший ответ проверяет не только время, но и кардинальность и правильность итогов.

Представление ссылки требует обращения к таблице объекта и иногда дополнительных полей. Для массового отчёта выводите только нужные значения и избегайте разыменования составных ссылок.

Практический пример. вывод 15 ссылочных полей заставил получать представления разных типов; замена части полей кодами сократила соединения.

Комментарий интервьюера. спросите, какие представления действительно нужны пользователю и можно ли получать их после агрегации малого набора.

БСП хранит пользовательские настройки и поставляемые варианты через подсистему вариантов отчётов. Подключение и сигнатуры интерфейсов зависят от встроенной редакции БСП.

Практический пример. поставляемый вариант обновляется вместе с конфигурацией, пользовательская копия сохраняет собственные настройки и доступность.

Комментарий интервьюера. кандидат должен учитывать версию БСП и правила обновления изменённых пользователем вариантов.

Тестировать нужно слоями: запрос и данные, применение настроек, итоговые значения и критичный макет. Пиксельное сравнение всего табличного документа обычно хрупкое.

Практический пример. отдельный тест проверяет сумму набора, второй — пользовательский отбор, третий — наличие обязательного подвала; изменение шрифта не ломает расчётный тест.

Комментарий интервьюера. попросите разделить стабильные бизнес-проверки и хрупкое сравнение визуального макета.

Движения — записи регистров, сформированные документом-регистратором. Они отражают влияние события на учётное состояние.

Практический пример. реализация создаёт расход количества в регистре товаров и увеличение долга в регистре взаиморасчётов; обе записи имеют одного регистратора.

Комментарий интервьюера. кандидат должен отличать движения от табличных частей и от проводок конкретного бухгалтерского регистра.

Оперативное проведение ориентировано на актуальный момент и оперативные проверки; неоперативное отражает событие прошлой датой. Конкретные ограничения задаёт прикладное решение.

Практический пример. сегодняшнее списание проводится оперативно с контролем доступности, восстановление документа прошлого месяца — неоперативно по регламенту.

Комментарий интервьюера. уточните, какие ограничения задаёт сама платформа, а какие реализованы конкретной конфигурацией.

Запись сохраняет реквизиты и табличные части документа. Проведение дополнительно выполняет алгоритм и записывает движения; проведённость означает успешное отражение в учёте.

Практический пример. записанный заказ сохраняет намерение клиента, а проведённая реализация меняет товарный и финансовый учёт.

Комментарий интервьюера. вопрос проверяет понимание бизнес-события; флаг проведения без корректных движений сам по себе ничего не гарантирует.

Запись документа и согласованных движений обычно выполняются в общей транзакции платформы. Код проведения не должен добавлять диалог, долгий HTTP или другую непредсказуемую задержку.

Практический пример. документ и два набора движений записываются атомарно; ошибка второго регистра откатывает шапку и первый набор.

Комментарий интервьюера. попросите показать, что произойдёт с внешним письмом, если его отправить до фиксации этой транзакции.

Свойство определяет, когда платформа удаляет прежние движения документа при записи/проведении. Режим выбирают с учётом ручной записи наборов; точные варианты проверяют в свойствах версии.

Практический пример. перед перепроведением старые движения регистратора удаляются и заменяются новыми; при ручном управлении наборами режим удаления выбирают осознанно.

Комментарий интервьюера. точные варианты свойства зависят от версии, но кандидат обязан понимать риск оставшихся или удвоенных движений.

Последовательность контролирует хронологическую зависимость документов. Изменение прошлой записи сдвигает границу, после которой документы могут требовать перепроведения.

Практический пример. изменение поступления 5 января сдвигает границу последовательности, и реализации после этой даты требуют перепроведения для восстановления партий.

Комментарий интервьюера. спросите, чем граница последовательности отличается от простого списка непроведённых документов.

Разбить документы на упорядоченные порции, хранить контрольную точку, ограничивать транзакцию и нагрузку, протоколировать ошибки. Перед запуском проверить закрытые периоды и влияние на пользователей.

Практический пример. 500 тысяч документов сортируют по периоду и ссылке, проводят порциями по 500, фиксируют курсор и ограничивают ночную нагрузку.

Комментарий интервьюера. кандидат должен описать продолжение после сбоя и поведение с ошибочным документом внутри порции.

Повтор должен сформировать тот же набор движений, а не добавить второй. Движения очищают/заменяют в области регистратора, а внешние эффекты защищают ключом идемпотентности.

Практический пример. повторное проведение заказа удаляет движения его регистратора и формирует те же строки; внешняя отправка защищена MessageId.

Комментарий интервьюера. уточните, какие эффекты находятся вне транзакции ИБ и требуют отдельной идемпотентности.

После записи собственных движений запрос может видеть состояние с ними, что меняет смысл контроля. Следует заранее определить методику: контроль до записи с блокировкой либо расчёт с исключением движений текущего документа.

Практический пример. документ уже добавил расход 7, затем запрос остатка показывает 3; повторная проверка исходного остатка 10 по этому значению будет ошибочно трактована.

Комментарий интервьюера. попросите кандидата выбрать одну методику контроля и явно учесть движения текущего регистратора.

Код-схема: НачатьТранзакцию(); Блокировка.Заблокировать(); Остаток=ПолучитьОстаток(); Если Остаток<Количество Тогда ВызватьИсключение; КонецЕсли; ЗаписатьДвижения(); ЗафиксироватьТранзакцию();. В исключении обязательно отменить транзакцию.

Практический пример. внутри Попытка сначала Блокировка.Заблокировать(), затем запрос остатка, вызов исключения при дефиците и запись движений; Исключение отменяет транзакцию.

Комментарий интервьюера. ключевая проверка — чтение выполняется после блокировки, иначе между проверкой и записью остаётся гонка.

Конструктор полезен как старт типового алгоритма; рабочий код обычно формирует наборы массово по данным запроса. Построчная запись каждого движения отдельно создаёт лишние обращения.

Практический пример. запрос рассчитывает движения сразу по всем строкам документа и загружает набор; конструктор использовался лишь как исходный шаблон.

Комментарий интервьюера. построчная запись набора в цикле должна вызвать вопрос о числе обращений и целостности общей операции.

Вызываются события перед записью и при записи объекта, обработка проведения и связанные подписки. Точный порядок формы и объекта зависит от способа вызова, поэтому инварианты держат в серверном слое.

Практический пример. ПередЗаписью проверяет реквизиты, обработка проведения формирует движения, подписка регистрирует аудит, а форма только отображает результат.

Комментарий интервьюера. попросите назвать различия цепочки при программной записи без открытия формы.

Централизованно проверять дату по настройкам запрета изменения данных и правам пользователя перед записью/проведением. Скрытие команды формы недостаточно.

Практический пример. сервер сравнивает дату документа с индивидуальной датой запрета и проверяет право изменения закрытого периода, независимо от видимости кнопки.

Комментарий интервьюера. кандидат должен учитывать обмен и фоновую обработку, которые не используют пользовательскую форму.

Запрос предпочтителен при массовом вычислении по таблицам и регистрами. Построчный код допустим для малого набора со сложной логикой, которую нельзя разумно выразить запросом; результат измеряют.

Практический пример. 10 тысяч строк распределяются запросом пропорционально базе; пять строк со сложным предметным условием рассчитываются ясным циклом в памяти.

Комментарий интервьюера. попросите подтвердить границу между вариантами замером и оценкой сопровождаемости.

Регистр сведений хранит многомерные факты без собственной ссылочной сущности. Бывает периодическим или непериодическим, независимым либо подчинённым регистратору.

Практический пример. соответствие внешнего кода внутреннему объекту хранится непериодическим независимым РС, история курса — периодическим.

Комментарий интервьюера. кандидат должен назвать ключ записи и объяснить, почему справочник или документ хуже в каждом случае.

Независимый регистр записывается по ключу без документа-регистратора. Подчинённый хранит записи в области регистратора и обычно управляется набором движений документа.

Практический пример. настройки пользователя записываются независимо, а строки сведений, сформированные документом импорта, удаляются вместе с областью его регистратора.

Комментарий интервьюера. уточните доступность менеджера записи и способ массовой замены области для обоих режимов.

Ключ задают измерения, а у периодического регистра также нормализованный период; для подчинённого режима участвуют системные поля записи. Физический индекс зависит от свойств.

Практический пример. для непериодического регистра ключ — организация и настройка; для месячного добавляется нормализованный месяц, поэтому в одном месяце допустима одна запись ключа.

Комментарий интервьюера. попросите кандидата учесть разделители и регистратора, если они включены свойствами метаданных.

Периодичность задаёт минимальную точность момента записи и влияет на уникальность. При периодичности «месяц» две записи одного ключа внутри месяца конфликтуют как один период.

Практический пример. периодичность «день» превращает два времени 10:00 и 18:00 одной даты в один логический период для одинаковых измерений.

Комментарий интервьюера. хороший ответ связывает периодичность не только с отображением даты, но и с уникальностью данных.

Платформа нормализует дату до начала единицы периодичности: дня, месяца и т. п. Для «секунда» сохраняется секундная точность; детали специальных режимов сверяют по документации.

Практический пример. запись 17.03.2026 14:25 в месячном регистре относится к периоду 01.03.2026, а в дневном — к 17.03.2026 00:00.

Комментарий интервьюера. уточните потребность нескольких событий внутри единицы периода до выбора схемы.

Ресурс — основное значение описываемого факта, реквизит — дополнительное свойство записи. Для РС различие прежде всего моделирующее, но помогает правильно читать схему.

Практический пример. в регистре цен Цена — ресурс факта, ИсточникЗагрузки — реквизит, поясняющий происхождение записи.

Комментарий интервьюера. попросите показать, какие поля участвуют в виртуальном срезе и какие являются лишь дополнительными данными.

Создать набор записей с точным отбором, прочитать нужную область, очистить и записать. Нельзя очищать набор без понимания отбора: запись заменяет всю его область.

Практический пример. для удаления цен только одного вида набор получает отбор ВидЦены, читает эту область, очищает и записывает; пустой отбор затронул бы всё.

Комментарий интервьюера. кандидат должен понимать замещающую семантику записи набора, а не просто вызвать Очистить().

«Ведущее» связывает существование записи с ведущим измерением и участвует в контроле удаления; «Основной отбор» оптимизирует типовые формы/доступ по полю. Точное платформенное поведение сверяют по версии.

Практический пример. ведущее измерение Номенклатура связывает существование записей свойств с товаром, основной отбор помогает типовой форме быстро показать его свойства.

Комментарий интервьюера. точное платформенное поведение стоит сверить, но смысл свойств кандидат должен отличать от обычного индекса.

СрезПоследних возвращает последние записи не позже границы по каждому ключу, СрезПервых — первые в требуемом направлении. Отборы по измерениям передают параметром виртуальной таблицы.

Практический пример. на 15 марта СрезПоследних возвращает цену от 10 марта, игнорируя будущую запись от 20 марта; СрезПервых решает обратную временную задачу.

Комментарий интервьюера. попросите объяснить результат при двух измерениях и отсутствии записи до границы.

Запрос к СрезПоследних(&Дата, Номенклатура В (&Список)), затем выбрать номенклатуру и ресурс цены. Список лучше передать таблицей/массивом подходящего размера, а план проверить.

Практический пример. Пример запроса: Цены.СрезПоследних(&Дата, Номенклатура В (&Товары) И ВидЦены=&ВидЦены) возвращает по одной актуальной цене на ключ.

Комментарий интервьюера. уточните размер списка и индекс, если товаров сотни тысяч; синтаксически верный запрос ещё не гарантирует скорость.

Если сначала получить срез по всем измерениям, а потом фильтровать, будет обработано лишнее. Кроме того, отбор по реквизиту после выбора последней записи семантически отличается от отбора допустимых записей до среза.

Практический пример. сначала выбрать последнюю запись любого источника и потом оставить Источник="API" — не то же самое, что искать последнюю среди API-записей.

Комментарий интервьюера. вопрос одновременно проверяет производительность и семантику порядка применения отбора.

Если требуется несколько событий одного ключа внутри минимальной периодичности либо самостоятельная сущность события с жизненным циклом, периодический РС не подходит. Выбирают меньшую периодичность, документ или отдельный объект.

Практический пример. журнал датчиков получает десятки событий в миллисекунду; секундная периодичность РС теряет уникальность, поэтому добавляют идентификатор события или отдельный объект.

Комментарий интервьюера. кандидат должен вывести схему из требуемой частоты, а не механически выбрать «периодический регистр».

Задать отбор ровно по изменяемой области, загрузить данные пачкой и записать набор один раз. Пустой/широкий отбор способен заменить чужие записи.

Практический пример. импорт формирует таблицу 50 тысяч соответствий, устанавливает отбор по источнику и записывает один набор вместо 50 тысяч менеджеров записи.

Комментарий интервьюера. спросите, как не удалить вручную созданные записи другого источника и как обработать частичную ошибку.

Платформа создаёт обязательные ключевые индексы и дополнительные для измерений/реквизитов со свойством индексирования. Точный состав смотрят в официальной таблице индексов для версии и режима регистра.

Практический пример. включение индексирования измерения ВнешнийКод создаёт дополнительный индекс для поиска, но замедляет каждую загрузку записей.

Комментарий интервьюера. кандидат должен сверить фактический состав индекса, а не угадывать порядок колонок по окну метаданных.

Сначала учитывают уникальность и частые условия: ведущие поля равенства должны поддерживать левый префикс индекса. Затем проверяют ширину ключа, селективность и план.

Практический пример. запросы почти всегда задают организацию и товар, поэтому этот порядок рассматривают для ключа; редкий отбор только по периоду проверяется отдельно.

Комментарий интервьюера. «самое селективное поле первым» не является достаточным универсальным правилом составного индекса.

Регистр накопления хранит числовые движения в разрезе измерений и поддерживает получение итогов. Он предназначен для остатков или оборотов, а не для свойств сущности.

Практический пример. движения поступления и реализации хранят количество по складу и товару, а виртуальные таблицы дают остатки и обороты.

Комментарий интервьюера. попросите объяснить, почему текущую цену или комментарий товара не следует моделировать ресурсом этого регистра.

Остаточный регистр имеет направления приход/расход и позволяет получить остаток; оборотный хранит только величину оборота. Нельзя осмысленно запросить остаток у оборотного регистра.

Практический пример. складской запас требует остаточного регистра, статистика количества обращений за день — оборотного, потому что отрицательный/конечный остаток там не имеет смысла.

Комментарий интервьюера. кандидат должен выбирать вид по бизнес-смыслу ресурса, а не по привычке использовать остатки.

У остаточного доступны Остатки, Обороты, ОстаткиИОбороты; у оборотного — Обороты. Состав специальных виртуальных таблиц зависит от вида регистра.

Практический пример. для товарного регистра используются Остатки, Обороты и ОстаткиИОбороты; у регистра продаж остаются только обороты.

Комментарий интервьюера. уточните параметры периода и отличие оборотов регистратора от оборотов по календарному периоду.

Первый параметр — граница периода соответствующего типа даты; последующие параметры задают условия/измерения согласно синтаксису виртуальной таблицы. Точную сигнатуру проверяют конструктором запроса версии.

Практический пример. Остатки(&КонецДня, Склад=&Склад) получает границу датой и внутреннее условие, а не произвольную таблицу значений в первом параметре.

Комментарий интервьюера. если кандидат не помнит точную сигнатуру, правильнее открыть конструктор виртуальной таблицы, чем выдумывать её.

Основная таблица хранит первичные движения. Таблицы итогов содержат агрегированные производные значения для ускорения чтения.

Практический пример. реализация записывает строку движения, а таблица итогов хранит агрегат по периоду, складу и товару для быстрого остатка.

Комментарий интервьюера. попросите назвать, какую таблицу можно восстановить и почему прямое редактирование итогов недопустимо.

Первичны движения; итоги можно пересчитать из них. Прямое исправление итогов без движений нарушает модель и не является прикладным способом ремонта.

Практический пример. после потери/повреждения итогов штатный пересчёт строит их из сохранённых движений; обратное восстановление конкретных документов из итоговой суммы невозможно.

Комментарий интервьюера. это проверяет понимание направления производности данных.

Это граница, до которой поддерживаются рассчитанные текущие итоги. Она влияет на способ получения данных за разные даты, но не меняет смысл движений.

Практический пример. итоги рассчитаны по 31 декабря, запрос февраля использует периодические итоги и последующие движения согласно механизму платформы.

Комментарий интервьюера. кандидат не должен выдавать изменение периода итогов за исправление ошибочных первичных движений.

Обычно имеется в виду установить период рассчитанных итогов/закрыть прошлый интервал, чтобы запросы эффективно использовали итоги. Термин нужно уточнить, потому что это не формальное имя единственной операции.

Практический пример. после закрытия декабря пользователям запрещают менять документы прошлого периода, а расчёт итогов фиксирует эффективную границу аналитики.

Комментарий интервьюера. термин «закрыть регистр» неоднозначен; сильный кандидат сначала уточнит, что именно имеет в виду интервьюер.

Проблема возникает, если движения продолжают изменяться в закрываемом прошлом или модель требует пересчёта раньше границы. Нужно устранить источник задних изменений и определить регламент закрытия.

Практический пример. импорт ежедневно меняет движения трёхмесячной давности, поэтому граница итогов постоянно отступает и закрытие не стабилизируется.

Комментарий интервьюера. решение должно устранить процесс задних изменений, а не только чаще запускать пересчёт.

Ресурс накапливается и участвует в итогах; реквизит лишь описывает движение. Денежная сумма — ресурс, комментарий или источник — реквизит.

Практический пример. Количество и Сумма — ресурсы, которые суммируются в итогах; КомментарийИмпорта — реквизит отдельного движения.

Комментарий интервьюера. попросите предсказать, появится ли реквизит в виртуальной таблице остатков и почему.

Каждое измерение расширяет ключ и число комбинаций итогов, увеличивая объём и стоимость записи. Универсальный регистр с десятками разрезов часто хуже нескольких предметных.

Практический пример. добавление измерений Поставщик, Проект, Менеджер создаёт множество комбинаций итогов даже там, где отчёту достаточно аналитического реквизита движения.

Комментарий интервьюера. попросите кандидата оценить не только размер основной таблицы, но и рост ключей и итоговых строк.

Разделение итогов хранит несколько частей одной логической итоговой строки, уменьшая конфликт записей. Чтение должно их суммировать, поэтому компромисс проверяют нагрузкой.

Практический пример. десять касс одновременно увеличивают одну итоговую строку; разделение итогов распределяет запись, а отчёт складывает части при чтении.

Комментарий интервьюера. правильный ответ должен назвать обратную сторону — дополнительную работу чтения и необходимость нагрузочного сравнения.

Агрегаты — дополнительные предварительно рассчитанные структуры для ускорения аналитики по выбранным разрезам больших регистров. Их состав и обслуживание требуют отдельной настройки и измерения.

Практический пример. для многолетних продаж агрегат по месяцу, организации и товарной группе ускоряет типовой отчёт, не сохраняя все детальные измерения.

Комментарий интервьюера. уточните, кто и как выбирает полезный состав агрегатов; случайный набор может занять место без ускорения запросов.

Использовать ОстаткиИОбороты(&Начало,&Конец,...) и выбрать начальный остаток, приход, расход и конечный остаток по ресурсам. Условия по измерениям передать внутрь виртуальной таблицы.

Практический пример. ОстаткиИОбороты за март показывает 10 на начало, приход 5, расход 3 и 12 на конец по одному складу.

Комментарий интервьюера. попросите кандидата объяснить границы периода и включение движений на начальную/конечную дату.

Отбор по регистратору позволяет связать обороты с документом. ОборотыДтКт бухгалтерского регистра выдаёт корреспондирующие дебетовые и кредитовые разрезы при поддержке корреспонденции.

Практический пример. ОборотыДтКт показывает пары Дт 41 — Кт 60 по поступлениям, сохраняя аналитику обеих сторон проводки.

Комментарий интервьюера. проверьте, включена ли поддержка корреспонденции; без неё ожидаемая виртуальная таблица и смысл отличаются.

Найти первичные ошибочные документы, исправить их штатно, перепровести зависимый период и пересчитать итоги. В закрытом периоде применяют разрешённый корректирующий документ, а не SQL-правку.

Практический пример. отрицательный остаток появился из-за реализации раньше поступления; исправляют даты/документы, перепроводят период и сверяют остатки, а не обновляют итог SQL-командой.

Комментарий интервьюера. кандидат должен назвать контроль закрытого периода и влияние корректировки на себестоимость следующих списаний.

Измерениями делают разрезы, по которым реально нужны остатки и блокировки: склад, номенклатура, характеристика, серия, назначение. Не каждый аналитический атрибут должен попадать в один регистр.

Практический пример. склад и товар обязательны для остатка, серия включается только при серийном учёте, менеджер остаётся реквизитом или отдельной аналитикой.

Комментарий интервьюера. спросите, какие реальные запросы требуют каждого измерения и сколько комбинаций оно создаёт.

Строка увеличивает ширину ключа и индекса, сравнение и хранение; длинные строки могут не помещаться в эффективный индекс. Лучше ссылочное нормализованное измерение, если это сущность.

Практический пример. строковый склад длиной 150 символов заменяют ссылкой на справочник складов, уменьшая ключ и исключая варианты написания.

Комментарий интервьюера. кандидат должен учитывать не только индекс, но и качество НСИ и ссылочную идентичность сущности.

Когда разрезы, жизненные циклы, частота записи и запросы существенно различаются. Разделение уменьшает ширину итогов и связанность, но добавляет согласование между регистрами.

Практический пример. складские остатки и денежные лимиты разделяют на два регистра: у них разные измерения, частота записи и правила контроля.

Комментарий интервьюера. попросите описать атомарность операции, которая должна согласованно изменить оба специализированных регистра.

Создать документ на известных данных, провести, запросом получить движения только его регистратора и сравнить ключи/ресурсы с эталоном. Затем проверить повторное проведение и отмену.

Практический пример. после проведения тест выбирает движения только по регистратору, сравнивает склад, товар и количество, затем повторяет проведение и проверяет отсутствие дублей.

Комментарий интервьюера. проверка общей суммы недостаточна — две ошибочные строки могут взаимно компенсироваться.

Регистр бухгалтерии встроенно связан с планом счетов, субконто и бухгалтерскими итогами; накопительный хранит произвольные ресурсы по измерениям. Бухгалтерский выбирают, когда нужна именно семантика счетов.

Практический пример. остаток товара можно хранить в РН, но учёт по счетам 41, 60 и субконто с двойной записью естественно требует регистра бухгалтерии.

Комментарий интервьюера. кандидат должен обосновать встроенную бухгалтерскую семантику, а не утверждать, что один регистр всегда быстрее другого.

План счетов определяет допустимые счета, их признаки и виды субконто; регистр хранит проводки по этим счетам и рассчитывает итоги. Один план может быть основой соответствующего бухгалтерского учёта.

Практический пример. план счетов задаёт счёт 41 и виды субконто, а регистр хранит проводки поступлений с конкретной номенклатурой и складом.

Комментарий интервьюера. уточните, что изменится в физической и прикладной модели при добавлении нового вида субконто.

Субконто — аналитический разрез счёта, например контрагент или договор. Виды субконто задаются через план видов характеристик и подключаются к счетам.

Практический пример. на счёте 60 субконто Контрагент и Договор позволяют получить долг не только по счёту, но и по аналитическим объектам.

Комментарий интервьюера. попросите различить вид субконто как описание и конкретное значение субконто в движении.

Активный счёт обычно имеет дебетовое сальдо и отражает активы; пассивный — кредитовое и источники; активно-пассивный допускает оба. Конкретное толкование зависит от плана счетов.

Практический пример. касса 50 — дебетовое сальдо активного счёта, кредит 100 по займу — сальдо пассивного; расчёты могут иметь обе стороны.

Комментарий интервьюера. не требуйте бухгалтерских тонкостей конкретного плана, если вакансия проверяет платформенный механизм.

Дебет и кредит — стороны бухгалтерской записи; оборот — сумма движений за период; сальдо — остаток на границу. Экономический смысл стороны зависит от типа счёта.

Практический пример. проводка Дт 10 Кт 60 увеличивает материалы и кредиторскую задолженность; обороты за месяц изменяют начальное сальдо в конечное.

Комментарий интервьюера. попросите кандидата проговорить смысл сторон для активного и пассивного счёта, а не дать формальное определение.

Забалансовый счёт учитывает объекты, не включаемые в баланс в обычном порядке, и может не требовать двойной корреспонденции. Правила задаются планом счетов и учётной политикой.

Практический пример. имущество, принятое на ответственное хранение, учитывается на забалансовом счёте без обычного включения в баланс организации.

Комментарий интервьюера. точные правила зависят от учётной политики; кандидат должен обозначить границу своей компетенции.

Поддержка корреспонденции хранит в одной записи связь счёта дебета и счёта кредита. Это позволяет получать ОборотыДтКт и контролировать двойную запись.

Практический пример. одна запись регистра связывает дебет товарного счёта и кредит расчётов с поставщиком, благодаря чему анализируется корреспонденция.

Комментарий интервьюера. спросите, как выглядел бы учёт без поддержки корреспонденции и какие запросы стали бы сложнее.

Есть таблица движений и несколько итоговых таблиц по счетам, субконто и корреспонденциям в зависимости от настроек. Точный физический состав смотрят по метаданным и документации версии.

Практический пример. кроме движений поддерживаются итоги по счетам и аналитике, а при корреспонденции — структуры для пар дебет/кредит.

Комментарий интервьюера. кандидат вправе не помнить имена физических таблиц, но обязан различать первичные движения и восстанавливаемые итоги.

Когда управленческая модель действительно использует счета, двойную запись и изменяемую аналитику субконто. Если нужны лишь остатки ресурсов, регистр накопления проще и обычно эффективнее.

Практический пример. управленческий план счетов для холдинга оправдан при двойной записи и гибких субконто; простой бюджет лимитов лучше хранить в РН.

Комментарий интервьюера. попросите сравнить стоимость универсальности субконто и более узкой схемы накопительного регистра.

План видов расчёта описывает взаимозависимые виды начислений, план видов характеристик — расширяемые виды свойств и типы значений. Их механизмы и назначение различны.

Практический пример. ПВР описывает Оклад, Отпуск, Премию и их зависимости, тогда как ПВХ описывает типы дополнительных свойств товара.

Комментарий интервьюера. сходство названий «план видов» не должно скрывать совершенно разные механизмы использования.

Регистр расчёта хранит записи сложных периодических расчётов и их результаты, поддерживая зависимость, вытеснение и перерасчёты. Типичный пример — начисления зарплаты.

Практический пример. оклад, отпуск и больничный записываются в регистр расчёта, где периоды и вытеснение определяют оплачиваемые интервалы.

Комментарий интервьюера. спросите, почему обычная таблица результатов не даёт встроенной регистрации перерасчётов.

Период регистрации показывает, когда расчёт зарегистрирован; период действия — за какой интервал он назначен; фактический период — часть действия после вытеснения. Эти интервалы нельзя смешивать в запросах.

Практический пример. начисление зарегистрировано в апреле за март, действует 1–31 марта, а отпуск 10–15 марта сокращает фактический период оклада.

Комментарий интервьюера. кандидат должен уверенно разделять три даты, иначе запросы прошлых перерасчётов будут неверны.

Вытесняющий расчёт исключает интервалы другого вида; базовый предоставляет данные для расчёта; ведущий вызывает необходимость пересчитать зависимые записи при изменении. Конкретные связи задаются планом видов расчёта.

Практический пример. отпуск вытесняет оклад, оклад входит в базу премии, а изменение оклада ведёт к перерасчёту премии.

Комментарий интервьюера. попросите назвать направление каждой зависимости; механическое перечисление терминов легко скрывает путаницу.

Перерасчёт регистрирует, какие ранее рассчитанные записи потеряли актуальность после изменения ведущих данных. Он указывает необходимость пересчитать, но сам не выполняет бизнес-расчёт.

Практический пример. после изменения оклада за январь появляется запись перерасчёта февральской премии, но сумма изменится только после выполнения расчёта.

Комментарий интервьюера. важно услышать, что перерасчёт регистрирует необходимость, а не автоматически исправляет начисление.

Изменить ведущую запись прошлого периода, зарегистрировать зависимость и убедиться, что появилась запись перерасчёта; после расчёта сравнить новую базу и результат. Тест должен охватывать частичное вытеснение периода.

Практический пример. тест меняет базовое начисление, проверяет регистрацию зависимой записи, запускает перерасчёт и сравнивает новую сумму с формулой.

Комментарий интервьюера. добавьте случай частичного пересечения периодов, иначе вытеснение останется непроверенным.

Транзакция объединяет изменения в атомарную операцию: либо фиксируются все, либо откатываются все. Она также задаёт границу удержания транзакционных блокировок.

Практический пример. создание заказа и его строк фиксируется вместе; исключение при записи строки откатывает и шапку, не оставляя полудокумент.

Комментарий интервьюера. кандидат должен связать атомарность с конкретным бизнес-инвариантом, а не повторить ACID без применения.

Полноценных независимых вложенных транзакций нет. Повторный НачатьТранзакцию увеличивает внутреннюю вложенность, но отмена во вложенном коде влияет на всю внешнюю операцию.

Практический пример. внешний метод начал транзакцию, внутренний снова вызвал НачатьТранзакцию; внутренняя фиксация не публикует изменения до завершения внешней.

Комментарий интервьюера. уточните, кто владеет границей транзакции и почему библиотечный метод не должен самовольно отменять чужую операцию.

Вложенная фиксация не делает изменения окончательно видимыми до завершения внешней транзакции. Отмена помечает общую транзакцию отменённой; внешнему коду нельзя продолжать как после успеха.

Практический пример. внутренний код отменил транзакцию и вернул управление; попытка внешней фиксации уже не превращает операцию в успешную.

Комментарий интервьюера. попросите кандидата объяснить поведение исключения и состояние данных после отмены, а не только счётчик вложенности.

Пример: НачатьТранзакцию(); Попытка ... ЗафиксироватьТранзакцию(); Исключение Если ТранзакцияАктивна() Тогда ОтменитьТранзакцию(); КонецЕсли; ВызватьИсключение; КонецПопытки;. Сетевые вызовы внутрь не помещают без крайней необходимости.

Практический пример. НачатьТранзакцию(); Попытка Записать(); ЗафиксироватьТранзакцию(); Исключение ОтменитьТранзакцию(); ВызватьИсключение; КонецПопытки;.

Комментарий интервьюера. проверьте условие активности перед отменой и отсутствие поглощения исходного исключения.

Сеанс остаётся с активной/некорректной транзакционной границей и последующие операции могут завершиться ошибкой или удерживать блокировки. В обработчике нужно отменить транзакцию и передать ошибку выше.

Практический пример. ошибка уникальности перехвачена без отмены, после чего сеанс пытается выполнить следующий запрос и продолжает удерживать транзакционные ресурсы.

Комментарий интервьюера. сильный ответ считает транзакцию после ошибки непригодной и восстанавливает состояние до продолжения.

Запись объектов и проведение выполняются платформой транзакционно; конкретная операция может открыть неявную транзакцию. Явную транзакцию используют, когда несколько операций должны быть атомарны вместе.

Практический пример. Объект.Записать() открывает платформенную транзакцию записи, а явная транзакция объединяет запись заказа и служебной очереди в один атомарный шаг.

Комментарий интервьюера. попросите не окружать каждую одиночную запись явной транзакцией без сформулированной причины.

Не делать одну транзакцию на 100 000 документов. Выбрать бизнес-атомарную порцию, сохранять курсор, фиксировать после порции и обеспечивать безопасный повтор.

Практический пример. загрузка фиксирует каждые 500 документов и хранит последний внешний ключ; повтор после сбоя начинает с неподтверждённой порции.

Комментарий интервьюера. граница порции должна учитывать не только скорость, но и требуемую атомарность связанных документов.

HTTP задерживает фиксацию и удерживает блокировки, а удалённая система всё равно не участвует в локальном коммите. При тайм-ауте результат внешней операции может остаться неизвестным.

Практический пример. сервис оплаты ответил через 40 секунд, а всё это время транзакция заказа держала блокировку остатков; при тайм-ауте платёж уже мог пройти.

Комментарий интервьюера. кандидат должен предложить состояние операции и повтор по тому же ключу, а не просто увеличить тайм-аут.

Применить локальный outbox: в одной транзакции записать бизнес-изменение и сообщение, после коммита отправлять его фоново. Получатель обрабатывает повтор по уникальному ключу идемпотентности.

Практический пример. заказ и исходящее сообщение записываются вместе, затем отправитель доставляет сообщение и отмечает подтверждение отдельной транзакцией.

Комментарий интервьюера. спросите о сбое между фактической отправкой и отметкой успеха — именно он требует дедупликации получателя.

Идемпотентная операция при повторе с тем же ключом возвращает тот же результат и не создаёт второй эффект. Это позволяет безопасно повторять после временных сетевых ошибок.

Практический пример. два запроса создания с ключом abc-123 возвращают одну ссылку заказа; уникальный индекс защищает от одновременного первого запроса.

Комментарий интервьюера. кандидат должен различать идемпотентность чтения и идемпотентность команды с побочным эффектом.

Уровень изоляции определяет видимость параллельных изменений. Основные аномалии: грязное чтение, неповторяемое чтение и фантомы; реализация зависит от СУБД и режима блокировок 1С.

Практический пример. повторный SELECT в одной транзакции увидел изменённую другим сеансом цену — неповторяемое чтение; новая подходящая строка создаёт фантом.

Комментарий интервьюера. попросите связать аномалию с бизнес-риском и выбранной блокировкой, а не только назвать уровни ANSI.

В автоматическом режиме согласованность обеспечивается блокировками/изоляцией СУБД по правилам платформы. В управляемом режиме разработчик явно защищает бизнес-чтение через менеджер блокировок 1С.

Практический пример. автоматический режим полагается на выбранную платформой изоляцию СУБД, управляемый — на явную блокировку остатка по складу и товару перед чтением.

Комментарий интервьюера. ответ должен учитывать фактический режим конфигурации; код управляемой блокировки вне него нельзя оценивать абстрактно.

При начале транзакционной операции платформа открывает транзакцию соединения СУБД и транслирует запросы/фиксацию. Детали изоляции различаются по СУБД и режиму управления блокировками.

Практический пример. начало транзакции 1С закрепляет соединение СУБД, запросы выполняются в нём, а ЗафиксироватьТранзакцию отправляет коммит.

Комментарий интервьюера. точные уровни изоляции различаются по СУБД и режиму, поэтому категоричный единый ответ должен насторожить.

После серьёзной ошибки СУБД транзакцию следует считать непригодной и отменить. Продолжение допустимо только после восстановления согласованного состояния в новой транзакции.

Практический пример. после deadlock СУБД откатила транзакцию-жертву; код начинает новую попытку целиком, а не продолжает со следующей строки.

Комментарий интервьюера. спросите, какие внешние эффекты могли уже произойти и делают автоматический повтор небезопасным.

Создать операцию с несколькими записями, искусственно вызвать исключение между ними и проверить отсутствие всех изменений. Отдельно проверить ошибку фиксации и повтор операции.

Практический пример. тест записывает документ, затем намеренно нарушает уникальность при записи служебной строки; после исключения ни документа, ни первой строки нет.

Комментарий интервьюера. проверяйте состояние через новый контекст чтения после отката, а не через оставшийся объект в памяти.

Блокировка временно ограничивает конкурентный доступ к области данных. В 1С нужно различать управляемые блокировки платформы, блокировки СУБД и объектную блокировку редактирования.

Практический пример. управляемая блокировка защищает остаток по товару, SQL-блокировка удерживает физический ключ индекса, объектная блокировка предупреждает редактора формы.

Комментарий интервьюера. кандидат должен назвать назначение каждого слоя и не обещать, что объектная блокировка защитит фоновую запись.

Сильный пример: контроль остатка, уникального номера или конкурентная обработка очереди. Назовите пространство, поля, режим, границу транзакции и результат нагрузочного теста.

Практический пример. при выдаче следующего номера блокируется строка нумератора по организации, номер читается и увеличивается в одной короткой транзакции.

Комментарий интервьюера. попросите назвать слишком широкую альтернативу и измеримый эффект сужения области.

Разделяемые блокировки совместимы с другими разделяемыми, но конфликтуют с исключительной. Исключительная применяется для защищаемого изменения и обычно несовместима с конкурентным доступом той же области.

Практический пример. два отчёта могут держать совместимые разделяемые блокировки, но документ с исключительной блокировкой изменения ждёт их освобождения.

Комментарий интервьюера. совместимость оценивается для одной области пространства; разные ключи не обязаны конфликтовать.

Объектная блокировка предупреждает одновременное интерактивное редактирование. Транзакционная защищает целостность данных при чтении/записи независимо от интерфейса.

Практический пример. пользователь A открыл заказ на редактирование, но интеграция всё равно может записать его без транзакционной проверки; объектная блокировка не решает гонку.

Комментарий интервьюера. вопрос выявляет опасное смешение UX-предупреждения и гарантии целостности данных.

Менеджер блокировок 1С работает в пространствах прикладных данных и координирует управляемые транзакции. СУБД блокирует физические ключи/страницы/таблицы согласно своему плану.

Практический пример. 1С блокирует логическую область Склад=1, Товар=Х, а MS SQL вследствие плана удерживает ключи конкретного индекса.

Комментарий интервьюера. попросите объяснить, почему узкая логическая блокировка не отменяет необходимость хорошего SQL-плана.

Создать БлокировкаДанных, добавить элемент нужного пространства, указать исключительный/разделяемый режим, задать поля и значения, затем вызвать Заблокировать() внутри транзакции. Имена пространства сверяют в документации метаданных.

Практический пример. Пример кода задаёт пространство регистра, исключительный режим, значения склада и товара и вызывает Заблокировать() только после начала транзакции.

Комментарий интервьюера. проверьте, совпадают ли имена полей блокировки с измерениями и установлен ли одинаковый порядок для нескольких ключей.

Блокировка станет широкой: вместо одного склада/товара может закрыть весь регистр или большой диапазон. Это снижает параллельность и повышает риск ожиданий.

Практический пример. забытое значение Склад превратило контроль одного товара на одном складе в блокировку товара по всем складам.

Комментарий интервьюера. попросите оценить число ожидающих сеансов и показать событие ТЖ, подтверждающее широкую область.

В транзакции взять исключительную блокировку по товару и складу, затем прочитать остаток, проверить 7 ≤ остаток и записать движение. Второй сеанс дождётся фиксации и увидит уже уменьшенный остаток.

Практический пример. первый сеанс блокирует ключ, видит 10 и списывает 7; второй ждёт, затем видит 3 и отклоняет списание.

Комментарий интервьюера. чтение остатка до блокировки — критическая ошибка даже при правильной последующей записи.

Взаимоблокировка — цикл ожидания: каждая транзакция держит ресурс, нужный другой. Система выбирает жертву и отменяет одну транзакцию.

Практический пример. A ждёт ресурс B, удерживая A; B ждёт A, удерживая B; СУБД отменяет одну транзакцию для разрыва цикла.

Комментарий интервьюера. кандидат должен отличить deadlock от обычного долгого ожидания одной блокировки.

A блокирует склад 1, затем ждёт склад 2; B блокирует склад 2, затем ждёт склад 1. Исправление — всегда сортировать склады и блокировать в одинаковом порядке.

Практический пример. документы блокируют склады в порядке строк документа; строки [1,2] и [2,1] создают цикл, сортировка ключей его устраняет.

Комментарий интервьюера. попросите учесть разные участки кода — единый порядок должен соблюдаться всеми конкурирующими алгоритмами.

Единый порядок исключает цикл: транзакции могут ждать, но не захватывают ресурсы навстречу друг другу. Ключи перед блокировкой сортируют детерминированно.

Практический пример. все операции сначала блокируют организацию, затем склад, затем товары по возрастанию ссылки; ожидание остаётся, но цикл не формируется.

Комментарий интервьюера. сильный ответ не обещает полного отсутствия ожиданий, только снижение вероятности взаимоблокировки.

Без индекса СУБД читает и удерживает больше ключей/страниц, а запрос длится дольше. Поэтому логически узкое условие может физически создать широкое ожидание.

Практический пример. условие по неиндексированному внешнему коду просматривает миллионы строк и удерживает их дольше, хотя бизнес-ключ единственный.

Комментарий интервьюера. попросите подтвердить связь фактическим планом и количеством прочитанных ключей.

Эскалация — замена множества мелких блокировок более крупной, например табличной, по правилам СУБД. Она экономит память менеджера, но снижает параллельность.

Практический пример. массовое обновление накопило тысячи блокировок строк, и MS SQL заменил их блокировкой таблицы, остановив параллельные документы.

Комментарий интервьюера. точные пороги зависят от СУБД; кандидат должен предложить порции и индекс, а не магическое число строк.

По времени и идентификаторам сеанса найти события ожидания в ТЖ, соответствующие запросы и транзакции, затем сопоставить с журналом блокировок СУБД. Ищут владельца, ожидающего и длительность.

Практический пример. пользователь сообщает время 14:32; по ТЖ находят 18-секундное ожидание, владельца-сеанс и его тяжёлый запрос без отбора.

Комментарий интервьюера. завершение сеанса без выяснения запроса лишь снимет симптом и может откатить важную операцию.

Нужны события запросов СУБД, транзакций, блокировок, исключений и серверных вызовов; точные имена событий зависят от версии. Фильтр должен быть узким по времени/сеансам.

Практический пример. фильтр ТЖ на период инцидента собирает DBMSSQL/DBPOSTGRS, TLOCK, TRANSACTION и EXCP для конкретных процессов — набор уточняется по версии.

Комментарий интервьюера. кандидат должен ограничивать трассу, иначе диагностический журнал сам создаст чрезмерный объём.

Два фоновых/тестовых сеанса синхронизируют точки: первый берёт ресурс A, второй B, затем оба запрашивают второй ресурс. Тест обязан иметь тайм-аут и работать только в изолированной базе.

Практический пример. два тестовых клиента доходят до барьера, захватывают разные ключи и одновременно продолжают ко второму ключу, воспроизводя цикл детерминированно.

Комментарий интервьюера. Пауза(1) без барьера даёт flaky-тест и не является надёжным доказательством исправления.

Если операция идемпотентна и транзакция полностью откатилась, её можно повторить ограниченное число раз с задержкой. Нельзя повторять внешний неидемпотентный эффект вслепую.

Практический пример. проведение без внешних эффектов после deadlock повторяется максимум три раза с jitter; повторная оплата без ключа идемпотентности запрещена.

Комментарий интервьюера. попросите назвать критерий временной ошибки и предел, после которого событие уйдёт в карантин.

Длинная транзакция дольше удерживает даже узкие блокировки и увеличивает окно конфликта. Поэтому сначала сокращают время и выносят сеть/вычисления, затем уточняют область.

Практический пример. транзакция блокирует одну итоговую строку, но 60 секунд ждёт HTTP; сотни пользователей выстраиваются за единственным узким ключом.

Комментарий интервьюера. первый вопрос оптимизации — что можно вычислить и вызвать до начала либо после фиксации.

Собрать уникальные пары склад–товар, отсортировать по стабильному ключу и блокировать в этом порядке. Все конкурирующие алгоритмы обязаны использовать тот же порядок.

Практический пример. пары (Склад,Товар) дедуплицируют и сортируют по ссылкам перед последовательным захватом, независимо от порядка строк документа.

Комментарий интервьюера. строковое представление ссылки не всегда подходящий стабильный порядок — используйте сравнимый ключ платформы осознанно.

ДЛЯ ИЗМЕНЕНИЯ выражает намерение блокирующего чтения в запросе; БлокировкаДанных явно задаёт пространство и значения. Последний даёт более управляемую прикладную гранулярность.

Практический пример. ДЛЯ ИЗМЕНЕНИЯ блокирует строки, выбранные запросом, а БлокировкаДанных явно описывает пространство и конкретные значения измерений.

Комментарий интервьюера. не принимайте универсальный выбор одного варианта; он зависит от режима, запроса и необходимой гранулярности.

Один объект метаданных обычно отображается в несколько физических таблиц: основную, табличные части, движения, итоги и регистрацию изменений. Схемой управляет платформа.

Практический пример. справочник создаёт основную таблицу и таблицы табличных частей, документ дополнительно связан с регистрами движений, а РН — с таблицами итогов.

Комментарий интервьюера. кандидат должен говорить о логическом соответствии, не обещая стабильные внутренние имена физических таблиц между версиями.

Справочник имеет основную таблицу реквизитов и отдельные таблицы табличных частей, связанные ссылкой владельца/строкой. Есть системные поля ссылки, кода, наименования и иерархии согласно свойствам.

Практический пример. элемент номенклатуры хранится в основной таблице, его штрихкоды — в отдельной табличной части со ссылкой владельца и номером строки.

Комментарий интервьюера. спросите, как чтение табличной части через объект отличается от соединения её таблицы в запросе.

Документ хранит шапку и табличные части; движения находятся в таблицах регистров с регистратором. Проведение не создаёт одну универсальную «таблицу проводок» для всех регистров.

Практический пример. шапка реализации и товары находятся в таблицах документа, а расходы склада и взаиморасчётов — в разных регистрах с тем же регистратором.

Комментарий интервьюера. кандидат не должен искать универсальную физическую таблицу «всех движений документа».

РС имеет основную таблицу записей; ключ и индексы зависят от периодичности, измерений и регистратора. Периодический регистр поддерживает логические виртуальные срезы, а не отдельную таблицу каждого среза.

Практический пример. периодический регистр цен имеет основную таблицу записей; СрезПоследних вычисляется виртуальным механизмом запроса, а не хранится отдельной таблицей среза.

Комментарий интервьюера. уточните ключ и индексы для конкретной периодичности и режима записи.

РН имеет таблицу движений и таблицы итогов; могут быть таблицы опций/агрегатов. Движения первичны, итоги восстанавливаемы.

Практический пример. таблица движений товаров содержит приход и расход, итоговая таблица — агрегат по периоду, складу и товару, а служебные таблицы поддерживают настройки итогов.

Комментарий интервьюера. попросите назвать первичный источник и последствия прямой SQL-правки производной таблицы.

Суффиксы физических таблиц — внутреннее представление платформы и меняются по типу объекта. Использовать их допустимо для диагностики чтения, но не для прямой прикладной записи.

Практический пример. администратор видит _AccumRg... в плане и использует имя для диагностики конкретной базы, но прикладной код обращается к РегистрНакопления.Товары.

Комментарий интервьюера. внутреннее имя допустимо в расследовании, но не является поддерживаемым контрактом разработки.

Индекс — упорядоченная вспомогательная структура для поиска и соединения. Он ускоряет подходящие чтения ценой места и дополнительной работы при записи.

Практический пример. индекс по внешнему коду находит одну запись среди миллионов, но при каждой загрузке СУБД должна обновлять эту дополнительную структуру.

Комментарий интервьюера. хороший ответ одновременно называет выигрыш чтения и цену записи/места.

Кластерный индекс определяет основную физическую организацию строк в терминах конкретной СУБД; некластерный хранит отдельный ключ и указатель. PostgreSQL и MS SQL реализуют детали по-разному.

Практический пример. в MS SQL кластерный индекс определяет организацию строк таблицы, некластерный содержит отдельный ключ; в PostgreSQL терминология и физика отличаются.

Комментарий интервьюера. не принимайте описание одной СУБД как универсальное объяснение всех поддерживаемых платформой баз.

Платформа создаёт индексы для системных ключей, ссылок, регистраторов и отмеченных индексируемыми полей. Полный состав определяется объектом, свойствами, разделителями и версией.

Практический пример. для регистра платформа создаёт ключ периода/регистратора и дополнительные индексы отмеченных измерений; точный порядок берут из методической таблицы версии.

Комментарий интервьюера. кандидат должен уметь проверить состав, а не воспроизводить устаревший список по памяти.

Обычное индексирование создаёт ключ по полю; дополнительное упорядочивание добавляет поля, позволяющие эффективнее читать в типовом порядке. Точный состав индекса сверяют по официальной таблице платформы.

Практический пример. дополнительное упорядочивание расширяет индекс полями типового порядка чтения, позволяя получить строки без отдельной сортировки в подходящем запросе.

Комментарий интервьюера. попросите показать фактический индекс и план; название свойства без этого не доказывает эффект.

Индекс (A,B,C) эффективно поддерживает поиск, начинающийся с A, затем B. Условие только по C обычно не использует его как прямой поиск.

Практический пример. индекс (Организация, Контрагент, Дата) поддерживает поиск по организации и контрагенту, но запрос только по дате пропускает левую часть ключа.

Комментарий интервьюера. уточните диапазон после первых равенств — поля справа от диапазона обычно хуже сужают чтение.

Обычно сначала поля точного равенства, затем диапазон; после диапазона следующие поля хуже сужают поиск. Сортировка, покрытие и селективность могут изменить выбор — решает план.

Практический пример. (Организация =, Склад =, Дата между) ставит два равенства перед диапазоном; требуемая сортировка по дате совпадает с хвостом ключа.

Комментарий интервьюера. правило порядка нужно проверить селективностью и планом, особенно если одно поле почти всегда имеет одно значение.

При низкой селективности, функции над полем, несоответствии левого префикса, устаревшей статистике или слишком широком диапазоне. Оптимизатор может предпочесть последовательное чтение.

Практический пример. индекс по булевому Проведён невыгоден, когда 99,9% документов проведены; оптимизатор выбирает сканирование.

Комментарий интервьюера. кандидат должен назвать распределение данных и фактическую долю, а не объявить все низкоселективные индексы бесполезными.

Не индексируют без причины поля с малой селективностью, часто изменяемые длинные строки и поля, не участвующие в запросах. Каждый индекс увеличивает запись и объём БД.

Практический пример. длинный комментарий, меняющийся при каждой записи и не участвующий в поиске, не индексируют; внешний уникальный код, по которому приходит интеграция, индексируют.

Комментарий интервьюера. попросите связать каждый индекс с конкретным запросом и частотой записи.

Если условие выбирает значительную часть таблицы, обход индекса с обращениями к данным может быть дороже сканирования. Порог зависит от СУБД и распределения.

Практический пример. условие Статус=Активен выбирает 80% таблицы, поэтому последовательное чтение дешевле миллионов переходов по индексу.

Комментарий интервьюера. селективность оценивается на реальном распределении, которое может различаться по организациям и периодам.

При вставке/изменении СУБД обновляет каждый индекс, возможны перестроения страниц и дополнительные блокировки. Лишний индекс ускоряет ни один важный запрос, но оплачивается всегда.

Практический пример. добавление пяти индексов ускорило редкий отчёт, но загрузка прайса выросла с 2 до 9 минут из-за обслуживания каждого ключа.

Комментарий интервьюера. решение должно учитывать суммарную стоимость всех важных операций, а не оптимизацию одного запроса.

Покрывающий индекс содержит все поля, нужные запросу, позволяя не обращаться к основной таблице. В 1С возможность его получить ограничена индексами, которые создаёт платформа и свойства метаданных.

Практический пример. индекс содержит Контрагент, Дата, Сумма, и отчёт читает эти поля без обращения к основной строке; это подтверждается планом.

Комментарий интервьюера. в конфигурации 1С возможности включённых колонок ограничены создаваемыми платформой индексами — кандидат должен это оговорить.

Фрагментация ухудшает локальность страниц; статистика описывает распределение значений для оптимизатора. Обслуживание выполняют штатными средствами СУБД по измеренной необходимости.

Практический пример. после массового удаления страницы индекса разрежены, а статистика всё ещё ожидает старое распределение; обслуживание меняет и IO, и выбор плана.

Комментарий интервьюера. ежедневное полное перестроение без порогов и метрик — такой же антишаблон, как полное отсутствие обслуживания.

RLS добавляет соединения и условия; если их поля не поддержаны индексами, исходный индекс запроса может стать бесполезен. Анализируют план под реальными правами пользователя.

Практический пример. запрос использовал индекс по организации, но RLS добавил соединение по подразделению без индекса, и основная стоимость переместилась туда.

Комментарий интервьюера. план нужно получать под ограниченным пользователем, а не только под администратором без RLS.

Платформа может удалить или изменить самодельный индекс при реструктуризации, а его поддержка не учитывается конфигуратором. Такие изменения допускают только как управляемое эксплуатационное решение с тестом и регламентом.

Практический пример. DBA создал индекс вручную, обновление конфигурации перестроило таблицу и удалило его; отчёт снова деградировал.

Комментарий интервьюера. если ручной индекс необходим, кандидат должен предложить реестр, автоматическую проверку и тест после реструктуризации.

Получить фактические планы и метрики каждой СУБД на одинаковом наборе. Названия операций и стоимость нельзя сравнивать напрямую; сравнивают строки, чтения, время и ожидания.

Практический пример. MS SQL использует Nested Loops и Key Lookup, PostgreSQL — Bitmap Scan и Hash Join; сравнивают фактические строки и чтения, а не условные стоимости.

Комментарий интервьюера. попросите назвать инструменты получения плана для каждой СУБД и влияние параметров.

В клиент-серверном варианте временные таблицы обслуживаются соединением к СУБД/сервером, в файловом — движком платформы. Их жизнь связана с менеджером временных таблиц.

Практический пример. временная таблица живёт в менеджере одного пакетного процесса и исчезает после его закрытия; другой серверный вызов не должен полагаться на неё.

Комментарий интервьюера. кандидат должен отличать логическое время жизни 1С от физического каталога temp конкретной СУБД.

Составная ссылка хранит тип и идентификатор в служебном представлении, что увеличивает ширину и усложняет соединения. Точную физическую раскладку платформа считает внутренней.

Практический пример. составной реквизит хранит признак типа и значение, поэтому индекс/строка шире, а разыменование должно учитывать несколько целевых таблиц.

Комментарий интервьюера. попросите объяснить компромисс гибкости составного типа и стоимости запросов.

Оба ссылочные, но ПВХ дополнительно хранит тип значения характеристики и служебные поля механизма. Это отражается в физической колонке типа и связанных таблицах.

Практический пример. ПВХ дополнительно хранит допустимый тип значения характеристики, чего нет у обычного справочника цветов.

Комментарий интервьюера. физическая колонка типа — следствие назначения механизма; не сводите отличие только к скрытому имени поля.

Широкая строка увеличивает страницы и ключи; составной тип добавляет поля типа/значения и потенциальные соединения. Это повышает IO и ограничивает полезную индексацию.

Практический пример. три строковых измерения по 200 символов раздувают каждую итоговую строку; замена сущностей ссылками уменьшает ключ и устраняет дубли написания.

Комментарий интервьюера. спросите о миграции существующих строк и индексах после нормализации.

Назовите измеримый масштаб и конкретный инцидент: пользователи, БД, операция, p95, инструменты и результат. «Высокая нагрузка» без цифр и методики ничего не доказывает.

Практический пример. «800 одновременных сеансов, БД 2,3 ТБ, 40 проведений/с; пики подтверждены мониторингом за закрытие месяца».

Комментарий интервьюера. слово «высоконагруженный» без периода измерения и характера операций не является доказательством опыта.

Сначала определить конкретную медленную операцию и период, затем разделить клиент, сеть, сервер 1С, СУБД и блокировки. Собирать минимальный ТЖ и метрики, искать доминирующую стоимость, проверять исправление тем же сценарием.

Практический пример. медленное открытие формы делят на 1,5 с клиента, 6 с серверного запроса и 12 с ожидания блокировки, после чего работают с доминирующей частью.

Комментарий интервьюера. кандидат должен сначала локализовать слой, а не сразу переписывать запрос по догадке.

Клиентский замер показывает обработчики и ожидание; сетевые метрики — RTT; ТЖ — серверные вызовы и запросы; СУБД — CPU, IO, waits и планы. Времена коррелируют по идентификаторам и часам.

Практический пример. RTT сети 20 мс, но форма делает 300 вызовов и теряет 6 секунд; серверные запросы по отдельности быстрые.

Комментарий интервьюера. попросите показать, каким измерением доказано число переходов и почему ускорение СУБД не решит проблему.

Замер производительности считает время и вызовы строк/процедур встроенного языка. Он помогает найти горячий код, но не заменяет план СУБД и анализ ожиданий.

Практический пример. замер показывает, что 70% времени встроенного языка уходит на поиск строки таблицы в двойном цикле; заменяют соответствием.

Комментарий интервьюера. если основное время внутри СУБД, построчный замер языка не заменяет план запроса.

Журнал регистрации — аудит прикладных и административных событий. Технологический журнал — детальная диагностическая трасса процессов, запросов, блокировок и исключений.

Практический пример. журнал регистрации подтверждает изменение объекта пользователем, а ТЖ показывает SQL и ожидание, из-за которого запись заняла 25 секунд.

Комментарий интервьюера. кандидат должен выбрать журнал по вопросу расследования и учитывать чувствительность диагностических данных.

Для запросов — события СУБД и длительность, для блокировок — ожидания/транзакции, для вызовов — серверные вызовы и контекст. Имена событий сверяют по версии платформы.

Практический пример. для одного медленного вызова собирают серверный CALL, запрос СУБД, событие транзакции и TLOCK, связывая их по процессу и времени.

Комментарий интервьюера. попросите ограничить фильтр конкретным контекстом, чтобы сбор не превратился в бесконтрольный дамп всей системы.

ЦУП собирает показатели операций и помогает сравнивать производительность; APDEX классифицирует время относительно целевого порога. Порог должен быть бизнес-обоснованным.

Практический пример. операция имеет целевой порог 2 с; 80% быстрее 2 с, 15% — до 8 с, 5% хуже, из чего рассчитывается APDEX по выбранной методике.

Комментарий интервьюера. пороги должны отражать ожидания пользователя, а не подбираться после измерения ради красивого индекса.

Агрегировать запросы по нормализованному тексту/контексту и считать сумму времени, число вызовов и строки. Частый запрос по 100 мс может стоить больше редкого по 10 секунд.

Практический пример. запрос по 80 мс выполняется миллион раз и потребляет 22 часа суммарно, тогда как единичный запрос 30 с менее значим.

Комментарий интервьюера. попросите ранжировать по суммарной стоимости, частоте и критичности пользовательской операции.

Среднее сглаживает редкие тяжёлые случаи. p95/p99 показывают время, хуже которого лишь 5%/1% операций, и лучше отражают пользовательский хвост.

Практический пример. девять операций занимают 1 с, одна — 30 с; среднее 3,9 с скрывает, что каждый десятый пользователь ждёт полминуты.

Комментарий интервьюера. кандидат должен назвать перцентили и объём выборки, а не использовать одно среднее.

Обычно p50 для типичного поведения, p95 для SLA и p99 для хвоста; выбор зависит от критичности и объёма. Нужно также указывать окно и число операций.

Практический пример. p50 показывает типичный заказ, p95 входит в SLA, p99 выявляет редкие блокировки; метрики считаются отдельно для пикового часа.

Комментарий интервьюера. уточните период агрегации и число операций — p99 из десяти наблюдений статистически бессмысленен.

Сформировать реалистичные документы и несколько параллельных пользователей, прогреть систему, измерить throughput, p95, CPU/IO и блокировки. Проверить корректность движений после нагрузки.

Практический пример. 50 виртуальных пользователей одновременно проводят документы на пересекающихся складах; измеряются p95, throughput, CPU, IO и ошибки остатков.

Комментарий интервьюера. нагрузочный тест без проверки бизнес-целостности может объявить быстрым алгоритм, который теряет движения.

Нагрузочный проверяет ожидаемый профиль, стрессовый ищет предел и деградацию, длительный выявляет утечки и накопление очередей. Это разные критерии успеха.

Практический пример. нагрузочный тест проверяет 100 пользователей, стрессовый увеличивает до отказа, длительный 24 часа ищет рост памяти и очередей.

Комментарий интервьюера. попросите отдельный критерий успеха и завершения для каждого вида испытания.

Копия/генератор должен воспроизводить объём, распределение ключей, историю и права, а не только число строк. Персональные данные обезличивают.

Практический пример. генератор создаёт не равномерные товары, а 5% популярных позиций с 70% движений, воспроизводя реальные горячие ключи.

Комментарий интервьюера. объём без распределения не создаёт production-планы и конкуренцию.

На пустой базе другие планы, помещаемость в кэш и почти нет конкуренции. Такой тест доказывает только функциональный запуск.

Практический пример. на тысяче строк таблица целиком в памяти и запрос летает; на 500 млн строк тот же текст меняет план и читает диски.

Комментарий интервьюера. тест пустой базы подходит для функциональности, но не доказывает масштабируемость.

N+1 — один запрос списка и отдельный запрос/серверный вызов для каждой строки. Исправление — пакетно получить зависимости и сопоставить по ключу.

Практический пример. список 100 заказов вызывает отдельное получение контрагента для каждого; один запрос с соединением устраняет 100 дополнительных обращений.

Комментарий интервьюера. N+1 бывает и на уровне HTTP/серверных вызовов, не только SQL.

Фоновые задания конкурируют за CPU, IO, соединения и блокировки. Их расписание, параллельность и требования назначения кластера согласуют с пользовательским пиком.

Практический пример. ночной пересчёт захватывает IO до 100% и продолжается утром, увеличивая p95 пользовательских запросов в пять раз.

Комментарий интервьюера. решение может включать расписание, ограничение параллельности и выделение процессов, но его нужно проверить нагрузкой.

Смотреть динамику памяти процесса, контексты вызовов, большие коллекции/двоичные данные и число сеансов. Разовый снимок не отличает кэш от утечки; нужен повторяемый рост.

Практический пример. память рабочего процесса растёт на 2 ГБ после каждой загрузки и не возвращается при одинаковом числе сеансов; исследуют удерживаемые большие коллекции.

Комментарий интервьюера. разовый высокий RSS может быть допустимым кэшем; важна воспроизводимая динамика и влияние на систему.

Разделять, когда разные виды нагрузки конфликтуют или требуют изоляции ресурсов. Назначения функциональности должны иметь резерв и не создавать единственную точку отказа.

Практический пример. тяжёлые фоновые расчёты получают отдельный рабочий процесс, а пользовательские вызовы — два резервных процесса на разных серверах.

Комментарий интервьюера. изоляция без резервирования способна превратить специализированный процесс в точку отказа.

Обрабатывать порциями, читать и записывать набором, ограничивать транзакции, хранить прогресс и разрешать повтор. Сначала испытать на копии объёма и ограничить скорость.

Практический пример. обработка читает 1000 объектов запросом, изменяет их набором, фиксирует курсор и делает паузу при превышении лимита нагрузки.

Комментарий интервьюера. кандидат должен объяснить повтор порции и поведение при частичной бизнес-ошибке.

p95/p99, throughput, CPU, IO, чтения, длительность блокировок, размер очереди и ошибки до/после. Одна цифра времени без нагрузки недостаточна.

Практический пример. после оптимизации p95 упал с 8 до 2 с, throughput вырос с 20 до 65 операций/с, CPU не изменился, чтения сократились в 15 раз.

Комментарий интервьюера. одна положительная метрика может скрывать перенос нагрузки на другой ресурс или ухудшение хвоста.

RLS — ограничение доступа на уровне записей по условию данных. Оно дополняет права роли и применяется ко всем способам чтения, а не только форме.

Практический пример. роль разрешает читать документы, а RLS оставляет только строки организаций из групп доступа пользователя.

Комментарий интервьюера. спросите, как тот же запрет действует при прямой ссылке и в фоновом задании.

Роль разрешает операцию над объектом/полем в целом; RLS ограничивает конкретные строки. Пользователю могут разрешить чтение справочника, но только своей организации.

Практический пример. право Чтение открывает справочник контрагентов в целом, условие RLS ограничивает контрагентов конкретного региона.

Комментарий интервьюера. кандидат должен разделять метаданные роли и данные, по которым вычисляется разрешённая область.

РАЗРЕШЕННЫЕ возвращает доступную часть данных вместо ошибки при наличии запрещённых строк. Оно не расширяет права и может скрыть неполноту результата.

Практический пример. отчёт с РАЗРЕШЕННЫЕ возвращает только доступные продажи, но итог становится неполным; интерфейс обязан объяснить пользователю ограниченность.

Комментарий интервьюера. конструкция не должна использоваться, чтобы молча скрыть ошибку прав или неожиданную неполноту.

Без конструкции запрос может завершиться ошибкой недостаточных прав, если обращение затрагивает запрещённые данные. Поведение зависит от текста запроса и прав.

Практический пример. запрос без РАЗРЕШЕННЫЕ касается закрытой организации и завершается ошибкой прав вместо частичного результата.

Комментарий интервьюера. попросите назвать желаемое бизнес-поведение конкретного отчёта, прежде чем выбирать конструкцию.

Параметр сеанса хранит доверенный контекст — пользователя, организацию, группу доступа — и используется в шаблоне RLS. Заполняется на сервере, не из произвольного клиентского значения.

Практический пример. сервер при входе вычисляет идентификатор набора разрешений и кладёт его в параметр сеанса, используемый шаблоном RLS.

Комментарий интервьюера. значение не должно поступать из клиентской формы; иначе пользователь сможет подменить контекст доступа.

RLS добавляет условия/соединения к каждому обращению; сложный шаблон и отсутствие индекса резко увеличивают чтения. План получают под конкретным пользователем.

Практический пример. простой список получает дополнительное соединение с 2 млн строк разрешений; индекс по пользователю и организации сокращает чтение.

Комментарий интервьюера. проверяйте план под несколькими профилями, потому что администратор и ограниченный пользователь получают разные запросы.

Ограничения применяются при чтении исходных таблиц; виртуальная таблица может усложнить добавленные условия, а временная содержит уже отобранный результат текущего запроса. Конкретный SQL проверяют.

Практический пример. виртуальная таблица остатков сначала должна учитывать доступные склады, а временная таблица содержит уже прошедшие ограничения строки текущего выполнения.

Комментарий интервьюера. точный итоговый SQL платформы важнее общих предположений о порядке применения RLS.

Простой ВЫБРАТЬ может получить дополнительные соединения с таблицами групп доступа и условия параметров сеанса. Это меняет порядок join и оценку кардинальности.

Практический пример. ВЫБРАТЬ Заказы превращается в соединение с таблицей групп и условие параметра сеанса, меняя кардинальность и порядок join.

Комментарий интервьюера. кандидат должен анализировать запрос после внедрения ограничений, а не только исходный текст конфигурации.

Для каждой строки/ключа может потребоваться поиск актуальной записи на период, что создаёт дорогие срезы. Обычно права материализуют в более простой актуальный регистр с индексами.

Практический пример. доступ вычисляется через СрезПоследних назначения менеджеров на каждый документ, создавая дорогой коррелированный поиск.

Комментарий интервьюера. попросите предложить актуальную материализованную таблицу разрешений и механизм её обновления.

Роль — метаданные платформы с правами. Профиль БСП объединяет роли и виды доступа, группа назначает профиль пользователям и значения разрешённых разрезов.

Практический пример. профиль МенеджерПродаж включает роли чтения и изменения, а группа РегионСевер назначает профиль пользователям и список организаций.

Комментарий интервьюера. роли определяют возможности, группы и виды доступа — конкретную область данных; это разные оси.

Запустить тесты под ограниченным пользователем: список, прямую ссылку, отчёт, подбор, поиск, печать и API. Проверять не только UI, но и фактическое отсутствие чужих данных.

Практический пример. тестовый пользователь не видит чужой заказ в списке, затем вручную подставляет его ссылку в URL/API и всё равно получает отказ.

Комментарий интервьюера. проверка только видимости строк не обнаруживает IDOR-подобный доступ по известному идентификатору.

Зависит от пользователя/контекста, от имени которого запущено задание, и привилегированности кода. Нельзя считать фоновые задания автоматически полноправными.

Практический пример. фоновая выгрузка запущена от ограниченного пользователя и получает только его организации; привилегированный служебный метод явно расширяет доступ для системной задачи.

Комментарий интервьюера. кандидат должен назвать, почему и где такое расширение полномочий безопасно.

Привилегированный режим отключает проверки прав для выполняемого серверного участка. Он не должен охватывать непроверенный пользовательский запрос или большой модуль.

Практический пример. привилегированный метод удаляет помеченные служебные записи по заранее проверенному списку, но не принимает произвольное условие от клиента.

Комментарий интервьюера. чем шире вход и операция, тем выше риск обхода всей модели доступа.

Чем меньше публичная поверхность, тем легче проверить авторизацию входов. Привилегированный модуль должен выполнять узкую операцию и не быть универсальным прокси к данным.

Практический пример. вместо привилегированной функции ВыполнитьЛюбойЗапрос(Текст) создают метод ПолучитьРазрешённыйОстаток(Склад,Товар) с валидацией.

Комментарий интервьюера. хороший API ограничивает не только тип параметров, но и саму допустимую операцию.

На сервере повторно проверить право текущего пользователя на объект и допустимость операции, не доверяя присланной ссылке. При запрете вернуть 403/404 по принятой политике.

Практический пример. клиент передал ссылку договора другой организации; сервер проверил принадлежность текущему пользователю и вернул 403 без содержимого договора.

Комментарий интервьюера. UI-фильтр договора не заменяет повторной проверки на серверной границе.

Общий реквизит-разделитель физически присутствует в данных и автоматически ограничивает область. Он решает изоляцию областей, но не все прикладные права внутри области.

Практический пример. общий реквизит ОбластьДанных автоматически разделяет арендаторов, а RLS внутри арендатора ограничивает отделы конкретного пользователя.

Комментарий интервьюера. кандидат должен понимать, что техническая изоляция и прикладные полномочия решают разные задачи.

Создать матрицу роль×операция×область, запускать сценарии под тестовыми пользователями и проверять разрешённые и запрещённые случаи. Особое внимание — прямым ссылкам и API.

Практический пример. матрица содержит чтение, изменение и удаление для менеджера своей и чужой организации; сценарии запускаются под реальными тестовыми профилями.

Комментарий интервьюера. добавьте отрицательные тесты прямых ссылок, API и фоновых операций, иначе матрица покрывает лишь меню.

Получить итоговый SQL/план, упростить шаблон, материализовать разрешения, добавить поддерживаемый индекс либо разделить отчёт. Нельзя отключать безопасность ради скорости.

Практический пример. отчёт деградировал из-за шаблона с тремя подзапросами; разрешения материализовали в простой регистр и индексировали по пользователю и организации.

Комментарий интервьюера. решение не должно отключать RLS или выполнять отчёт привилегированно ради скорости без эквивалентной защиты.

Скрытая команда лишь меняет интерфейс; пользователь или интеграция может вызвать серверный метод другим способом. Право проверяется на серверной бизнес-границе.

Практический пример. кнопка удаления скрыта, но пользователь вызывает опубликованный серверный метод; только серверная проверка права останавливает операцию.

Комментарий интервьюера. вопрос проверяет базовый принцип — интерфейс не является доверенной границей.

Внешний код может читать файлы, сеть или выполнять опасные операции. Безопасный режим и профили разрешений ограничивают возможности; доверие выдаётся минимально.

Практический пример. внешняя обработка в безопасном режиме не читает произвольный каталог и не выполняет COM; профиль разрешает только выбранную операцию с файлом.

Комментарий интервьюера. попросите назвать минимально необходимые разрешения и последствия выдачи полного профиля.

HTTP-сервис задаёт произвольные маршруты, методы и форматы, часто JSON/REST. Web-сервис реализует SOAP/WSDL и типизированные XDTO-операции.

Практический пример. мобильный клиент отправляет JSON в HTTP-сервис /orders, а банк предоставляет SOAP/WSDL, к которому 1С подключается WS-ссылкой.

Комментарий интервьюера. кандидат должен выбирать механизм по контракту партнёра, а не объявлять SOAP или REST безусловно лучше.

Добавить объект сервиса и обработчики, настроить публикацию ИБ на веб-сервере, аутентификацию, права и TLS. Затем проверить URL, методы и журнал без раскрытия секретов.

Практический пример. после добавления маршрута /api/v1/orders/{id} ИБ публикуют на Apache/IIS, включают HTTPS, роль сервисного пользователя и ограничение методов.

Комментарий интервьюера. спросите о тестовом endpoint, ротации сертификата и отсутствии отладочных данных в production-ответе.

Да, но способ зависит от SOAP/XDTO и поддержки MTOM либо кодирования. Для больших файлов лучше потоковый HTTP-контракт, если SOAP не обязателен.

Практический пример. небольшой файл возвращается Base64/XDTO, большой SOAP-вызов использует MTOM, если обе стороны поддерживают контракт.

Комментарий интервьюера. кандидат должен оценить рост размера Base64 и память, а не просто подтвердить техническую возможность.

Шаблон URL выбирает обработчик; метод GET/POST/... проверяется кодом/маршрутом; тело читается из запроса, ответ задаёт статус, заголовки и тело. Ошибки возвращают стабильный код и correlation id.

Практический пример. POST /orders читает JSON, валидирует обязательные поля, возвращает 201 и Location; неизвестный заказ по GET даёт 404.

Комментарий интервьюера. попросите различить ошибку формата 400, запрет 403, конфликт 409 и внутреннюю ошибку 500.

Успех — подходящий 2xx, ошибка клиента/доступа — 4xx, серверная — 5xx. Не возвращайте 200 с полем «Ошибка» для всех случаев и не отдавайте стек.

Практический пример. дублирующий внешний номер возвращает 409 с машинным кодом ORDER_EXISTS и correlation id, а не 200 с текстом «ошибка».

Комментарий интервьюера. стабильный код предназначен клиенту, подробный стек — внутреннему журналу; смешение создаёт риск утечки.

Создать HTTP-соединение и запрос, задать заголовки/тело, выполнить нужный метод, проверить статус и разобрать JSON. Тайм-ауты, TLS и повтор должны быть явной частью контракта.

Практический пример. Пример кода создаёт HTTPЗапрос, устанавливает Content-Type: application/json, выполняет POST, проверяет КодСостояния и только затем разбирает тело.

Комментарий интервьюера. спросите про тайм-аут, TLS и ограничение размера ответа — счастливого пути недостаточно.

Тайм-ауты задают при создании соединения/вызове доступными средствами версии. Различают соединение и чтение; после тайм-аута состояние удалённой операции может быть неизвестно.

Практический пример. соединение ограничено 5 секундами, чтение — 30; после тайм-аута отправки клиент проверяет статус операции по её ключу.

Комментарий интервьюера. увеличение всех тайм-аутов маскирует зависимость и удерживает ресурсы, не решая неопределённый результат.

Использовать системное хранилище доверия и корректное имя узла; не отключать проверку сертификата как «исправление». Для внутреннего CA установить цепочку доверия на серверы кластера.

Практический пример. сертификат внутреннего CA устанавливают в доверенное хранилище серверов кластера, а имя endpoint совпадает с SAN сертификата.

Комментарий интервьюера. ответ «отключить проверку сертификата» является красным флагом для production-интеграции.

Секрет хранить в защищённой настройке, не включать в URL и маскировать заголовки Authorization. В журнал писать идентификатор интеграции, но не токен и тело с ПДн.

Практический пример. токен хранится в защищённой настройке, заголовок Authorization маскируется, а журнал содержит только имя интеграции и MessageId.

Комментарий интервьюера. попросите учесть резервные копии, тестовые базы и доступ администраторов к секрету.

REST — архитектурный стиль с ресурсами, единообразными операциями и без серверного клиентского состояния между запросами. HTTP endpoint с командами может быть корректным API, но не обязательно REST.

Практический пример. /orders/42 представляет ресурс заказа и использует GET/PATCH, а /DoEverything с состоянием сессии — HTTP RPC, но не REST в строгом смысле.

Комментарий интервьюера. терминологическая чистота менее важна, чем предсказуемый контракт; кандидат должен объяснить выбранный стиль.

OData автоматически открывает стандартную модель метаданных и запросов. Собственный HTTP API даёт стабильный предметный контракт, но требует больше разработки и версионирования.

Практический пример. OData быстро открывает чтение справочника, а собственный /available-stock скрывает внутренние регистры и сохраняет предметный контракт при их изменении.

Комментарий интервьюера. спросите о версии, правах и лимитах сложных клиентских фильтров OData.

Сильная связь с внутренними метаданными, широкая поверхность чтения/записи, сложные запросы клиентов и нагрузка. Ограничивают публикацию, права и объёмы.

Практический пример. клиент OData запросил широкую навигацию и $expand, породив тяжёлый запрос ко внутренним таблицам; API ограничили публикацию и объёмы.

Комментарий интервьюера. автоматическая публикация не отменяет проектирование поверхности доступа и мониторинг нагрузки.

WSDL описывает SOAP-контракт операций и типов; SOAP — XML-протокол сообщений; XDTO — типовая модель XML в 1С. Вместе дают строгий, но более тяжёлый контракт.

Практический пример. WSDL описывает операцию GetBalance, SOAP передаёт XML-конверт, XDTO отображает тип ответа в объекты 1С.

Комментарий интервьюера. попросите объяснить обработку изменения схемы и необязательного поля, а не только расшифровать аббревиатуры.

Версию включить в URL/заголовок или схему, сохранять обратную совместимость в пределах версии и объявлять срок вывода. Не менять смысл существующего поля молча.

Практический пример. /api/v1/orders сохраняет старое поле на переходный период, v2 вводит новую модель, а потребители получают дату отключения v1.

Комментарий интервьюера. молчаливое изменение смысла существующего поля опаснее явного выпуска новой версии.

Дата — согласованный ISO 8601 с часовым поясом/правилом зоны; число — JSON number без локальных запятых; UUID — строка; ссылка — внешний стабильный идентификатор, не внутреннее представление 1С без договора.

Практический пример. дата передаётся 2026-08-21T10:30:00+03:00, сумма — 123.45, идентификатор — UUID-строка; представление ссылки 1С наружу не утекает.

Комментарий интервьюера. попросите согласовать временную зону, точность денег и внешний стабильный ключ до написания сериализации.

Читать/писать потоками или порциями и не преобразовывать весь файл в строку/Base64 без необходимости. Ограничить размер, проверить контрольную сумму и использовать временное хранилище.

Практический пример. файл 4 ГБ читается блоками и сохраняется во временный поток с вычислением SHA-256; целиком в двоичные данные рабочего процесса не загружается.

Комментарий интервьюера. уточните лимит, очистку неполного файла и защиту имени/пути от подстановки.

Клиент передаёт ключ; сервер в одной транзакции проверяет/создаёт запись с уникальным индексом и сохраняет результат. Повтор с тем же ключом возвращает прежний результат.

Практический пример. таблица операций имеет уникальный IdempotencyKey; первая транзакция создаёт заказ и сохраняет ответ, повтор читает сохранённую ссылку.

Комментарий интервьюера. простая проверка Найти() без уникального ограничения не защищает два параллельных первых запроса.

В транзакции бизнес-операции записать строку регистра/справочника исходящих сообщений. Фоновое задание после коммита отправляет, фиксирует попытку и помечает успех; потребитель дедуплицирует.

Практический пример. заказ и строка outbox фиксируются вместе; отправитель публикует её, а затем отдельной транзакцией помечает доставленной.

Комментарий интервьюера. сбой после публикации до отметки успеха должен приводить к безопасной повторной доставке.

Не создавать второй эффект с новым ID. Повторить с тем же ключом идемпотентности или запросить статус удалённой операции по внешнему идентификатору.

Практический пример. платёжный API не ответил, но мог списать деньги; клиент повторяет с тем же PaymentId или запрашивает его статус, а не создаёт новый.

Комментарий интервьюера. кандидат обязан различать «ответ не получен» и «операция не выполнена».

Классифицировать ошибки: временные повторять с экспоненциальной задержкой и jitter, постоянные помещать в карантин. Ограничить попытки и уведомлять с correlation id.

Практический пример. 503 повторяется через 1, 2 и 4 минуты с jitter, 400 сразу уходит в карантин как постоянная ошибка, после пяти попыток создаётся оповещение.

Комментарий интервьюера. попросите назвать классификацию кодов и верхний предел, иначе очередь способна повторять вечную ошибку бесконечно.

Назначить ключ партиционирования, например заказ, и обрабатывать его сообщения последовательно; разные ключи — параллельно. Номер версии/последовательности помогает обнаружить пропуск.

Практический пример. сообщения одного заказа идут в партицию по OrderId и обрабатываются последовательно, разные заказы выполняются параллельно.

Комментарий интервьюера. глобальная последовательность часто избыточна; кандидат должен найти минимальный ключ необходимого порядка.

Метрики: вход/успех/ошибка, p95 задержки, возраст и длина очереди, число повторов и карантин. Логи коррелируются идентификатором сообщения без секретов.

Практический пример. dashboard показывает возраст старейшего сообщения, p95 доставки, процент 5xx, число повторов и карантин по каждому endpoint.

Комментарий интервьюера. просто считать количество ошибок недостаточно — одна застрявшая критичная операция может потеряться среди успешных.

Планы обмена/РИБ, универсальный обмен, HTTP/SOAP/OData, брокер, файлы, COM и прямой экспорт форматов. Выбор определяется связностью, SLA, объёмом и владением данными.

Практический пример. синхронный запрос цены идёт HTTP, массовая ночная загрузка — файлом, события заказов — через брокер, изменения между узлами 1С — планом обмена.

Комментарий интервьюера. попросите связать каждый выбор с SLA, связностью и восстановлением после сбоя.

Одновременное изменение одного объекта, конфликт удаления/изменения и разный порядок событий. Решают владением данных, приоритетами узлов, версиями и разбором конфликтов.

Практический пример. центральный и магазин одновременно изменили адрес клиента; правило владения отдаёт мастерство центру, а конфликт записывается для разбора.

Комментарий интервьюера. «последняя запись победила» требует синхронизированных часов и может терять важное изменение.

Да, план может регистрировать изменения, а преобразование выполняет собственный код/правила обмена. Одинаковые метаданные для самого факта регистрации не обязательны, но контракт сопоставления нужен.

Практический пример. план обмена регистрирует изменённый заказ УТ, правило преобразует его в другой набор объектов самописной конфигурации.

Комментарий интервьюера. кандидат должен разделять регистрацию изменений и трансформацию формата данных.

Платформа записывает, какие объекты изменились для каких узлов. После успешной доставки регистрацию очищают адресно; преждевременная очистка теряет изменения.

Практический пример. изменение товара зарегистрировано для трёх магазинов; после подтверждения магазина A удаляется только его запись регистрации, B и C продолжают ожидать.

Комментарий интервьюера. преждевременная общая очистка приводит к тихой потере доставки другим узлам.

Авторегистрация может включить в обмен огромный или запрещённый набор изменений. Типовые решения часто регистрируют только осознанные объекты и узлы по правилам синхронизации.

Практический пример. автоматическая регистрация всех изменений цен создаёт миллионы сообщений для узлов, которым нужен только розничный вид цены; регистрацию делают адресной.

Комментарий интервьюера. запрет авторегистрации требует собственного полного алгоритма — иначе нужные изменения тоже потеряются.

Зависимость от Windows/разрядности и установленного клиента, лицензирование, слабая пригодность через сеть, синхронность и сложная отказоустойчивость. Для распределённой интеграции HTTP/очередь обычно лучше.

Практический пример. COM-обмен на сервере Linux не запускается и зависит от разрядности установленного клиента Windows; HTTP-контракт устраняет эту связность.

Комментарий интервьюера. COM может быть оправдан локальной утилитой, поэтому нужен контекст, а не безусловный запрет.

КД2 основана на правилах конвертации объектов и XML-подходе; КД3 ориентирована на формат EnterpriseData и правила синхронизации. Выбор зависит от источников и целевого типового механизма.

Практический пример. разовый обмен старой самописной базы строят правилами КД2, а синхронизацию современных типовых через EnterpriseData — механизмами КД3.

Комментарий интервьюера. кандидат должен назвать фактический опыт и версии; сравнение «3 новее, значит лучше» недостаточно.

HTTP — запрос/ответ; брокер — асинхронность и буфер; файл — пакетная совместимость; план обмена — регистрация изменений 1С. Сопоставляют SLA, связность, порядок, объём и операционную зрелость.

Практический пример. запрос доступного лимита требует немедленного ответа — HTTP; события отгрузки выдерживают задержку и всплеск — брокер; реестр за сутки — файл.

Комментарий интервьюера. попросите описать поведение каждого варианта при недоступности получателя.

Предопределённое регламентное задание описано в конфигурации и поддерживается платформой по метаданным. Непредопределённое создаётся программно как экземпляр с настройками.

Практический пример. предопределённое задание очистки описано в конфигурации и появляется после обновления, а администраторское одноразовое задание создано программно.

Комментарий интервьюера. кандидат должен различать описание задания и конкретные фоновые запуски по расписанию.

Регламентное задание задаёт расписание и параметры запуска. Фоновое — конкретное асинхронное выполнение серверного метода.

Практический пример. регламентное задание «каждые 10 минут» создаёт фоновое выполнение метода обмена; несколько выполнений могут пересечься без дополнительной защиты.

Комментарий интервьюера. спросите, где хранится расписание и как обнаружить зависший предыдущий экземпляр.

Передаются только сериализуемые параметры. Для сложного/большого контекста передают идентификатор задания или адрес временного хранилища, а данные читают на сервере.

Практический пример. фоновому заданию передают GUID операции, а список миллиона строк оно читает из служебного регистра, не сериализуя его в параметр.

Комментарий интервьюера. параметр должен быть сериализуемым и достаточно малым; временное хранилище имеет ограниченный срок жизни.

Сохранить идентификатор, статус, прогресс и результат в типовом механизме длительных операций/служебном хранилище. Клиент опрашивает состояние и отдельно обрабатывает ошибку.

Практический пример. клиент получает OperationId, опрашивает статус, показывает 65%, а после завершения скачивает файл по сохранённому адресу или отображает безопасную ошибку.

Комментарий интервьюера. попросите описать повторное открытие формы и получение результата после завершения пользовательского сеанса.

Запустить задание, поставить серверную точку останова и подключить отладчик к серверному процессу/фоновому сеансу. На тесте полезен синхронный вызов того же внутреннего метода.

Практический пример. точка останова ставится в серверном методе, отладчик подключается к фоновому сеансу; для unit-проверки внутренняя функция вызывается синхронно.

Комментарий интервьюера. кандидат должен отделить отладку бизнес-функции от особенностей планировщика фоновых заданий.

Использовать уникальный ключ фонового задания или атомарную запись состояния/блокировку. Простая проверка списка запущенных без атомарности сама допускает гонку.

Практический пример. уникальный ключ задания Обмен:Узел42 не позволяет создать второй экземпляр, а завершившийся/аварийный статус освобождает возможность повторного запуска.

Комментарий интервьюера. неатомарное чтение списка активных заданий оставляет окно гонки между проверкой и запуском.

Запись-замок с уникальным ключом и сроком аренды создаётся атомарно; владелец продлевает lease, а после тайм-аута другой узел может забрать. Нужно защититься от старого владельца токеном поколения.

Практический пример. узел получает lease на 60 секунд с токеном поколения, продлевает его каждые 20; просроченный старый владелец не может записать результат.

Комментарий интервьюера. один timestamp без fencing token допускает работу двух владельцев после сетевой паузы.

После каждой порции сохранять курсор и состояние; операция должна повторно обрабатывать порцию безопасно. При старте находить незавершённые операции и продолжать с подтверждённой точки.

Практический пример. обработка сохранила курсор 150000, процесс упал на следующей порции, новый запуск повторяет только неподтверждённый диапазон идемпотентно.

Комментарий интервьюера. статус «выполняется» без heartbeat и срока аренды может навсегда оставить операцию зависшей.

Выбирать порцию запросом по стабильному ключу после курсора, обрабатывать набором, фиксировать и сохранять новый курсор. Не использовать смещение по изменяемой таблице — строки могут пропускаться.

Практический пример. Пример запроса: ГДЕ Ссылка > &ПоследняяСсылка УПОРЯДОЧИТЬ ПО Ссылка ПЕРВЫЕ 500; после коммита сохраняется максимальная обработанная ссылка.

Комментарий интервьюера. смещение ПРОПУСТИТЬ по изменяемому набору способно пропустить или повторить строки; стабильный курсор безопаснее.

Хранить флаг отмены, проверять между атомарными порциями, завершать текущую транзакцию согласованно и отмечать статус. Насильственное завершение процесса оставляют только аварийным средством.

Практический пример. пользователь нажал отмену, текущие 200 записей завершаются и фиксируются, перед следующей порцией операция ставит статус Отменена.

Комментарий интервьюера. принудительное уничтожение рабочего процесса не является штатной отменой и может оставить неопределённое внешнее состояние.

Права определяются контекстом запуска и пользователем/механизмом, а не фактом «фоновое». Серверный метод всё равно должен проверять допустимость и не полагаться на UI.

Практический пример. задание запущено от сервисного пользователя с доступом к двум организациям и не выгружает третью; системная задача использует узкий привилегированный метод.

Комментарий интервьюера. «фон работает с полными правами» — опасное необоснованное предположение.

Группировать мелкие элементы в порции, ограничивать число параллельных заданий и использовать очередь. Тысячи коротких запусков создают накладные расходы планировщика и соединений.

Практический пример. вместо 100 тысяч заданий по одному товару создают очередь и 10 воркеров, каждый обрабатывает порции по 500 товаров.

Комментарий интервьюера. попросите оценить накладные расходы планировщика, соединений и журналирования каждого мелкого задания.

Идентификатор операции и корреляции, этап, обработано/всего, время начала/обновления, владелец, число попыток и безопасная ошибка. Это позволяет отличить зависание от медленной работы.

Практический пример. запись операции содержит OperationId, владельца, heartbeat, 32500/100000, последнюю ссылку, попытку 2 и correlation id ошибки.

Комментарий интервьюера. по этим данным дежурный должен отличить медленное выполнение, зависание и повтор после сбоя.

БСП — поддерживаемая фирмой 1С библиотека универсальных подсистем и программных интерфейсов. Она ускоряет разработку типовой инфраструктуры и задаёт правила интеграции механизмов.

Практический пример. вместо собственной подсистемы файлов, печати и пользователей конфигурация внедряет поддерживаемые блоки БСП и расширяет их через предусмотренные интерфейсы.

Комментарий интервьюера. кандидат должен назвать цену библиотеки — зависимости, обновления и необходимость следовать её контрактам.

Посмотреть служебные сведения/константы и документацию, встроенную в конкретную конфигурацию; не выводить версию по релизу прикладного решения. При обновлении фиксировать фактический номер сборки.

Практический пример. в конфигурации ERP может быть встроена БСП 3.1.x, хотя на сайте уже доступна 3.2.1; сигнатуры берут из фактической поставки проекта.

Комментарий интервьюера. номер прикладного релиза или «последняя БСП» не доказывает встроенную версию.

Публичный интерфейс документирован и поддерживается библиотекой; экспортная служебная функция может измениться без совместимости. Вызывать следует интерфейс своей редакции БСП.

Практический пример. документированный ДлительныеОперации используется напрямую, а экспортный ДлительныеОперацииСлужебный не вызывается из прикладного кода.

Комментарий интервьюера. попросите показать, где в документации объявлена стабильность выбранной функции.

Модули Переопределяемый содержат предусмотренные точки подключения прикладной конфигурации. Их заполняют по контракту, не меняя внутреннее ядро библиотеки.

Практический пример. в РаботаСФайламиПереопределяемый конфигурация сообщает поддерживаемые типы объектов, не изменяя основной модуль подсистемы.

Комментарий интервьюера. переопределяемая точка — контракт дополнения; копирование всего библиотечного модуля разрушает обновляемость.

Выбрать подсистему и зависимости в помощнике внедрения, объединить объекты по инструкции, заполнить переопределяемые модули и выполнить проверку внедрения. Обновление сначала репетируют на копии и читают изменения версии.

Практический пример. помощник внедрения добавляет «Работу с файлами» вместе с зависимостями, затем разработчик заполняет определяемые типы и запускает проверку внедрения.

Комментарий интервьюера. спросите о повторном помощнике при обновлении и анализе снятых/добавленных зависимостей.

Внешний файл сообщает регистрационные сведения, назначение и команды; БСП регистрирует его и вызывает команду в указанном режиме. Разрешения и безопасный режим задают явно.

Практический пример. внешняя обработка сообщает вид ДополнительнаяОбработка, назначение документам заказа и команду ПроверитьЛимит, выполняемую на сервере.

Комментарий интервьюера. кандидат должен учитывать безопасный режим, разрешения и способ передачи выбранных объектов.

Обычно вид обработки, версия, назначения, команды, представления и режимы выполнения. Имена полей и обязательность зависят от редакции, поэтому берут шаблон её документации.

Практический пример. регистрационные сведения содержат имя, версию, безопасный режим, назначения и массив команд с идентификаторами и типами вызова.

Комментарий интервьюера. точные поля меняются по редакциям; правильный навык — взять шаблон именно встроенной БСП.

Создать внешнюю обработку нужного вида, вернуть назначения объектов и команду печати, затем сформировать табличные документы в коллекцию печатных форм. Проверить массовую печать и права.

Практический пример. внешняя печатная форма назначена реализации, принимает массив ссылок и добавляет табличный документ НакладнаяПартнёра в коллекцию печати.

Комментарий интервьюера. спросите о массовой печати нескольких объектов и отметке обработанных ссылок.

Процедура печати получает массив объектов и коллекцию, формирует табличный документ и добавляет его под именем макета/команды. Необходимо отметить обработанные объекты и параметры печати по контракту версии.

Практический пример. для каждой реализации формируется именованный табличный документ, параметры печати сохраняют количество копий и выбранный принтер.

Комментарий интервьюера. кандидат не должен напрямую открывать форму печати из серверной функции формирования макета.

Запустить серверную функцию через интерфейс длительных операций, получить идентификатор, на клиенте подключить ожидание и обработать результат/ошибку. Не вызывать внутренние служебные модули напрямую.

Практический пример. БСП запускает фоновый расчёт файла, клиент получает идентификатор ожидания, затем обработчик завершения открывает готовый файл или показывает ошибку.

Комментарий интервьюера. попросите назвать поведение при закрытии формы и повторном подключении к операции.

Подсистема регистрирует обработчики перехода между версиями и выполняет миграцию данных. Она хранит состояние, поддерживает отложенные/порционные этапы и диагностику.

Практический пример. при переходе 2.4→2.5 обработчик создаёт новые соответствия внешних ключей, отмечает выполненную версию и запускает тяжёлое заполнение отложенно.

Комментарий интервьюера. миграция должна быть повторяемой и наблюдаемой, а не одной длинной процедурой начала сеанса.

Перед изменением проверять, выполнено ли оно; использовать уникальные признаки/версии, порции и контрольные точки. Повтор после падения не должен создавать дубликаты или повторный эффект.

Практический пример. обработчик перед вставкой проверяет существование записи по уникальному ключу, фиксирует каждые 1000 строк и сохраняет курсор.

Комментарий интервьюера. повтор после падения должен продолжить работу без дублей; «запускать только один раз» не является технической гарантией.

Карточка присоединённого файла связана с объектом, версии хранят содержимое и реквизиты; содержимое может быть в ИБ или томах. Выбор учитывает размер, резервирование и доступность файлового хранилища.

Практический пример. карточка файла хранит имя и владельца в ИБ, версия содержимого лежит в томе 2026/08, а резерв копирует базу и том согласованно.

Комментарий интервьюера. попросите описать восстановление, если БД вернулась на вчера, а файловый том — на сегодняшнее состояние.

При записи подключённого объекта БСП сохраняет сериализованную версию/различия и позволяет сравнить или восстановить. Объекты подключаются через настройки подсистемы и переопределяемые точки.

Практический пример. перед изменением договора подсистема сохраняет версию, пользователь сравнивает реквизиты и при необходимости восстанавливает прошлое состояние.

Комментарий интервьюера. уточните объём версий, период хранения и то, какие изменения, выполненные прямым набором записей, не попадут в объектную историю.

Пользователь идентифицирует работающего; профиль объединяет роли и виды разрешений; группа доступа связывает пользователей с профилем и значениями доступных областей.

Практический пример. пользователь Иван входит в группы ПродажиСевер и ТолькоЧтение, каждая использует профиль ролей и набор доступных организаций.

Комментарий интервьюера. кандидат должен объяснить объединение назначений и избегать смешения пользователя ИБ с прикладным справочником физлиц.

Включить тип объекта в определяемый тип/настройку подсистемы и реализовать предусмотренные переопределяемые процедуры. Конкретный состав контактных видов и представление настраиваются через интерфейс версии.

Практический пример. документ партнёра подключён к контактной информации, форма показывает адреса и телефоны через стандартную команду, а представление формирует БСП.

Комментарий интервьюера. спросите, какие определяемые типы и переопределяемые процедуры меняются при добавлении нового объекта.

Подключить объект к механизму свойств, определить наборы свойств и размещение команд/форм. Значения обычно хранятся в универсальных регистрах БСП; стабильные обязательные поля лучше оставить реквизитами.

Практический пример. пользователи добавляют свойство товара Материал через механизм дополнительных реквизитов, но обязательный Артикул остаётся реквизитом метаданных.

Комментарий интервьюера. кандидат должен назвать цену универсального хранения для запросов, индексов и обязательной проверки.

Использовать предусмотренный общий модуль Переопределяемый, общую команду или расширение и задокументированный интерфейс. Изменение служебного модуля БСП осложняет обновление.

Практический пример. команда очистки очереди добавлена общей командой и вызывает публичный сервис, а настройки регистрируются через предусмотренную переопределяемую точку.

Комментарий интервьюера. изменение внутренней формы БСП без контракта должно рассматриваться как риск следующего обновления.

Поставляемые и пользовательские настройки СКД регистрируются как варианты, имеют владельца, размещение и доступность. БСП выполняет хранение, выбор и обновление поставляемых вариантов.

Практический пример. администратор поставляет вариант ПродажиПоРегионам, менеджер сохраняет личную копию с отбором, обновление меняет только поставляемую основу по правилам БСП.

Комментарий интервьюера. попросите объяснить права публикации общего варианта и конфликт с пользовательской модификацией.

Вызывать публичный интерфейс подсистемы для подписи/проверки/шифрования, передав сертификат и данные, а не работать с провайдером напрямую. Ошибки сертификатов и закрытые ключи обрабатываются безопасно.

Практический пример. документ подписывается через интерфейс БСП выбранным сертификатом, результат проверки хранит статус цепочки и время, закрытый ключ не попадает в ИБ.

Комментарий интервьюера. кандидат должен учитывать истечение/отзыв сертификата и различие подписи данных и шифрования.

Экспортность — синтаксическая доступность, а не гарантия совместимости. Случайный вызов может исчезнуть при обновлении и обходить нужные проверки/настройки.

Практический пример. разработчик вызвал экспортный служебный метод очистки файлов; БСП обновилась, сигнатура изменилась, хотя публичный интерфейс остался совместимым.

Комментарий интервьюера. спросите, как статический анализ или реестр зависимостей обнаружит такие прямые вызовы перед обновлением.

Назовите реальные пять, например доступ, печать, файлы, длительные операции и обновление ИБ; для каждой — что подключали и какой конфликт обновления решали. Не перечисляйте подсистемы без практического примера.

Практический пример. кандидат реально внедрял печать, файлы, длительные операции, обновление ИБ и доступ; для файлов называет миграцию в тома, для доступа — оптимизацию RLS.

Комментарий интервьюера. перечень названий без описания точки подключения и ошибки обновления не подтверждает практический опыт.

Расширение добавляет/изменяет функциональность без прямого редактирования основной конфигурации. Оно облегчает сравнение и обновление, но совместимость всё равно нужно тестировать.

Практический пример. расширение добавляет поле и команду к типовому заказу, основная конфигурация остаётся на поддержке и обновляется без ручного объединения этой доработки.

Комментарий интервьюера. попросите назвать конфликт, который расширение всё равно может получить после изменения формы поставщиком.

Расширения, внешние отчёты/обработки и печатные формы, подписки и документированные интерфейсы БСП/типовой. Выбор зависит от глубины вмешательства и требований поддержки.

Практический пример. отчёт подключается как дополнительный, печатная форма — через БСП, реакция на запись — подпиской, глубокое изменение алгоритма — расширением.

Комментарий интервьюера. сильный кандидат выбирает наименее связанный механизм, но не заставляет внешнюю обработку решать задачу, требующую транзакционной интеграции.

Заимствование переносит описание объекта основной конфигурации в расширение как основу для изменения/контроля. Заимствовать нужно минимально, иначе растёт зависимость от обновлений.

Практический пример. в расширение заимствовали только форму заказа ради одной команды, а не весь документ с табличными частями и реквизитами.

Комментарий интервьюера. каждое лишнее заимствование увеличивает поверхность сравнения и должно иметь причину.

Добавление создаёт новый элемент, изменение дополняет существующий, контроль проверяет соответствие ожидаемого фрагмента основной конфигурации. Режим выбирают по характеру адаптации.

Практический пример. новый реквизит добавляется, обработчик формы изменяется, а критичный текст процедуры берётся под контроль ожидаемой версии.

Комментарий интервьюера. попросите связать режим с поведением при обновлении, а не только пересказать названия операций расширения.

&Перед выполняет код до метода, &После — после, &Вместо заменяет вызов; изменение и контроль внедряет изменение с проверкой исходного текста. Точные ограничения зависят от версии.

Практический пример. &После дописывает аудит после штатного расчёта, &Вместо полностью заменило бы алгоритм и потребовало перенести новые исправления поставщика.

Комментарий интервьюера. кандидат должен знать ограничения конкретного контекста и не использовать перехват как обычное наследование.

Замена копирует ответственность исходного метода и может пропустить новые исправления поставщика. После каждого обновления нужно сравнивать алгоритм и иметь регрессионные тесты.

Практический пример. типовая процедура получила новую проверку запрета периода, но старое &Вместо её обошло и разрешило запись в закрытый месяц.

Комментарий интервьюера. это ключевой риск замены — незаметная потеря исправлений и проверок безопасности поставщика.

Поставщик может изменить сигнатуру, форму, объект или контролируемый фрагмент; расширение перестанет применяться либо изменит поведение. Проверка применимости — обязательный этап релиза.

Практический пример. поставщик переименовал элемент формы и изменил параметр процедуры; расширение перестало применяться при проверке совместимости до запуска пользователей.

Комментарий интервьюера. хороший процесс обнаруживает конфликт в CI/тестовой базе, а не после production-обновления.

Развернуть копию, обновить основную конфигурацию, проверить применение расширения, статический анализ и критичные автотесты, затем нагрузочные сценарии затронутых механизмов.

Практический пример. копию обновляют, подключают все расширения, выполняют проверку применимости, статический анализ и сценарии заказа, печати и проведения.

Комментарий интервьюера. простой успешный запуск приложения не проверяет скрытый перехват, который срабатывает только в редком сценарии.

Минимизировать изменения поставщика, использовать расширения и публичные интерфейсы, изолировать код, документировать каждое отличие и автоматизировать регрессию обновления.

Практический пример. изменение типовой процедуры вынесено в один маркированный блок, имеет ADR и тест; остальные доработки переведены в расширение и БСП-интерфейсы.

Комментарий интервьюера. попросите показать реестр изменений и оценку времени следующего объединения.

Когда механизм расширений не поддерживает нужное изменение либо обход создаёт больший риск. Изменение делают минимальным, маркируют, покрывают тестами и учитывают при каждом объединении.

Практический пример. платформа текущей версии не позволяет расширением изменить необходимое свойство метаданных; команда вносит минимальное изменение в основную и фиксирует его.

Комментарий интервьюера. кандидат должен сравнить стоимость прямой модификации и опасного обхода, а не догматически запрещать основную конфигурацию.

Хранилище конфигурации централизует версии объектов и их захват разработчиками. Оно работает на уровне метаданных и не заменяет все возможности ветвления Git.

Практический пример. разработчик захватывает объект документа, меняет модуль и помещает новую версию; другой не может одновременно записать конфликтующий объект без согласования.

Комментарий интервьюера. спросите, как работать с большим общим модулем, где блокирующий захват сам создаёт организационную очередь.

Git версионирует файлы и ветки, EDT представляет конфигурацию файловым проектом; хранилище управляет объектами конфигурации и блокирующим захватом. Процесс выбирают под инструменты команды.

Практический пример. конфигурация выгружается в файлы EDT и ветвится в Git, тогда как старый процесс использует центральное хранилище с захватом объектов.

Комментарий интервьюера. кандидат должен объяснить не только инструменты, но и процесс сборки, слияния и получения воспроизводимого артефакта.

Сначала понять смысл обеих версий, сравнить метаданные и модули, вручную собрать итог и запустить тесты. Автоматическое принятие «нашей» стороны теряет изменения.

Практический пример. обе ветки изменили проведение; разработчик сравнивает бизнес-смысл строк, объединяет проверки и запускает тесты движений, а не выбирает «принять нашу».

Комментарий интервьюера. автоматическое разрешение синтаксического конфликта не гарантирует сохранение двух требований.

Основная ветка релиза, короткие feature-ветки и отдельная hotfix от production-тега; исправление затем переносится вперёд. Схема должна соответствовать частоте поставок и инструментам 1С.

Практический пример. срочный fix создаётся от production-тега, выпускается, затем переносится в основную ветку, чтобы следующий релиз не вернул дефект.

Комментарий интервьюера. спросите, как версионируются миграции данных, если hotfix и feature-релиз меняют одну структуру.

Корректность, транзакции/блокировки, права, запросы и серверные вызовы, обработка ошибок, тесты и обновляемость. Стиль обсуждают после рисков данных и безопасности.

Практический пример. review проведения сначала замечает гонку остатков, затем запрос в цикле, после — имя переменной; критичность комментариев явно различается.

Комментарий интервьюера. стиль не должен заслонять риск потери данных, а критичное замечание должно содержать воспроизводимый сценарий.

Выгрузка/сборка, синтаксическая проверка, статический анализ, unit/integration tests, проверка расширений и smoke-тест запуска. Набор зависит от проекта, но должен блокировать дефектный артефакт.

Практический пример. pipeline выгружает исходники, запускает синтаксическую проверку, статический анализ, unit/integration tests и smoke обновлённой базы.

Комментарий интервьюера. попросите назвать, какой этап реально блокирует выпуск и где сохраняются диагностические артефакты.

Хранить исходники и версии зависимостей, собирать конфигурацию скриптом, выполнять тесты, формировать подписанный/версионированный артефакт и публиковать его из CI, а не с компьютера разработчика.

Практический пример. тег 2.7.14 однозначно собирает .cf/.cfu, manifest зависимостей и протокол тестов; ручная сборка с ноутбука исключена.

Комментарий интервьюера. воспроизводимость проверяется повторной сборкой того же commit, а не наличием инструкции из десяти ручных шагов.

Добавить обработчик обновления: создать новые структуры платформой, преобразовать данные порциями, проверить количество/суммы и отметить версию. Нужны резерв и повторяемость.

Практический пример. новый справочник создаётся реструктуризацией, обработчик порциями переносит старые строки, сверяет количество и ставит версию миграции.

Комментарий интервьюера. спросите о повторе после 60% выполнения и сохранении обратной совместимости кода во время миграции.

Использовать версионированный формат сообщения и период совместимости, когда старый и новый узлы понимают общий минимум. Обновлять узлы по плану и мониторить несовместимые сообщения.

Практический пример. центр уже отправляет поле TaxMode, старый магазин его игнорирует, новый использует; обязательным оно станет после завершения обновления всех узлов.

Комментарий интервьюера. версия сообщения и период совместимости важнее предположения, что распределённые узлы обновятся одновременно.

До релиза иметь проверенную резервную копию и обратную/компенсирующую миграцию. Если схема необратима, откат означает восстановление БД и потерю изменений после точки — это нужно согласовать заранее.

Практический пример. релиз добавил необратимое объединение справочников; откат приложения требует восстановления backup и повторного ввода операций после точки либо заранее подготовленной компенсации.

Комментарий интервьюера. «вернуть старую cf» не является полноценным планом отката после изменения схемы и данных.

Назовите реальные уровни: модульные тесты логики, интеграционные проведения/регистров, сценарные UI и нагрузочные. Для каждого приведите дефект, который он поймал.

Практический пример. формула скидки проверяется unit-тестом, проведение — интеграционным, оформление заказа — UI-сценарием, блокировки — конкурентным тестом.

Комментарий интервьюера. попросите кандидата объяснить, почему один сквозной UI-тест не заменяет четыре более диагностичных уровня.

Модульный изолирует функцию, интеграционный использует ИБ и механизмы, сценарный воспроизводит пользователя. Их стоимость и диагностическая точность различаются.

Практический пример. unit-тест вызывает чистую функцию без ИБ, integration создаёт документ в базе, scenario нажимает элементы формы реальным клиентом.

Комментарий интервьюера. различие определяется зависимостями и наблюдаемым контрактом, а не названием используемой библиотеки.

Состав и значения движений, повторное проведение, отмену, недостаток остатка, заднюю дату, права и параллельное проведение. Проверять следует бизнес-результат, не только флаг Проведён.

Практический пример. тест реализации проверяет расход товара, долг, повторное проведение, отмену и ошибку при недостатке остатка.

Комментарий интервьюера. флаг Проведён без точной проверки движений допускает логически неверный учёт.

Создавать минимальные данные с уникальными идентификаторами и фиксированными параметрами, затем удалять только их или пересоздавать базу. Тест не зависит от production-справочников.

Практический пример. тест создаёт организацию с GUID в наименовании, документы только для неё и удаляет собственный набор либо пересоздаёт базу.

Комментарий интервьюера. очистка «всех тестовых данных» по общему признаку способна повредить параллельный тест.

Каждый тест создаёт собственное состояние, не зависит от порядка и не оставляет фоновые эффекты. Общие справочники либо неизменяемы, либо создаются fixture с уникальными ключами.

Практический пример. тест цены не использует товар, созданный предыдущим тестом, а сам формирует минимальную цену и дату; порядок запуска можно перемешать.

Комментарий интервьюера. прогон одного теста отдельно — обязательная проверка его независимости.

Передавать дату как зависимость в бизнес-функцию или использовать предусмотренную настройку тестового времени. Прямой ТекущаяДата() в глубине логики делает тест недетерминированным.

Практический пример. функция расчёта пени принимает ДатаРасчёта, поэтому тест фиксирует 31 марта и не зависит от реальных часов сервера.

Комментарий интервьюера. глобальная подмена времени не должна случайно влиять на параллельные тесты и фоновые задания.

Поднять локальный stub HTTP с заранее заданными ответами и направить тестовую настройку на него. Проверить успех, 4xx/5xx, тайм-аут, неверный JSON и повтор.

Практический пример. stub возвращает сначала 503, затем 200 с тем же MessageId; тест проверяет повтор и один созданный объект.

Комментарий интервьюера. mock счастливого ответа без тайм-аута, повреждённого JSON и ошибки авторизации оставляет основные риски непроверенными.

Отправить одно сообщение дважды с тем же ключом и проверить один бизнес-эффект и одинаковый ответ. Затем параллельно отправить два повтора для проверки уникального ограничения.

Практический пример. два параллельных запроса с ключом K1 проходят барьер и одновременно создают операцию; уникальный индекс оставляет один результат.

Комментарий интервьюера. последовательная отправка двух повторов не доказывает защиту от гонки первого создания.

Запускать одинаковые операции под пользователями разных групп и проверять как разрешение, так и запрет. Включить прямую ссылку, отчёт, API и фоновый контекст.

Практический пример. менеджер своей организации проводит заказ, чужой получает отказ, администратор видит обе; тот же набор повторяется через API.

Комментарий интервьюера. тест должен проверять и разрешение, и запрет, иначе слишком строгая RLS также может пройти незамеченной.

Два сеанса синхронно проводят документы на один остаток; барьер ставится перед блокировкой/чтением. Проверить, что один ждёт/отклоняется и отрицательный остаток не возникает.

Практический пример. два тестовых клиента синхронизируются перед блокировкой одного товара; один проводит, второй получает контролируемый дефицит, итог неотрицателен.

Комментарий интервьюера. случайный параллельный запуск без барьера способен пройти даже при реальной гонке.

Использовать управляющие точки/барьеры в двух тестовых сеансах, чтобы задать порядок захвата ресурсов. Не полагаться на случайный Пауза() как единственную синхронизацию.

Практический пример. клиент A сигнализирует «захватил склад 1», B — «захватил склад 2», затем тест разрешает обоим запросить второй склад.

Комментарий интервьюера. детерминированная точка управления важнее длительной паузы, зависящей от скорости машины.

Менеджер тестирования управляет вторым клиентом — клиентом тестирования — через логическую модель интерфейса. Клиент воспроизводит действия, менеджер проверяет результат.

Практический пример. менеджер тестирования на тонком клиенте находит кнопку заказа в клиенте тестирования, нажимает её и читает сообщение формы.

Комментарий интервьюера. кандидат должен различать процесс управления тестом и приложение, в котором воспроизводятся действия.

Критичные маршруты доступности команд, сложное взаимодействие форм и интеграцию элементов интерфейса. Расчёт и проведение лучше проверять ниже UI.

Практический пример. сложный drag-and-drop или доступность команды по состоянию формы проверяется UI-тестом, расчёт суммы — быстрой серверной функцией.

Комментарий интервьюера. попросите объяснить, какой дефект невозможно поймать без реального интерфейса.

Они зависят от расположения/имен элементов, времени, окружения и больших данных, поэтому медленнее и чаще ломаются при изменении интерфейса. Их оставляют для главных сквозных сценариев.

Практический пример. переименование элемента формы ломает 30 сценариев, хотя бизнес-логика не изменилась; Page Object/шаги локализуют исправление.

Комментарий интервьюера. дороговизна UI-тестов — аргумент за пирамиду, а не за полный отказ от критичных сквозных сценариев.

Логи клиента/сервера, шаг сценария, скриншот, ТЖ нужного окна, тестовые данные/seed, версия сборки и correlation id. Секреты из артефактов удаляют.

Практический пример. при падении сохраняются скриншот, шаг, логи клиента, ТЖ по correlation id, версия сборки и идентификаторы тестовых данных.

Комментарий интервьюера. артефакт должен позволить расследование без повторного случайного воспроизведения и не содержать секреты.

Flaky-тест нестабилен без изменения кода из-за времени, порядка, общих данных, асинхронности или среды. Нужно воспроизвести с тем же seed и устранить источник, а не бесконечно перезапускать.

Практический пример. тест иногда читает результат до завершения фонового задания; явное ожидание состояния заменяет фиксированную паузу 5 секунд.

Комментарий интервьюера. бесконечный retry в CI скрывает flaky-причину и делает зелёный статус недостоверным.

Smoke запуска, запись/проведение критичных документов, основные отчёты, права, обмены, обработчики обновления и совместимость расширений. Набор определяется картой изменений релиза.

Практический пример. после обновления запускают миграцию, проведение ключевых документов, основные отчёты, обмен, RLS и проверку применимости расширений.

Комментарий интервьюера. набор должен строиться по карте изменений и бизнес-критичности, а не быть одинаковым для любого релиза.

Восстановить обезличенную копию, измерить миграцию, проверить контрольные суммы/количество объектов, журналы ошибок и повторный запуск. Отдельно оценить место и окно простоя.

Практический пример. копия 2 ТБ обезличивается, миграция выполняется дважды, сравниваются суммы регистров, число объектов, длительность и свободное место.

Комментарий интервьюера. тест маленькой базы не выявит окно простоя и поведение порций на production-объёме.

Мутационное качество/пойманные дефекты, стабильность, длительность, скорость диагностики, доля критичных сценариев и время обратной связи. Процент строк легко увеличить бессмысленными тестами.

Практический пример. покрытие 80% дополнено временем 12 минут, 0,5% flaky, числом пойманных дефектов и критичными сценариями без теста.

Комментарий интервьюера. одна метрика покрытия легко улучшается тестами, которые ничего существенного не утверждают.

Приведите только реальный случай: какой дефект, какой тест упал и что предотвратил. Если такого опыта нет, честно опишите, какие тесты внедрили бы и почему.

Практический пример. тест повторного проведения поймал удвоение резерва до релиза; кандидат показывает условие, которое упало, и исправленный механизм записи набора.

Комментарий интервьюера. если реального случая нет, честный проект тестовой стратегии лучше выдуманной истории успеха.

Файловую базу копируют согласованно при отсутствии записи/штатной блокировке; клиент-серверную — средствами СУБД с журналами и политикой хранения. Главное — проверяемое восстановление.

Практический пример. файловую базу копируют после блокировки сеансов, MS SQL — full backup плюс журналы для point-in-time recovery.

Комментарий интервьюера. попросите назвать RPO и RTO; без них нельзя оценить достаточность выбранной схемы резервирования.

.dt — логическая выгрузка, медленная для больших баз и не обеспечивает point-in-time recovery/журналы СУБД. Это дополнительный переносимый артефакт, не единственная backup-стратегия.

Практический пример. выгрузка .dt базы 1 ТБ занимает слишком долго и не позволяет восстановиться на 14:35; backup СУБД с журналом позволяет.

Комментарий интервьюера. .dt полезна для переноса и логической копии, но не должна называться единственной production-защитой.

Регулярно автоматически восстановить в отдельную среду, проверить целостность, запуск, контрольные данные и время RTO. Наличие файла без восстановления ничего не гарантирует.

Практический пример. каждую неделю backup восстанавливается в изолированный контур, проверяется вход, контрольный отчёт и время восстановления 48 минут.

Комментарий интервьюера. успешный статус задания backup подтверждает создание файла, но не его пригодность к восстановлению.

ТЖ — файловая диагностическая трасса платформы. Настраивают только нужные события, фильтры и ограниченный период/ротацию, иначе объём и влияние могут стать значительными.

Практический пример. на 15 минут включают события запросов и блокировок только для процесса проблемного сервиса, задают ротацию и затем отключают сбор.

Комментарий интервьюера. неограниченный ТЖ на всех событиях может заполнить диск и создать новый инцидент.

Собрать дамп/логи ОС, ТЖ до аварии, состояние кластера и версию платформы, сопоставить процесс и контекст вызова. Затем воспроизвести на копии и проверить известные исправления релиза.

Практический пример. crash dump рабочего процесса, журнал ОС и ТЖ показывают падение во внешней компоненте при обработке конкретного файла.

Комментарий интервьюера. перезапуск процесса восстанавливает доступность, но не является анализом первопричины.

Журнал регистрации хранит аудит событий ИБ. Настраивают уровни/события, архивирование и срок хранения, контролируя права и объём.

Практический пример. события изменения критичных справочников хранятся год, фоновые технические события — короче; архив защищён отдельными правами.

Комментарий интервьюера. политика журнала должна учитывать аудит, объём, персональные данные и скорость поиска.

Измерить реструктуризацию на копии размера production, оценить блокировки/место, выбрать окно, резерв и откат; тяжёлые изменения разбить предварительной миграцией, если возможно.

Практический пример. добавление индексируемого реквизита на 500 млн строк репетируют на копии, измеряют 6 часов и требуют 300 ГБ свободного места.

Комментарий интервьюера. окно обновления определяется фактической реструктуризацией, а не размером файла конфигурации.

Штатная диагностика логической/ссылочной целостности и итогов; для файловой базы доступны дополнительные операции. Выполняют после резерва и по подтверждённой причине, часто монопольно.

Практический пример. после аварийного завершения файловой базы выполняют тестирование логической целостности на копии после backup, а не запускают исправление вслепую на production.

Комментарий интервьюера. спросите, какие исправления допустимы и как сверить бизнес-результат после автоматического ремонта.

По статистике фрагментации/изменений обновлять статистику и реорганизовывать/перестраивать индексы средствами СУБД. Не применять ежедневное полное перестроение без измерения.

Практический пример. статистику высокоизменяемой таблицы обновляют чаще, фрагментированный крупный индекс реорганизуют по порогу, маленькие не трогают.

Комментарий интервьюера. обслуживание должно исходить из метрик и окна, а не из универсального ежедневного скрипта перестроения всего.

Число и тип лицензий, их выдачу, сервер лицензирования, резервирование и ошибки журнала. Не публиковать регистрационные данные и ключи.

Практический пример. мониторинг показывает выдачу 480 из 500 конкурентных лицензий и периодические ошибки программного сервера лицензирования.

Комментарий интервьюера. кандидат должен уметь диагностировать дефицит, но не раскрывать регистрационные номера или содержимое ключей.

Обновление схемы требует исключить конкурентную работу с изменяемыми структурами; платформа запрашивает блокировку/монопольный доступ по типу операции. Точное окно проверяют на копии.

Практический пример. обновление добавляет колонку большой таблице и требует исключительного доступа; пользователи заранее отключены, фоновые задания остановлены, окно подтверждено репетицией.

Комментарий интервьюера. динамическое обновление не следует обещать для любого изменения схемы — допустимость зависит от типа изменения и версии.

Найти длительность, активный вызов и транзакцию; сначала связаться с пользователем/остановить источник. Принудительное завершение может откатить транзакцию и прервать интеграцию, поэтому фиксируют контекст.

Практический пример. сеанс 12 часов держит транзакцию проведения; перед завершением фиксируют запрос, пользователя и MessageId, уведомляют владельца и ожидают откат.

Комментарий интервьюера. принудительное завершение без контекста может прервать оплату или обмен и затруднить восстановление.

Установить модуль расширения веб-сервера, опубликовать ИБ/сервисы, настроить пул/права, сертификат и HTTPS, аутентификацию и ограничения. Проверить журнал и обновление сертификата.

Практический пример. публикация /erp работает через Apache с HTTPS, отдельным пулом, сервисным пользователем и закрытыми неиспользуемыми сервисами.

Комментарий интервьюера. спросите о продлении сертификата, логах веб-сервера и ограничении размера входящего запроса.

До первого запуска отключить расписания или заблокировать выполнение настройкой среды/узла, затем включать только тестовые задания. Одной замены времени недостаточно.

Практический пример. копия production запускается с флагом среды TEST, который запрещает регламентные отправки до явного включения конкретного задания.

Комментарий интервьюера. ручное выключение после первого запуска слишком поздно — сообщение уже могло уйти реальному клиенту.

Почту, банки, ЭДО, кассы, реальные HTTP endpoints, планы обмена и регламентные отправки; заменить секреты и адреса. Персональные данные обезличить согласно политике.

Практический пример. адрес банка заменён stub-сервисом, SMTP — локальной ловушкой, обмены остановлены, токены отозваны, номера телефонов обезличены.

Комментарий интервьюера. попросите пройти полный список исходящих каналов, включая редко используемые внешние компоненты и печать.

Назовите цепочку конкретной конфигурации: заказ, реализация/приобретение, складские ордера, перемещение, инвентаризация и корректировки. Не смешивайте названия разных редакций без оговорки.

Практический пример. в УТ кандидат называет заказ, приобретение/реализацию, складские ордера, перемещение и инвентаризацию, отделяя их от терминов ERP другой редакции.

Комментарий интервьюера. важна связная цепочка процесса и реальные регистры, а не максимально длинный список документов.

Ордерная схема разделяет финансовый документ и фактическую складскую операцию. Она позволяет разным подразделениям работать независимо, но требует контроля неоформленных расхождений.

Практический пример. офис оформляет реализацию утром, склад выдаёт товар по расходному ордеру позже; система показывает оформленное, но ещё не исполненное количество.

Комментарий интервьюера. попросите назвать контроль расхождений между финансовой и складской частью.

Ордерный склад использует отдельные приходные/расходные ордера для факта движения. Заказ или накладная задаёт основание и финансовую часть.

Практический пример. склад принимает фактические 98 из ожидаемых 100 отдельным приходным ордером, после чего офис разбирает расхождение с накладной.

Комментарий интервьюера. кандидат должен объяснить пользу разделения ответственности, а не только назвать документы.

Характеристика описывает вариант товара (размер/цвет), серия — партию или экземпляр с номером/сроком. Конкретные разрезы учёта настраиваются в конфигурации.

Практический пример. футболка размера M и цвета синего — характеристика, партия с номером LOT-17 и сроком 2027-01 — серия.

Комментарий интервьюера. уточните, по какому разрезу ведутся остатки и когда серия идентифицирует каждый экземпляр.

Партионный учёт связывает выбытие с поступлением для стоимости и аналитики. Партия может определяться документом, датой, организацией и другими правилами решения.

Практический пример. списание по FIFO выбирает самое раннее поступление товара и переносит его стоимость в себестоимость реализации.

Комментарий интервьюера. спросите о корректировке позднего поступления и пересчёте последующих списаний.

FIFO списывает ранние партии, LIFO — поздние, средняя стоимость усредняет доступные запасы. Допустимость метода определяется учётной политикой и законодательством.

Практический пример. партии 10×100 и 10×150; FIFO для расхода 12 даёт 10×100+2×150, средняя — 12×125, LIFO — обратный выбор.

Комментарий интервьюера. допустимость LIFO зависит от правил учёта; кандидат должен отделить алгоритм от законодательства.

Метод выбора партии определяет стоимость конкретного выбытия и остатка. Изменение прошлого поступления может потребовать пересчёта последующих списаний.

Практический пример. изменение стоимости первой партии с 100 на 110 меняет себестоимость всех реализаций, которые списали её по FIFO.

Комментарий интервьюера. попросите описать регламент пересчёта и контроль закрытого периода.

Допрасходы распределяют на партии по базе — стоимости, количеству, весу и т. п. — увеличивая себестоимость запасов; база должна быть согласована учётной политикой.

Практический пример. доставка 300 распределяется на товары стоимостью 1000 и 2000 как 100 и 200 при базе «стоимость».

Комментарий интервьюера. другая база — вес или количество — даст иной результат; она должна быть согласована бизнесом.

Закрытие собирает движения периода, распределяет затраты и рассчитывает фактическую себестоимость с корректировками. Точный алгоритм зависит от ERP/УТ и настроек учёта.

Практический пример. закрытие собирает выпуск, материалы, услуги и распределяемые затраты, рассчитывая фактическую стоимость и корректировочные движения.

Комментарий интервьюера. кандидат должен называть редакцию и настройки, потому что алгоритмы УТ, ERP и БП не идентичны.

Позднее поступление, допрасход, корректировка или изменение партии меняет базу прошлых списаний. Поэтому требуется регламентный перерасчёт и контроль закрытого периода.

Практический пример. документ допрасходов введён в апреле за март, после чего мартовская себестоимость и валовая прибыль реализаций изменились.

Комментарий интервьюера. спросите, как система уведомляет о необходимости повторного закрытия и ограничивает задние изменения.

Обособленный учёт разделяет запасы/затраты по назначению, заказу или проекту. Нельзя свободно использовать остаток одного назначения для другого без корректировки.

Практический пример. десять единиц зарезервированы под заказ A и не доступны заказу B, хотя физически находятся на том же складе.

Комментарий интервьюера. кандидат должен различать физический остаток, доступный остаток и назначение обеспечения.

Резерв фиксирует доступный остаток под потребность; обеспечение шире и описывает, откуда потребность будет покрыта — запас, закупка, производство, перемещение.

Практический пример. резерв использует текущие пять единиц, ещё десять обеспечиваются будущей закупкой; оба источника покрывают потребность заказа.

Комментарий интервьюера. попросите объяснить состояние при отмене закупки и перераспределении обеспечения.

Детализация может идти по партнёру/контрагенту, договору, заказу или расчётному документу. Выбор определяет, как закрываются авансы и долги и насколько детальны сверки.

Практический пример. долг ведётся по заказу клиента, поэтому оплата закрывает конкретный заказ; при детализации по договору она может погасить общий долг нескольких заказов.

Комментарий интервьюера. выбор детализации влияет на автоматическое закрытие и сложность сверки, его нельзя менять без миграции смысла.

Хранят сумму в валюте взаиморасчётов и регламентированную оценку, фиксируют курс и отражают курсовые разницы при переоценке/погашении. Правила зависят от конфигурации и учёта.

Практический пример. счёт 1000 EUR отражён по курсу 100, оплата прошла при 105; разница 5000 RUB учитывается отдельно.

Комментарий интервьюера. уточните валюту документа, взаиморасчётов и регламентированного учёта — они могут различаться.

Инвентаризация сравнивает фактическое наличие с учётным. Излишки и недостачи отражаются отдельными документами после утверждения результатов.

Практический пример. учёт показывает 100 единиц, пересчёт — 97; после утверждения оформляется недостача 3, а не переписывается остаток напрямую.

Комментарий интервьюера. кандидат должен отделять документ фиксации факта от документов отражения результата.

Финансовый документ фиксирует обязательства/реализацию, складской — фактическое перемещение. Связь по основанию и статусам позволяет видеть разрыв между оформлением и исполнением.

Практический пример. реализация создаёт долг клиента, расходный ордер подтверждает фактическую выдачу; отсутствие ордера означает финансово оформленный, но не отгруженный товар.

Комментарий интервьюера. спросите о статусах и отчёте, который обнаруживает зависшие расхождения двух контуров.

Определить момент и разрез контроля, применять транзакцию и узкую блокировку, учитывать резервы и движения текущего документа. Сообщение должно показывать дефицит по ключу.

Практический пример. доступность = физический остаток − резервы + разрешённые ожидаемые поступления; контроль выполняется после блокировки ключа склада/товара.

Комментарий интервьюера. формулу нельзя назвать универсальной без правил обеспечения конкретной конфигурации.

Не менять старые таблицы напрямую: оформить корректирующий документ в разрешённом периоде либо открыть период по регламенту, затем пересчитать партии и зависимые операции.

Практический пример. ошибочную партию марта корректируют разрешённым документом апреля и повторно рассчитывают зависимую себестоимость, сохраняя аудит.

Комментарий интервьюера. прямое исправление закрытого движения нарушит воспроизводимость отчётности и должно быть отвергнуто.

Офлайн-касса может продавать на локальных данных и синхронизироваться позже; онлайн-режим требует доступности центральной системы/сервиса. Это отдельно от юридического понятия онлайн-ККТ.

Практический пример. магазин продаёт при потере связи на локальном ассортименте и позже синхронизирует чеки; центральный онлайн-вызов для каждой продажи ему не требуется.

Комментарий интервьюера. не путайте архитектурный offline-режим обмена с юридическим термином онлайн-кассы.

Чек фиксирует отдельную продажу/возврат, отчёт закрытия смены агрегирует результаты смены и служит основанием отражения в учёте. Названия документов зависят от решения.

Практический пример. три чека смены отражают отдельные продажи, а отчёт закрытия агрегирует выручку и оплаты всей смены для учёта.

Комментарий интервьюера. попросите описать возврат после закрытия и связь с кассовым оборудованием конкретного решения.

НДС начисляется при облагаемой реализации и принимается к вычету при выполнении условий по входному налогу; ведутся счета-фактуры/регистры. Точный ответ должен учитывать страну, период и конфигурацию.

Практический пример. реализация начисляет исходящий НДС, подтверждённое приобретение формирует входной налог к вычету, данные попадают в регистры и отчётность.

Комментарий интервьюера. точные условия вычета и документы зависят от законодательства на дату; непроверенная уверенность — минус.

Если сумма включает ставку r%, налог = Сумма * r / (100 + r). При 120 и 20%: 120*20/120=20; правила округления берут из учётной системы.

Практический пример. НДС = Окр(СуммаСНДС * Ставка / (100 + Ставка), 2); // для 120 и 20% получаем 20.

Комментарий интервьюера. спросите о ставке без НДС, дробных копейках и принятом правиле округления.

Налоговый учёт формирует базу и показатели по правилам налогообложения, которые могут отличаться от бухгалтерских. Конкретные регистры и разницы зависят от законодательства и конфигурации.

Практический пример. представительские расходы признаются бухгалтерски, но налоговая база ограничивает их по своим правилам, создавая различие учётов.

Комментарий интервьюера. кандидат-разработчик может не быть методистом, но должен знать, где подтвердить правило и как не зашить устаревшую норму.

Объект принимают к учёту с первоначальной стоимостью и параметрами полезного использования; амортизация распределяет стоимость по периодам. Способ и проводки задаются стандартами/учётной политикой.

Практический пример. станок принят по первоначальной стоимости 1,2 млн и сроку 60 месяцев, после чего ежемесячно начисляется амортизация выбранным способом.

Комментарий интервьюера. спросите о модернизации, ликвидации и различиях бухгалтерского/налогового параметра только если это требуется вакансией.

Доход увеличивает экономические выгоды, расход уменьшает; валовая прибыль — выручка минус себестоимость продаж, чистая — итог после остальных расходов и налогов. Формулы отчёта зависят от принятой классификации.

Практический пример. выручка 1 млн минус себестоимость 600 тыс. даёт валовую прибыль 400 тыс.; после прочих расходов и налога определяется чистая.

Комментарий интервьюера. кандидат должен оговорить классификацию расходов и не смешивать денежный поток с признанием дохода.

Курсовая разница возникает при переоценке валютного требования/обязательства из-за изменения курса между датами. Она отражается как доход или расход по правилам учёта.

Практический пример. задолженность 1000 USD при курсе 90 переоценена по 95, образовав разницу 5000 RUB до погашения.

Комментарий интервьюера. попросите назвать даты курса и отличить переоценку от фактической валютной оплаты.

Постоянная разница не обратится в будущих периодах; временная возникает из разного момента признания и впоследствии погашается, создавая отложенный налог. Термины уточняют по действующим стандартам.

Практический пример. разный срок амортизации создаёт временную разницу, которая погасится; непризнаваемый штраф создаёт постоянную.

Комментарий интервьюера. точные проводки и термины следует подтверждать действующими стандартами, если роль не методологическая.

Сформировать ожидаемые проводки по правилам документа, проверить счета, субконто, суммы, валюту и равенство дебета/кредита. Добавить отрицательные сценарии и повторное проведение.

Практический пример. тест поступления ожидает Дт 41 Кт 60, конкретные субконто, валютную сумму и равенство сторон; лишняя проводка также считается ошибкой.

Комментарий интервьюера. общая сумма проводок не доказывает правильные счета и аналитику.

Оперативный регистр и бухгалтерия могут иметь разный момент отражения, аналитику, валютную оценку и регламентные корректировки. Расхождение расследуют от первичных документов и правил трансляции.

Практический пример. товар уже списан оперативно, но бухгалтерская проводка формируется регламентно после закрытия; на промежуточную дату регистры закономерно расходятся.

Комментарий интервьюера. кандидат должен искать правило трансляции и момент отражения, а не механически «чинить несоответствие».

Кадровые документы задают условия, документ начисления рассчитывает виды расчёта и налоги, ведомость фиксирует сумму к выплате, банк/касса отражает выплату. Названия зависят от редакции ЗУП.

Практический пример. приём задаёт оклад, начисление рассчитывает месяц и налоги, ведомость определяет сумму к выплате, банковский документ подтверждает перечисление.

Комментарий интервьюера. названия и последовательность зависят от редакции ЗУП; оценивайте понимание процесса и регистров расчёта.

Создать/настроить вид расчёта, формулу, базовые и вытесняющие зависимости, показатели и отражение; затем включить в документы начисления. Изменения регламентированных расчётов сверяют с методикой.

Практический пример. новая премия зависит от оклада, имеет показатель процента, базовый период и способ отражения; тест проверяет изменение оклада прошлого месяца.

Комментарий интервьюера. собственный вид расчёта без зависимостей и перерасчётов легко даёт неверный прошлый результат.

Изменение ведущих данных регистрирует перерасчёт зависимых начислений; повторный расчёт пересчитывает базу и разницу. Выплаченный прошлый период обычно корректируется текущим документом по правилам решения.

Практический пример. в марте исправили январский оклад; система регистрирует перерасчёт январской базы и отражает разницу в разрешённом текущем периоде.

Комментарий интервьюера. попросите объяснить, что произойдёт с уже выплаченной суммой и отчётностью.

Отпуск вытесняет оклад на пересекающемся интервале: фактический период оклада сокращается, отпуск занимает эти дни. Это позволяет рассчитать оплату только за непересекающиеся интервалы.

Практический пример. отпуск 10–14 июня вырезает эти дни из фактического периода оклада, чтобы один интервал не оплатился дважды.

Комментарий интервьюера. кандидат должен показать границы пересечения и случай неполного дня/периода, если он поддерживается моделью.

Сначала объяснить платформенный механизм регистра расчёта, затем отдельно — документы и настройки конкретной редакции. Если редакция незнакома, не выдумывать её интерфейс.

Практический пример. разработчик объясняет вытеснение регистра расчёта, но честно уточняет названия документов конкретной ЗУП 3.1 по документации.

Комментарий интервьюера. не наказывайте за интерфейс другой редакции, если вакансия проверяет платформенную глубину; и наоборот.

Сослаться на официальное изменение законодательства/релиз, тестовую методику и контрольные примеры, выполнить сравнение до/после. Ответ по памяти без даты нормативного правила ненадёжен.

Практический пример. новый расчёт проверяется по официальному письму/релизу 1С, контрольным примерам методиста и автотестам на граничные даты.

Комментарий интервьюера. ссылка «так всегда считали» не подтверждает актуальное правило после изменения законодательства.

API принимает заказ с ключом идемпотентности, быстро записывает входящее сообщение, обработка идёт через очередь; резерв защищён узкой блокировкой, статусы отправляются outbox. Нужны rate limit, p95 и карантин ошибок.

Практический пример. API принимает 100 заказов/с, пишет входящие команды с ключом, очередь сглаживает пик, резерв блокирует только товар/склад, статусы идут outbox.

Комментарий интервьюера. попросите посчитать пропускную способность воркеров и поведение при недоступности 1С или канала оплаты.

Потоковое чтение в staging, проверка/дедупликация, порции по стабильному ключу, массовая запись, контрольная точка и сверка сумм. Размер порции выбирают нагрузочным тестом.

Практический пример. CSV читается потоком в staging по 10 тысяч строк, ошибки попадают в карантин, курсор и контрольная сумма позволяют продолжить после сбоя.

Комментарий интервьюера. массовая загрузка объектами по одной строке должна быть обоснована или заменена наборной обработкой.

Историю хранить как события/периодический РС, текущее состояние — материализованное поле/непериодический РС для быстрого чтения. Обновление истории и состояния выполняется атомарно.

Практический пример. каждое изменение статуса пишется событием с временем и версией, текущий статус обновляется атомарно в отдельной быстрой проекции.

Комментарий интервьюера. спросите, как восстановить текущую проекцию из истории и разрешить два конкурирующих перехода.

Резерв по товару/складу выполняется в короткой транзакции с управляемой блокировкой и проверкой доступного остатка. Каналы используют общий сервис и ключ операции.

Практический пример. все каналы вызывают общий сервис резерва; транзакция блокирует один ключ, проверяет доступность и создаёт резерв с RequestId.

Комментарий интервьюера. отдельная реализация резерва для сайта и оператора почти гарантирует расхождение правил и порядка блокировок.

Использовать бизнес-процесс с точками маршрута и задачами; параллельные ветви сходятся по условию завершения, последовательные создаются после результата. Решения и версии документа аудируются.

Практический пример. юридическая и финансовая ветви идут параллельно, после обеих создаётся задача директора; отклонение любой ветви возвращает документ автору.

Комментарий интервьюера. попросите описать адресацию заместителю, тайм-аут задачи и аудит изменения маршрута.

Материализовать членство пользователя в разрешённых организациях/подразделениях, индексировать ключи и использовать простой шаблон RLS. Проверить план на массовых профилях и кэшировать только безопасный контекст сеанса.

Практический пример. разрешения 5000 пользователей материализованы по группам, запрос RLS использует ГруппаДоступа+Организация, а не миллионы индивидуальных строк.

Комментарий интервьюера. проверьте пользователя с одной и с тысячей организаций — распределение доступа влияет на план.

Отдельная аутентификация клиента, scopes, предметный API вместо OData всей базы, проверка владения каждой сущностью, rate limit, аудит и минимальные поля. Секреты и ПДн не логировать.

Практический пример. партнёр получает OAuth-токен со scope заказов, endpoint возвращает только его данные, ограничивает частоту и пишет неизменяемый аудит.

Комментарий интервьюера. собственный API предпочтительнее публикации внутренних регистров, если контракт должен пережить их рефакторинг.

Сначала измерить конфликт CPU/IO/блокировок и определить владельца данных. Возможны разнесение регламентных задач, read-модель или отдельный контур; физическое разделение требует контрактов согласованности.

Практический пример. закрытие месяца переносится в выделенный процесс и read-модель для отчётов; разделение базы рассматривают только после подтверждения конфликтов IO и владения.

Комментарий интервьюера. распределение без чётких границ данных создаст обмены и новые точки отказа, не решив исходную проблему.

Очередь на каждый магазин, пакеты с версиями и подтверждением, повтор/дедупликация, мониторинг возраста очереди и правила владения данными. Магазин продолжает локальную работу при разрыве.

Практический пример. каждый магазин имеет исходящую очередь и подтверждённый курсор, работает локально сутки без связи, затем догоняет изменения с дедупликацией.

Комментарий интервьюера. спросите о конфликте цен и товара, изменённых одновременно в центре и магазине.

Инвентаризация данных и качества, карта соответствий, пробные миграции, сверка остатков/оборотов, дельта на момент переключения и план отката. Бизнес подтверждает контрольные отчёты.

Практический пример. три пробные миграции сверяют остатки и обороты, перед переключением грузится дельта, старая система остаётся read-only для проверки.

Комментарий интервьюера. успешная загрузка объектов без бизнес-сверки сумм не доказывает корректную миграцию.

Каталогизировать изменения и зависимости расширений, сократить пересечения, поднять промежуточные версии, автоматизировать применимость и регрессию. Репетировать на копии с реальным объёмом.

Практический пример. 50 расширений строятся в граф зависимостей, пересечения сокращаются, обновление проходит по промежуточным релизам с автоматическими тестами применимости.

Комментарий интервьюера. попросите стратегию отката и владельца каждого расширения; анонимный набор доработок невозможно безопасно сопровождать.

Заявка печати записывается в очередь с принтером/макетом/приоритетом; воркеры берут задания с lease, печатают идемпотентно и фиксируют статус. Оборудование изолировано адаптером.

Практический пример. задание печати получает GUID, принтер и макет; воркер берёт lease, сохраняет spool-id и не печатает второй экземпляр при повторе подтверждения.

Комментарий интервьюера. физическая печать не всегда идемпотентна, поэтому статус «неизвестно» требует отдельного разбора оператором.

Малые часто читаемые — в ИБ; большие — в томах/объектном хранилище с метаданными в 1С. Решение включает резервирование, права, дедупликацию, доступность и стоимость восстановления.

Практический пример. договоры до 5 МБ хранятся в томах с версиями БСП, видеозаписи — в объектном хранилище, в ИБ остаются метаданные и контрольная сумма.

Комментарий интервьюера. спросите о согласованном backup, правах прямого доступа и восстановлении ссылки на отсутствующий объект.

Добавить append-only журнал с пользователем, временем, операцией, старым/новым значением и корреляцией; ограничить права изменения и выгружать в независимое хранилище. Криптографическую неизменность проектировать отдельно.

Практический пример. изменение банковского счёта пишет старое/новое значение, пользователя, основание и хеш в отдельный append-only журнал, копируемый во внешнюю SIEM.

Комментарий интервьюера. обычная таблица, доступная тому же администратору на изменение, не обеспечивает строгую неизменяемость.

Классифицировать правовое основание и сроки, отделить обязательные учётные записи, а необязательные данные удалить/анонимизировать во всех копиях и интеграциях. Нужен подтверждаемый процесс и аудит.

Практический пример. телефон клиента анонимизируется после срока, юридически обязательные суммы документов сохраняются, копии и поисковые индексы очищаются по тому же процессу.

Комментарий интервьюера. удаление поля в основной базе недостаточно — есть backup, файлы, обмены и журналы с разными основаниями хранения.

Обработчики порционные, идемпотентные и возобновляемые, с прогрессом и ограничением нагрузки; новые поля можно предварительно заполнить фоново до переключения. Миграцию измеряют на копии 5 ТБ.

Практический пример. миграция 5 ТБ сначала добавляет совместимое поле, неделями заполняет его порциями, затем переключает чтение и позже удаляет старое.

Комментарий интервьюера. одно окно простоя для полного преобразования должно быть доказано измерением или заменено этапной схемой.

Зафиксировать временную линию и сравнить метрики; при возможности откатывать/отключать по одному фактору на копии или canary. ТЖ, планы и release diff помогают локализовать слой.

Практический пример. feature flag отключает новый алгоритм, платформа и СУБД сравниваются на canary-копии, планы запросов сопоставляются с baseline до релиза.

Комментарий интервьюера. одновременный откат всех трёх компонентов не локализует причину; нужен контролируемый эксперимент.

Один регистр удобен при общих разрезах и транзакции; несколько — при разных жизненных циклах, запросах и частоте записи. Сравнить ширину итогов, связанность и стоимость согласования.

Практический пример. один регистр заказов с 20 необязательными измерениями заменён регистрами складского обеспечения и финансовых лимитов, связанными общей операцией.

Комментарий интервьюера. разделение уменьшает ширину, но добавляет риск рассогласования — кандидат должен описать атомарную границу.

Вынести, если нужна независимая масштабируемость, специализированная технология или отдельный владелец; оставить, если логика тесно транзакционно связана с данными 1С. Учитывать сеть и распределённую согласованность.

Практический пример. распознавание изображений вынесено в специализированный сервис, а резерв остатков оставлен в 1С из-за транзакционной близости к регистрам.

Комментарий интервьюера. модный стек не является причиной выноса; нужны нагрузка, компетенции, владение и стоимость сети.

SLA/объёмы, консистентность, доступность, RPO/RTO, безопасность, аудит, обновляемость, совместимость и бюджет эксплуатации. Каждое требование должно иметь метрику и владельца.

Практический пример. «p95 заказа ≤2 с при 100 rps, RPO 5 мин, RTO 1 ч, повтор не создаёт дубль, аудит хранится год».

Комментарий интервьюера. слова «быстро», «надёжно» и «безопасно» превращаются в архитектурные требования только после измеримой формулировки.

Транзакционная граница, блокировки и порядок ресурсов, запросы в цикле, массовость движений, повторное проведение, запрет периода, обработка ошибки и тесты.

Практический пример. в review реализации находят чтение остатка до блокировки, запись движений в цикле и отсутствие теста повторного проведения.

Комментарий интервьюера. попросите ранжировать три дефекта; гонка данных важнее косметической перестройки цикла.

Запрос/Выполнить() внутри Для каждого, получение объекта по каждой строке, серверный вызов в клиентском цикле. Статический анализ дополняют замером количества вызовов.

Практический пример. статический анализ видит Новый Запрос внутри Для каждого Строка, а ТЖ подтверждает 12 тысяч одинаковых выполнений.

Комментарий интервьюера. автоматическое правило должно допускать обоснованное исключение и показывать место пакетной альтернативы.

Контекстный вызов ради одного поля, вызов в цикле, повторное получение неизменных настроек, цепочка последовательных серверных процедур. Их объединяют в предметный пакетный метод.

Практический пример. ПриАктивизацииСтроки трижды вызывает сервер за ценой, остатком и резервом; один DTO возвращает все показатели разом.

Комментарий интервьюера. объединение не должно отдавать всю карточку товара на клиент — пакетный контракт остаётся минимальным.

Внутри транзакции есть HTTP, файлы, пользовательский диалог, большой цикл или вычисления, не влияющие на атомарность. Также признак — длительные ожидания при малом числе записей.

Практический пример. транзакция начинается до чтения Excel, продолжается HTTP-запросом и фиксируется через пять минут; атомарная запись занимает только последние 200 мс.

Комментарий интервьюера. кандидат должен вынести подготовку до транзакции, но повторно проверить данные после получения блокировки.

Каждый НачатьТранзакцию должен иметь гарантированную отмену в исключении и повтор ошибки; внешние эффекты — компенсацию/идемпотентность. Нельзя фиксировать частичный результат молча.

Практический пример. код отменяет транзакцию, логирует MessageId и повторно вызывает исключение; внешний файл перемещается в архив только после успешного коммита.

Комментарий интервьюера. спросите о сбое между коммитом и перемещением файла — требуется идемпотентный повтор импорта.

Методы, нужные только внутри подсистемы, не экспортируют. Особо ограничивают серверные и привилегированные функции, которые можно вызвать с клиента.

Практический пример. внутренняя функция расчёта хеша остаётся неэкспортной, наружу опубликован только метод ЗарегистрироватьСообщение с проверенным контрактом.

Комментарий интервьюера. каждый экспорт увеличивает связанность и, на сервере с вызовом клиента, поверхность доступа.

Обход прав увеличивает ущерб от ошибки входных данных. Проверяют минимальную область, отсутствие произвольного запроса/ссылки и журналирование критичной операции.

Практический пример. привилегированный метод принимает ссылку объекта и без проверки возвращает данные — review требует предметного параметра и явной авторизации.

Комментарий интервьюера. пометка модуля не должна автоматически распространяться на универсальные вспомогательные функции.

Разделить на логические этапы и временные таблицы, дать содержательные псевдонимы, убрать дубли и зафиксировать параметры. Затем проверить, не скрывает ли красота плохой план.

Практический пример. 500 строк запроса делят временными таблицами РазрешённыеТовары, Обороты, Результат, сохраняя возможность проверить каждый этап.

Комментарий интервьюера. структурирование не должно ухудшить план бесконтрольной материализацией; после рефакторинга нужен повторный замер.

Когда этап имеет самостоятельный смысл, повторно используется или изолирует агрегацию от соединений. Читаемость полезна, если стоимость материализации приемлема.

Практический пример. промежуточный расчёт партий используется в трёх последующих соединениях и получает собственный индекс, делая запрос понятнее и быстрее.

Комментарий интервьюера. если этап используется один раз и мал, временная таблица может добавить ненужную запись.

Несвязанные функции, множество причин изменения, циклические зависимости, смешение клиента/сервера и неясный API. Разделять по предметной ответственности и направлению зависимостей.

Практический пример. ОбщегоНазначенияПроекта содержит HTTP, зарплату, печать и товары; его разделяют на предметные сервисы с направленными зависимостями.

Комментарий интервьюера. размер файла — симптом, но главный критерий разделения — разные причины изменения и владельцы.

Высокоуровневая подсистема зависит от стабильного публичного интерфейса нижней, но не от её форм и служебных регистров. Циклические зависимости устраняют контрактом/событием.

Практический пример. продажи вызывают публичный интерфейс цен, но модуль цен не зависит от формы заказа; уведомление об изменении идёт событием без обратного импорта продаж.

Комментарий интервьюера. попросите нарисовать цикл зависимостей и показать, какой контракт его разрывает.

Сравнить заменяемый алгоритм с новым релизом, сохранить новые проверки поставщика, проверить сигнатуру и все выходы, иметь регрессионные тесты. &Вместо — высокий риск.

Практический пример. &Вместо старой процедуры не содержит новую проверку лимита поставщика; review сравнивает diff релиза и добавляет регрессионный сценарий.

Комментарий интервьюера. замена должна рассматриваться как владение всей логикой исходного метода на каждом обновлении.

Собрать объекты/изменения набором, использовать запрос и наборы записей, а массовые объекты обрабатывать порциями. Если запись объекта обязательна, контролировать число и транзакцию.

Практический пример. 20 тысяч объектов не записываются по одному: ссылки выбирают запросом, данные обновляют поддерживаемым наборным механизмом/порциями, события учитывают отдельно.

Комментарий интервьюера. массовая объектная запись иногда обязательна из-за поведения; кандидат должен назвать цену и ограничение параллельности.

Пользовательские сообщения должны быть понятны и не содержать стека; строки вынесены/локализуемы; число, дата и представления учитывают локаль. Техническая ошибка идёт в журнал с correlation id.

Практический пример. пользователю показывают «Не удалось провести заказ, код 7F3A», а журнал по коду содержит стек и технические параметры без токена.

Комментарий интервьюера. сообщение должно помогать действовать и не раскрывать SQL, файловые пути или персональные данные.

Назначение, параметры и типы, возвращаемое значение, исключения, контекст клиент/сервер, права, побочные эффекты, версия/стабильность и пример. Комментарий должен описывать контракт, не пересказывать код.

Практический пример. комментарий API описывает Заказ, Режим, возвращаемую структуру, возможные исключения, серверный контекст и отсутствие внешних эффектов.

Комментарий интервьюера. фраза «процедура получает заказ и выполняет обработку» пересказывает имя и не является контрактом.

Абстракция полезна при двух реальных одинаковых изменениях и стабильном общем контракте. Если объединение требует множества флагов и условностей, это преждевременное обобщение.

Практический пример. два реально одинаковых адаптера выделяют общий интерфейс; третий требует десять флагов, поэтому остаётся отдельным вместо «универсального» монстра.

Комментарий интервьюера. попросите назвать прогнозируемую причину совместного изменения, иначе переиспользование поверхностно.

Проверить идемпотентность, порции, ключи сопоставления, контрольные суммы, ошибки/повтор, производительность, права, резерв и откат. Особое внимание необратимым преобразованиям.

Практический пример. review миграции проверяет уникальный внешний ключ, повтор после 60%, сверку сумм, карантин ошибок и восстановление backup.

Комментарий интервьюера. корректный цикл на десяти строках не доказывает производительность и восстановимость на миллионах.

Новые/изменённые тяжёлые запросы, индексы и регистры, проведение, блокировки, массовые миграции, RLS, фоновые задания и интеграционные очереди.

Практический пример. добавление измерения остаточного регистра требует нагрузки проведения и пересчёта итогов, изменение текста сообщения — нет.

Комментарий интервьюера. решение о тесте строится по риску данных, плану и конкуренции, а не по числу изменённых строк кода.

Синтаксис, стандарты, запросы в цикле, небезопасные привилегированные вызовы, пустые исключения, лишние экспорты, применимость расширений и запуск тестов.

Практический пример. CI запрещает пустой Исключение, запрос в цикле и клиентский вызов привилегированного экспорта, но допускает оформленное исключение правила.

Комментарий интервьюера. автоматическая проверка должна иметь низкий шум, иначе команда научится игнорировать весь отчёт.

Сначала дефекты потери/утечки данных и безопасности, затем транзакции/отказы, производительность, сопровождаемость и стиль. Каждое замечание содержит сценарий ущерба и исправление.

Практический пример. P0 — утечка чужого договора, P1 — гонка остатков, P2 — запрос в цикле, P3 — имя переменной; review отражает порядок исправления.

Комментарий интервьюера. попросите сформулировать ущерб и воспроизводимый сценарий для первых двух замечаний.

Зафиксировать требования и критерии, собрать варианты, проверить неизвестное прототипом/замером и документировать решение с условиями пересмотра. Должность не заменяет доказательство.

Практический пример. спор о едином или двух регистрах решают ADR с критериями, прототипом на 100 млн движений и нагрузочным сравнением.

Комментарий интервьюера. лидерство проявляется в прозрачном процессе решения, а не в фразе «я архитектор, поэтому будет так».

ADR: контекст, решение, альтернативы, критерии, последствия, риски, дата и владельцы. Краткий документ связывают с задачей и кодом.

Практический пример. ADR фиксирует контекст резервов, выбранную управляемую блокировку, альтернативу очереди, последствия и условие пересмотра при 500 rps.

Комментарий интервьюера. документ без альтернатив и последствий превращается в протокол решения без объяснения.

Аналитик отвечает за процесс и критерии, разработчик — дизайн/реализацию, тестировщик — стратегию проверки; границы согласуют вместе. Не передавать дефект требований «по цепочке» молча.

Практический пример. аналитик определяет правило отмены, разработчик проектирует состояния и идемпотентность, тестировщик строит матрицу переходов; критерии согласуются совместно.

Комментарий интервьюера. границы ответственности не должны создавать ситуацию «это никто не проверял, потому что думал на другого».

Выбрать несколько автоматизируемых правил с высоким риском, объяснить пользу, включить в review/CI и дать период адаптации. Измерять дефекты и скорость, а не число наказаний.

Практический пример. команда сначала включает обязательную проверку транзакций и запросов в цикле, исправляет baseline, затем добавляет остальные правила.

Комментарий интервьюера. стандарт внедряют с инструментом и объяснением риска, а не сотней ручных требований за один день.

Дать конкретную обратную связь и влияние, согласовать обязательные правила и последствия, использовать сильные стороны. Если поведение не меняется, защищать команду через управленческое решение.

Практический пример. сильному разработчику показывают три повторных обхода review и влияние на релизы, согласуют обязательные правила и срок изменения поведения.

Комментарий интервьюера. техническая сила не компенсирует систематический риск для команды; лидер обязан защищать общий процесс.

Разобрать инвариант на конкурентном примере, вместе написать блокировку и тест двух сеансов, затем review реальной задачи. Проверить понимание через объяснение альтернатив.

Практический пример. Middle сначала воспроизводит гонку 10−7−7 в двух сеансах, затем вместе добавляет блокировку и пишет детерминированный тест.

Комментарий интервьюера. лекция без практики не подтверждает способность применить порядок блокировок в реальном проведении.

Закрепить владельцев за бизнес-контекстами и критичными компонентами, но требовать документацию и второго reviewer. Ownership — ответственность, не запрет другим изменять.

Практический пример. подсистема обмена имеет основного и резервного владельца, ADR и runbook; изменение критичного контракта требует review одного из них.

Комментарий интервьюера. ownership не должен превращаться в монополию, при которой отсутствие одного человека останавливает выпуск.

Регистрировать долг как риск с влиянием, стоимостью и триггером; приоритизировать рядом с продуктом. Погашать частями в затрагиваемых областях и измерять эффект.

Практический пример. долг «ручные повторы обмена» оценён в 20 часов поддержки/месяц и риск дублей; outbox включён в квартальный план с метрикой снижения инцидентов.

Комментарий интервьюера. карточка «переписать красиво» без бизнес-влияния закономерно проиграет продуктовым задачам.

Перевести в деньги/риски: вероятность инцидента, задержка релизов, простой и стоимость ручной работы. Предложить минимальный вариант и последствия отказа.

Практический пример. отсутствие индекса вызывает 30 минут блокировок закрытия и риск простоя 200 пользователей; исправление занимает два дня и нагрузочный тест.

Комментарий интервьюера. перевод в измеримый риск помогает бизнесу принять решение, не требуя разбираться в B-tree.

Оценить срочность и ущерб; быстрый fix сделать ограниченным и наблюдаемым, завести системное продолжение с владельцем. Не обещать рефакторинг без места в плане.

Практический пример. срочно ограничивают утечку feature flag и проверкой права, затем отдельной задачей упрощают модель RLS и добавляют тесты.

Комментарий интервьюера. системное продолжение должно иметь владельца и срок, иначе временный fix становится постоянной архитектурой.

Без поиска виноватого: влияние, временная шкала, технические и процессные причины, что помогло, действия с владельцами/сроками и проверка выполнения.

Практический пример. postmortem deadlock фиксирует таймлайн, разные порядки блокировки, отсутствие теста, исправление порядка и контроль выполнения через месяц.

Комментарий интервьюера. формулировка «разработчик ошибся» не является корневой причиной и не предотвращает повтор в другом модуле.

Полезны lead time, частота/надёжность релизов, дефекты и время восстановления; вредно оценивать людей строками кода или числом закрытых задач. Метрика не должна стимулировать обход цели.

Практический пример. команда отслеживает lead time, change failure rate и MTTR, но не сравнивает разработчиков по строкам кода и закрытым тикетам.

Комментарий интервьюера. спросите, какое нежелательное поведение стимулирует каждая предложенная метрика.

Разбить на рисковые вертикальные части, отдельно оценить исследование и миграцию, сравнить с аналогами и дать диапазон. Провести review оценки исполнителями.

Практический пример. миграцию делят на исследование качества, разработку правил, пробный прогон, дельту и переключение; каждый блок имеет диапазон и допущения.

Комментарий интервьюера. одна точная цифра для неизвестного качества данных должна вызвать вопрос о скрытом резерве или ложной уверенности.

Показать конкретный критерий риска и предложить canary, feature flag, перенос или откат. Если риск данных/безопасности не принят владельцем полномочий, эскалировать и зафиксировать.

Практический пример. нагрузочный тест не пройден, лидер предлагает canary на 5% и feature flag; при отказе бизнеса принять риск письменно останавливает полный rollout.

Комментарий интервьюера. важно увидеть безопасную альтернативу, а не только способность сказать «нет».

Документировать контракт и runbook, провести парное изменение и тренировочный инцидент, назначить второго владельца. Проверять передачу выполнением задачи без автора.

Практический пример. автор обмена пишет runbook, проводит парную доработку и учебное восстановление очереди; второй инженер затем самостоятельно дежурит.

Комментарий интервьюера. передача завершена, когда получатель выполняет задачу, а не когда файл документа отправлен в чат.

Честно назовите 3–4 приоритета и их порядок: содержание роли, команда, устойчивость продукта, формат и компенсация. Свяжите их с этапом карьеры, не говорите «важно всё».

Практический пример. «Сначала содержание роли и зрелость команды, затем формат и компенсация; готов обсуждать баланс после понимания ответственности».

Комментарий интервьюера. ответ должен быть честным и ранжированным; социально желательное «интересные задачи важнее всего» легко расходится с решениями кандидата.

Выберите предпочтение и поясните опыт, но покажите способность выполнять соседние задачи. Например: «Ближе продуктовая разработка, при этом эксплуатацию считаю частью ответственности».

Практический пример. «Предпочитаю продуктовую разработку с ответственностью за эксплуатацию; внедрение интересно там, где есть длительный владелец результата».

Комментарий интервьюера. спросите о задаче из менее любимого типа — зрелый кандидат не обесценивает необходимую поддержку.

Ответьте по рабочему стилю: крупный проект даёт архитектурную глубину, мелкие задачи — быстрый цикл. Можно предпочитать смешанный поток с ограничением переключений.

Практический пример. «Лучше один крупный контекст и ограниченный поток мелких production-задач; постоянные переключения между десятью клиентами снижают качество».

Комментарий интервьюера. ответ помогает проверить совместимость с реальным режимом компании, а не выставить оценку личности.

Нейтрально назвать изменение обстоятельств и позитивную цель: более широкая ответственность, инженерная культура, подходящие задачи. Не раскрывать лишнее и не очернять работодателя.

Практический пример. «Обстоятельства текущей работы изменились, поэтому ищу роль с более широкой технической ответственностью и зрелым процессом выпуска».

Комментарий интервьюера. не требуйте раскрытия личных деталей; проверяйте согласованность причины с ожиданиями от новой позиции.

Пример: чаще — архитектура, производительность, интеграции и mentoring; реже — бессистемные срочные правки без анализа. Подчеркнуть готовность поддерживать production.

Практический пример. «Хочу чаще заниматься архитектурой интеграций и производительностью, реже — срочными правками без диагностики, но production-поддержку считаю частью роли».

Комментарий интервьюера. хороший ответ не пытается отказаться от всей неприятной работы, а объясняет желаемый баланс и качество процесса.

Назовите наблюдаемое: ясные приоритеты, автономия в решении, доступный feedback и ранняя эскалация рисков. Избегайте требования полного отсутствия контроля или обратной связи.

Практический пример. «Мне подходят ясные приоритеты, автономия в реализации, еженедельная синхронизация и возможность быстро эскалировать риск».

Комментарий интервьюера. сопоставьте это с фактическим стилем руководителя; несовместимость лучше увидеть до оффера.

Senior превращает неопределённую задачу в проверяемый результат, учитывает данные, конкуренцию, безопасность и эксплуатацию, помогает команде и отвечает после релиза. Знания синтаксиса недостаточно.

Практический пример. Senior получает неясную задачу резерва, уточняет инварианты, проектирует блокировку, пишет тест, выпускает и отвечает за мониторинг после релиза.

Комментарий интервьюера. количество лет и знание методов платформы — лишь вход, а не достаточное определение уровня.

Прошу помощь, когда риск/неизвестность превышает разумное время исследования или нужен владелец предметной области. Прихожу с контекстом, проверенными гипотезами и конкретным вопросом.

Практический пример. после двух часов исследования незнакомого расчёта кандидат приносит схему, две проверенные гипотезы и конкретный вопрос методисту.

Комментарий интервьюера. ранняя содержательная помощь лучше недели молчания и лучше мгновенного перекладывания задачи без попытки разобраться.

Сначала уточняю риск и критерий; приношу документацию, тест или замер. При равноценных вариантах следую стандарту команды, существенный риск фиксирую и эскалирую техническому владельцу.

Практический пример. спор об индексе решается фактическим планом и нагрузкой; при равном результате команда следует принятому стандарту оформления метаданных.

Комментарий интервьюера. оцените способность изменить мнение по данным и сохранить рабочие отношения.

Используйте STAR: ситуация и различие целей, ваша задача, конкретные действия по согласованию фактов/вариантов, измеримый результат и вывод. Не изображайте вторую сторону некомпетентной.

Практический пример. аналитик требовал синхронную отправку, разработчик показал риск блокировки и предложил outbox; прототип подтвердил SLA и решение приняли совместно.

Комментарий интервьюера. сильная история содержит интересы второй стороны и конкретный результат, а не победу над «непонимающим заказчиком».

Сообщить сразу после подтверждения риска: выполнено, причина, новый диапазон, варианты сокращения объёма и влияние. Не ждать дня дедлайна и не давать новую точную дату без оснований.

Практический пример. на второй день обнаружена плохая НСИ; кандидат сообщает выполненное, новый диапазон 8–12 дней и варианты: очистить только критичные поля или перенести полный объём.

Комментарий интервьюера. раннее сообщение с вариантами ценнее позднего героического обещания «постараюсь успеть».

Назовите конкретную тему и практический план: например, диагностика PostgreSQL/ТЖ, автотесты или архитектура очередей; курс/лаборатория и применение на проекте. Связать с ролью.

Практический пример. «Хочу углубить PostgreSQL для 1С: пройти лабораторию планов, разобрать три production-запроса и внедрить checklist review».

Комментарий интервьюера. конкретный способ применения отличает реальный план развития от списка модных технологий.

Честные критерии: непрозрачная зона ответственности, отсутствие доступа к качеству/тестам при ответственности за результат, несогласованный формат, юридические или компенсационные условия.

Практический пример. кандидат откажется, если обязан отвечать за production без доступа к логам, тестовой среде и возможности остановить опасный релиз.

Комментарий интервьюера. критерии должны быть разумными и согласованными с уровнем ответственности, а не ультимативным списком удобств.

Указать формат, часы пересечения, предпочтительный письменный/устный канал, ритм синхронизаций и оборудование. Это проверка совместимости, а не поиск «правильного» ответа.

Практический пример. «Удалённо, пересечение 10–17 МСК, архитектурные решения письменно, короткие ежедневные синхронизации, отдельное время на глубокую работу».

Комментарий интервьюера. сравните ожидание с часовыми поясами и культурой команды до обсуждения деталей оффера.

Спросить архитектуру и нагрузку, процесс релиза/инцидентов, качество и тесты, обновления типовых, технический долг, ожидания первых 90 дней и почему открыта позиция.

Практический пример. кандидат спрашивает p95 и объём БД, долю типовой/самописной части, частоту релизов, тесты, ночные дежурства и критерии первых 90 дней.

Комментарий интервьюера. качество встречных вопросов показывает, умеет ли Senior оценивать среду, в которой будет отвечать за результат.