Матрица компетенций: Angular
Hard skills
Skill Passport — Frontend
JS/TypeScriptОбосновывает выбор между несколькими подходами к типизации состояния или архитектуре модуля (например, discriminated union вместо набора boolean-флагов loading/error/data, generic vs. function overload) — с указанием, какие альтернативы рассматривались и почему отклонены. Проектирует типы так, чтобы недопустимое состояние было невозможно выразить на уровне компилятора.
HTML/CSSОбосновывает выбор стратегии стилизации для проекта (CSS-in-JS vs. CSS Modules vs. utility-first) с указанием конкретного trade-off — размер бандла, runtime-стоимость, скорость онбординга новых разработчиков. Диагностирует и устраняет конфликт специфичности/каскада в большой кодовой базе (например, между независимо задеплоенными частями приложения).
State managementОбосновывает выбор конкретного паттерна управления состоянием (глобальный store vs. context vs. server-state библиотека vs. состояние в URL) под конкретный кейс, перечисляя рассмотренные и отклонённые альтернативы. Находит и устраняет причину конкретной проблемы — лишнего ре-рендера или рассинхронизации состояния между компонентами — в реальном приложении, а не методом проб и ошибок.
Производительность/оптимизацияФормулирует конкретный целевой порог метрики для проекта (например, «LCP ≤ 2.5с на симулированном 4G, потому что...») и предлагает план его достижения с указанием, что именно оптимизируется — размер критического CSS, время до интерактивности, объём общего бандла — и каким способом (SSR/SSG, предзагрузка ресурсов, разбивка бандла по маршрутам). Проводит аудит производительности прод-приложения (Lighthouse/WebPageTest) и приоритизирует находки по соотношению эффект/трудозатраты.
Тестирование (Jest/RTL)Обосновывает стратегию тестирования для фичи или проекта — что покрывается unit-тестами, что integration, что e2e (пирамида тестирования), а не «всё через e2e». Диагностирует причину нестабильного (flaky) теста — например, гонку при асинхронном обновлении DOM — и устраняет причину, а не маскирует симптом увеличением timeout.
Сборщики (Webpack/Vite)Обосновывает выбор или миграцию сборщика для проекта с измеримым эффектом (например: «миграция с Webpack на Vite сократила холодный старт dev-сервера с X до Y секунд»). Проводит анализ бандла через bundle analyzer, находит и устраняет дублирование зависимостей и настраивает tree-shaking для библиотек, которые не шейкаются по умолчанию (например, из-за отсутствия `sideEffects: false` в их package.json).
Кроссбраузерность/адаптивностьОбосновывает стратегию поддержки браузеров/устройств для продукта (например, на основе реальных данных аналитики аудитории — какие версии реально можно не поддерживать, какой полифилл нужен и почему). Проектирует решение для сложного кросс-платформенного кейса — например, учёт safe-area на iOS-устройствах с вырезом или поведение вьюпорта при появлении мобильной клавиатуры.
Accessibility (a11y)Обосновывает решение по доступности сложного кастомного компонента (например, select или datepicker) — что взято из ARIA Authoring Practices, а что упрощено и почему, с учётом того, как компонент будет вести себя со скринридером (NVDA/VoiceOver). Проводит аудит доступности продукта и приоритизирует находки по критичности (блокирует использование vs. косметическое замечание).
Angular (направление)Обосновывает архитектурное решение на уровне приложения — например, структуру feature-модулей с lazy loading по маршрутам, выбор между NgRx и сервис-based state management под конкретный масштаб команды и проекта. Диагностирует и устраняет утечку памяти от неотписанной RxJS-подписки в реальном приложении, объясняя механизм (а не просто добавляя `unsubscribe` наугад) — например, через `async` pipe, `takeUntil` или `DestroyRef`.
Soft skills
Skill Passport — Автономность и глубина
Автономность и масштаб задачОписывает случай самостоятельного ведения задачи масштаба, выходящего за рамки одной фичи — например, сам декомпозировал крупную задачу на подзадачи (для себя или для команды), отвечал за результат на уровне модуля/сервиса/продукта, а не отдельного тикета. Явно называет, какие решения принимал сам, а не получал в готовом виде сверху.
Глубина технических решенийЯвно называет trade-off выбранного решения — не только почему выбрал, но и что теряется по сравнению с отклонёнными вариантами, и в каком случае выбрал бы иначе. Может честно указать на ограничение собственного решения, а не подавать его как безальтернативно правильное.