Question d'entretien pour Développeur frontend

Comment construiriez-vous un formulaire d'inscription dont les erreurs de validation soient réellement utilisables, y compris pour les utilisateurs de lecteurs d'écran ?

Ce que le recruteur cherche à évaluer, comment structurer votre réponse et un exemple parlé à adapter.

Réponse rapide

Utilisez de vrais labels liés aux champs, validez au blur et à la soumission plutôt qu'à chaque frappe, et placez chaque message d'erreur à côté de son champ avec un aria describedby qui pointe dessus plus aria invalid sur le champ. À la soumission, déplacez le focus vers le premier champ invalide ou vers un résumé des erreurs. Gardez les contraintes et les types natifs pour que les claviers mobiles et le remplissage automatique fonctionnent, et ne signalez jamais une erreur par la couleur seule.

Pourquoi les recruteurs posent cette question

Les formulaires sont l'endroit où les échecs d'accessibilité coûtent vraiment de l'argent, donc c'est un test pratique plutôt qu'une question de valeurs. Le recruteur veut entendre parler d'association programmatique entre l'erreur et le champ, de gestion du focus à la soumission, et du comportement des régions live, autant de choses que les outils automatiques ne peuvent pas vérifier. Ça révèle aussi si vous validez d'une façon qui agace les utilisateurs, comme afficher une erreur d'e-mail avant qu'ils aient fini de le taper.

Comment structurer votre réponse

  • Commencez par la sémantique native : labels, types de champ, required.
  • Donnez la règle de timing pour le déclenchement de la validation.
  • Expliquez le lien programmatique entre le champ et le message d'erreur.
  • Décrivez la gestion du focus lors d'une soumission échouée.

Exemple de réponse

Exemple parlé, à la première personne

Je pars du natif, parce que l'essentiel vient gratuitement : un vrai label avec un attribut for, le bon type de champ pour que le mobile affiche le bon clavier, des attributs autocomplete pour que les gestionnaires de mots de passe fonctionnent, et required là où ça s'applique. Pour le timing, je valide un champ au blur et tout à la soumission, jamais à chaque frappe, puisque dire à quelqu'un que son e-mail est invalide pendant qu'il le tape n'est que du bruit. Une fois qu'un champ a été marqué invalide, je revalide bien pendant la saisie, pour que l'erreur disparaisse dès qu'elle est corrigée. Chaque message est juste sous son champ, et le champ reçoit aria invalid true et un aria describedby pointant vers l'id du message, ce qui fait qu'un lecteur d'écran annonce l'erreur quand le focus arrive dessus. Sur une soumission échouée, je déplace le focus vers le premier champ invalide, ou vers un court résumé d'erreurs en haut avec des liens vers chaque champ s'il y en a plusieurs. Et les erreurs ne sont jamais uniquement en couleur ; il y a du texte et une icône, parce qu'une bordure rouge seule ne veut rien dire pour beaucoup de gens.

Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.

Voir comment ça marche

Questions de relance à prévoir

  • Quand utiliseriez-vous une région live ici, et quand serait-ce agaçant ?
  • Comment géreriez-vous une erreur côté serveur qui arrive après la soumission ?
  • Comment testez-vous ça sans lecteur d'écran à disposition ?

Autres questions pour Développeur frontend

Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.

Prédire mes questions

Répétez les questions difficiles avant qu'on vous les pose

Entraînez-vous avec un copilote en direct, puis présentez-vous prêt. Un Session Pass à $29 vous accompagne pendant l'entretien, sans abonnement et sans engagement.

Obtenir GhostPilot