Comments 25
Наша компания, как и многие другие, предлагает после устного собеседования сделать тестовое задание.
В печку и вашу компанию "и многие другие" :)))
Вы безработный? Последних лет так пять я не устраивался на позицию сеньёра или выше без тестового.
Поздравляю, вы наверное в гугле,Фейсбук или эпл работали? Там да, конкуренция большая и требования жёсткие. Тестовые задания выполнять надо. Большая там зп?
За последние 5 лет я не устраивался ни на одну работу, где надо было делать тестовое. Ну, я тупо игнорировал эти места. Мне просто надоело. Ибо какого хрена, я вот 10 лет работаю, да хуже того - я работаю прямо сейчас где-то, и меня никто не увольняет. И ни разу не увольняли. Более того, могу даже отправить к людям, которые дадут рекомендации. Это не доказывает, что я могу писать код? Что ж, нам не по пути.
Да, в какие-то наукоёмкие проекты, требующие специфической квалификации или, быть может, особенного образования - действительно имеет смысл дать тестовое, чтобы понять, что человек чего-то понимает в вопросе. Но ведь не у всех R&D. И не все предлагают какие-то космические условия по деньгам. Так что если я ну прям очень хочу в проект, я соглашусь на тестовое, в остальных случаях - пусть идут лесом)
Так здравый смысл. Я ниже ровно про тоже и написал. С опытом прохождения собеседований появляется интуиция и навык, которые позволяют оценивать: стоит ли тестовое задание свеч или нет. Кстати, 3 компании назад как раз в R&D и работал, и там тоже требовалось тестовое задание где-то на 2 часа.
Коротко: если компания ищет мидл разработчика за еду с обязательным тестовым заданием, то очевидно, что туда не нужно собеседоваться. Или я в чём не прав-то?
Если и не правы, то только в категоричности суждений (если я вас правильно понял). Т.к. бывает по-разному. Моих два последних найма на сеньора, например, без тестовых и в один раунд, причем по времени это заняло 10 и 40 минут соответственно, с последующими офферами. Но я не распространяю этот частный опыт на все возможные наймы, лишь констатирую вариант развития событий.
У меня категоричность? Вы самый первый комментарий в этой ветке читали?
Я всего лишь пытаюсь альтернативное мнение представлять. Я бы вообще прошёл мимо комментариев, если бы не первый комментарий.
Понятно, что бывает по-разному со стороны соискателя. Плюс, я написал опыт/взгляд со стороны нанимателя. Не стоит считать, что все люди одинаковые. За время, когда я участвовал в отборе, я насмотрелся на разных, поэтому могу взвешенно оценить практику с тестами.
Почему человек с подтверждённым опытом работы, и выявленными пусть и теоретическими знаниями на собеседовании, должен делать работу бесплатно? Для чего существуют все эти испытательные сроки и прочее? Да и вообще зачем нужны hr тогда? Рассылайте тесты. Кто сделал, убив пару дней на различные задания, тот молодец и может быть, будет принят в нашу конторку. Остальным спасибо, вы поработали бесплатно, повезёт в следующий раз.
Я был по обе стороны: и нанимал, и проходил собеседования.
- Когда нанимал, я вообще жёстко фильтровал людей - общение только после тестового задания. Это мне высвободило 90% времени, которое ранее я затрачивал на "фантазёров", которые на словах мастера, в 25 лет обладают 10 летним опытом, работали над "крупными проектами", а доходя до элементарных вопросов по стеку или до простых задач, плыли как неподготовленные школьники на экзамене. Да, ЗП были большие, желающих было много.
- Когда собеседуюсь, то я всегда смотрю на тех, с кем общаюсь, если это тупо HR и компания готова сделать предложение, так как я прохожу по профилю, отказываюсь. Это говорит лишь о дикой текучке либо работа будет связана с чем-то, с чем люди не хотят работать. Если собеседуюсь и вижу: токсиков на собеседовании, отсутствие пунктуальности, не отвечают на мои вопросы, которые касаются работы и будущих коллег - тоже лесом; в компании есть проблемы в коллективе. Если на техн собеседовании оч вялые вопросы или нет интересного тестового - оставляю в выборке предложений, но смотрю дальше, так как для меня важно понимать, с каким уровнем задач я буду сталкиваться; я не хочу тупо таскать задачки и править буковки в коде.
imho если тестовое задание требует несколько дней для исполнения, оно должно оплачиваться (у меня таких было несколько и делал с удовольствием, так как они были и сложные, и интересные, к тому же с предсказуемой оплатой; одно тестовое было 1 месяц, оплата была больше моей ЗП в 3 раза, делал по вечерам, тестовое прошёл, финальное собеседование с руководителем нет). Если тестовое меньше 8 часов, то нужно оценивать компанию и тестовое задание - это компромисс.
Говорить кардинально, что тестовое - это плохо, я бы не стал.
Но допускаю, что много людей сталкивалось с плохими компаниями, у которых найм был через одно место. Тут могу сказать, что навык отбора таких компаний приходит с опытом: чаще собеседуйтесь, будет интуитивно понятнее, какая компания не подходит и их тестовое лучше не делать.
Скажите, а зачем вы даете тестовое задание, чтобы что? Вам недостаточно просто поговорить? Ваши 8 пунктов говорят только о том, что у этих людей другой стиль написания тестов, чем принято в вашей компании (и вы даже про это сами говорите).
В моем понимании, единственное тестовое задание, которое может быть, это опросник/задачка, чтобы HR отсеивал совсем никаких
Добрый день! Как написано в статье, тестовое проверяет не столько стиль кода, сколько, скажем так, ход мысли человека. Стиля кода, пожалуй, касаются только пункты про засовывание нескольких тестов в один (но есть же атомарность, которая на стиль никак не влияет) и про “говорящие” названия тестов и переменных. Не думаю, что, например, отсутствие в тесте адекватной проверки является различием в стиле – это неудачный тест. Если бы результаты устного собеседования всегда совпадали с результатами тестового, то мы бы, полагаю, от него отказались. Но, увы, пока что это не так. К примеру, по нашей статистике из дошедших до теста и выполнивших его кандидатов похвастаться удовлетворительным результатом могут не более 30%.
Так может вам устное подтюнить, пока не станут совпадать результаты? Кажется, что ход мысли человека вполне себе можно узнать на собеседовании.
Вы же понимаете, что тестовое задание - отталкивающий кандидата фактор? Были хорошие кандидаты, которые отказались делать или забили, согласившись?
На устном собеседовании кандидаты часто подвержены волнению, и на какие-то вопросы, проверяющие то же, что тестовое, могут не ответить. Не по незнанию, а просто из-за усталости, напряжения, формата вопрос-ответ или чего-то другого.
У нас были кандидаты, которые на тестовом показали себя лучше, чем на собеседовании. К тому же на устном собеседовании есть ряд классических вопросов, ответы на которые можно заучить, произвести хорошее впечатление, а потом посыпаться в задании.
Конечно, есть кандидаты, отказавшиеся делать тестовое, но на удивление их было крайне мало.
Как написано в статье, тестовое проверяет не столько стиль кода, сколько, скажем так, ход мысли человека.
На деле оно проверяет только степень занятости проверяющего, и еще то, с какой ноги он встал с утра. Можно подумать, что кто-то из специалистов реально будет разбираться в чьем-то чужом коде (практическая ценность которого равна нулю) когда своего собственного кода в работе выше крыши. Скорее всего вообще кинут его не глядя в корзину и сделают отписку либо: "ОК." либо: "Говнокод." (лично я когда-то так всегда и делал :D).
На деле оно проверяет только степень занятости проверяющего, и еще то, с какой ноги он встал с утра.
Актуально для всех этапов собеседования.
Можно подумать, что кто-то из специалистов реально будет разбираться в чьем-то чужом коде
Это тесты на API, там не должно быть сложности. Если всем дают одинаковое здание, то проверка должна занимать минут 10.
Скорее всего вообще кинут его не глядя в корзину и сделают отписку либо: "ОК." либо: "Говнокод." (лично я когда-то так всегда и делал :D).
Если не времени сделать нормально, надо говорить Нет.
"6. Рандомизация в тестах". Вам там property-based testing https://en.m.wikipedia.org/wiki/Software_testing#Property_testing и фаззинг https://ru.m.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B7%D0%B7%D0%B8%D0%BD%D0%B3 показывают, а вы отнекиваетесь, что "не надо писать рандомизированные тесты". Надо. Надо их писать. Вот пример с недавнего Гейзенбага: https://youtu.be/fbhuzSpyUJc.
Почти в любой системе количество входных данных таково, что полный перебор всех возможных вариантов никогда не закончится. И рандомизация (особенно, если она с учётом граничных значений, coverage guided, и так далее) может тестировать новые и новые данные с каждым запуском. Всех случаев не проверишь но 1-5 минут рандома на каждый pull request и рано или поздно ошибка найдётся.
Мы не то чтобы совсем отнекиваемся от этих тестов. Как было сказано в статье, иногда этот подход уместен. И у нас такие тесты тоже есть. Но на мой взгляд, и фаззинг, и рандомизация не самодостаточны и часто подходят скорее для исследования. Сначала очевидные детерминированные кейсы, потом уже можно и рандомизированные добавлять для поиска новых. Так и наши рандомизированные тесты идут “вместе“, а не “вместо“. В приведенном примере же был только рандомный тест, без простых тестов со строгим поведением.
Фаззинг нужная и полезная штука, но до неё нужно дойти на практике.
Шестой раздел статьи очень сомнительный, согласен.
PS За видосик спасибо, было полезно
але есть ручники которые пишут последовательность шагов, есть автотестер который это автоматизирует, зачем мне эти ваши тестпланы, граничные значения и тд. моя задача автоматизировать тесты, разделение труда придумали очень давно , каждый занимается тем что ему нравится, если вам нужен и чтец и жнец и на дуде игрец, то получите грустного и замученого колегу через пару месяцев. Всегда посылал такие "универсальные" предложения, где надо 50 на 50 и тест план продумать и тест кейсы писать и автоматизировать, а потом ещё регрес со всеми ночью, мы же дружная командаааа!.
Один наш кандидат добавил в тестовое и логирование, и потоки, и даже
скромный нагрузочный тест (хотя всего этого в задании не требовалось),
но, к сожалению, не прошел, так как с полнотой покрытия его тесты не
справлялись. Возможно, если бы он сфокусировался сперва на кейсах, а
потом уже на демонстрации остальных своих умений и возможностей, сейчас у
меня был бы крутой коллега.
В целом статья интересная, с некоторыми пунктами согласен, но вот с этим не согласен прямо сильно. Я не считаю, что задача в тестовом - обеспечить максимальное покрытие. Если у вас иначе, это стоит прямо явно обозначать кандидату. Дело в том, что время на выполнение тестового всё-таки ограничено. В реальной жизни я бы, например, потратил на покрытие данного функционала тестами N времени, потому что мне за это платят, а в случае с тестовым я готов бесплатно потратить только N/4. То есть тестовое для меня - это некое демо того, что я могу. А в демо логично постараться показать максимум своих возможностей, пройдясь по ним по верхам. Я считаю, что имеет смысл скорее показать владение несколькими эффективными подходами, уделив каждому немного внимания, чем максимально покрыть функционал однотипными тестами. А то, что тут можно ещё и это проверить, и то, и вот это, можно просто обозначить одной строчкой, например - сделать кучку пустых тестовых функций с названием и без реализации или даже комментарием написать. Я почти не сомневаюсь, что вы сделали глупость, упустив того потенциального коллегу, который показал вам широту взглядов и умений вместо того, чтобы закапываться в очевидные для него вещи.
Фу, тестовое. Или 8 ошибок в заданиях для QA на живом примере