Questions d'entretiens chez Good Architecture
Quelles sont les bonnes questions à poser dans une interview pour voir ce que le candidat sait sur l'architecture?
L'architecture est l'une de ces choses qui n'est pas simplement une question triviale (par exemple, les utilisations des modèles de conception) et est beaucoup plus subjective que les autres sujets d'interview. Il n'y a souvent pas une seule architecture correcte, ce qui rend plus difficile l'évaluation de quelqu'un. Le maximum que vous pouvez obtenir est une idée de la façon dont la personne interrogée pense.
Je suggérerais que vous décriviez à l'interviewé un produit complexe ou une partie d'un produit que vous (l'intervieweur) connaissez le mieux. Demandez-lui ensuite de réfléchir à la façon dont il pourrait le concevoir et d'expliquer son raisonnement, puis concentrez-vous sur des décisions spécifiques et posez des questions.
Bien sûr, ne faites cela que si:
- Vous êtes ouvert à entendre d'autres designs qui ne vous appartiennent pas.
- Vous êtes capable de prendre des critiques potentielles et de reconnaître que votre propre conception peut être imparfaite
Un bonus supplémentaire est que vous verriez comment vous pourriez gérer les désaccords s'il est embauché.
Une approche alternative si votre produit a déjà été retouché est de décrire l'architecture de l'ancienne version et de demander à l'interviewé comment il le ferait. Si le résultat est proche de l'architecture actuelle, il est plus probable que le candidat soit bien adapté au style et à l'état d'esprit de votre groupe.
- Demandez qui dans la "communauté" ils suivent et admirent pour leur capacité architecturale et pourquoi? Cela vous donnera une indication du penchant philosophique de leur style architectural. De plus, s'ils ne peuvent nommer personne ou pourquoi ils les admirent, c'est un gros drapeau rouge car ils ne suivent clairement pas les meilleures pratiques et les avancées de la communauté.
- Demandez-leur de nommer un problème/con/compromis avec un modèle de conception architecturale pertinent pour l'entretien. S'il ne peut pas faire cela, c'est un drapeau rouge car ils peuvent être inconsciemment incompétents (c'est-à-dire: un fanboy) par opposition à avoir une expérience et des connaissances réelles dans ce domaine. Il est beaucoup plus facile de nommer les avantages d'une architecture donnée, alors que vraiment comprendre les inconvénients nécessite une analyse plus approfondie.
En supposant que vous les ayez déjà vérifiés pour la culture/personnalité et les compétences de développement, je suggère de faire ce qui suit:
Demandez au candidat de décrire l'architecture d'un système de moyenne à grande échelle qu'il a réellement conçu et/ou mis en œuvre. Posez des questions approfondies sur les compromis de conception qu'ils ont faits.
Fournir au candidat la conception d'un système qui présente plusieurs défauts connus. Cela peut être celui que vous avez inventé ou celui qui est bien connu de tous. Demandez au candidat d'identifier les défauts et de repenser le système, en supposant qu'ils n'avaient pas de contraintes de temps ou d'argent.
Présentez au candidat un ensemble d'exigences pour un système non trivial (c'est-à-dire un système distribué pour examiner les images médicales dans un environnement hospitalier) Demandez-leur de mettre en tableau blanc les composants du système en augmentant les niveaux de détail jusqu'à ce que vous vous sentiez à l'aise avec leur capacité à susciter exigences de la partie prenante (vous) et faites les compromis appropriés dans leur conception.
Rien de tout cela ne garantira que vous sélectionnerez le meilleur "architecte" (j'ai le même problème avec l'architecte en titre que Joel et Jeff). Cependant, ce sont certainement de bonnes techniques de filtrage et devraient vous aider à identifier quelqu'un avec des caractéristiques intéressantes pour votre équipe.
"Donc, je ne vais pas te branler ici: peux-tu me dire quelque chose qui me convaincra que tu en sais beaucoup sur l'architecture?"
Je suis un peu préoccupé par votre question. À première vue, je suggérerais quelque chose dans le sens de "veuillez décrire les influences des formes des prairies du Midwest sur les conceptions des arts et métiers modernes".
Retirer la langue de la joue, je suggérerais ce que Chris a fait ci-dessus. Donnez au candidat l'occasion d'interagir avec vous et votre équipe sur la conception d'une architecture pertinente pour votre travail. Si vous ne vous sentez pas équipé pour juger de leur compétence en les voyant résoudre des problèmes plutôt que des problèmes en conserve, vous DEVEZ faire participer quelqu'un d'autre à l'entretien. Ou bien prenez une page du livre de Joel et Jeff et grattez le terme "architecture" et commencez à chercher des ingénieurs logiciels compétents.
À mon avis, la capacité de concevoir ou "d'architecte" est une compétence, pas un ensemble de connaissances. Leur poser un tas de questions comme "quelles sont les ramifications de performances de l'utilisation de J2EE vX vs J2EE vY" ou "qui est mieux, CORBA ou RMI" va juste vous faire paraître idiot.
Le problème avec poser des questions comme celle-ci est qu'il n'y a pas vraiment de "bonne" réponse, donc l'essentiel est de faire parler le candidat. Je leur demanderais de décrire une architecture qu'ils ont implémentée et dont ils sont fiers. Et puis enchaîner avec des choses comme: "qu'en êtes-vous le plus fier?". Et vous pouvez alors leur demander quelles erreurs ils ont faites dans le passé, ce genre de chose.
Je me sens plus à l'aise à ce sujet parce que vous ressentez la personne et non sa capacité à répondre à une question en conserve.
"Avez-vous lu Code Complete de McConnell?"