Take-home встречается не везде: чаще при потоке откликов, на middle-ролях и в компаниях, где важен стиль кода в репозитории. Форматы — мини-сервис, рефакторинг легаси, интеграция с API, фикс бага в открытом фрагменте кода. По времени в ТЗ часто пишут 2–8 часов; календарный срок — от суток до недели.
Что реально оценивают
- соблюдение требований и разумный scope (не «переписать всё»);
- читаемость, структура проекта, именование;
- тесты хотя бы на критичные пути;
- README: как запустить, что сделано, что бы улучшили с большим временем;
- коммиты и история, если просят git.
Идеальная архитектура на 20 микросервисов для трёхчасового ТЗ — признак неумения приоритизировать, а не силы.
Красные флаги в задании
- ожидание полноценного продукта за выходные без оплаты;
- доступ к закрытому коду «как к стажировке» без оффера;
- отсутствие чётких критериев приёмки;
- бесконечные итерации «доработайте ещё» до техсекции.
Вежливый отказ с объяснением — нормальная практика. Иногда компания предлагает оплату или сокращённый вариант — это здоровый знак.
Как сдать сильно
- Перечитайте ТЗ и выпишите must-have vs nice-to-have.
- Сделайте must-have с тестами и инструкцией запуска.
- В README опишите trade-offs: почему SQLite, а не Postgres, и т.д.
- Оставьте 2–3 пункта «сделал бы при +1 дне» — покажет зрелость.
Связь с другими раундами
На технической секции часто разбирают ваше тестовое построчно — будьте готовы защищать каждое решение. Если тестового не было, live coding заменяет эту проверку. Для senior иногда вместо take-home дают углублённый system design.