Czego szukamy w Senior Angular Developerze
Angular w 2026 roku to zupełnie inny framework niż ten z czasów AngularJS czy nawet wczesnych wersji Angulara 2-8. Wprowadzenie Signals (od 16/17), standalone components, deferrable views, hydration i nowy build system esbuild/Vite fundamentalnie zmieniły sposób, w jaki budujemy aplikacje. Senior Angular Developer w 2026 musi rozumieć zarówno dziedzictwo (RxJS + NgModules, które wciąż dominują w istniejących projektach), jak i nowy paradygmat reaktywny oparty o Signals. W ARDURA Consulting weryfikujemy kandydatów dla projektów enterprise — dashboardów analitycznych, systemów back-office, aplikacji finansowych i medycznych, gdzie liczy się stabilność, accessibility i performance.
Dobry Senior Angular Dev powinien znać: Angular 17+ z naciskiem na Signals, Standalone Components, Control Flow (@if/@for/@switch), Deferrable Views (@defer) i Hydration; TypeScript 5.x na poziomie zaawansowanym (generics, conditional types, mapped types, satisfies); RxJS (operators, schedulery, error handling, kombinatory typu combineLatest, switchMap, exhaustMap); zarządzanie stanem (NgRx, NGXS lub Signal-based stores); UI libraries (Angular Material, PrimeNG, opcjonalnie Tailwind); testing (Jest lub Karma+Jasmine + Cypress lub Playwright dla E2E); Module Federation oraz NX dla monorepo; Angular Universal (SSR) i performance (Web Vitals, performance budgets, change detection optimization); accessibility (WCAG 2.2). W tym przewodniku znajdziesz pytania, zadania i red flags, które wyłapujemy w procesie weryfikacji.
Top 15 pytań rekrutacyjnych (z odpowiedziami)
1. Czym są Signals w Angularze i jak różnią się od Observables?
Signals to reaktywny prymityw wprowadzony w Angular 16, stabilny od 17. Signal trzyma wartość i powiadamia zależności, gdy się zmieni. Różnice względem Observables: Signal jest synchroniczny i ma zawsze aktualną wartość (signal(), computed(), effect()), Observable jest strumieniem asynchronicznym. Signals są zoptymalizowane pod change detection — w przyszłości umożliwią zonless Angular. Senior wskaże, że RxJS nie znika — Signals są dla stanu, Observables dla strumieni (HTTP, eventy, async).
2. Standalone Components vs NgModules — kiedy migrować i jak?
Standalone Components (stable od 15) eliminują boilerplate NgModule. Zalety: prostsze drzewo zależności, lepsze tree-shaking, bezpośrednie importy w komponencie. Migracja: ng generate @angular/core:standalone automatycznie konwertuje moduł po module. Senior wskaże, że dla nowych projektów standalone jest defaultem, dla legacy — migracja stopniowa, zaczynając od lazy-loaded routes.
3. Wyjaśnij Change Detection. Czym różni się Default od OnPush?
Default CD sprawdza całe drzewo komponentów przy każdym evencie (kliknięcie, setTimeout, Promise). OnPush sprawdza komponent tylko gdy: zmieni się referencja @Input, emit Observable z async pipe, manualnie markForCheck(). Senior wyjaśni Zone.js, problem z mutowaniem obiektów przy OnPush i to, że Signals robią precyzyjny CD na poziomie komponentu (a w przyszłości — na poziomie templatki).
4. Co to zonless Angular i jaki ma sens?
Tryb bez Zone.js, w którym change detection wyzwalają Signals i markForCheck. Mniejszy bundle (~100KB Zone.js), lepsza interoperacyjność z innymi bibliotekami, lepsze profiling. Senior wspomni, że to wymaga przebudowy stanu na Signals — provideExperimentalZonelessChangeDetection() to nie magic switch.
5. Operatory RxJS — wyjaśnij switchMap, mergeMap, concatMap, exhaustMap. Kiedy które? switchMap — anuluje poprzedni stream, używaj dla typeahead, route params. mergeMap — równolegle, używaj dla wielu niezależnych żądań. concatMap — sekwencyjnie, używaj gdy kolejność i kompletność jest ważna. exhaustMap — ignoruje nowe, dopóki poprzedni nie skończy, używaj dla guard’ów typu “double click submit”. Senior poda przykład bugu: typeahead z mergeMap zamiast switchMap = race condition w wynikach.
6. NgRx — kiedy ma sens, a kiedy to overkill?
NgRx (Redux dla Angulara) ma sens przy: dużym współdzielonym stanie, wielu komponentach modyfikujących te same dane, potrzebie debugowania historii akcji, wymaganym caching’u API z invalidacją. Overkill dla: prostych formularzy, lokalnego stanu komponentu, aplikacji z 2-3 ekranami. Senior wspomni o lżejszych alternatywach: NGXS, Signal-based stores (signalStore z @ngrx/signals), services z BehaviorSubject.
7. Co to są deferrable views (@defer) i kiedy ich używasz?
@defer (Angular 17+) opóźnia ładowanie bloku templatki według triggerów: on idle, on viewport, on interaction, on timer, when condition. Wraz z @placeholder, @loading, @error. Zmniejszają initial bundle. Senior wspomni: defer dla heavy chartów, video, third-party widgets — nie dla każdej małej rzeczy.
8. Jak optymalizujesz performance dużej aplikacji Angularowej?
OnPush CD wszędzie gdzie się da, lazy loading routes, preloading strategy (PreloadAllModules lub custom), virtual scrolling dla długich list (CDK Virtual Scroll), trackBy w @for, defer dla heavy components, image optimization (NgOptimizedImage), bundle analysis (source-map-explorer), performance budgets w angular.json. Senior wspomni o Web Vitals (LCP, INP, CLS) i o tym, że ng build --stats-json + analyze powinno być częścią CI.
9. SSR z Angular Universal — kiedy i jak?
SSR ma sens dla: publicznych stron (SEO), TTFB, social previews, aplikacji dostępnych dla użytkowników na słabych urządzeniach. W Angular 17+ SSR jest pierwszą klasą obywatela (provideServerRendering, full hydration). Senior wspomni o hydration — Angular re-używa server-rendered DOM zamiast go niszczyć — i o transfer state dla deduplikacji HTTP calls.
10. Hydration — co to, jak działa, jakie pułapki?
Hydration (od 16, stable od 17) sprawia, że client-side Angular nie niszczy DOM wyrenderowanego przez SSR, tylko go ożywia. Pułapki: ręczne manipulacje DOM (innerHTML, jQuery), różnice między server a client output, missing meta tags. Senior wskaże ngSkipHydration jako escape hatch i wspomni o incremental hydration (od 19/20) jako kolejnym kroku.
11. Testing — Jest vs Karma+Jasmine. Cypress vs Playwright. Co wybierasz? Jest jest szybszy, lepiej działa z TS, ma snapshot testing. Karma to oficjalny default, ale powoli wypierane. Senior wskaże migrację Karma→Jest jako standardowy ruch (od 17 oficjalnie wspierany experimental). Cypress vs Playwright: Cypress ma lepsze DX, Playwright lepiej wspiera multi-browser i parallelization. Senior nie ma dogmatu — wybiera narzędzie pod team i projekt.
12. Module Federation i mikrofrontendy w Angularze — wady i zalety? Module Federation pozwala dynamicznie ładować remote moduły. Zalety: niezależne deploye zespołów, technology mixing (Angular + React), inkrementalna migracja legacy. Wady: złożoność konfiguracji, shared dependencies (Angular musi być w tej samej wersji), trudniejszy debug, koszt komunikacji między MF. Senior wspomni o NX jako narzędziu, które robi to lepiej dla większości przypadków (monorepo + lazy modules).
13. NX monorepo — kiedy ma sens? NX zarządza wieloma aplikacjami i bibliotekami w jednym repo z: affected commands (buduje tylko to co się zmieniło), generators, computation cache (lokalny i zdalny — NX Cloud), enforce module boundaries. Sens: kilka aplikacji dzielących bibliotekę UI/utils, organizacja z 10+ developerów, microfrontends, fullstack monorepo (Angular + NestJS).
14. Accessibility (WCAG 2.2) — co Senior musi wiedzieć? Semantyczny HTML, role ARIA tylko gdy nie da się semantycznie, focus management (przy modal, route change), keyboard navigation (Tab order, ESC, Enter), kontrast (4.5:1 dla normalnego tekstu, 3:1 dla dużego), aria-live dla dynamicznych komunikatów, screen reader testing (NVDA, VoiceOver), Angular Material/CDK ma a11y built-in (LiveAnnouncer, FocusTrap). Senior wspomni o axe-core w testach E2E.
15. Jak zarządzasz formularzami? Reactive vs Template-driven? Reactive Forms dla wszystkiego średniego i większego: type safety (Typed Forms od 14), walidacje custom, dynamic forms, łatwe testowanie, ValueChanges jako Observable. Template-driven tylko dla prostych formularzy login/search. Senior pokaże znajomość: cross-field validators, async validators, FormArray dla dynamicznych list, AbstractControl.setErrors dla server-side validation.
Zadania techniczne — 3 scenariusze
Scenariusz 1: Live coding (60 min) — Signal-based feature
Kandydat dostaje skeleton aplikacji Angular 17+ i ma zaimplementować feature: lista produktów z filtrowaniem (search po nazwie + filter po kategorii), paginacja, sortowanie. Wymagamy: użycia Signals (signal, computed, effect), standalone component, OnPush CD, NgOptimizedImage dla zdjęć produktów, podstawowej a11y (focus management, aria-label), przynajmniej jednego unit testu (Jest). Patrzymy na: czystość kodu, użycie computed zamiast manualnej derived state, brak nadmiarowych subskrypcji, separacja prezentacji od logiki (smart/dumb components albo service z signal store). Red flag: zostanie przy starym BehaviorSubject pattern bez próby Signals.
Scenariusz 2: System design (45 min) — dashboard analityczny z 200 widgetami Kandydat projektuje dashboard B2B: 200 konfigurowalnych widgetów (charty, tabele, KPI), real-time updates (WebSocket), filtrowanie globalne (zmienia dane we wszystkich widgetach), edycja layoutu drag & drop, SSR dla landing page, role-based widgets (RBAC). Oczekujemy diagramu: architektura komponentów (lazy modules per widget type, defer dla heavy charts), state management (NgRx z entity adapter? signal stores? feature stores?), data flow (WebSocket → store → widgets via OnPush), performance (virtual scrolling kontenera, defer, memoization, bundle splitting), SSR strategy (universal dla landing, CSR dla dashboard), testing strategy. Pytamy o trade-offy.
Scenariusz 3: Code review (30 min) — komponent z bugami i smelłami Pokazujemy komponent ~200 linii z ukrytymi problemami: (1) brak unsubscribe (memory leak — subscription bez takeUntilDestroyed lub DestroyRef), (2) mutacja @Input objectu (anti-pattern, łamie OnPush u rodzica), (3) logika biznesowa w templatce (function call w binding = wywołanie na każdy CD), (4) brak trackBy w @for (przerysowanie wszystkich nodów), (5) any zamiast typu, (6) nested subscription zamiast switchMap (callback hell + race conditions), (7) hardcoded string zamiast i18n, (8) brak ARIA dla custom buttona. Senior znajduje 6-8 z 8 w 30 minut.
Red flags i deal-breakers
Kandydat deklaruje Senior, ale używa wyłącznie składni NgModule sprzed 2 lat i nie zna Signals nawet z dokumentacji — alarm. Brak testów w portfolio („nie pisałem, bo nie miałem czasu”) — w 2026 to dyskwalifikacja, nie wymówka. Subskrypcje bez unsubscribe (memory leaks) — fundamentalna ignorancja. Mutowanie @Input — łamanie kontraktu Angulara. Nadużywanie any w TypeScript — sygnał, że TS jest dla niego utrudnieniem, nie pomocą. Brak znajomości RxJS poza subscribe() i map() — Senior bez switchMap/combineLatest to nie Senior. Brak rozumienia change detection przy 100% deklarowanym doświadczeniu — alarm. Brak pytań o test coverage, CI/CD, design system, conventions zespołu — sygnał niskiego zaangażowania. Wreszcie: kandydat który mówi „Angular jest przestarzały, ja preferuję React” na rozmowie o rolę Angular Developer — natychmiastowa odmowa, nie tylko technicznie, ale i kulturowo.
Jak ARDURA Consulting weryfikuje kandydatów
W ARDURA Consulting prowadzimy 3-etapowy proces weryfikacji Senior Angular Developerów w 5 dni roboczych. Etap 1 (dzień 1) — screening CV + 30-minutowa rozmowa techniczna z lead frontendem, podczas której zadajemy 8-10 pytań z listy powyżej, weryfikujemy znajomość Angular 17+, TypeScript, RxJS i historii projektów. Etap 2 (dni 2-3) — zadanie techniczne live (90 minut): Signal-based feature live coding + system design (dashboard albo formularz dynamiczny) + code review komponentu z bugami. Etap 3 (dzień 4) — rozmowa z naszym CTO o doświadczeniu projektowym (skala aplikacji, zespół, design system, accessibility, performance), dopasowaniu kulturowym, oczekiwaniach finansowych i dostępności. Dzień 5 — finalna decyzja i przekazanie kandydata klientowi z pełnym raportem (mocne strony, ryzyka, rekomendacja seniority). Korzystamy z bazy 500+ zweryfikowanych seniorów, 99% retencji i średnio 2 tygodnie do wdrożenia w projekt klienta. Sprawdź dostępnych ekspertów →