Вопросы для собеседования программиста 1С

Что хотим услышать

• Тонкий и веб-клиент не имеют доступа к базе, только к данным формы
• Работа с базой, запросы и объекты только на сервере
• Каждый серверный вызов это сетевой обмен, их минимизируют
• Директивы задают контекст исполнения
• Без контекста быстрее: не передаются данные формы

Если ответил, копните глубже

Что хотим услышать

• WHERE фильтрует строки до группировки, HAVING фильтрует группы после
• В WHERE нельзя агрегаты, в HAVING можно
• Порядок: FROM, WHERE, GROUP BY, HAVING, SELECT
• Условия без агрегатов лучше писать в WHERE: меньше строк до группировки
• Пример: WHERE status = 'paid' и HAVING SUM(total) > 10000

Если ответил, копните глубже

Что хотим услышать

• Две-три стороны, а не список из десяти
• Каждая подкреплена примером
• Стороны связаны с вакансией
• Нет пустых слов вроде «стрессоустойчивый, коммуникабельный» без доказательств
• Уверенно, без хвастовства

Если ответил, копните глубже

Что хотим услышать

• Каждое обращение к реквизиту ссылки читает объект целиком
• В цикле это тысячи отдельных обращений к базе
• Переписать одним запросом со всеми нужными полями
• Для одиночных случаев функции БСП ЗначениеРеквизитаОбъекта
• Сначала замерить, чтобы убедиться, что проблема здесь

Если ответил, копните глубже

Что хотим услышать

• INNER: только пары, где условие ON истинно
• LEFT/RIGHT: все строки одной стороны, у недостающей стороны NULL
• FULL: все строки обеих сторон
• CROSS: декартово произведение, N × M строк
• Связь один ко многим размножает строки «одной» стороны, два таких JOIN перемножают
• Строки с NULL в ключе не соединяются: NULL = NULL не true

Если ответил, копните глубже

Что хотим услышать

• Назвал реальную слабость, а не штамп
• Слабость не критична для роли
• Рассказал, что делает, чтобы её компенсировать
• Есть пример прогресса
• Коротко, без самобичевания

Если ответил, копните глубже

Что хотим услышать

• Справочник хранит условно-постоянную информацию: товары, склады, контрагенты
• Документ фиксирует хозяйственное событие с датой: приход, продажа
• Регистр хранит данные в разрезе измерений для быстрого получения итогов
• Документ при проведении делает движения по регистрам
• Отчёты строятся по регистрам, а не по документам

Если ответил, копните глубже

Что хотим услышать

• Один запрос за списком и по запросу на каждый элемент за связанными данными
• Типично возникает из-за ленивой загрузки в ORM в цикле
• Заметить: число запросов растёт с размером списка, логи SQL, APM, счётчик запросов в тестах
• Исправить: JOIN, запрос по списку id (IN или ANY), eager loading, DataLoader в GraphQL
• Следить, чтобы JOIN не размножил строки и не тянул лишнее

Если ответил, копните глубже

Что хотим услышать

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

Если ответил, копните глубже

Что хотим услышать

• NULL означает «значение неизвестно», а не ноль и не пустую строку
• Сравнение с NULL через = или <> даёт unknown, WHERE такие строки отбрасывает; проверка через IS NULL
• NOT IN со списком или подзапросом, где есть NULL, возвращает пустой результат
• Агрегаты кроме COUNT(*) игнорируют NULL, SUM на пустом наборе даёт NULL
• COALESCE подставляет значение по умолчанию, IS DISTINCT FROM сравнивает с учётом NULL

Если ответил, копните глубже

Что хотим услышать

• Все агрегаты, кроме COUNT(*), пропускают NULL
• AVG делит на число непустых значений, а не на число строк
• SUM, AVG, MIN, MAX на пустом наборе дают NULL, COUNT даёт 0
• COUNT(*) после LEFT JOIN считает строку с NULL, нужен COUNT(правая.id)
• COALESCE для подстановки нуля там, где этого требует смысл

Если ответил, копните глубже

Что хотим услышать

• Замер: сколько серверных вызовов и данных на одно действие
• Пересчёт суммы строки на клиенте, без сервера
• Серверные вызовы без контекста и с минимальными параметрами
• Объединение нескольких вызовов в один
• Кеширование справочных данных на клиенте или в модуле с повторным использованием
• Проверка на медленном канале и в веб-клиенте

Если ответил, копните глубже

Что хотим услышать

