Недавно в силу своей работы, мне довелось отбирать стажеров в нашу компанию. Все кто еще помнит как это — быть стажером/джуном, должны помнить как сложно без опыта воткнуться в более-менее нормальное место, где будут тратить ресурсы на твое обучение. Из-за того, что поток начинающих разработчиков очень большой, у работодателя есть возможность выбирать из этого потока если и не самых лучших, то как минимум толковых, перспективных ребят, на которых стоить потратить время на обучение, чтобы потом их у себя трудоустроить.
У каждой компании своя методика поиска таких кандидатов. Мы, на сегодняшний день, придерживаемся следующей: даем небольшое тестовое задание (около часа работы, для опытного разработчика), для выполнения которого достаточно знаний java-core и просим выложить его на гитхаб. По времени выполнения не ограничиваем. Затем, качественно выполнивших задание соискателей приглашаем на собеседование.
Задание обычно содержит реализацию CRUD методов в файл через консольное меню с одной-двумя сущностями плюс валидацию некоторых полей. В качестве примера приведу классическую ситуацию с пользователем, которому нужно реализовать валидацию email и телефона, по заданному шаблону и к этому иметь возможность ввести от 1 до 3 телефонов. Откликов приходит очень много, а мест очень мало — соответственно отбор достаточно жесткий.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода. К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?).
Многие могут счесть такой подход несправедливым, сказать что задача же решена, код работает, однако жизнь стажера и джуниора сурова и беспощадна.
Решение задачи без ошибок присылает большая половина соискателей, а добротный код — единицы, которые и проходят естественный отбор и попадают в следующий тур. Все исполнители получают фидбек. Те кто написал добротный код, который дошел до запуска — персональный фидбек, те, что прислали спагетти, написанное на коленке — более обобщенный.
P.S.: Надеюсь мои советы помогут вам, уважаемые соискатели лучше выполнять ваши тестовые задания, а проверяющим реже плакать кровавыми слезами. Удачи вам в поисках и хорошего стартового места работы!
У каждой компании своя методика поиска таких кандидатов. Мы, на сегодняшний день, придерживаемся следующей: даем небольшое тестовое задание (около часа работы, для опытного разработчика), для выполнения которого достаточно знаний java-core и просим выложить его на гитхаб. По времени выполнения не ограничиваем. Затем, качественно выполнивших задание соискателей приглашаем на собеседование.
Задание обычно содержит реализацию CRUD методов в файл через консольное меню с одной-двумя сущностями плюс валидацию некоторых полей. В качестве примера приведу классическую ситуацию с пользователем, которому нужно реализовать валидацию email и телефона, по заданному шаблону и к этому иметь возможность ввести от 1 до 3 телефонов. Откликов приходит очень много, а мест очень мало — соответственно отбор достаточно жесткий.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода. К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?).
Многие могут счесть такой подход несправедливым, сказать что задача же решена, код работает, однако жизнь стажера и джуниора сурова и беспощадна.
В связи с этим, предлагаю свой список рекомендаций к выполнению тестового задания
- Ваше решение должно работать в соответствии с ТЗ
Досконально выполняйте требования изложенные в условиях к решению задачи. Не додумывайте своих полей у сущностей, не меняйте условия валидации и тд. и тп. Это показывает насколько вы внимательны к деталям, что для разработчика очень важно. - Кропотливо проверяйте выполненную задачу
Сделали задачу — проверьте работоспособность. Сначала основной функционал, описанный в ТЗ, затем дополнительный. Постарайтесь «сломать» свое приложение: проверить или адекватно заданию себе введет приложение, если ввести не валидные данные, данные максимально похожие. Не забудьте только исправить все, что найдете. - Кодировка
Все файлы должны быть в одной кодировке, на мой взгляд в UTF-8. Настройте свою IDE для этого. Помните, если у вас Windows, то у проверяющего может быть Linux, а дополнительные приседания с кодировкой — лишняя трата времени проверяющего. - Не делайте задачу в один коммит
Нужно коммитить по мере решения своей задачи, добавляйте к коммитам внятные описания. Если знаете английский, то лучше на английском языке. Это косвенно указывает на то, что вы не просто слили чужое решение с гита, а писали код сами. - Старайтесь не сливать чужие решения
Учитывая, что вы претендуете максимум на джуна, чаще всего у вас еще недостаточно опыта, чтобы использовать чужой код. Условия задачи могут незначительно меняться и когда вы просто копируете чужое решение, оно уже может немного не соответствовать текущей задаче. А задача должна быть выполнена в точности с заданием (см. П1). - Добавьте файл readme
Добавьте в корень проекта readme.md файл. Вкратце опишите свое приложение, выложите дополнительные пояснения для запуска, если необходимо. Если у вас есть другие уже выполненные задачи — добавьте readme и туда. Я, например, если кандидат заинтересовал, могу посмотреть и другой его код. Да и если не пройдете сюда — этот код вы тоже сможете приложить в резюме. - Делайте удобное меню
Приложение должно быть user friendly. Помните, что время для проверки часто ограничено, поэтому предзагрузите приложение данными, добавьте метод показать все сущности (какая там в условиях). Переходы по меню должны быть удобными, например при помощи цифр. А то иногда реализуют так, что для удаления сущности нужно ввести в консоли «Delete». Однако здесь нельзя перестараться и выйти за рамки ТЗ. - Делайте максимально хорошо, насколько вам позволяют ваши навыки
Раз уж вы решили выполнять тестовое задание, подходите к его решению с максимальной отдачей. Даже если задача кажется тривиальной и простой, не нужно подходить к ее решению формально и писать код на коленке. И если вы не пройдете в эту компанию, то у вас на гитхабе останется выполненное решение, а это практика. - Не забывайте о принципах ООП
Пусть вам кажется, что задача небольшая не забывайте — задание тестовое, а java в первую очередь объектно ориентированный язык. И смотреть будут не только на работоспособность приложения но и на код. Качество кода — это очень важная часть решения. Не пишите спагетти код. Разложите все по классам, пакетам. Создайте где нужно интерфейсы, вынесите перечисления в ENUM, если необходимо. - Постарайтесь использовать паттерны проектирования
Удачное применение хотя бы одного паттерна проектирования покажет, что вы имеете понятие о паттернах проектирования (либо не имеете). Только прежде чем применять тот или иной паттерн — разберитесь в чем задумка, как он должен работать и для чего он был придуман. Я, если вижу паттерны в коде, потом на собеседовании могу задать вопрос о примененном паттерне. - Пользуйтесь ресурсами
Все сообщения выводимые пользователю лучше выносить в ресурсы и брать оттуда. Это покажет проверяющему, что вы умеете работать с ресурсами и понимаете для чего они используются. Сообщения лучше выводить на английском языке. - Не забывайте переопределять где нужно equals & hashcode
- Используйте фичи java8+, такие как лямбда-выражения, стримы
Не забывайте, что чаще коллекции удобнее массива. Если выбор пал в пользу коллекций, то пользуйтесь правильными коллекциями. Вы должны на собеседовании быть готовым обосновать свой выбор в пользу той или иной коллекции либо массива. - Тесты
Если умеете, напишите тесты, но это уже на пять с несколькими плюсами. Часто, подразумевается, что любой хороший код обычно покрывают тестами. Хотя для приведенной в примере задаче, отсутствие тестов минусом не будет, так как это простое консольное приложение на знание java core.
Резюме
Решение задачи без ошибок присылает большая половина соискателей, а добротный код — единицы, которые и проходят естественный отбор и попадают в следующий тур. Все исполнители получают фидбек. Те кто написал добротный код, который дошел до запуска — персональный фидбек, те, что прислали спагетти, написанное на коленке — более обобщенный.
P.S.: Надеюсь мои советы помогут вам, уважаемые соискатели лучше выполнять ваши тестовые задания, а проверяющим реже плакать кровавыми слезами. Удачи вам в поисках и хорошего стартового места работы!