Décroche le poste, sans bachoter dans le vide.

Langage interprété, dynamiquement typé, multi-paradigme (impératif, OO, fonctionnel), single-threaded (asynchrone via l'event loop) et basé sur les prototypes.

Pas au sens classique (Java/C#). C'est un langage à prototypes : héritage par prototype, propriétés ajoutables à la volée. Les class ES6 ne sont que du sucre syntaxique au-dessus des prototypes.

Un modèle (blueprint) qui définit la structure (propriétés) et le comportement (méthodes) d'objets, avec un constructor appelé à la création.

Un objet concret créé à partir d'une classe via new. Analogie : classe = moule, instance = gâteau.

Le code concret qui réalise un contrat défini par une interface. L'interface dit quoi (signatures), l'implémentation dit comment (class X implements Y).

Une représentation en arbre de la page HTML, exposée comme API pour lire/modifier contenu, structure et style. En Angular on évite la manipulation directe : on passe par le binding et la change detection.

Une interface de programmation = un contrat qui spécifie comment des logiciels échangent des données. Types : REST (HTTP), GraphQL, WebSocket (temps réel), SOAP (XML, ancien).

Une classe TS décorée @Component qui contrôle une portion de l'UI : un décorateur (métadonnées), un template (HTML) et de la logique (classe).

Smart (container) : logique métier, injecte des services, fait les appels, passe les données. Dumb (présentationnel) : affiche les input() reçus, émet via output(), pas de service, OnPush, hautement réutilisable.

Oui : parent→enfant via input(), enfant→parent via output(), siblings via un service partagé.

Archi en couches (presentation/application/domain/infrastructure) + standalone + lazy loading ; tooling ESLint + Prettier + Husky + conventional commits ; état signals (NgRx si complexe) ; tests unitaires + E2E + coverage cible ; CI/CD pipeline build/test/deploy ; doc README + Compodoc/Storybook.

Feature-based : core/ (singletons, guards, interceptors), shared/ (composants/pipes réutilisables), features/<contexte>/{domain,application,infrastructure,presentation}, layout/. Pourquoi : scalable, maintenable, lazy-loadable, on trouve vite le code.

Feature-based (recommandé), Layer-based (par type technique, moins scalable), Atomic Design (atoms→pages), DDD (par domaine, bounded contexts).

Standalone, sans hésiter, depuis Angular 15+ (défaut depuis 17). Moins de boilerplate, imports explicites par composant, lazy loading par loadComponent, meilleur tree-shaking. Les NgModule ne restent que pour du legacy à migrer.

Plus de zone.js qui patche les API async → la change detection n'est plus déclenchée « automatiquement partout ». On rend l'état explicitement réactif via signals (un set/update notifie le framework). Bénéfices : bundles plus légers, CD plus prévisible et performante.

Une classe TS @Injectable qui porte la logique métier réutilisable, la communication backend (HTTP) et le partage de données entre composants, fournie via la DI.

Une seule instance (singleton) pour toute l'app, disponible partout sans import, et tree-shakeable. Alternatives : 'any', providers au niveau d'une route, ou providers: [] au niveau d'un composant pour une instance locale.

Un pattern : on fournit les dépendances depuis l'extérieur au lieu de les créer dans la classe. Gains : testabilité (mocks faciles), découplage, réutilisabilité, maintenabilité.

Un pattern garantissant une seule instance d'une classe dans l'app. En Angular, providedIn: 'root' en crée un automatiquement. Use cases : AuthService, ConfigService, cache global.

Interpolation {{ }}, property [prop], event (event), two-way [(ngModel)] ; plus attribute [attr.x], class [class.active], style [style.color].

En HTML natif, disabled est actif dès qu'il est présent, même disabled="false". Il faut le property binding : [disabled]="isDisabled".

Classiques : *ngIf (+ else/then), *ngFor (index, first, last, trackBy crucial perf), [ngSwitch]/*ngSwitchCase.

3 syntaxes : objet [ngClass]="{active: isActive}" (le plus courant), tableau ['btn', role], ou méthode getClasses(). Pour une seule classe, [class.active]="…" est plus direct.

Une classe TS qui modifie le comportement/apparence d'un élément. 3 types : component (directive avec template), structurelle (@if/*ngFor), attribut (ngClass, custom via @HostListener/@HostBinding).

Fonction de transformation dans le template. Natifs : uppercase, number, currency, percent, date, json, et async (subscribe/unsubscribe auto — clé). Custom : @Pipe({name, standalone: true}) + transform(). Pure (défaut, recalcul si la référence change) vs impure (chaque CD, ⚠️ perf).

On déclare un tableau Routes (path→component), Angular utilise <router-outlet> comme emplacement, et remplace le contenu à la navigation sans recharger la page (SPA). Wildcard ** pour le 404.

Une directive placeholder où Angular affiche le composant de la route active (comme un cadre photo dont l'image change selon l'URL).

Charger un composant/feature à la demande via loadComponent / loadChildren → bundle initial plus petit, démarrage plus rapide, bande passante économisée.

Un flux asynchrone qui émet 0..N valeurs dans le temps : push-based, lazy (s'exécute au subscribe), peut compléter ou émettre une erreur (next/error/complete).

Un Observable spécial multicast et hot (émet sans subscriber), à la fois Observable et Observer. Variantes : Subject, BehaviorSubject (valeur initiale + dernière valeur), ReplaySubject (N dernières), AsyncSubject (dernière à la complétion).

Partout : HttpClient (appels), valueChanges des forms (avec debounceTime/switchMap), paramMap du router, et état via service. À consommer de préférence avec le pipe async.

Création of/from/interval/timer/fromEvent ; transfo map/switchMap/mergeMap/concatMap ; filtrage filter/take/takeUntil/debounceTime/distinctUntilChanged ; combinaison combineLatest/forkJoin/merge ; utilitaires tap/catchError/retry.

switchMap : autocomplete (annule la recherche précédente). mergeMap : envoyer N requêtes en parallèle indépendantes (upload de fichiers). concatMap : préserver l'ordre (file d'actions séquentielles). exhaustMap : ignorer les déclenchements pendant un traitement en cours (anti-double-clic sur un bouton login).

toSignal() subscribe immédiatement et a besoin d'une valeur initiale (sinon undefined au premier rendu) → bien typer/initialValue. Et toObservable() émet sur la base de l'effet : attention aux émissions en doublon ou au timing si on attendait une sémantique « valeur courante » stricte.

Oui.

Critères : partage (combien de features touchent l'état), complexité des mutations, besoin de traçabilité/time-travel, taille d'équipe. Petit/moyen → signals services. Beaucoup d'effets de bord async + audit → NgRx (ou NgRx SignalStore qui marie signals + structure). Ne pas sur-architecturer une petite app.

Une requête = method (GET/POST/PUT/PATCH/DELETE) + URL/endpoint + headers (Content-Type, Authorization) + body (POST/PUT/PATCH). Réponse = status (2xx succès, 4xx erreur client, 5xx erreur serveur) + body.

Une API dont l'architecture s'appuie sur HTTP : ressources adressées par URL, opérations via les méthodes HTTP, sans état (stateless).

Create / Read / Update / Delete ↔ POST / GET / PUT (ou PATCH partiel) / DELETE.

Du code lisible et maintenable : nommage explicite, fonctions courtes (1 responsabilité), DRY, commentaires seulement si nécessaire (le code s'auto-explique), principes SOLID.

Ports & Adapters : isoler la logique métier des détails techniques. Le domaine (pur) ne dépend de rien ; les ports (interfaces) sont implémentés par des adapters (HTTP, DB). Avantages : domaine testable sans dépendances, implémentations interchangeables.

Approche centrée métier : Ubiquitous Language (vocabulaire commun devs/métier), Bounded Contexts, Entities (identité), Value Objects (comparés par valeur), Aggregates, Repository pattern (abstraction de l'accès données).

Web Components : standards (Custom Elements, Shadow DOM, Templates) pour des composants réutilisables indépendants du framework. Micro-frontends : app découpée en features développées/déployées séparément. Avantages : équipes autonomes, déploiement indépendant ; inconvénients : complexité, duplication, perf (multi-bundles). Approches : iframe, Web Components, Module Federation, Single-SPA.

Custom Element : standard web pour des balises HTML personnalisées. Angular Elements (@angular/elements, createCustomElement) convertit un composant Angular en Web Component utilisable partout (React, Vue, vanilla).

3 voies : Angular Elements (petits composants), Stencil (design system framework-agnostic), ou logique headless partagée (lib TS pure) + UI propre à chaque framework, en mutualisant les styles (CSS/tokens).

Mécanisme par lequel Angular détecte les changements d'état et met à jour le DOM. OnPush : le composant n'est vérifié que si un input() change (nouvelle réf), qu'un événement interne survient, qu'un Observable émet (async pipe), ou sur markForCheck(). Eager : vérifie tout le sous-arbre à chaque événement (simple, peut être lent). ⚠️ Depuis Angular 22 (juin 2026), OnPush est la stratégie PAR DÉFAUT : un composant qui ne dit rien est en OnPush, et l'ancien Default a été renommé Eager (le nom décrit enfin ce que la stratégie fait). ng update tague les composants existants en Eager pour que rien ne casse le jour de la migration.

Mesurer (Angular DevTools profiler), puis : track sur @for (évite de re-render tout), OnPush, virtual scroll (cdk-virtual-scroll-viewport), pagination/lazy, éviter les pipes impurs et le travail lourd dans le template, computed mémoïsé.

Sans clé de tracking, Angular détruit/recrée tous les nœuds DOM quand la liste change → coûteux et perte d'état (focus, animations). Avec track item.id, il réconcilie uniquement ce qui a changé.

SSR + hydration (incrémentale/@defer), NgOptimizedImage pour le LCP image, lazy loading des routes, réduire le JS initial (standalone + tree-shaking esbuild), preconnect/preload des ressources critiques, éviter le CLS (dimensions réservées).

APM/erreurs : Sentry, New Relic, Datadog. Logging : ELK, Splunk, CloudWatch. RUM/session : GA, Hotjar, LogRocket. Perf : Lighthouse, WebPageTest, Bundle/Source-Map Analyzer. Angular : Angular DevTools.

Écrire les tests avant le code. Cycle Red→Green→Refactor : test qui échoue, code minimal pour passer, nettoyage. En place : framework de test, suivre le cycle, coverage cible, intégration CI.

Unitaires (services, pipes, fonctions pures), intégration (composant + dépendances), E2E (parcours critiques, formulaires, nav).

Unitaires : unité isolée, rapides (ms), nombreux, dépendances mockées. E2E : app complète côté utilisateur, lents (s/min), peu nombreux, vraies dépendances. Suivre la pyramide des tests (beaucoup d'unitaires, peu d'E2E).

Sélecteurs stables (data-cy/data-testid, pas de CSS fragile), tests indépendants, setup/teardown des données, attentes explicites (pas de wait fixe), Page Object Pattern.

Ordre : data-cy/data-testid (meilleur), puis id stable, classes sémantiques en dernier recours. À éviter : CSS complexe (div > p:nth-child(2)), classes de style (.btn-primary), texte (fragile en i18n).

Tester : règles métier, mappers/transformations, stores/état, parcours critiques. Ne pas tester : le framework lui-même, les internals de libs tierces, le code généré, les getters triviaux. Viser la valeur, pas le % de coverage pour le %.

TestBed qui importe le composant standalone directement (plus de module de test). Pour les signals, on set l'état puis on lit le rendu/computed (pas de tick zone en zoneless : déclencher la CD explicitement). Mocker les services injectés via providers.

L'Angular CLI gère le bundler sous le capot (config via angular.json, pas de webpack.config.js). En local : ng serve (HMR), ng build, ng build --watch. Customisation rare via @angular-builders/custom-webpack.

Bundling, minification, tree-shaking (supprime le code mort), code splitting (lazy), HMR, source maps.

Des marqueurs qui déclenchent des actions dans la pipeline : tags Git (v1.0.0 → build prod/release/deploy), flags dans les messages de commit ([ci skip], [deploy]), patterns de branches (main, release-*), environment tags (staging/production). Pipeline type : commit → build → tests → lint → build prod → deploy.

HTML sémantique d'abord (button, ul/li), rôles ARIA si besoin (role="listbox"/option, aria-expanded, aria-activedescendant), navigation clavier complète (flèches, Échap, Entrée, Tab), focus visible et focus management (Angular CDK a11y : FocusTrap, LiveAnnouncer, cdkTrapFocus), labels associés.

Sur-utiliser ARIA là où l'HTML natif suffit (<div role="button"> au lieu de <button>), ou poser des aria-* qui mentent sur l'état réel (ex aria-hidden sur un élément focusable). Règle d'or : no ARIA is better than bad ARIA.

Réponse honnête selon ton profil : expertise frontend Angular assumée (ex 80/20 ou 70/30 si à l'aise Node/NestJS), capacité d'adaptation, exemples concrets. Le message : « je livre de la valeur sur toute la chaîne, mon point fort est le front ».

Onboarding (doc, pair programming, walkthrough), formation continue (code reviews avec feedback constructif, best practices, sessions ciblées RxJS/signals/routing), autonomie progressive (tâches de complexité croissante, droit à l'erreur), accompagnement (dispo, feedback régulier pas que négatif).

Quantitatif : PR mergées sans aide, temps de résolution en baisse, taux d'acceptance des PR, coverage maintenu. Qualitatif : autonomie (moins de questions), qualité du code, propositions d'amélioration d'archi. Feedback : retours juniors/équipe, 1-on-1. Ex : passage de 3-4 aller-retours par PR à 1 en 3 mois.

Ramener au critère objectif (perf, maintenabilité, coût, risque), faire un spike/POC ou un ADR comparatif quand c'est possible, écouter le « pourquoi » de l'autre, décider en explicitant le trade-off assumé, et se rallier une fois la décision prise (disagree & commit). Exemple concret de ta carrière > théorie.