Как-то раз получил я письмо с предложением рассмотреть вакансию на программиста 1С и выполнить тестовое задание, чтобы подтвердить свои навыки программирования. Вакансия меня заинтересовала и я согласился. В тот же день мне пришло описание тестовой задачи с предупреждением о максимально допустимом сроке выполнения в 2 дня с момента получения и предложением задавать вопросы, если они появятся. Был вечер пятницы и я решил, что это отличная возможность.
И вот в субботу утром я принялся за дело, отлично понимая, что я могу потратить весь день или даже оба выходных, но игра стоила свеч. Немного смущало само задание. Оно было довольно таки объёмным, но при этом с очень поверхностным описанием требуемого функционала. Речь шла о реализации конфигурации с нуля, но требования к возможностям этой конфигурации ограничивались составом обязательных реквизитов документов и обрывками общих фраз касательно работы подсистем учёта. Впрочем, обещанная в вакансии заработная плата соответствовала программисту высокого уровня. А грамотные специалисты из скудных слов заказчика должны быть способны понять, что требуется и как это реализовать. Задавать вопросы по заданию мне показалось делом недостойным специалиста, к тому же шли выходные и ответы могли и не прийти до начала рабочей недели. Поэтому в местах, по которым у меня были сомнения, я старался сделать функционал более гибким за счёт добавления настроек.
В воскресенье вечером вместе с сопроводительным письмом я отправил на проверку готовое решение задания в виде базы данных (конфигурация написана на 8.3.20), заполненной сгенерированными автоматически случайными данными, обработку генерации этих самых данных отправил тоже. По условиям задания я должен был также предоставить сценарий тестирования, следуя которому проверяющий мог бы убедиться в правильности выполнения задания. Понимая, что составление такого сценария займёт немало времени, а срок выполнения задания истекает, я решил отправить сценарий тестирования уже на следующий день, о чём уведомил в письме с решением. Представитель работодателя был не против.
Половину своего рабочего понедельника я потратил на составление сценария тестирования. В процессе, каюсь, обнаружил несколько недоработок и даже две-три действительно критичных ошибки. Впрочем, дело обычное, поэтому я оперативно подготовил доработанную конфигурацию и отправил её вместе со сценарием представителю работодателя, объяснив ситуацию. Спустя буквально полчаса я получаю ответ об отрицательном решении относительно моей кандидатуры.
Надо сказать, что получение хоть какого-то ответа можно считать определённой удачей. Чаще всего после собеседования или решения тестового задания потенциальный работодатель не считает нужным отвечать вообще. В моём случае мне даже предоставили аргументацию отказа, чему я был бы бесконечно рад, если бы не содержимое этой аргументации.
Решение слишком запутанное, простые вещи максимально усложнены и перегружены функционалом, которого нет в описании задачи (решение похоже на адаптацию типовой конфигурации под эту задачу, что не требовалось). В целом тестовое задание работает.
Эффект от такого заключения был как от ведра ледяной воды, вылитого на мою разгорячённую голову. Назвать моё решение запутанным мог только неопытный программист, студент или стажёр. Естественно, я не заимствовал ни строчки из типовых конфигураций, а писал сам теми же пальчиками, которыми сейчас пишу эту статью. Да, стиль написания действительно может быть похож на типовые конфигурации. Но попробуйте не начать подражать тому, с чем вы уже долгое время работаете! К тому же, существует методика разработки от самой 1С, и это естественно, что я её стараюсь придерживаться, точно так же, как их придерживаются и разработчики типовых конфигураций.
Мой ответ на этот отказ был вежливым, но очень язвительным. Не думаю, что после такого ответа у меня ещё осталась хоть какая-то возможность когда-либо и где-либо поработать с этой организацией или этими людьми.
Вот несколько банальных советов, которые я хотел бы дать самому себе из прошлого, будь у меня машина времени:
-
Берись за выполнение тестового задания на свой страх и риск. Нужно чётко понимать, что, независимо от того, сколько своего личного времени ты потратишь на это задание, не подвергается сомнению право работодателя отказать в приёме на работу без объяснения причин.
-
Оцени формулировку задачи. Её составлял кто-то из твоих потенциальных будущих коллег, возможно ведущий программист или начальник отдела разработки. Описание задания может рассказать что-то важное о характере составителя и его компетенциях.
-
Не стесняйся задавать вопросы и уточнять, действительно ли требуется реализовать тот или иной функционал. Но в этом тоже нужно быть осторожным — излишняя назойливость может составить у работодателя не самое хорошее мнение о тебе и повлиять на его решение по твоей кандидатуре.
Для тех, кого интересуют подробности, к статье прикреплены текст задания в его первозданном виде, база данных с решением и обработка для генерации тестовых данных.
А каково ваше мнение по описанной ситуации?
-
Работодатель прав. Решение тестового задания должно быть максимально простым и понятным, но при этом функциональным. Если соискатель добавляет функционал, который не описан в условиях задачи, то это признак его некомпетентности как программиста.
-
Работодатель не прав. Решение тестового задания должно демонстрировать способности соискателя. Добавленный и корректно реализованный дополнительный функционал идёт только в плюс при оценке компетентности соискателя как программиста.
