У каждой компании своя методика поиска таких кандидатов. Мы, на сегодняшний день, придерживаемся следующей: даем небольшое тестовое задание (около часа работы, для опытного разработчика), для выполнения которого достаточно знаний 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.: Надеюсь мои советы помогут вам, уважаемые соискатели лучше выполнять ваши тестовые задания, а проверяющим реже плакать кровавыми слезами. Удачи вам в поисках и хорошего стартового места работы!
Комментарии (78)
PendalFF
23.08.2019 08:20… нам не нужно экономить память.
Конечно, зачем бы. Правда у среднего смартфона памяти уже в 8-16 раз больше чем было у меня на первом собственном ПК, но вы продолжайте, продолжайте.GreenBeasT Автор
23.08.2019 12:06Зачем экономить память в приложении с 1-2 сущностями? Если приложение маленькое, удобнее использовать коллекции, вместо того чтобы возиться с массивами, если вы об этом.
PendalFF
23.08.2019 12:17Зачем писать хороший код в приложении с 1-2 сущностями?
Оно же маленькое?
Потом эти же программисты масштабируют подход, которому они обучились на маленьких приложениях. И мы получаем то что получаем, hello world, наполненный 100500-ми фреймворками и весом в сотни мегабайт. Делать надо хорошо, фигово само получится. И хорошо, на мой взгляд, это не только «правильно» в любой из систем координат разработки, но и эффективно, в том числе с точки зрения затрачиваемых прикладом ресурсов.GreenBeasT Автор
23.08.2019 12:58Зачем писать хороший код в приложении с 1-2 сущностями?
Оно же маленькое?
Чтобы показать, что вы умеете писать хороший код. Не нужно путать ТЗ для
разработчиков с опытом и стажеров, только-только познавших java-core.PendalFF
23.08.2019 13:20Чтобы показать, что вы умеете писать хороший код. Не нужно путать ТЗ для
разработчиков с опытом и стажеров, только-только познавших java-core.
Ну то есть одна сторона «хорошего кода» (подход и оформление) важна а другая (эффективность) — нет? Признаться, в данном выборе приоритеты у меня были бы прямо противоположные.GreenBeasT Автор
23.08.2019 13:52В чем по-вашему выражается эффективность? Если вы не внимательно прочитали статью, то напомню: работающий код присылает большая часть соискателей. Или вы считаете эффективным написанный на коленке код, который потом будет тяжело поддерживать? Писать спагетти код может почти каждый, кто худо-бедно выучил стек. А вот писать код, который потом будет удобно поддерживать и легко читать — единицы. И не забывайте, что задание для стажеров/джуниоров. Они еще априори не умеют делать быстро и качественно.
Так что для нас, лучше взять человека, который понимает принципы SOLID не только теоретически. А руку на скорость он набьет, мы ему дадим такую возможность.PendalFF
23.08.2019 16:11Эффективность в моем понимании — это не следовать советам типа «вам не нужно экономить память». Не понимаю я одного — почему вы считаете достаточным _красивый_ код (то что он должен работать — не обсуждается), а оптимизацию не то что не требуете а советуете ей пренебречь. Про скорость же я вообще ничего не говорил.
И таки я внимательно прочитал статью и увидел, в принципе, тоже что и многие здесь — «угадайте чего мы хотим от вас сегодня».GreenBeasT Автор
23.08.2019 17:14Хорошо, возможно пример с массивами и не очень удачен. И я, кстати, не писсимизирую соискателя, не считаю это ошибкой, если он использовал массив а не коллекцию. Но когда человек использует правильную коллекцию — это может дополнительно охарактеризовать его знания в этой области, только и всего. А область по работе с оптимизацией памяти мне кажется, на стажера наваливать просто рановато. У них и так в голове часто одна теория не закрепленная практикой.
akryukov
23.08.2019 08:38Интересно, что пункты 1 и 2 противоречат друг другу.
Не додумывайте своих полей у сущностей, не меняйте условия валидации и тд. и тп.
А потом сразу
Постарайтесь сломать свое приложение, ввести не валидные данные, данные максимально похожие. Не забудьте только исправить все, что найдете.
Пункт 6 тоже интересно сочетается с пунктом 1.
Добавьте в корень проекта readme.md файл. Вкратце опишите свое приложение, выложите дополнительные пояснения для запуска, если необходимо.
Если делать строго по ТЗ, то в readme будет это самое ТЗ.
Переходы по меню должны быть удобными, например при помощи цифр. А то иногда реализуют так, что для удаления сущности нужно ввести в консоли «Delete».
А как же ТЗ?
ffs
23.08.2019 11:51ТЗ в основном это просто 3-4 пункта описания функционала. Всякие "мелочи" вроде проверок, валидаций, особенностей интерфейса не указывают.
GreenBeasT Автор
23.08.2019 12:131 и 2 не противоречат. Читайте внимательно. 1 пункт как делать, 2 ой как проверять уже готовое, по вашему мнению, приложение.
Если делать строго по ТЗ, то в readme будет это самое ТЗ.
возможно, но если использовали в качестве сборщика, к примеру мавен, и для запуска нужна команда, ее пишут тоже там. И даже если там будет просто ТЗ, это будет плюсом, если код хороший, а соискатель не прошел собеседование.akryukov
23.08.2019 12:26Множество невалидные данных может быть гораздо шире, чем вы описали в ТЗ. Если ввести то, что по смыслу невалидно, но при этом не описано в ТЗ, то получается противоречие с пунктом 1.
GreenBeasT Автор
23.08.2019 13:03Проверяется валидация только тех полей, которые указаны в ТЗ. И в п2 рекомендуется проверить, что если для валидации задана маска телефона 245хх-ххххххх где х любая цифра, то валидацию пройдут только телефоны соответствующие маске а телефоны вида 245хххххххххх без тире или с большим количеством цифр будут не валидными.
akryukov
23.08.2019 13:26Множество невалидных данных все равно может быть шире, чем вы описали в ТЗ. Пускай для телефона требования исчерпывающие. Но это ведь не единственное значение, которое вы получаете от пользователя. В других требованиях вы могли что-то упустить и там все равно получится противоречие в 1 и 2 пунктах.
Вы эти рекомендации позиционируете как универсальные или "для вашей компании"? Если первое, то они должны подходить не только к вашему конкретному ТЗ, но и к возможным ТЗ от других компаний.
Если второе, то о какой компании речь? Зачем публично выкладывать рекомендации для попадания в вашу конкретную компанию?GreenBeasT Автор
23.08.2019 14:00Советы подойдут для всех стажеров/джуниоров.
А вы почитайте, думаю вам будет не лишним: принципы SOLIDakryukov
23.08.2019 14:22+1Каким образом ссылка на принципы SOLID опровергает мой тезис?
Если вы позиционируете советы для всех стажеров/джуниоров, то пункты 1 и 2 противоречат друг другу в тех тестовых заданиях, где ТЗ неполное.
GreenBeasT Автор
23.08.2019 22:30Предыдущий комментарий улетел немного не туда. Теперь подробно.
то пункты 1 и 2 противоречат друг другу в тех тестовых заданиях, где ТЗ неполное
Как может п1. где говорится чтоприложение должно работать в соответствии с ТЗ
может противоречить п2. где говорится:Кропотливо проверяйте выполненную задачу
Или вы не понимаете разницу между тем как делать, и как после этого тестировать свое консольное приложение? Как вообще могут противоречить советы по выполнению советам по проверке? По моему все достаточно четко. Сначала сделал, соответствуя спеке (п1), затем проверь, что все работает согласно ей же (п2). А ТЗ достаточно полное, четкое и простое до боли.
musicriffstudio
23.08.2019 09:10+2Мы, на сегодняшний день, придерживаемся следующей:
ставлю десять центов что ни вы, ни кто-то из ваших уже работающих программистов этот тест не пройдёт.GreenBeasT Автор
23.08.2019 12:16Как написано выше, ТЗ для стажеров — возможность показать то, как они умеют писать код. И нам хватает тех, кто проходит.
RomeoGolf
23.08.2019 09:24+4Очередная статья о том, что для успешного прохождения собеседования/задания надо быть телепатом. Надо выполнить «качественно», то есть, в соответствии с хотелками, которые где-то в голове проверяющего. А у другого — другие хотелки.
Одному надо «не додумывайте», другой хочет инициативу.
Одному надо «не делайте в один коммит», другого интересует только прохождение тестов.
Одному надо «удобное меню, юзер френдли», другой напомнит: «не додумывайте».
Одному надо пять пакетов с десятком классов в каждом, другой скажет: «Ты с ума сошел, fizzbuzz с пятью классами и двумя пакетами?»
Одному надо коллекции вместо массива, потому что не надо экономить память, другому надо экономить память.
Одному тесты — это задача со звездочкой, другому — обязательное требование, третий сам тесты предоставляет.
Допишите уж в заголовке: "… в мою компанию" или "… через меня".GreenBeasT Автор
23.08.2019 12:19-2Это статья, призванная помочь стажерам и показать себя с лучшей стороны. Все советы будут плюсом при выполнении любого ТЗ, так как они советуют не писать гов… код, к которому вы, возможно привыкли.
RomeoGolf
23.08.2019 12:26"Зачем экономить память в приложении с 1-2 сущностями? Если приложение маленькое, удобнее использовать коллекции, вместо того чтобы возиться с массивами"
И эти люди, не видя ни строчки моего кода, предполагают, что я привык к гов… коду? Спасибо за переход на личности, это отличный показатель.
RomeoGolf
23.08.2019 14:33А ещё так. Приходит юниор с горящими глазами, говорит: "дайте мне задание" Ему в ответ: "А сыграй, пардон, напиши так, чтоб душа, пардон, связный список сперва развернулся, а потом свернулся." И пишет он, болезный, стараясь экономить о большое и память. А ему говорят: "приложение-то маленькое, что ты жмешься, только линкед лист, только хардкор! (И не забудь переопределить сетхеш)" "Ах, маленькое...", думает юниор, и пишет как маленькое. А ему — "Ну, не настолько же маленькое! Пакетов надо минимум три, классов в каждом хотя бы пять!" И пошел бедный юниор с покалеченной психикой раздумывать над философским смыслом Java-термина "маленький"...
mmMike
23.08.2019 09:51+1К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких
классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?).Какая связь принципов ООП и расположения в одном пакете?!
Пусть вам кажется, что задача небольшая не забывайте — задание тестовое, а java в первую очередь объектно ориентированный язык.
Задача "валидацию emil и телефона, по заданному шаблону" и ООП с разбросом классов по отдельным пакетам. Вы шутите?
Да. Если платят за количество строк, то можно и расписать такую задачу… Эх размахнись плечо в рамках ООП с разными пакетами.
вынесите константы в ENUM.
С чего вы решили, что ENUM это самое удачно решение. Иногда удачно. Иногда нет. С мотря где и зачем.
Критерий "константы не вынесены в ENUM" — тест провален… У меня нет слов.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода.
Хм. Если бы мне такое надо было и кандидатов было бы… ну скажем больше 10. Я бы написал за эти 30..40 минут автотесты, включая автоматическую выкачку с Git
А в ТЗ четко бы определил API. Судя по фразе "Задание обычно содержит..." это как раз подходящий случай.
Кропотливо проверяйте выполненную задачу
И странно, что ни словом не упомянуто JUnit в качестве требования к готовой реализации.
И "Если умеете, напишите тесты, но это уже задача со звездочкой" это не звездочка… Это минимум. Особенно на фоне всего остального.
Остальные пункты (по переопределению equals & hashcode в демонстрационных целях и использованию где надо и не надо коллекциями) очень хочется тоже комментировать, но вежливых слов не хватает.
Однако, вы телепатов ищете. Которые знают что конкретно Вы от них ждете!
Причем не в области ТЗ, а в области "я так вижу как должен быть оформлен код".GreenBeasT Автор
23.08.2019 12:28Какая связь принципов ООП и расположения в одном пакете?!
Читаете между строк?
весь код сконцентрирован в нескольких классах
для вас это нужно жирным выделить было? Или вы не знаете как писать ООП приложение?
Критерий «константы не вынесены в ENUM»
Где написано что тест провален?
Если бы мне такое надо было и кандидатов было бы… ну скажем больше 10. Я бы написал за эти 30..40 минут автотесты, включая автоматическую выкачку с Git
Очень смешно.Однако, вы телепатов ищете. Которые знают что конкретно Вы от них ждете!
Кто ясно излагает, тот ясно мыслит.
Причем не в области ТЗ, а в области «я так вижу как должен быть оформлен код».
Вы вообще когда-нибудь проверяли чьи-то задания? Очень похоже, что статью вы читали сугубо поверхностно, нравится потролить, хотя сами ни одного выполненного задания даже в глаза не видели, не вижу смыла вам что-либо дальше объяснять.mmMike
23.08.2019 12:56Читаете между строк?
Ээ… я Вас же процитировал? Ваши слова: "К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?). "
Где тут между строк то..
Очень смешно.
Выдать ТЗ с четким описанием API и подготовить набор тестов для проверки — что в этом смешного?
А вообще, в стандартном цикле разработки, блок кода фиксировать как законченный без внутренних юнит тестов — моветон. А по хорошему и внешние тесты должны прилагаться, если есть возможность.
Вы вообще когда-нибудь проверяли чьи-то задания?
Регулярно. Когда в свой отдел народ собеседую. Хотя мерятся пс… ками в комментария — то же моветон.
P.S. Остальное без комментарий… Вас не смущает общая оценка статьи?
GreenBeasT Автор
23.08.2019 13:38Сколько вы проверили тестовых заданий? Подозреваю, что ни одного.
Вас не смущает общая оценка статьи?
Нет, оценку ставят такие как вы, тролли.
А вас не смущает количество людей добавивших статью в закладки? Это начинающие разработчики, и они скорее всего просто не имеют права голосовать на Хабре, поэтому оценка и ушла вниз.
В статье я выложил вполне дельные советы начинающим разработчикам. Все, кто помнит, как то — джуном искать работу, статью оценят. Вам же, если вы вообще имеете опыт в Java порекомендую книгу Роберта Мартина «Чистый код», если ее не читали.
Neikist
23.08.2019 17:09Я вот добавил статью в закладки чтобы последить с попкорном за холиваром.
А по теме… Не, если вы все эти рекомендации к ТЗ прикладываете — честь вам и хвала. А вот если нет… Не раз например встречал мнение что на таких заданиях наоборот стоит максимально упрощать а не городить классы с пакетами, это же тестовое а не продакшен, FizzBuzzEnterpriseEdition уже мемом стал. Да и к асимптотике алгоритмов и памяти бывает прикапываются (у вас же наоборот). А еще бывает в каких то компаниях заворачивают решения с библиотеками «мы хотели посмотреть как сами думаете» а в других «зачем велосипеды, есть же leftpad в npm». Будьте честными, это требования именно вашей компании, хотя не удивлюсь даже если окажется что только вашего отдела. В других компаниях все может быть, и нередко бывает, иначе.GreenBeasT Автор
23.08.2019 18:07Я уже отвечал в других комментариях. На мой взгляд, если позволяет время, нужно писать максимально хорошо. Для java как для ООП языка есть такие принципы, как SOLID, в соответствии с которыми и пишутся хорошие приложения на этом языке. А некоторые из советов просто помогают их осознать. Да и я не вижу ни одного совета, который может быть плохо воспринят при проверке тестового задания в любой компании (для java). Единственное, там зацепились за массив/коллекцию, но я уже отвечал и на это замечание тоже.
например встречал мнение что на таких заданиях наоборот стоит максимально упрощать а не городить классы с пакетами, это же тестовое а не продакшен
Это задание достаточно легкое по логике, и задание для стажера. Поэтому, если стажер уже считает, что может не придерживаться основных принципов ООП при написании кода на java, о которых написано на каждом столбе… Ну не знаю даже, что еще тут сказать.Neikist
23.08.2019 19:03Кроме SOLID есть немало других принципов достойных упоминания, те же KISS и YAGNI. Да и в SOLID не помню требований несколько классов обязательно по куче пакетов распихивать. Вообще не вижу зачем в таком маленьком задании как вы описываете (на час работы) городить кучу пакетов. Ну разве что отдельно для POJO. Да может от настроения если слои/фичи выделятся, но тут уж у многих программистов свои привычки как правильно на пакеты бить.
GreenBeasT Автор
23.08.2019 19:31Там и не будет кучи пакетов. Чаще это репозиторий, комманд или экшены, валидаторы. На счет KISS и YAGNI — эти принципы, на мой взгляд, больше применимы при решении реальных задач и понять писал ли соискатель свой код в соответствии с этими принципами или просто не умеет лучше — распознать сложнее. Возможно следует добавить в ТЗ условие, что приложение должно быть легко расширяемым и масштабированным.
akryukov
23.08.2019 19:35Возможно следует добавить в ТЗ условие, что приложение должно быть легко расширяемым и масштабированным.
Всегда можно придумать такое требование, которое идет вразрез с задуманными возможностями для расширения и масштабирования.
GreenBeasT Автор
23.08.2019 22:09Выдать ТЗ с четким описанием API и подготовить набор тестов для проверки — что в этом смешного?
АПИ в консольном приложении? Серьезно?mrsantak
24.08.2019 10:47Вы пользовались grep, cat, tail, etc? Это все консольные приложения и у них есть API.
Matisumi
23.08.2019 09:59Ооочень спорные замечания. Это если не сказать больше. Какой вот, например, практический смысл оставлять в коммитах комментарии обязательно на английском? Ваша компания работает с зарубежными заказчиками или коллегами?
Очень многие за этими «помните об ООП» и «заюзайте как можно больше паттернов» забывают про то, что код должен в первую очередь решать бизнес-задачи.GreenBeasT Автор
23.08.2019 12:35Ваша компания работает с зарубежными заказчиками или коллегами?
Да, в основном на зарубежных. На русском каждый может, если оставляете на английском — мы считаем это небольшим плюсом. Хотя для стажеров, на это почти не смотрим. В резюме обычно указан уровень английского.
«помните об ООП» и «заюзайте как можно больше паттернов»
Вы мыслите как сложившийся разработчик при подходе к решению бизнес задачи, и я согласен что порой нужно просто что-то быстро написать и доставить, но мы имеем код стажера, который в первую очередь, должен показать его знания.
andrey_2_new
23.08.2019 10:09Мы тоже даём тестовое задание. Только оно проще на порядок. И первое, на что смотрим, — это тесты. Нет тестов — до свидания. Даже если это junior.
musicriffstudio
23.08.2019 10:14пробелы или табы? Пусть угадывают.
Речь-то не о самом задании, а о том что раз в неделю подобная статья о телепатии появляется.GreenBeasT Автор
23.08.2019 12:36Где тут телепатия? Просто советы начинающим разработчикам, как писать код лучше. Или вы из тех кто пишет классы по 100500 строк которые все делают?
musicriffstudio
23.08.2019 12:57так пробелы или табы?
GreenBeasT Автор
23.08.2019 13:10так пробелы или табы?
Вы о чем вообще? В ТЗ все валидации и все условия обычно точно описаны.musicriffstudio
23.08.2019 14:04вы не можете дать точный ответ на простой и краткий вопрос.
А туда же, судить-рядить.
Скромней надо быть. Я б на месте вашего работодателя присмотрелся, соответствуете ли вы своей должности.GreenBeasT Автор
23.08.2019 22:50вы не можете дать точный ответ на простой и краткий вопрос
Вопрос вообще не относится к теме. Не нужно путать оформление кода и структуру.
Где тут телепатия?
вы из тех кто пишет классы по 100500 строк которые все делают?
Так что с ответами?
Хотя, мне кажется, от вас такого ответа не дождусь, так как к java вы никакого отношения не имеете (java и javascript это разные вещи, если что). А вы, как я вижу, так чисто, пошлепать зашли.
ps не поленился заглянуть в профиль.
Matisumi
23.08.2019 10:40+1А в ТЗ вы про тесты что-то пишете? Или соискатель сам должен догадаться, что вы хотите видеть тесты?
GreenBeasT Автор
23.08.2019 12:41-1А тесты опциональны. Есть — хорошо, нет — ничего страшного. Просто встречал несколько выполненных заданий покрытых тестами.
Когда вы выбираете какой-нибудь товар, вы же стараетесь выбрать получше, если выбор огромен-не?
Так и тут — выбор достаточно большой и в статье лишь описаны способы, как свой товар (свое выполненное ТЗ), сделать более привлекательным.Matisumi
23.08.2019 12:55+1Нет, товарищ вон выше пишет, что если тестов нет — до свидания. Вот и хочется узнать, есть ли в ТЗ что-то про тесты.
GreenBeasT Автор
23.08.2019 14:22Нет, про тесты ничего нет. Если их нет — это ни на что не влияет, но если они есть — мы видим, что человек просто их умеет писать. Для стажера будет небольшим плюсом.
andrey_2_new
23.08.2019 16:05Если в двух словах, то да, соискатель должен сам догадаться. Тесты — идут вместе с кодом, в идеале, они описывают то, что код делает и проверяют что он это делает правильно.
Хорошо, представьте что вы считаете себя профессиональным разработчиком ПО. Получаете задание создать приложение, которое читает два числа с консоли и печатает их сумму. Ввод и вывод должны быть римскими цифрами.
Я почти уверен, что в приложении будут функции разбора и генерации римских цифр. Будет очень очень странно, если профессиональный разработчик, даже junior не догадается покрыть их тестами.
Частонеобходимостьпривычка тестировать все, что только можно подвигает структурировать код так, что он становится лучше и понятней. Появляется модульность, о которой пишет автор. Тестируем корректные варианты, и тестируем заведомо некорректные. Появляется валидация ввода. Автор тоже об этом писал.
По-моему, это очевидные вещи. В нашем случае речь идет о Java. Любой, кто считает себя профессиональным java-разработчиком, знает о build-системах и пользуется ими. Будет очень странно, если разработчик выполнитgradle initа потом сознательно, отдавая себе очет в том, что делает, удалит папку src/test.
0xd34df00d
23.08.2019 20:23Нет тестов — до свидания.
А если есть, кхе-кхе, формальное доказательство корректности?
WNeZRoS
23.08.2019 10:24Последний год также смотрю тестовые задания, но на C#. Задание алгоритмическое — сериализация-десериализация, делается минут за 10 в 50 строк красивого кода (джуны растягивают на несколько часов и сотни строк кода).
Требования просты: написанный код должен решать поставленную задачу. Оформлять можно как угодно, хоть скриншот в .doc файле. Обычно я просто смотрю код, делаю код ревью. За последние полгода присланный код я запускал один раз — не мог поверить что человек прислал неработающую программу. Если в коде кол-во проблем не выходит за рамки приличия, то человек приглашается на собеседование, где ему будут также заданы вопросы про эти проблемы.
Совет "Старайтесь не сливать чужие решения" правильный. Все чужие решения сразу заметно, особенно когда в один день приходят два одинаковых теста. Я пробовал найти хорошее решение в открытых источниках, но у меня это не получилось. Если оно где-то и есть, то очень глубоко.
v2kxyz
23.08.2019 11:13+1А у вас задание также сформулировано:
Задание обычно содержит реализацию CRUD методов в файл через консольное меню с одной-двумя сущностями плюс валидацию некоторых полей.
?
Или тестовое задание предполагает проверку способности конвертации потока сознания заказчика(начальника?) в код?
P.S. Извините, наболело.GreenBeasT Автор
23.08.2019 12:43Задание оформлено нормально, где описано какая там дожна быть сущность и какие поля она должна содержать, как валидироваться. Просто само задание я не выкладывал.
pilot911
23.08.2019 12:42Задание бы сделал, но работу бы нашел в другом месте. Лучше поговорить с человеком, узнать его образование, цели, достижения. А код писать — надо давать что-нибудь попроще.
GreenBeasT Автор
23.08.2019 12:45Стажером/джуниором без опыта? удачи в ваших поисках.
Matisumi
23.08.2019 13:00Нет, это вам удачи в ваших поисках. Те, кто сможет пройти ваши овер-тесты для джунов так, как вы этого хотите — с большой вероятностью смогут устроиться в какое-то другое место на миддла с бОльшей зп.
akryukov
23.08.2019 13:27Справедливости ради, тут не такое уж сложное задание. Только рекомендации получились неочень.
GreenBeasT Автор
23.08.2019 13:29В здравом уме и твердой памяти никто не возьмет на должность мидла разработчика без опыта работы. Не вводите, пожалуйста, людей в заблуждение. А нам удача в поиске не нужна. Мы вполне закрываем свои потребности в стажерах.
Matisumi
23.08.2019 13:39Если человек может написать все так, как указано в ваших пунктах — я уверен он сможет написать и более сложную программу без особых проблем. И тогда, спрашивается, зачем ему идти к вам джуном, если он может пойти куда-то на более высокую позицию, показав там свои скиллы на тестовом?
Izaron
23.08.2019 14:03При всем скептицизме, список в посте из 14 пунктов — это нифига не миддл, даже не близко… Ну кроме 7 пункта, там пусть менеджеры спорят, какого цвета должно быть меню.
GreenBeasT Автор
23.08.2019 16:56Нет, быстро не способен — нет опыта. И это всего лишь знание java core, принципов ООП и SOLID. Ничего тут сверх естественного нет. И люди идут, быстро развиваются, получают знания и опыт и вливаются в работу.
Izaron
23.08.2019 13:53Учитывая, что вы претендуете максимум на джуна, чаще всего у вас еще недостаточно опыта, чтобы использовать чужой код.
Все равно намного лучше использовать что-то уже готовое, желательно использующееся повсеместно в компаниях. Гораздо лучше, если кандидат, например, знает про Bean Validation API и напишет
@Email(message = "Email should be valid") private String email;
Чем если он герой соцтруда и ударно импортозаместит наш ответ империалистическому bicycle.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода.
Дед Мазай может убить всех зайцев одним махом:
- Убрать трату времени на проверку работоспособности
- Избавиться от исследования жестокой лапши кода (архитектура проекта не так проста для кандидатов)
- Заставить всех следовать тестам
- Заведомо получить как-то работающий результат.
Если заранее написать множество хороших тестов, которое программа должна проходить после написания кода (использовав Test Driven Development).
GreenBeasT Автор
23.08.2019 14:13-1Я способен быстро отличить кратко и емко написанный код, от спагетти кода. По поводу готовых решений, не нужно ставить опытного разработчика на одну ступеньку со стажерами.
Все равно намного лучше использовать что-то уже готовое, желательно использующееся повсеместно в компаниях. Гораздо лучше, если кандидат, например, знает про Bean Validation API
Да, лучше, но как показывает практика, это пока за гранью понимания стажеров.
Убрать трату времени на проверку работоспособности
Проверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?Izaron
23.08.2019 15:01По поводу готовых решений, не нужно ставить опытного разработчика на одну ступеньку со стажерами.
Проверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?Ну и зря. Моя позиция такова, что относиться по-человечески и уважать надо всех. К стажерам это даже в большей степени относится.
GreenBeasT Автор
23.08.2019 17:05Поверьте, я просматриваю все задания, просто не весь код сливаю и запускаю. Я пишу фидбеки всем, но когда я вижу, что все написано в спагетти — я уже не копаюсь в валидаторах и решениях и не пишу индивидуальный фидбек. Тут фибек уже будет общего плана. Что-то на вроде: «вам необходимо лучше разобраться в принципах ООП и SOLID».
vrag86
23.08.2019 14:01Проблема ваших рекомендаций в том, что это только «ваши рекомендации». Все, что не описано в ТЗ, это просто ваши мысли и человек, выполняющий тестовое задание, их не знает. Считаю, что если вы не описываете какие-то условия в ТЗ (использовать несколько классов, проверить данные на корректность при вводе, добавьте readme), то все это не должно иметь никакого значения при принятии решения. Ваше задание можно сделать и за 1 час и за 40 часов, если нет конкретики по требованиям
GreenBeasT Автор
23.08.2019 17:53Следуя вашим суждениям в ТЗ должно быть написано: “приложение должно быть написано в стиле ООП и по принципам SOLID”. Однако… это же java. Плюс, это же самые распространенные вопросы на собеседовании и, на мой взгляд, это каждый разработчик должен понимать и писать код в соответствии с ними по умолчанию (и если он не вспомнит на собеседовании как какой принцип называется, ничего страшного в этом нет).
y90a19
24.08.2019 06:43Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
tandzan
Это все за час реально сделать?
Прошу, даже призываю, экономьте время соискателей тоже. Если задание займет более часа моего времени, то я скорее всего от него просто откажусь. Тратить дни и недели на незнакомца, который даже фидбек не пришлет, ИМХО не разумно.
qwez
Сказано, что час опытного специалиста, у него все пункты автоматом будут соблюдены. Джун, конечно, может и больше потратить, но на то он и джун. Если место достойное, то можно и неделю потратить. Конкуренция на рынке начинающих программистов не в пользу последних.
AGhostik
Я бы даже добавил, что джуну полезно будет разобраться в задаче. Особенно если задание выдали не абы какое, а близкое к реальной предстоящей работе.
Ну, очевидные вещи написал :)
Timuch
Если человек претендует на место джуна, то он и неделю может это делать. На то он и джун)
GreenBeasT Автор
Фидбек будет всем, но подробный, только с хорошим кодом.