Недавнее собеседование по 1С стало для меня неожиданным опытом. Не потому, что вопросы были сложные, а потому что формат общения оказался максимально далеким от нормальной профессиональной дискуссии. Вместо разговора двух специалистов о процессах, задачах и решениях это превратилось в полуторачасовой поиск совпадения формулировок с методичкой. Интервьюер задавал вопросы так, как будто сам до конца их не понимал. Формулировки были размытыми, без привязки к конкретным кейсам или конфигурации. На попытку уточнить звучало не "я имел в виду вот это", а повторение вопроса теми же словами. В какой-то момент я поймала себя на том, что не понимаю не тему, а логики постановки вопросов. Это тот случай, когда профессионал пытается ответить, а перед ним как будто устный экзамен по билету "угадай, что у меня в голове". Самое показательное начиналось после ответов. Я говорю: "Вот так это настраивается, вот пример из практики". В ответ слышу: "Я ожидал услышать..." – и дальше человек своими словами пересказывает по сути то же самое, что я уже сказала. Добавляет пару маловажных деталей и подает это как "правильный" вариант. То есть совпадение по смыслу не засчитывается, важно было попасть в нужные слова. По ощущениям, меня гоняли не по аналитике и ERP, а по "правильному тексту из методички". Отдельный уровень абсурда – проверка BPMN. Вместо того чтобы взять реальную схему процесса (а у меня есть сложные, живые схемы из проектов), мы полчаса разбирали отдельные значки. Я несколько раз предлагала: "Давайте перейдем к конкретной схеме, и я покажу, как описываю процессы и как это потом ложится в ТЗ", но интереса к реальному опыту не было. Важнее стало, помню ли я точное название каждого элемента нотации, чем то, умею ли я вообще мыслить процессами и разговаривать с бизнесом на одном языке. Почему я об этом пишу. Такой формат собеседований вреден для всех. Он отсекает не тех, кто не умеет думать, а тех, кто не готов играть в игру "повтори за мной". Аналитику важно уметь разбираться в реальных кейсах, собирать требования, видеть риски, объяснять пользователям сложные вещи простым языком. Ни один из этих навыков не проверяется вопросами уровня "а как точно называется эта стрелочка в BPMN". Когда интервьюер оценивает не смысл, а совпадение формулировки, он по сути тестирует не компетенцию, а способность заучивать чужой текст. Кандидат в такой ситуации тоже многое видит. Если меня часами перебивают фразой "я ожидал услышать другое" вместо нормального диалога, я делаю выводы не о себе, а о культуре общения внутри компании. Если отказываются смотреть реальные схемы и ТЗ, зато цепляются к иконкам и терминам – это сигнал о том, что в работе важнее красивая отчетность, чем результат. И это уже повод задуматься, насколько мне вообще по пути с такой командой. Мне бы хотелось, чтобы в нашей сфере было больше адекватных собеседований. Где спрашивают: "Как вы настраивали взаиморасчеты в ERP? Как описывали процесс производства? Как решали конфликт между бухгалтерией и складом?". Где, если ответ по сути верный, интервьюер не придирается к словам, а уточняет детали и просит пример. Где BPMN и любые нотации – это инструмент описания живых процессов, а не повод устроить экзамен по картинкам. И, наверное, важное напоминание самим себе - если на собеседовании от вас требуют не смысла, а совпадения с методичкой – это не обязательно показатель вашей слабости. Иногда это просто способ собеседующего почувствовать себя "экспертом". В такой момент полезно задать себе вопрос: а хочу ли я потом годами доказывать этому человеку, что я что-то знаю, или лучше найти команду, с которой можно говорить по-взрослому – о задачах, процессах и результатах, а не о правильных словах.