Тут однозначного ответа на этот вопрос нету. В принципе, были собесы из разряда «кода на бумажке» и обсасывания каждой из букв SOLID и прочего «интересного». Так же было недоумение насчет моих ответов на вопрос по поводу различных хитрых особенностей того или иного синтаксиса языка из разряда «зачем зубрить наизусть то что используется не каждый день и гуглится за 10 секунд». К тестовым у меня была неприязнь по одной простой причине. По крайней мере у меня так получалось, пока я менял работу, я закрывал все дела на старой. И времени физически не хватало на это. Это же не просто нужно наваять «курица лапой», а сесть, подумать и расписать как можно лучше, еще желательно на свежую голову. И как мне кажется, давать что то реальное которое потом будет использоваться на проекте в качестве ТЗ не сильно гуманно. Что в плане времени, что в плане оплаты труда. А решение сферических коней в вакууме адекватной картины не дает, да и платить каждому человеку исполняющему ТЗ тоже компании не с руки. Так же не является минусом отсутствия у человека пет проектов и гитхаба. Скорее всего у человека есть еще личная жизнь и другие увлечения помимо программирования в свободное время и это, о ужас, нормально.
Обычно практика кучи собеседований + ТЗ в больших конторах делается чтобы отсеивать больше народу и брать людей под какие то узкие конкретные задачи. А так как если ты например Амазон, то тебе резюме падают сотнями в день если не тысячами и с этим надо что то делать.
В реалиях же более скромных можно ограничиться подробным тех интервью и испытательным сроком. Так будет честно и выгодно обеим сторонам. Но это мое сугубо личное.

Очень полезная статья. Но есть нюанс. Весь мрак кроется в деталях, а конкретнее в составлении требований, построении архитектуры продукта и тд. Если на этапе проектирования и планирования не учтено все до мелочей(до определенного адекватного порога естественно) то сколько времени в буфер не закладывай выйдет натягивание совы на глобус. Потому что не учтенные но важные мелочи собираются в один большой ад в самом конце и оттягивают сроки.
И еще надо понимать риски не только материальные такие штрафы по дедлайну, вылеты из бюджета и так далее, а еще и психологические. Потому как с каждым днем прошедшего дедлайна настроение в команде меняется не в лучшую сторону что сказывается на общей продуктивности. Ок, можно в экстренных ситуациях сидеть по ночам и разгребать это, но потом можно не удивляться почему сотрудники выгорают и сваливают. Прочувствовал это на своей шкуре с одной и с другой стороны «баррикад».