Comment répondez-vous à la question «expliquer l'architecture actuelle de votre projet» dans les entretiens? [fermé]

L'application sur laquelle je travaille actuellement est un peu énorme. Cela ne peut pas être expliqué en 15 minutes environ.

La dernière fois, j'ai fini par dessiner des diagrammes de classe et la façon dont ils sont liés, mais j'ai pu voir que l'intervieweur n'était pas satisfait de la réponse.

Quelles sont les principales choses à souligner lors de la réponse à cette question?

Par exemple, comment la session est gérée, comment la persistance est atteinte sont peu de choses.

Quelles sont les autres choses à ne pas manquer?

Personnellement, je pense que vous allez approfondir (pour une interview) si vous commencez à dessiner des diagrammes de classe, à moins qu'ils ne le demandent.

La dernière fois que j'ai eu cette question, j'ai fini par dessiner les différentes couches (application à 3 niveaux), expliqué comment les assemblages étaient mappés (car c'était quelque chose d'étrange pour le projet à mon avis), dans quelle direction les couches avaient des dépendances et la direction du flux de données.

Vous pouvez aller plus loin dans des composants spécifiques si vous le ressentez. Mais je ne suis jamais allé bien plus loin que "nous avons utilisé Workflow Foundation pour cette partie de la logique métier, pour cette raison". Cela m'a donné l'occasion de souligner que nous avons utilisé une certaine technologie utilisée , sans perdre de temps sur des choses triviales comme de simples objets POCO.

Le plus important est de montrer que vous comprenez l'architecture et pourquoi c'est fait comme ça. Encore mieux est de signaler les points d'amélioration (si possible) et d'expliquer pourquoi. Si, d'un autre côté, vous pensez que le design est «parfait», vous pouvez souligner une partie particulière du design qui ne semble pas logique pour un spectateur et expliquer pourquoi il convient à ce projet.

Si vous ne parvenez pas à fournir un aperçu de haut niveau de l'architecture de votre projet, ou à expliquer le projet en 5 minutes (sans parler de 15) à quelqu'un d'autre, alors la raison la plus probable est que vous êtes trop près de la surface du charbon.

Vous devez prendre une certaine distance pour pouvoir voir votre propre travail comme les autres le verraient. Comme un peintre, éloignez-vous et regardez le tout. Ensuite, vous verrez quelles sont les choses importantes dans un aperçu de 5 minutes.

Toutes ces réponses sont superbes, mais j'ai remarqué qu'un diagramme de composants de très haut niveau, une liste de la pile technologique (par exemple Java, JSF, Primefaces, etc ...) et un sourire confiant et une attitude ouverte sont les meilleurs. répondre à cette question.

Si vous n'êtes pas souriant ou même un peu excité lorsque vous expliquez l'architecture de votre projet actuel, l'intervieweur peut vous voir comme détaché et désintéressé de votre travail acharné. J'agis avec enthousiasme et j'en parle comme si je pensais que c'était la chose la plus "cool" au monde et que l'intervieweur était souriant et confortable, et il commençait à poser des questions plus détaillées.

Pensez à répondre à cette question comme comment vous l'expliqueriez à un client. Votre client ne se soucie pas des écrous et boulons, il veut simplement connaître la structure globale.

Dans le même sens, l'intervieweur veut juste que la vue d'ensemble montre de quel type d'environnement vous venez et comment il est en corrélation avec leur propre projet. Ils ne veulent pas que vous parliez de votre projet et vous ne devriez pas montrer de diagrammes de classe dans l'interview.

Alors, donnez-leur la vue d'ensemble de l'architecture de 10 000 milles. S'ils veulent plus de détails sur quelque chose, ils demanderont. Ensuite, commencez à aller plus loin.

Commencez par le plus haut niveau possible et descendez. Je commencerais par un schéma fonctionnel de base sur le tableau blanc. N'oubliez pas que l'intervieweur sera (espérons-le) doté de compétences techniques, mais ne sait rien de votre projet.

Quel que soit le projet, vous devriez pouvoir dessiner un aperçu de l'opération de base en quelques (<10) blocs. Vous pouvez ensuite développer les blocs que vous connaissez bien et ajouter plus de détails. Par exemple, vous mentionnez la persistance - cela pourrait être un seul bloc dans le premier diagramme, mais peut couvrir un tableau blanc entier si vous avez besoin d'explorer les détails.

S'ils posent des questions sur l'architecture, ils s'attendront à une vue d'ensemble pour voir si vous savez réellement comment elle s'emboîte ou si vous venez de travailler sur un petit morceau du projet. Assurez-vous de le fournir avant de commencer à explorer une petite zone.