Часть 2: об оценке кандидата, тестовых заданиях, принятии решения.
Профессиональные навыки (hard skills)
Это способность к применению своих знаний и опыта на практике. Можно сколь угодно долго читать профессиональную литературу или сидеть на форумах, но в нашем деле практика всегда будет на первом месте. Поэтому так хочется послушать о ваших достижениях, пусть даже скромных. Вспомните 3-4 последних задачи, проблемы, которые удалось решить. Держите их наготове, чтобы не вспоминать с мучениями, что я делал в прошлом месяце, кроме нудной правки десятка печатных форм и добавления реквизита "Комментарий" в документ. Я утрирую, но суть вы поняли :)
Несколько тем навскидку:
- новая подсистема или выделенная функциональность. Например, учет техники сотрудников;
- оптимизация работы сложного запроса. Было - 1 мин, стало 2 сек;
- минимизация времени открытия формы, сокращение числа серверных вызовов: какими способами и насколько стало быстрее;
- применение новых фишек платформы: например, системы взаимодействия;
- мобильные приложения или мобильный клиент.
То есть это интересные вам задачи, выполненные в "потоке". Мы готовы послушать детали. Только без фанатизма, не нужно рассказывать какие справочники и реквизиты были добавлены.
Устные вопросы
Отлично помню заданные мне алгоритмические задачи при приеме на работу во франчайзи. Те самые, из разряда "построй снежинку" или "опиши сгибы полоски бумаги". Для разработчика самого начального уровня - вещь полезная. Вносят некоторую ясность, сможет ли кандидат принести хоть какую-то пользу компании. На позицию выше джуниора таких задач не встречал.
Поэтому значимыми считаю вопросы практического характера, непосредственные связанные с 1С. Примеры таких вопросов:
- назначение и особенность индексов таблиц;
- способ запроса данных на конкретном примере;
- клиент-серверное взаимодействие.
Данные знания приходят с опытом. Это паттерны нашей области. При этом ответ можно изложить устно.
К вопросам вида "расскажите корректный способ записи движения документов в УТ" я отношусь негативно.
Это знания более высокого уровня, которые всегда можно подсмотреть и которые не нужны каждый день, здесь и сейчас.
Усложняя или упрощая вопросы, можно прояснить ваши навыки. На таких вопросах рекомендую не молчать. Если вы подзабыли или плохо знаете тему, изложите свое понимание. Если познаний совсем нет, то будьте честны. Это не школьный урок, а беседа.
Личностные качества (soft skills)
Это ваша способность "жить среди людей".
Здесь не так много критериев оценки и они у всех почти одинаковы. Сколько бы ни было опыта в собеседованиях, это тот случай, когда две головы лучше, чем одна. Поэтому и появляются на собеседовании коллеги или "специально приглашенные эксперты", которые для галочки могут задать наивный вопрос. По сути, это наблюдатели за вашим поведением. Надеюсь, для опытных разработчиков я не открыл нового :)
Коммуникации
Это способность к взаимодействию с окружающим. Умение найти золотую середину между своими задачами и потребностями окружающих. Отсутствие таковой способности проявляется обычно в нежелании отвечать за результат и постоянном стремлении перевести ответственность на соседа.
Что-то я слишком умно написал. Проще: речь о токсичности. У каждого из вас был/есть/будет такой человек, которого избегаете, но вынуждены работать вместе. И мы меньше всего хотим получить такого человека в команду. Это заразная вещь, которую нужно пресекать.
К сожалению, в рамках собеседования токсичность выявить почти нереально. Можно задавать вопросы о командной работе, но все "добрые и отзывчивые" ровно до боевых условий.
Творчество и результат
Разработка предполагает долю творчества. Но есть готовые шаблоны (паттерны), которым можно и нужно следовать. Иногда возникают попытки изобрести велосипед. Яркие примеры:
- загрузка простейшего файла Excel с фиксированной структурой через навороченную обработку с настройкой соответствия полей и поиска;
- создание цепочки документов для отправки электронного письма (рассылка).
Поэтому при рассказе о ваших достижения старайтесь избегать подобных творений. Лучше вспомните то, что действительно упростило работу пользователей.
Вначале я брал таких гениев. С упоением рассказывающих про написание драйвера для сканера отпечатков или систему распознавания лиц. У меня аж слезы умиления появлялись).
Дело заканчивалось отказом от реальных задач в пользу косвенных, малозначимых, но интересных сотруднику. "У вас все не так работает, сейчас я вам систему сбора заявок и драйвер запилю, там работы на неделю". В итоге, не было никакой системы или драйвера, выяснялось, что систему распознавания лиц он писал "на попробовать" и она немного не доработана.
Еще раз: конечная цель разработки - пользователь решает свою проблему с наименьшими усилиями. Ему без разницы как там у вас все устроено.
Самостоятельность
Это то самое качество, которое джуниору открывает путь выше. И которое можно и нужно развивать.
"Самая сложная вещь на свете - думать своей собственной головой". Идеальный разработчик - получил задачу, сформировал ключевые вопросы, получил ответы, написал базу, сформировал еще набор вопросов, получил ответы, дописал код, профит.
Вы должны понимать, что нам не нужен сотрудник, который будет в панике вопрошать, что делать. Или, что еще хуже, молча сидеть и ждать ответа на свои вопросы. Нужен человек, который в состоянии докопаться до истины, приобретя при этом опыт. Да, будет помощь от более продвинутых коллег, но двигаться вперед нужно самому.
Примеры кода
Являются обязательным элементом вашей оценки. Это не значит, что нужно быть готовым показать свой код прямо на собеседовании. Но нужно иметь его под рукой, чтобы отправить в этот же день.
Многие скажут, что кандидат может выдать чужой код за свой. Пока с таким не сталкивался по двум причинам:
- всегда будут неизбежные вопросы по коду;
- ложь все равно вскроется (не сможет джуниор выдать себя за мидла и потом кодить как мидл).
Качество кода оценивается с позиций его читаемости и применения механик платформы. Упрощенные примеры:
- общий модуль - разбиение на отдельные методы по ответственности;
- форма - клиент-серверное взаимодействие.
Это та область, где вполне четко можно оценить ваши способности.
Из этого следует пара простых выводов:
- имейте наготове свой лучший и свежий код, в идеале - соответствующий стандартам разработки 1С и общепринятым канонам программирования;
- сохраняйте части (!) рабочего кода.
В некоторых организациях, есть жесткие ограничения по доступу к кодовой базе.
Я ни коей мере не призываю вас копировать на работе продуктивные базы и пусть даже конфигурации.
Достаточно части общего модуля с десятком методов и части кода формы (даже в текстовом файле). Именно реальный, а не тестовый код дает представление о ваших талантах.
Я впадаю в ступор, когда разработчик с 3-летним стажем заявляет об отсутствии примеров кода. И такие случае не являются редкими. Хорошо, у тебя на работе тотальный контроль и запреты. Но неужели за 3 года ты не пробовал сделать что-то самостоятельно? Где портфолио?
Тестовые задания
Они должны быть, если:
- есть сомнения по качеству кода соискателя;
- примеров кода нет вовсе или их мало.
Содержание тестовых заданий предполагает оперативное решение и не должно быть узкоспециализированным. Если вам предлагают написать дополнительный отчет в УТ или создать http-сервис по определенному описанию, то это долго. Максимальное приемлемое время - это полдня.
Есть другая крайность - абстрактное тестовое задание. Это то, что в принципе не используется на практике. Те самые сортировки массивов 3 способами или рисование снежинки.
Место и время решения задания (дают его вам решить прямо здесь и сейчас, либо есть время на подумать дома) не влияет на его оценку. Нужно не просто его решить, а пояснить подход.
Именно поэтому считаю, что задания должны допускать вариативность, иметь несколько "красивых" решений. И спор с собеседующим по поводу правильности дает дополнительные очки.
Один из вариантов заданий - ревью кода. В этом случае рекомендую не описывать дотошно все ошибки, а указать ключевые ошибки, еще лучше - способы исправления.
Дополнительные встречи
Если вас пригласили на встретится повторно, то шансы получить работу заметно выросли. Вариант, когда вас зовут, чтобы огласить, что вы хороший человек, но не приняты, я не рассматриваю (хотя о прецедентах слышал).
Причина таких дополнительных встреч (обычно еще одна-две): пообщаться на непрофессиональные темы, понять ваше отношение к командной работе и способу достижения цели, часто - вашу мотивацию. Бывали забавные эпизоды, когда кандидаты открыто заявляли, что их и сейчас неплохо кормят, но "у вас ближе к дому" или "хочу поработать налегке". Мы не хотим, чтобы из-за оговоренных мелочей или недопонимания потом пришлось расстаться. Яркий пример моей ошибки: нанятый разработчик буквально воспринял удаленку и работал ночью, а днем уходил поспать на 2-3 часа или не работал вовсе.
Принятие решения
Итак, вы прошли пару собеседований, показали примеры кода, выполнили тестовое задание. И, в целом, условия вас устраивают. Варианты развития событий:
- Вас не хотят нанять.
Основной признак, если не говорят сразу - это затягивание сроков принятия решения. Фраза "Это от меня не зависит, мне нужно обсудить и через пару недель вернусь с ответом" должна быть сигналом к продолжению поиска. Даже если вам ответят положительно позже, остается догадываться об организации работы компании/качествах вашего будущего руководителя.
- Вас готовы взять.
Так как мы рассматриваем крупную компанию, то есть свои особенности. Предварительное решение огласят сразу, а потом пройдет 1-2 недели (бывает и дольше) предварительной подготовки. Как минимум:
- согласование департаментом безопасности;
Если на вас было/есть дело (просто задолжали, например, государству или является злостным неплательщиком алиментов), вероятность трудоустройства падает до нуля. На моей памяти был случай, когда кандидат задолжал налогов на пару сотен тысяч рублей, будучи ИП. Его настойчиво рекомендовали не брать.
- сбор рекомендаций от текущего работодателя;
- составление и согласование джоб-оффера.
Джоб-оффер
Немного о джоб-оффере. Ключевой момент: никто никому не обязан до подписания трудового договора. Джоб-оффер не имеет никакой юридической силы. Но уверяю вас, случаев, когда работодатель идет в отказ при подписанном джоб-оффере - очень мало (по крайней мере в крупных компаниях). А ситуаций, когда кандидат соскакивает при подписанном джоб-оффере, причем в день выхода :((( - полно. Поэтому воспринимайте его просто как гарантию работодателя, это его репутация. О том, что думает о вас работодатель, когда не явились в день выхода, написать не могу, слишком ругательно.
Кандидатам: внимательно читайте условия, прописанные в джоб-оффере. Особенно в части премии (если таковая есть). Уточняйте все, что вам неясно. Лучше перепонять, чем недопонять.