Три из четырех соискателей на нашу java junior вакансию теряют возможность попасть на второй этап собеседования из-за одной и той же ошибки при выполнении тестового задания.
О чем речь?
Всем, кто прошел предварительный отбор hr'ом, выдается домой небольшая задача для самостоятельного выполнения. В тексте которой есть следующий текст:
<...>
Написать консольное приложение `TreeRender`:
1. Приложение должно принимать на вход два параметра: `java --source 11 TreeRender.java INPUT_FILE_NAME OUTPUT_FILE_NAME`.
<...>
Ожидания от программы в порядке важности:
1. Работающая программа в соотвествие с ТЗ: на правильный ввод программа `TreeRender` выдает ожидаемый вывод (Проверка работоспособности программы выполняется нами **автоматизировано**).
<...>
Правильность работы приложения и успешность выполнения задания проверяется автоматизировано скриптом. Большинство соискателей пишет приложение, которое не может пройти такую проверку. Причина - внешний интерфейс программы не соответствует тому, что ожидает автоматизированный тест. Т.е. внутренняя логика программы может работать безукоризненно, а автоматический тест не может вызвать программу.
Первая часть допускаемых ошибок имеет java-специфику:
- Класс называется, например, "MyApp", а не "TreeRender"
- Программа состоит из нескольких файлов или входит в пакет, например, *org.example*
- Приложение является gradle проектом, требующим зависимости от третьих сторон.
Такие ошибки не позволяют выполнить java программу без дополнительных ручных действий.
К другой части относятся ошибки в семантике внешнего интерфейса, например, программа не принимает аргументы, а запрашивает их в интерактивном режиме выводя в консоль "Укажите аргумент INPUT_FILE_NAME:", что так же противоречит тексту ТЗ.
Первая наша реакция была: "Ага, все ясно. Соискатель не способен читать и анализировать ДП. Если возьмем на работу кандидата, то потребуется осуществлять постоянный контроль и в конечном счете наим себя не оправдает".
Но следом возникает вопрос. А может проблема в постановке задачи и мы тем самым отсекаем себя от хороших кандидатов? Возможно мы могли бы предоставить сервис автоматизированной проверки результата. Кандидат мог бы проверить программу на совместимость требованиям до того, как отправит окончательный вариант.
К нам приходит много резюме, однако у нас не достаточно ресурсов, что бы внимательно подойти к каждому кандидату . Отсев часто происходит по первичным критериям. Например, пустое голое резюме, где только имя, фамилия и вуз, обычно отправляется cразу в корзину. Такова правда жизни. На конкретную вакансию на собеседование можем позвать не больше 4-6 человек в неделю. С чистой совестью отказывали тем, кто не прошел автоматизированную проверку по любой из приведенных выше причин.
13 лет назад я не прошел собеседование по схожей причине. Я получил задание:
Результатом выполнения задания является исполняемая программа, позволяющая ввести строку длиной не более 30 символов и осуществить ее проверку на корректность. Результат проверки должен выдаваться в виде одного из двух возможных сообщений - "Check passed" или "Check failed".
Я написал приложение, которое выдавало окно с сообщением, что то типа ShowMessage('Успешно'). Я не увидел или не придал особого значения словам "одного из двух возможных сообщений". Это была моя ошибка. `Face Palm`. Да, я конечно пытался придумать себе оправдание, что у меня не было опыта работы по четким ТЗ, а скорее наоборот, был опыт отсутсвия четких ТЗ, требующий применять фантазию.
Я тогда сильно хотел получить оффер на ту вакансию и пройти собеседование. И именно этот провал многому меня научил: каждая деталь любого ТЗ важна.
Таким образом, внутреннее сомнение в правильности быстрого отказа по автоматизированному тесту не отпускало. Я начал искать знаки, которые бы подвердили или опровергли используемые подходы. Код приложений, которые проходили проверки автоматизировано, как правило, был лучше чем код приложений которые нельзя было проверить автоматизировано. А чтобы убедится в том, что кандидаты прошедшие автоматизированную проверку сильнее, приглашали на собеседование и тех, кто такую проверку не прошел, несмотря на то, что внутри их приложений все равно был приятный код, который работал без ошибок в логике. Оказалось, что на собеседовании нет никакой корреляции между теми у кого программу можно вызвать как `java --source 11 TreeRender.java INPUT_FILE_NAME OUTPUT_FILE_NAME` и теми, у кого нельзя. Вот такое открытие.
Отмечу, что я знаю несколько хороших разработчиков и одного даже очень хорошего, у кого "пустые" резюме - как раз одна из тех причин почему резюме кандидата отправляется сразу в корзину.
Какие выводы можно сделать ? Статью можно было бы назвать "75% нанимателей совершают эту ошибку, упуская хороших кандидатов". Но кандидату с этим ничего поделать нельзя. Процессы найма часто не совершенны. Спасение утопающего - дело самого утопающего. А такие относительно простые ошибки вольного тракатования ТЗ для кандидатов могут быть болезненны. О них нужно знать и лучше не допускать.
