Comments 83
Прошу, даже призываю, экономьте время соискателей тоже. Если задание займет более часа моего времени, то я скорее всего от него просто откажусь. Тратить дни и недели на незнакомца, который даже фидбек не пришлет, ИМХО не разумно.
Сказано, что час опытного специалиста, у него все пункты автоматом будут соблюдены. Джун, конечно, может и больше потратить, но на то он и джун. Если место достойное, то можно и неделю потратить. Конкуренция на рынке начинающих программистов не в пользу последних.
даже фидбек не пришлет
Фидбек будет всем, но подробный, только с хорошим кодом.
Зачем писать хороший код в приложении с 1-2 сущностями?
Оно же маленькое?
Чтобы показать, что вы умеете писать хороший код. Не нужно путать ТЗ для
разработчиков с опытом и стажеров, только-только познавших java-core.
Так что для нас, лучше взять человека, который понимает принципы SOLID не только теоретически. А руку на скорость он набьет, мы ему дадим такую возможность.
Интересно, что пункты 1 и 2 противоречат друг другу.
Не додумывайте своих полей у сущностей, не меняйте условия валидации и тд. и тп.
А потом сразу
Постарайтесь сломать свое приложение, ввести не валидные данные, данные максимально похожие. Не забудьте только исправить все, что найдете.
Пункт 6 тоже интересно сочетается с пунктом 1.
Добавьте в корень проекта readme.md файл. Вкратце опишите свое приложение, выложите дополнительные пояснения для запуска, если необходимо.
Если делать строго по ТЗ, то в readme будет это самое ТЗ.
Переходы по меню должны быть удобными, например при помощи цифр. А то иногда реализуют так, что для удаления сущности нужно ввести в консоли «Delete».
А как же ТЗ?
ТЗ в основном это просто 3-4 пункта описания функционала. Всякие "мелочи" вроде проверок, валидаций, особенностей интерфейса не указывают.
Если делать строго по ТЗ, то в readme будет это самое ТЗ.
возможно, но если использовали в качестве сборщика, к примеру мавен, и для запуска нужна команда, ее пишут тоже там. И даже если там будет просто ТЗ, это будет плюсом, если код хороший, а соискатель не прошел собеседование.
Множество невалидные данных может быть гораздо шире, чем вы описали в ТЗ. Если ввести то, что по смыслу невалидно, но при этом не описано в ТЗ, то получается противоречие с пунктом 1.
Множество невалидных данных все равно может быть шире, чем вы описали в ТЗ. Пускай для телефона требования исчерпывающие. Но это ведь не единственное значение, которое вы получаете от пользователя. В других требованиях вы могли что-то упустить и там все равно получится противоречие в 1 и 2 пунктах.
Вы эти рекомендации позиционируете как универсальные или "для вашей компании"? Если первое, то они должны подходить не только к вашему конкретному ТЗ, но и к возможным ТЗ от других компаний.
Если второе, то о какой компании речь? Зачем публично выкладывать рекомендации для попадания в вашу конкретную компанию?
А вы почитайте, думаю вам будет не лишним: принципы SOLID
Каким образом ссылка на принципы SOLID опровергает мой тезис?
Если вы позиционируете советы для всех стажеров/джуниоров, то пункты 1 и 2 противоречат друг другу в тех тестовых заданиях, где ТЗ неполное.
то пункты 1 и 2 противоречат друг другу в тех тестовых заданиях, где ТЗ неполное
Как может п1. где говорится что
приложение должно работать в соответствии с ТЗможет противоречить п2. где говорится:
Кропотливо проверяйте выполненную задачу
Или вы не понимаете разницу между тем как делать, и как после этого тестировать свое консольное приложение? Как вообще могут противоречить советы по выполнению советам по проверке? По моему все достаточно четко. Сначала сделал, соответствуя спеке (п1), затем проверь, что все работает согласно ей же (п2). А ТЗ достаточно полное, четкое и простое до боли.
Одному надо «не додумывайте», другой хочет инициативу.
Одному надо «не делайте в один коммит», другого интересует только прохождение тестов.
Одному надо «удобное меню, юзер френдли», другой напомнит: «не додумывайте».
Одному надо пять пакетов с десятком классов в каждом, другой скажет: «Ты с ума сошел, fizzbuzz с пятью классами и двумя пакетами?»
Одному надо коллекции вместо массива, потому что не надо экономить память, другому надо экономить память.
Одному тесты — это задача со звездочкой, другому — обязательное требование, третий сам тесты предоставляет.
Допишите уж в заголовке: "… в мою компанию" или "… через меня".
"Зачем экономить память в приложении с 1-2 сущностями? Если приложение маленькое, удобнее использовать коллекции, вместо того чтобы возиться с массивами"
И эти люди, не видя ни строчки моего кода, предполагают, что я привык к гов… коду? Спасибо за переход на личности, это отличный показатель.
А ещё так. Приходит юниор с горящими глазами, говорит: "дайте мне задание" Ему в ответ: "А сыграй, пардон, напиши так, чтоб душа, пардон, связный список сперва развернулся, а потом свернулся." И пишет он, болезный, стараясь экономить о большое и память. А ему говорят: "приложение-то маленькое, что ты жмешься, только линкед лист, только хардкор! (И не забудь переопределить сетхеш)" "Ах, маленькое...", думает юниор, и пишет как маленькое. А ему — "Ну, не настолько же маленькое! Пакетов надо минимум три, классов в каждом хотя бы пять!" И пошел бедный юниор с покалеченной психикой раздумывать над философским смыслом Java-термина "маленький"...
К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких
классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?).
Какая связь принципов ООП и расположения в одном пакете?!
Пусть вам кажется, что задача небольшая не забывайте — задание тестовое, а java в первую очередь объектно ориентированный язык.
Задача "валидацию emil и телефона, по заданному шаблону" и ООП с разбросом классов по отдельным пакетам. Вы шутите?
Да. Если платят за количество строк, то можно и расписать такую задачу… Эх размахнись плечо в рамках ООП с разными пакетами.
вынесите константы в ENUM.
С чего вы решили, что ENUM это самое удачно решение. Иногда удачно. Иногда нет. С мотря где и зачем.
Критерий "константы не вынесены в ENUM" — тест провален… У меня нет слов.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода.
Хм. Если бы мне такое надо было и кандидатов было бы… ну скажем больше 10. Я бы написал за эти 30..40 минут автотесты, включая автоматическую выкачку с Git
А в ТЗ четко бы определил API. Судя по фразе "Задание обычно содержит..." это как раз подходящий случай.
Кропотливо проверяйте выполненную задачу
И странно, что ни словом не упомянуто JUnit в качестве требования к готовой реализации.
И "Если умеете, напишите тесты, но это уже задача со звездочкой" это не звездочка… Это минимум. Особенно на фоне всего остального.
Остальные пункты (по переопределению equals & hashcode в демонстрационных целях и использованию где надо и не надо коллекциями) очень хочется тоже комментировать, но вежливых слов не хватает.
Однако, вы телепатов ищете. Которые знают что конкретно Вы от них ждете!
Причем не в области ТЗ, а в области "я так вижу как должен быть оформлен код".
Какая связь принципов ООП и расположения в одном пакете?!
Читаете между строк?
весь код сконцентрирован в нескольких классахдля вас это нужно жирным выделить было? Или вы не знаете как писать ООП приложение?
Критерий «константы не вынесены в ENUM»Где написано что тест провален?
Если бы мне такое надо было и кандидатов было бы… ну скажем больше 10. Я бы написал за эти 30..40 минут автотесты, включая автоматическую выкачку с GitОчень смешно.
Однако, вы телепатов ищете. Которые знают что конкретно Вы от них ждете!Кто ясно излагает, тот ясно мыслит.
Причем не в области ТЗ, а в области «я так вижу как должен быть оформлен код».
Вы вообще когда-нибудь проверяли чьи-то задания? Очень похоже, что статью вы читали сугубо поверхностно, нравится потролить, хотя сами ни одного выполненного задания даже в глаза не видели, не вижу смыла вам что-либо дальше объяснять.
Читаете между строк?
Ээ… я Вас же процитировал? Ваши слова: "К примеру, открыв решение на гитхабе я вижу, что весь код сконцентрирован в нескольких классах да еще и наваленных в одном package — быстрый отказ (как же принципы ООП?). "
Где тут между строк то..
Очень смешно.
Выдать ТЗ с четким описанием API и подготовить набор тестов для проверки — что в этом смешного?
А вообще, в стандартном цикле разработки, блок кода фиксировать как законченный без внутренних юнит тестов — моветон. А по хорошему и внешние тесты должны прилагаться, если есть возможность.
Вы вообще когда-нибудь проверяли чьи-то задания?
Регулярно. Когда в свой отдел народ собеседую. Хотя мерятся пс… ками в комментария — то же моветон.
P.S. Остальное без комментарий… Вас не смущает общая оценка статьи?
Вас не смущает общая оценка статьи?
Нет, оценку ставят такие как вы, тролли.
А вас не смущает количество людей добавивших статью в закладки? Это начинающие разработчики, и они скорее всего просто не имеют права голосовать на Хабре, поэтому оценка и ушла вниз.
В статье я выложил вполне дельные советы начинающим разработчикам. Все, кто помнит, как то — джуном искать работу, статью оценят. Вам же, если вы вообще имеете опыт в Java порекомендую книгу Роберта Мартина «Чистый код», если ее не читали.
А по теме… Не, если вы все эти рекомендации к ТЗ прикладываете — честь вам и хвала. А вот если нет… Не раз например встречал мнение что на таких заданиях наоборот стоит максимально упрощать а не городить классы с пакетами, это же тестовое а не продакшен, FizzBuzzEnterpriseEdition уже мемом стал. Да и к асимптотике алгоритмов и памяти бывает прикапываются (у вас же наоборот). А еще бывает в каких то компаниях заворачивают решения с библиотеками «мы хотели посмотреть как сами думаете» а в других «зачем велосипеды, есть же leftpad в npm». Будьте честными, это требования именно вашей компании, хотя не удивлюсь даже если окажется что только вашего отдела. В других компаниях все может быть, и нередко бывает, иначе.
например встречал мнение что на таких заданиях наоборот стоит максимально упрощать а не городить классы с пакетами, это же тестовое а не продакшенЭто задание достаточно легкое по логике, и задание для стажера. Поэтому, если стажер уже считает, что может не придерживаться основных принципов ООП при написании кода на java, о которых написано на каждом столбе… Ну не знаю даже, что еще тут сказать.
Выдать ТЗ с четким описанием API и подготовить набор тестов для проверки — что в этом смешного?
АПИ в консольном приложении? Серьезно?
Хорошо читабельный код, по моему мнению — имеет неоспоримое преимущество перед портянками.
Очень многие за этими «помните об ООП» и «заюзайте как можно больше паттернов» забывают про то, что код должен в первую очередь решать бизнес-задачи.
Ваша компания работает с зарубежными заказчиками или коллегами?Да, в основном на зарубежных. На русском каждый может, если оставляете на английском — мы считаем это небольшим плюсом. Хотя для стажеров, на это почти не смотрим. В резюме обычно указан уровень английского.
«помните об ООП» и «заюзайте как можно больше паттернов»
Вы мыслите как сложившийся разработчик при подходе к решению бизнес задачи, и я согласен что порой нужно просто что-то быстро написать и доставить, но мы имеем код стажера, который в первую очередь, должен показать его знания.
Мы тоже даём тестовое задание. Только оно проще на порядок. И первое, на что смотрим, — это тесты. Нет тестов — до свидания. Даже если это junior.
так пробелы или табы?Вы о чем вообще? В ТЗ все валидации и все условия обычно точно описаны.
вы не можете дать точный ответ на простой и краткий вопросВопрос вообще не относится к теме. Не нужно путать оформление кода и структуру.
Где тут телепатия?
вы из тех кто пишет классы по 100500 строк которые все делают?Так что с ответами?
Хотя, мне кажется, от вас такого ответа не дождусь, так как к java вы никакого отношения не имеете (java и javascript это разные вещи, если что). А вы, как я вижу, так чисто, пошлепать зашли.
ps не поленился заглянуть в профиль.
Когда вы выбираете какой-нибудь товар, вы же стараетесь выбрать получше, если выбор огромен-не?
Так и тут — выбор достаточно большой и в статье лишь описаны способы, как свой товар (свое выполненное ТЗ), сделать более привлекательным.
Хорошо, представьте что вы считаете себя профессиональным разработчиком ПО. Получаете задание создать приложение, которое читает два числа с консоли и печатает их сумму. Ввод и вывод должны быть римскими цифрами.
Я почти уверен, что в приложении будут функции разбора и генерации римских цифр. Будет очень очень странно, если профессиональный разработчик, даже junior не догадается покрыть их тестами.
Часто
По-моему, это очевидные вещи. В нашем случае речь идет о Java. Любой, кто считает себя профессиональным java-разработчиком, знает о build-системах и пользуется ими. Будет очень странно, если разработчик выполнит
gradle init а потом сознательно, отдавая себе очет в том, что делает, удалит папку src/test.
Последний год также смотрю тестовые задания, но на C#. Задание алгоритмическое — сериализация-десериализация, делается минут за 10 в 50 строк красивого кода (джуны растягивают на несколько часов и сотни строк кода).
Требования просты: написанный код должен решать поставленную задачу. Оформлять можно как угодно, хоть скриншот в .doc файле. Обычно я просто смотрю код, делаю код ревью. За последние полгода присланный код я запускал один раз — не мог поверить что человек прислал неработающую программу. Если в коде кол-во проблем не выходит за рамки приличия, то человек приглашается на собеседование, где ему будут также заданы вопросы про эти проблемы.
Совет "Старайтесь не сливать чужие решения" правильный. Все чужие решения сразу заметно, особенно когда в один день приходят два одинаковых теста. Я пробовал найти хорошее решение в открытых источниках, но у меня это не получилось. Если оно где-то и есть, то очень глубоко.
Задание обычно содержит реализацию CRUD методов в файл через консольное меню с одной-двумя сущностями плюс валидацию некоторых полей.
?
Или тестовое задание предполагает проверку способности конвертации потока сознания заказчика(начальника?) в код?
P.S. Извините, наболело.
Справедливости ради, тут не такое уж сложное задание. Только рекомендации получились неочень.
При всем скептицизме, список в посте из 14 пунктов — это нифига не миддл, даже не близко… Ну кроме 7 пункта, там пусть менеджеры спорят, какого цвета должно быть меню.
Учитывая, что вы претендуете максимум на джуна, чаще всего у вас еще недостаточно опыта, чтобы использовать чужой код.
Все равно намного лучше использовать что-то уже готовое, желательно использующееся повсеместно в компаниях. Гораздо лучше, если кандидат, например, знает про Bean Validation API и напишет
@Email(message = "Email should be valid")
private String email;Чем если он герой соцтруда и ударно импортозаместит наш ответ империалистическому bicycle.
Начав проверять все задания подряд, выяснилось, что на проверку работоспособности с запуском и фидбеком каждого задания уходит около 30 минут, пришлось пересмотреть методику проверки и вывести критерии для быстрого отсеивания недостаточно качественного кода.
Дед Мазай может убить всех зайцев одним махом:
- Убрать трату времени на проверку работоспособности
- Избавиться от исследования жестокой лапши кода (архитектура проекта не так проста для кандидатов)
- Заставить всех следовать тестам
- Заведомо получить как-то работающий результат.
Если заранее написать множество хороших тестов, которое программа должна проходить после написания кода (использовав Test Driven Development).
Все равно намного лучше использовать что-то уже готовое, желательно использующееся повсеместно в компаниях. Гораздо лучше, если кандидат, например, знает про Bean Validation APIДа, лучше, но как показывает практика, это пока за гранью понимания стажеров.
Убрать трату времени на проверку работоспособностиПроверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?
По поводу готовых решений, не нужно ставить опытного разработчика на одну ступеньку со стажерами.
Проверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?
Ну и зря. Моя позиция такова, что относиться по-человечески и уважать надо всех. К стажерам это даже в большей степени относится.
Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
К тому, же мне кажется что юниор(читай студент) просто не успел понять зачем это все, так как не писал, а главное не изменял больших программ. Да, конечно он может прочитать умные книжки и статьи, но осознать всю полезность — вряд ли. Хотя конечно бывают исключения.
Как выполнять тестовые задания для java- джуниоров/стажеров, чтобы попасть на собеседование