Это продолжение первой статьи (тык), где я рассказывал, как важно «упаковывать» свое решение.

Там были очень важные советы о том, какой контент и какая повестка должна окружать проверяющего при изучении твоей работы.

Теперь же переходим к более тонким, конкретным и технических вещам. Расскажу про то, что должно быть в твоем тестовом, чтобы не просто пройти дальше, а вызвать сильно наитие с тобой пообщаться.

💡 Важно!

Сколько раз ты нажимал кнопку на сайте и думал: «Зависло или грузится?» Сделай нормальный лоадер и избавь проверяющего от этого вопроса. Это еще и повод бахнуть interceptor, что только в плюс.

Если в ТЗ ничего не сказано про адаптив — сделай. Никто не хочет открывать твое тестовое в туалете и видеть поехавшую верстку.

Нет дизайна? Не используй стандартный Times New Roman, ты не в Word’е работаешь. Добавь нормальный шрифт, сделай красиво.

Добавь хоть что-то: плавную навигацию, мелкие эффекты, даже банальный opacity. Но не просто на CSS, а через @angular/animations. Так ты покажешь, что умеешь работать с движком Angular.

Если времени в обрез — редирект на главную. Если время есть — сделай нормальную кастомную страницу с 404-ошибкой. SSR? Пусть сервер реально отвечает 404, а не просто SPA-шка рендерит что-то.

Если язык не указан — бери язык вакансии. Если русская вакансия, но твое тестовое на английском — добавь русский. И обязательно используй ngx-translate. Никто не пишет тексты в HTML в нормальных проектах.

Если SSR ты предусмотрел — сделай, чтобы метатеги обновлялись при смене языка. Описал это подробно в первой части, не поленись прочитать.

Выделись. Тестовое с дефолтным Angular-логотипом — это сразу минус в карму. Закинь favicon.ico, это занимает 3 секунды.

Забудь про jpg и png. Используй webp и avif. Они меньше весят, грузятся быстрее, Google их любит. У avif лучше сжатие, но хуже поддержка браузерами. Почитать про их поддержу можно здесь: avif, webp.

Если есть авторизация, не давай гостю лазить туда, где он не должен быть. Используй CanMatch и другие гварды.

В 2025 году делать без ChangeDetectionStrategy.OnPush — это уже зашквар. А чтобы выделиться - добавь provideExperimentalZonelessChangeDetection. Сам проверяющий, возможно еще с эти не сталкивался.

Реальные проекты без ленивой загрузки — редкость. Делай loadChildren, loadComponent, чтобы не грузить все сразу.

ТЗ не говорит, какой стейт-менеджер использовать? Бери NgRx. Он самый популярный, и это очевидный выбор. Вот здесь сравнение его с конурентами. Используй новый пушечный Signal Store, он уже в продакшене.

Используй ngSrc, если грузишь картинки. Angular сам разберется, когда их подгружать, вместо тебя.

Вообще не обсуждается. Сделай ng lint, убери варнинги, настрой форматирование. Код должен быть идеален.

Пропиши алиасы в tsconfig.json, никто не хочет видеть в коде:

Если твой проект не запускается за минуту — ты облажался. Опиши в README.md, как установить зависимости, как запустить и что вообще ты сделал.

Добавь unit-тесты на важную логику. А если есть время — еще и E2E на базовые сценарии. Ты не должен оставлять впечатление, что твой код сломается при первом же изменении.

Добавь в GitHub Actions хотя бы простую проверку сборки и линтера. Покажи, что ты знаешь, как работают CI-пайплайны.

Перед тем, как сдать тестовое, проверь:

✅ Нет ошибок в консоли

✅ Нет ошибок в запросах

✅ Нет ошибок в терминале и при сборке

✅ Нет лишних запросов

✅ npm install не выдает ошибок и варнингов

✅ ng lint проходит без проблем

✅ Lighthouse 100/100/100/100 (angular 19 + ssr - это реально). Вот мой стартовый проект:

✅ Open Graph настроен (проверить здесь)

✅ HTML валидный (проверить здесь)

Если ты сделаешь хотя бы половину из этих пунктов и финальную проверку — твое тестовое будет на голову выше большинства. А если все 20 — оно будет незабываем и превратиться в первое свидание.

В следующей части я расшарю свой стартовый проект и сделай полный обзор на него. Соответственно, ты сможешь его форкнуть, если не хочешь писать свой и начинать делать тестовые уже с  🚀🔥