Вопросы на собеседовании 1С-разработчика

Пример сильного ответа

Главное отличие — 1С работает не с физическими таблицами, а с объектами метаданных, и запрос только читает данные: ни изменения, ни создания структур внутри языка нет. Обращение к реквизитам идёт через точку, ссылочные поля раскрываются неявными соединениями. Подзапрос в предложении ИЗ платформа не поддерживает — вместо него применяю временные таблицы. Нет хранимых процедур и представлений, индексы описываются в метаданных, а не в запросе. Результат — таблица значений. Ограничения обхожу так: разбиваю логику на несколько пакетов, помещаю промежуточные наборы во временные таблицы и индексирую их. На практике такое разбиение в отчёте по крупному регистру дало ускорение примерно в пять раз.

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

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

Пример сильного ответа

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

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

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

Пример сильного ответа

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

• Видно понимание, что обороты хранят движения
• Причины и решения названы по порядку
• Цифра подтверждает реальный опыт

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

Пример сильного ответа

На практике применяю набор простых правил. Первое — максимально сужаю выборку на входе: период, отборы через параметры виртуальных таблиц, только нужные поля вместо всех. Второе — убираю неявные соединения через точку в условиях и вместо подзапросов использую временные таблицы с индексированием по полям соединения. Третье — агрегаты фильтрую в ИМЕЮЩИЕ, а не в ГДЕ. Четвёртое — проверяю индексы в метаданных регистров. Пятое — измеряю, а не угадываю: замеры до и после, план запроса, отчёт по производительности. На одном типовом отчёте такой порядок действий дал ускорение примерно в семь раз, а закрытие месяца на участке сократилось на треть.

• Системный список приёмов, а не один совет
• Есть акцент на замерах до и после
• Цифры показывают эффект на практике

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

Пример сильного ответа

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

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

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

Пример сильного ответа

Главное — дата во встроенном языке хранит и время, и при сравнении это учитывается. Поэтому границы периода задаю полуинтервалом: больше или равно началу периода и строго меньше начала следующего дня, иначе записи за последние часы просто выпадают из отчёта. В запросах удобнее использовать НАЧАЛОПЕРИОДА и КОНЕЦПЕРИОДА, а в СКД — параметры с типом СтандартныйПериод. Ещё учитываю пустую дату и то, что часовой пояс сеанса может отличаться от пояса пользователя, поэтому границы считаю на сервере.

• Названа типичная ошибка с границей периода
• Показаны инструменты языка и СКД
• Упомянут часовой пояс — признак реального опыта

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

Пример сильного ответа

Обычная форма ближе к оконному описанию, логика там во многом живёт на клиенте, а платформа самостоятельно синхронизирует данные с базой. Управляемая форма строится декларативно, серверная и клиентская части разделены, обмен идёт явными вызовами. Отсюда директивы: код с &НаКлиенте выполняется у пользователя и не видит данные напрямую; &НаСервере выполняется на сервере, видит реквизиты формы, но требует передачи контекста; &НаСервереБезКонтекста работает без доступа к данным формы, поэтому быстрее и кэшируется — применяю его для справочных вычислений и выборок по параметрам.

• Сравнение идёт от архитектуры, а не от синтаксиса
• Директивы объяснены через контекст и производительность
• Видно понимание, когда какой вариант уместен

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

Пример сильного ответа

Использую расширение конфигурации: оно подключается поверх типовой и не меняет саму поставку, поэтому обновления проходят штатно. В расширении заимствую объект или создаю новый, добавляю реквизит через панель реквизитов, размещаю его на форме, рядом создаю команду и кнопку, привязывая их к процедуре-обработчику. Логику штатных процедур дополняю аннотациями &Вместо и &После, чтобы не дублировать типовой код. На одном из внедрений так закрылось около 20 доработок, и обновления перестали требовать ручного разбора.

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

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

Пример сильного ответа

Основной опыт — УТ: доработка документов продажи и закупки, печатные формы, обмены, отчёты на СКД, интеграция с сайтом через HTTP-сервисы. В ERP сталкиваюсь с более тяжёлым контуром, там доработки касались закупок и согласования, поэтому особенно внимательно отношусь к производительности запросов и к тому, чтобы расширения не мешали обновлениям. В ЗУП моя задача — расчёты, отчётность и печатные формы. Самая крупная система в моей практике — около 400 пользователей, и большая часть доработок сделана расширениями.

