Как провести собеседование с программистом 1С и оценить его квалификацию

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

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

Перед собеседованием зафиксируйте:

• Конфигурации и технологии. С какими системами предстоит работать: 1С, 1С: УХ, 1С: ЗУП, 1С: УТ или другими? Нужны ли знания БСП, СКД, HTTP-сервисов, расширений?
• Характер задач. Разработка нового функционала, доработка типовой конфигурации, поддержка существующей системы, интеграции или оптимизация производительности.
• Уровень самостоятельности. Будет ли специалист получать подробные технические задания или самостоятельно анализировать требования и проектировать решения?
• Особенности проекта. Количество пользователей, объём данных, степень доработки конфигурации, используемые инструменты командной разработки.

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

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

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

Для большинства разработчиков уровня Middle достаточно технического интервью продолжительностью 60−75 минут. Для Senior или Lead может потребоваться до 90 минут, особенно если нужно проверить навыки проектирования архитектуры.

Удобно разделить собеседование на шесть этапов. Такой формат позволяет проверить разные стороны квалификации и не превращать собеседование в экзамен на знание синтаксиса.

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

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

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

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

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

Выясните пять моментов:

1. Бизнес-задача. Какую проблему требовалось решить?
2. Личная ответственность. Что кандидат делал самостоятельно, а что выполняли другие участники команды?
3. Техническое решение. Какие механизмы платформы использовались и почему?
4. Сложности. Какие проблемы возникли и как удалось их устранить?
5. Результат. Как проверяли работоспособность решения и что изменилось после внедрения?

Например, кандидат рассказывает, что занимался оптимизацией 1С. Уточните, какие операции работали медленно, как он определил причину, что изменил и как измерил результат. Сильный разработчик обычно может объяснить последовательность своих действий, назвать ограничения и обосновать технические решения. Если же кандидат ограничивается формулировками «оптимизировал базу», «дорабатывал ERP», «участвовал в интеграциях» и не может раскрыть подробности собственной работы, заявленный опыт стоит проверить практическим заданием.

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

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

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

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

Необязательно просить разработчика написать полноценную обработку. За 15−20 минут можно проверить несколько важных навыков на небольшом примере.

Пример задания: оптимизация медленной обработки

Исходная ситуация.

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

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

Задача кандидата: разобраться в возможных причинах замедления и предложить способ оптимизации.

На выполнение выделяется 20 минут.

Первые 5 минут — анализ задачи.

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

Следующие 10 минут — техническое решение.

Попросите предложить конкретные изменения.

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

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

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

Последние 5 минут — проверка результата.

Спросите, как разработчик убедится, что обработка стала работать быстрее и сохранила корректность данных.

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

Обратите внимание на четыре критерия:

1. Анализ проблемы. Кандидат сначала уточняет условия или сразу предлагает переписать код?
2. Техническое решение. Может ли предложить конкретные изменения и объяснить их?
3. Учёт ограничений. Понимает ли влияние алгоритма на производительность и другие части системы?
4. Проверка результата. Предусматривает ли тестирование и сравнение показателей?

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

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

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

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

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

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

Каждый критерий оценивается по шкале от 0 до 4:

• 0 — навыки не продемонстрированы;
• 1 — знания поверхностные, требуется постоянная помощь;
• 2 — справляется с типовыми задачами, сложные решает с поддержкой;
• 3 — самостоятельно выполняет задачи ожидаемого уровня;
• 4 — уверенно решает сложные задачи, учитывает ограничения и может объяснить выбор решения.

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

Например, за технические знания кандидат получил 3 из 4 баллов. При максимальном весе критерия 20 баллов результат составит 15 баллов.

После оценки всех критериев баллы суммируются.

Это пример внутренней методики оценки, а не универсальный стандарт квалификации разработчиков 1С.

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

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

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

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

Например:

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

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

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

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

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

Например, при подключении разработчиков 1С через Devcom можно предварительно проверить квалификацию специалистов, а затем провести дополнительное интервью на соответствие требованиям конкретного проекта.

Хорошее собеседование программиста 1С должно показать, какие задачи кандидат решал самостоятельно, насколько хорошо владеет необходимыми технологиями и сможет ли эффективно работать на вашем проекте.

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

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