• UPDATE создаёт новую версию строки, старая остаётся с xmax; DELETE только помечает версию
• Каждая транзакция видит версии по своему снимку, поэтому чтение не блокирует запись и наоборот
• VACUUM удаляет версии, которые уже никому не видны, обновляет visibility map и замораживает старые строки
• Долгие транзакции и забытые слоты репликации мешают очистке и раздувают таблицы
• Autovacuum настраивают по таблицам: autovacuum_vacuum_scale_factor, лимиты стоимости; мониторинг через pg_stat_user_tables
• HOT-обновления и fillfactor уменьшают нагрузку на индексы

Если ответил, копните глубже

Что хотим услышать

• Назван масштаб: команда, нагрузка, пользователи или деньги
• Есть решения, которые повлияли дальше своего кода
• Есть метрики результата
• Упомянуто влияние на команду: менторинг, процессы, ревью
• Уложился в 2 минуты, не утонул в деталях

Если ответил, копните глубже

Что хотим услышать

• Политика: основная конфигурация на поддержке, доработки в расширениях
• Несколько расширений по областям, с владельцами
• EDT и Git, ревью кода, стандарты 1С, проверка кода
• Автотесты ключевых сценариев (Vanessa Automation, YAxUnit)
• Регулярные обновления типовой на тестовом контуре
• Реестр доработок с обоснованием и стоимостью поддержки

Если ответил, копните глубже

Что хотим услышать

• Deadlock это цикл ожидания: транзакции держат блокировки и ждут друг друга
• PostgreSQL проверяет цикл после deadlock_timeout (1 с по умолчанию) и откатывает одну из транзакций с ошибкой 40P01
• В логе есть оба запроса и тип блокировок; включаю log_lock_waits для долгих ожиданий
• Главное лечение: единый порядок взятия блокировок, короткие транзакции, блокировка заранее через SELECT ... FOR UPDATE в порядке ключа
• Приложение должно уметь повторять транзакцию при 40P01 и 40001

Если ответил, копните глубже

Что хотим услышать

• Акцент на масштаб и влияние, а не на список фич
• Метрики бизнес-эффекта
• Лидерство: менторинг, процессы, архитектурные решения
• Компактность: старый опыт свёрнут
• Понимание, что резюме под роль, а не под всё сразу

Если ответил, копните глубже

Что хотим услышать

• Замер: где время, сервер или передача данных
• Не тащить на клиент лишнее: реквизиты формы, скрытые колонки, вычисляемые поля одним запросом
• Пересчёты строк на клиенте, без серверного вызова на каждое изменение
• Тяжёлые данные подгружать по требованию
• Условное оформление вместо программной раскраски строк
• Рассмотреть другой интерфейс: подбор, фильтры, разбиение документа

Если ответил, копните глубже

Что хотим услышать

• Индекс работает по левому префиксу: ведущие колонки должны быть в условии
• Сначала колонки с равенством, затем одна колонка с диапазоном или сортировкой
• После колонки с диапазоном следующие колонки для поиска уже не помогают
• Для примера: (tenant_id, status, created_at) закрывает и фильтр, и ORDER BY
• Учитывать, какие ещё запросы обслужит индекс, чтобы не плодить похожие
• Проверять на реальных данных через EXPLAIN ANALYZE

Если ответил, копните глубже

Что хотим услышать

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

Если ответил, копните глубже

Что хотим услышать

• Один DELETE на 300 млн плох: долгая транзакция, огромный WAL, лаг реплик, мёртвые строки
• Удалять пачками по ключу (например, по 10 тыс. id) с паузами и отдельными транзакциями
• Следить за лагом реплик и работой autovacuum во время чистки
• Если удалить надо больше, чем остаётся, быстрее скопировать нужное в новую таблицу и переключиться
• На будущее: партиционирование по времени и удаление партиций целиком

Если ответил, копните глубже

Что хотим услышать

• Технологический журнал: события TLOCK, TTIMEOUT, TDEADLOCK, кто держит и кто ждёт
• Найти «виновника»: длинные транзакции, регламентные задания, обмены
• Проверить избыточные блокировки: всей таблицы, лишние измерения
• Сократить транзакции: внешние вызовы и тяжёлые вычисления вынести
• Перенести тяжёлые задания на ночь, мониторинг ЦУП

Если ответил, копните глубже

Что хотим услышать

• B-tree по умолчанию: равенство, диапазоны, сортировка, уникальность, LIKE 'abc%'
• GIN для составных значений: jsonb, массивы, полнотекстовый поиск, pg_trgm для поиска по подстроке
• GiST для диапазонов, геометрии, ближайших соседей и exclusion-ограничений
• BRIN для огромных таблиц с корреляцией значения и физического порядка
• Частичные, по выражению и покрывающие (INCLUDE) индексы как способы сузить и ускорить
• Каждый индекс замедляет запись и мешает HOT-обновлениям, неиспользуемые находят по pg_stat_user_indexes

Если ответил, копните глубже