Questions d'entretien Angular à prévoir

La surface d'API d'Angular est vaste, et les listes de questions publiées traitent chaque décorateur comme également susceptible d'être abordé. Ce n'est pas le cas. Cette section couvre les domaines qui décident réellement de la plupart des entretiens, afin que votre pratique corresponde à la distribution réelle. Quatre groupes dominent :

• Détection des changements : ce qui déclenche une vérification, comment Zone.js patche les API asynchrones, ce que change OnPush, et comment les signals permettent à Angular d'éviter du travail.
• Injection de dépendances : injecteurs hiérarchiques, providedIn, jetons d'injection, et la fonction inject() face aux paramètres de constructeur.
• RxJS : observables face aux promesses, choix du bon opérateur, et nettoyage des abonnements avant la destruction d'un composant.
• Architecture des composants : composants standalone, inputs et outputs, projection de contenu, et hooks de cycle de vie.

La connaissance des versions compte plus ici que dans la plupart des entretiens sur des frameworks, car Angular a changé de direction. Les composants standalone, les blocs de flux de contrôle intégrés @if et @for, les vues différables, et les signals sont tous arrivés dans des versions majeures récentes, donc les recruteurs demandent souvent ce que vous écririez aujourd'hui par rapport à ce qu'utilise une base de code plus ancienne. Connaître les deux, et expliquer pourquoi le framework a évolué, fait meilleure impression que de prendre parti.

Plus loin que les noms d'opérateurs. La question RxJS qui distingue les niveaux est de savoir quel opérateur d'aplatissement convient : switchMap annule la requête interne précédente et convient à une saisie prédictive, mergeMap exécute tout en parallèle, concatMap préserve l'ordre, et exhaustMap ignore les nouveaux événements tant qu'un autre est en cours, ce qui lui convient pour un bouton d'envoi. Les recruteurs posent ensuite la question des fuites : que devient un abonnement manuel quand le composant est détruit, et pourquoi l'async pipe ou takeUntilDestroyed éliminent le problème.

Les questions sur les signals sont plus récentes et partent généralement de la motivation plutôt que de l'API. Attendez-vous à expliquer ce qu'est un signal, comment computed en dérive un, à quoi sert un effect, et pourquoi les signals donnent à Angular une manière plus fine de savoir ce qui a changé plutôt que de revérifier un arbre de composants. Une bonne réponse relie les deux sujets : les signals et OnPush réduisent tous deux le travail de la détection des changements, mais les signals le font en suivant les lectures plutôt qu'en restreignant le moment où une vérification s'exécute.

Les recruteurs ne s'attendent pas à ce que vous ayez utilisé chaque fonctionnalité récente en production. Ils attendent que vous disiez dans quelle version vous avez travaillé en dernier et que vous raisonniez clairement sur le reste.

La plupart des processus Angular incluent la construction de quelque chose de petit pendant que le recruteur observe. Les exercices récurrents restent stables d'une entreprise à l'autre :

• Appeler une API depuis un service et afficher le résultat avec l'async pipe.
• Construire une recherche à saisie prédictive avec debounceTime, distinctUntilChanged, et switchMap.
• Écrire un formulaire réactif avec un validateur personnalisé et des états d'erreur visibles.
• Faire passer des données entre un composant parent et enfant, puis les remonter dans un service.
• Ajouter une route avec un composant chargé paresseusement et un guard.

Un ingénieur front-end passant un entretien pour un poste produit de niveau intermédiaire pourrait, par exemple, construire la saisie prédictive, puis être poussé sur ce qui se passe quand les réponses arrivent dans le désordre, comment afficher un état de chargement, et ce qui devrait se passer quand l'utilisateur efface le champ. Ce sont ces extensions qui décident de l'entretien, donc entraînez-vous sur les questions de suivi plutôt que sur le chemin idéal. Les ensembles adjacents avec lesquels les entretiens Angular s'ouvrent encore, notamment les fondamentaux de JavaScript et TypeScript, se trouvent dans le hub de banques de questions.

Lire une liste de questions développe la reconnaissance, pas le rappel, et l'entretien teste le rappel pendant que quelqu'un observe. La solution consiste à répéter dans la forme réelle de l'entretien : construire les exercices standards depuis un projet vide, expliquer à voix haute les décisions de détection des changements et d'abonnements en tapant, et absorber les interruptions sans perdre le fil. Faire l'ensemble comme une répétition parlée, une question à la fois avec des relances, c'est à cela que sert l'entraînement à l'entretien simulé.

Une limite qu'il vaut la peine d'énoncer clairement : les entretiens Angular en direct se déroulent presque toujours dans un éditeur partagé ou avec votre écran visible, et tout ce qui s'y trouve est visible par le recruteur. Un assistant a sa place en préparation et dans les entretiens menés par la conversation, pas sur un écran partagé. Les formats qui autorisent quoi sont couverts dans les types d'entretien.