• Показан опыт сразу в трёх типовых конфигурациях
• Конкретика по объектам доработки, а не общие слова
• Есть масштаб системы — понятен уровень задач

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

Пример сильного ответа

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

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

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

Пример сильного ответа

Моя задача — связывать 1С с внешними системами: сайтом, CRM и логистикой. В зависимости от требований использую разные способы. Для онлайн-обмена — HTTP-сервисы и REST API: настраиваю авторизацию, JSON, обработку ошибок. Для больших объёмов — обмен через файлы и регламентные задания, иногда планы обмена. Если важна надёжность, подключаю очереди и повторные попытки. В одном проекте у меня было 5 систем: время обмена заказами сократилось с 20 минут до 2, количество ошибок упало. Главное — продумать формат, мониторинг и логирование.

• Показаны разные способы интеграции: API, файлы, очереди.
• Есть конкретные цифры: 5 систем, сокращение с 20 до 2 минут.
• Акцент на надёжности и мониторинге — важно для продакшена.

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

Пример сильного ответа

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

• Показан безопасный порядок действий через копию базы
• Упомянуто расширение как способ изоляции доработок
• Есть результат по времени и наличие плана отката

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

Пример сильного ответа

Автоматические блокировки платформа ставит самостоятельно на уровне СУБД, ими сложнее управлять, возможна эскалация и рост взаимоблокировок при конкуренции. Управляемые задаются в коде явно и обрабатываются менеджером блокировок: можно ограничиться нужными объектами и не эскалировать. Управляемый режим включаю там, где важна предсказуемость: массовые операции, одновременная работа многих пользователей, критичные участки с остатками и взаиморасчётами. Мне приходилось разбирать зависания на проведении документов: после аккуратной расстановки управляемых блокировок и сокращения длительности транзакций число конфликтов снизилось примерно на 70%.

• Чётко разделены два режима по механике
• Объяснено, когда именно нужен управляемый режим
• Есть измеримый эффект после оптимизации

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

Пример сильного ответа

Три уровня дополняют друг друга. Роли дают права на объекты и интерфейс, это базовый слой. RLS ограничивает видимость на уровне записей: через шаблоны и пользовательские параметры настраивается доступ по организации, подразделению или ответственному. Профили групп доступа объединяют роли в понятные наборы и назначаются пользователям, обычно по шаблону БСП, а сами пользователи попадают в группы. Я иду от должностей и реальных сценариев работы, а не от удобства администрирования. В одной базе удалось свести набор к шести профилям вместо россыпи ролей, и число обращений в поддержку по правам доступа заметно уменьшилось.

• Показана связь трёх механизмов между собой
• Логика идёт от должностей, а не от настроек
• Есть результат: шесть профилей и меньше обращений

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

Пример сильного ответа

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

• Перечислены конкретные инструменты, а не общие слова
• Есть пример из практики с измеримым результатом
• Видно системный подход: воспроизведение и автотесты

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

Пример сильного ответа

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

• Чёткий критерий выбора вместо заучивания
• Учтены итоги, срез и подчинённость регистратору
• Есть результат с числом из своей практики

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

Пример сильного ответа

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

• Сразу названы диагностика и порядок действий
• Решена и проблема блокировки пользователей
• Сильный результат: время сокращено кратно

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

Пример сильного ответа

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

• Сначала восстановление, потом разбор причин
• Предложено правильное решение — расширения
• Есть цифра, показывающая эффект подхода

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

Пример сильного ответа

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

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

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

Пример сильного ответа

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

• Есть конкретная задача, решение и измеримый результат
• Показано бережное отношение к типовым механизмам
• Упомянут этап проектирования, а не только код

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

Пример сильного ответа

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

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

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

Пример сильного ответа

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

• Есть ситуация, действие и результат с цифрами
• Показана работа с последствиями, а не поиск виноватых
• Сделан вывод в виде预防 мер — автотесты

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

Пример сильного ответа

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

• Фокус на бизнес-задаче, а не на формулировке пользователя
• Прототип снижает риск недопонимания
• Есть метрика по потоку обращений

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