Est-il raisonnable de s'attendre à ce qu'un développeur senior sache quels sont les modèles de conception OOP? [fermé]

Je prépare des questions pour des entretiens d'embauche pour un poste de développement senior. Le travail comprendrait la conception orientée objet, et le logiciel existant utilise des modèles de conception, je voudrais donc demander aux candidats d'expliquer quelques modèles de conception qu'ils connaissent, qu'ils ont utilisés, comment ils les ont utilisés, pourquoi ils ont les a utilisés et ainsi de suite. Cependant, dans des interviews précédentes, lorsque j'ai demandé à des développeurs seniors ayant au moins 5 à 10 ans d'expérience sur les modèles de conception, presque personne n'en avait jamais entendu parler. Je pense que deux développeurs sur vingt pourraient nommer un seul modèle de conception (Singleton et MVC, respectivement).

Ma question est donc la suivante: est-il judicieux de poser ces questions? Ou est-ce un sujet tellement obscur que vous ne pouvez pas vous attendre à ce que les nouveaux employés les connaissent déjà?

Un développeur senior devrait-il avoir une expérience préalable avec les modèles de conception, ou diriez-vous que les modèles de conception sont un sujet si simple que tout développeur décent peut les reprendre pendant la formation? Si oui, quelles questions poseriez-vous à la place pour évaluer leurs capacités de conception?

Ajouter Après avoir lu les réponses jusqu'à présent, je devrais apporter quelques clarifications:

• Le travail est pour un développeur .NET avec une expérience en OOP / OOD
• Le code existant utilise des noms de classe comme IParameterGraphVisitoret IStorageFactorydans de nombreux endroits
• Comment demandez-vous aux gens leurs expériences passées avec les designs OO qu'ils ont créés, s'ils n'ont pas le vocabulaire pour expliquer leurs designs? C'est ce que je veux faire, et tout ce que je peux trouver, c'est "veuillez dessiner la hiérarchie de conception / objet de votre dernier projet sur le tableau blanc".

Il y a de fortes chances qu'ils les connaissent. Ils ne les connaissent peut-être pas comme des «modèles de conception»; c'est-à-dire, ils peuvent ne pas être familiers avec la terminologie académique pour de telles choses. Ce que vous voyez comme une «machine d'état» pourrait simplement être une approche de bon sens à un problème pour un programmeur plus âgé et plus expérimenté. Je n'ai jamais prêté beaucoup d'attention aux `` modèles de conception '', par exemple, mais quand j'ai appris ce qu'était une State Machine, j'ai dû rire parce que je faisais ça depuis des années. Qui savait que j'étais un tel universitaire? Je l'ai toujours considéré comme une compétence de base en matière de codage, et non comme un «modèle de conception».

Le point n'est pas de supposer que vos développeurs expérimentés connaissent les termes du manuel pour les choses; demandez-leur plutôt comment ils structureraient les classes ou comment ils aborderaient une tâche.

Votre attente est tout à fait raisonnable pour un développeur OO senior. Quiconque se dit que sans connaître les modèles de conception démontre simplement que l'expérience ne s'apporte pas automatiquement au fil des années :-( Bien sûr, il y a beaucoup de développeurs qui ont passé des années voire des décennies sur le terrain, sans jamais entendre parler de design modèles - cela montre simplement qu'ils n'étaient pas intéressés à apprendre de nouvelles idées, à s'améliorer et à adopter les meilleures pratiques.

Un développeur senior devrait-il avoir une expérience préalable avec les modèles de conception, ou diriez-vous que les modèles de conception sont un sujet si simple que tout développeur décent peut les reprendre pendant la formation?

L'expérience de l'OMI compte beaucoup. En théorie, un développeur décent peut lire les modèles de conception dans un livre, ou même sur Wikipedia, et comprendre le concept de base en 15 minutes. Cependant, l' application correcte des concepts nécessite une expérience durement acquise. Il est facile de se passionner pour les motifs, en essayant de les entasser dans chaque morceau de code possible, l'art pour l'art. Il est également facile de les rejeter en disant que "les modèles ne sont pas une solution miracle, utilisez simplement la chose la plus simple qui pourrait éventuellement fonctionner". Trouver le juste milieu entre les deux extrêmes en apprenant quand et comment utiliser des modèles pour résoudre de vrais problèmes, et quand ne pas les utiliser, demande des années d'expérience .

Quelles questions poseriez-vous à la place pour évaluer leurs capacités de conception?

De concert avec ce qui précède, je voudrais seulement ajouter ces questions à votre liste:

• Quels sont les inconvénients des modèles de conception (en général, et de ceux qu'ils mentionnent explicitement)?
• Quand ne pas les utiliser et pourquoi?

Mise à jour

@GrandmasterB a un bon point en ce que certains développeurs peuvent utiliser des modèles de conception spécifiques sans connaître leur nom. D'une certaine manière, il a raison en ce qu'il s'agit d'une question de terminologie / communication. Cependant, l'autre côté de la médaille est qu'il s'agit bien d'une question de terminologie / communication :-) C'est-à-dire que l' un des principaux avantages des Design Patterns est de donner un vocabulaire commun aux développeurs, améliorant considérablement la communication . (Essayez d'expliquer l'idée de base de l' adaptateur sans utiliser le mot lui-même, ou ses synonymes "wrapper" et al!). Aussi talentueux et compétent qu'un candidat puisse être, sans connaître la ou les terminologies largement acceptées, il introduira un problème de communication dans votre équipe.

Un développeur senior ? Absolument. Un junior devrait. J'ai 15 ans, je n'ai pas d'éducation formelle sur le sujet et même je les comprends. Il est non seulement raisonnable de s'attendre à ce qu'ils les connaissent, mais ce serait inacceptable s'ils ne les connaissaient pas. En supposant qu'ils connaissent quelque chose sur la programmation orientée objet, ce qu'ils font très probablement.

Dans une entrevue, vous devez demander ce qui est essentiel pour le candidat de savoir afin de faire le travail.

S'ils doivent connaître les noms des modèles car ils proviennent de Gang of Four, alors c'est une exigence valide.

Si, d'autre part, vous voulez qu'ils affichent une connaissance pratique appropriée de l'architecture du programme, je pense que vous feriez mieux de leur donner un problème et de leur demander comment cela structurerait le code. S'ils vous donnent la solution de modèle appropriée, vous avez la preuve qu'ils le savent, quel que soit le nom utilisé.

Chaque fois que j'interviewe pour des postes supérieurs, ils ont tendance à être plus «pratiques» que les questions et réponses. Je veux une démonstration claire de compétence et de confort dans la programmation. Je veux également une base solide dans les concepts CS, ce qui signifie des compétences plus générales sur la façon d'appliquer des concepts tels que l'encapsulation, les algorithmes, le couplage / la cohésion, etc. Expérience et familiarité dans plusieurs langages et paradigmes.

Dépend du domaine de leur expertise. Je ne m'attendrais pas à ce qu'un développeur C intégré en sache beaucoup sur les modèles de conception. Si nous parlons d'un développeur Java ou .NET, ils doivent être familiers avec les modèles de conception, et surtout comment ne pas trop s'emballer avec eux.

En supposant que vous recherchez l'ancienneté dans la POO, la réponse est définitivement oui. Les modèles de conception sont le lexique du langage OOP.

De plus, il est aujourd'hui déraisonnable qu'un programmeur OOP décent avec 10 ans d'expérience ne puisse pas nommer un modèle de conception, étant des modèles de conception largement adoptés dans les API, les bibliothèques et les cadres de développement standard.

Cela fait des années maintenant que je pose cette question lors des entretiens et c'est un showstopper lorsque le candidat n'apporte pas de réponses satisfaisantes sur le sujet.

Oui, mais vous devriez probablement obtenir leur compréhension en posant des questions de conception plutôt qu'en demandant aux gens d'énumérer les modèles de conception dont ils ont entendu parler. Je suis assez à l'aise avec les modèles décrits dans PoEAA, GoF et même certains modèles de programmation fonctionnelle et je ne pense toujours pas que vous en apprendrez beaucoup plus sur mon approche de la résolution des problèmes en me demandant de nommer certains modèles.

Étant donné une question comme "Concevez-moi un éditeur de texte" avec des suivis comme, "Comment allez-vous prendre en charge les objets intégrés comme les images? Gras et italique? Annuler?" Vous finirez probablement par en entendre suffisamment pour reconnaître le modèle de commande, le modèle composite, le modèle de souvenir et quelques autres, même avec une courte conversation.

Des modèles de conception ont été découverts puis décrits afin que nous ayons un langage commun avec lequel communiquer les décisions de conception.

J'ai malheureusement travaillé pour quelqu'un pour qui chaque utilisation d'un modèle de conception devait être expliquée et justifiée, non pas à cause d'une diligence raisonnable, mais parce qu'il ne les connaissait tout simplement pas. Ce n'est pas amusant. Mais les développeurs les plus sérieux ont, par accident ou par conception, appris les noms des modèles OO les plus couramment utilisés, si rien d'autre, et la plupart des développeurs d'applications d'entreprise dignes de ce nom connaissent au moins quelque chose sur les modèles PoEAA les plus courants.

Raisonnable. Certainement. Nécessaire. Non

Je demande aux candidats potentiels s'ils connaissent les modèles de conception. Ce n'est qu'un critère parmi d'autres à peser dans son ensemble. Ne négligez pas l'image totale.

Oui, de nombreux développeurs utilisent sans le savoir certains modèles de conception, sans aucun doute.

Ce n'est pas pourquoi je pose la question.

Il est important de savoir que je peux communiquer rapidement et efficacement avec un autre développeur. Je ne veux pas passer 20 minutes sur un tableau blanc expliquant une machine d'état pour constater qu'ils "l'ont utilisé auparavant, mais n'ont jamais su comment l'appeler". Ce n'est pas productif.

Ils aident également au processus de refactorisation. En parcourant le code, on peut implémenter au hasard une forme de modèle d'usine, mais le modèle d'usine GoF a résisté à l'épreuve du temps. C'est pourquoi c'est le modèle d'usine, pas ENCORE UN AUTRE fp (réinventer la roue n'est pas préférable, Joel sur le logiciel a beaucoup sur les inconvénients de le faire).

Une équipe qui utilise et reconnaît l'importance des modèles de conception augmente la communication et la productivité. Si votre équipe, en tant qu'unité, n'utilise pas de dp, elle perd sa pertinence.

Parlant de ma propre expérience, j'ai ignoré les modèles de conception pendant un bon moment. Je savais qu'ils existaient, je n'ai jamais lu à leur sujet. Une fois que j'ai finalement mordu la balle, j'ai réalisé que j'utilisais le modèle de conception depuis le début et je ne m'en rendais pas compte ou je ne savais pas que mes solutions de conception avaient en fait un nom commun.

Je serais plus enclin à proposer un ensemble de problèmes où un modèle de conception particulier correspond bien à la solution et à voir le développeur proposer quelque chose de similaire au modèle. S'ils le font, tant mieux. Je serais peut-être encore plus enclin à embaucher un développeur qui utilise des modèles de conception sans le savoir, car je vois de nombreux développeurs qui ont des connaissances en matière de modèles de conception essayer d'adapter une solution à un modèle lorsque cela n'est pas approprié plutôt que de réaliser qu'un modèle particulier arrive à résoudre le problème. problème bien.

Je pense qu'une meilleure question serait: étant donné le nom d'un motif et une description du motif, par exemple un motif d'usine du livre Gang of Four, le candidat devrait être en mesure de proposer un scénario où le motif serait une approche raisonnable.

Il y a des développeurs avec 5 à 10 ans d'expérience et des développeurs seniors. Ce n'est pas du tout la même chose. Oui, si vous embauchez à un niveau supérieur et que vous vous attendez à ce que les gens connaissent et utilisent les modèles de conception, je n'embaucherais pas de personne âgée qui ne les connaissait pas. Ce serait comme embaucher un spécialiste de base de données qui ne comprend pas les jointures gauches. C'est un truc assez basique pour un vrai développeur senior. J'embaucherais probablement une personne junior cependant.

Oui, en effet, ils devraient être familiers avec le terme, et devraient même être en mesure de nommer quelques-uns des modèles - mais ne faites pas l'erreur de confondre les connaissances théoriques avec l'expérience.

Il y a beaucoup de gens qui, avant une interview, réviseront les modèles de conception et pourront les expliquer avec une brève description - mais ce n'est que la théorie. C'est un vrai développeur senior qui peut repérer quand en utiliser un, ou sans connaissance d'un modèle formel résoudrait le problème d'une manière classique.

La meilleure façon de vérifier est de les laisser concevoir quelque chose devant vous et de poser des questions approfondies. Un développeur senior est quelqu'un qui peut penser naturellement au niveau de l'abstraction. Ce sont ces gens qui "créent" les modèles de conception.

Comme la classe Peopleware qui parle d' embaucher un jongleur sans leur demander de jongler - simplement parce qu'ils disent qu'ils ne peuvent pas signifier grand-chose ... essayez-les.

Comme je l'ai déjà dit, je pense aussi que c'est OK s'ils ne se souviennent pas des mots à la mode par cœur. Mais comme il s'agit d'un poste de niveau supérieur, ils devraient savoir quand appliquer un modèle pour résoudre un problème de manière optimale au lieu d'utiliser les pires solutions. Ainsi, donnez-leur un problème qui devrait être résolu à l'aide d'un modèle (par exemple, comment créer un objet sans coder en dur sa classe, comment accéder aux éléments d'un objet sans avoir de détails sur sa mise en œuvre, etc.) et voir comment ils l'attaqueront.

Certainement, ils devraient connaître les modèles, mais pas nécessairement les mots à la mode.

Par exemple, MVC a de nombreuses alternatives très similaires comme PAC, 3 niveaux. Il y a quelques années, un autre mot à la mode populaire pour MVC était "Model 2". En fait, je connais de très bons développeurs qui connaissent parfaitement ce modèle, mais je ne savais pas que le mot à la mode actuel était MVC.

Très simplement: si vous les utilisez, vous devez demander à vos candidats. S'ils connaissent des modèles, cela devrait ajouter quelques points positifs; mais ne pas savoir ne doit pas nécessairement les exclure, surtout s'ils montrent de bonnes compétences en OOD. Il est peu probable que les développeurs qui ont participé à des projets de maintenance en savent beaucoup sur les modèles de conception par rapport à ceux qui ont commencé à les concevoir. cela dépend aussi du fait que l'on leur a enseigné des modèles de conception à l'université. D'après mon expérience, il est peu probable qu'ils le fassent. La plupart des universités et des cours privés vous enseignent OOP mais pas OOD. Les chances qu'ils aient étudié le DP sont encore moindres.

Personnellement, je n'avais pas étudié le DP jusqu'à ce que mon projet me demande aussi. Même alors, j'ai constaté que j'avais utilisé quelques-uns des modèles, au moins d'une manière similaire, sinon de la manière exacte décrite dans le livre. J'ai été surpris de savoir qu'ils étaient codifiés. Recherchez donc de bonnes compétences en conception si elles ne connaissent pas DP. S'ils connaissent le DP, il est probable qu'ils sont bons en conception, mais qu'ils les testent toujours. Ils ont peut-être simplement entendu un mot à la mode sur DP ou découvert par un initié et ont juste étudié quelques modèles sans les avoir appliqués.

Il est raisonnable pour vous de vous attendre à ce que les personnes qui postulent pour un emploi avec vous sachent (ou apprennent) les choses dont vous avez besoin dans votre créneau, qu'elles soient ou non conformes aux normes de l'industrie. Sinon, vous vous condamnez à la médiocrité. Mais méfiez-vous de faire de certaines connaissances (ou compétences) une exigence d'emploi, si ce n'est pas vraiment nécessaire.

Disons que vous avez deux candidats avec des antécédents à peu près similaires, et l'un est en mesure de vous parler des modèles de conception, et l'autre ne l'est pas. Qu'est-ce que cela vous apprendra sur la façon dont ils vont fonctionner au travail?

Vous dites que le logiciel existant utilise des modèles de conception. Est-ce un avantage? Si c'est le cas, comment? Votre objectif est-il que les nouveaux logiciels écrits soient conformes aux modèles existants ou que de nouveaux modèles soient introduits? Pourquoi?

Je peux penser à un développeur senior qui ne connaît pas les modèles de conception dans la situation suivante:

1. Il y a seulement un livre sur les modèles de conception. C'est le livre qui les a rendus populaires en premier lieu. Si la personne n'a pas lu ce livre, il est possible qu'elle ne connaisse pas les modèles de conception ou qu'elle en ait entendu parler, mais qu'elle ne sache pas à quoi elle sert
2. Au lieu de cela, ils devraient savoir quelque chose comme uml ...
3. Trouver de bonnes informations sur les modèles de conception sur Internet n'est pas facile. Vous êtes très chanceux si vous cliquez sur la bonne page Web qui possède une bonne connaissance des modèles de conception. Le simple fait de venir au logiciel après 1995 pourrait faire en sorte qu'une personne ne connaît pas le livre de modèles de conception, car le livre est ancien.

Pourquoi un développeur dans un environnement non OO devrait-il connaître les modèles de conception OO? J'ai travaillé dans des magasins qui ne faisaient que du Cobol, uniquement du PL / SQL, seulement du Progress 4GL, etc. modèles.

Être capable de citer sans réfléchir à partir d'un catalogue de modèles ne fait pas non plus de vous un bon développeur (en fait, selon mon expérience, il produit certains des pires morceaux de code que j'ai jamais vus). C'est pourtant ce que vous attendez d'être la marque d'un "développeur senior". Je travaille l'industrie depuis 15 ans, mais ne me demandez pas de dessiner un schéma de configuration. Je ne lui ai jamais donné beaucoup de temps, je n'en ai pas besoin. J'ai acquis suffisamment d'expérience pour trouver ce qui fonctionne sans y mettre un nom spécifique, et si j'ai besoin de la définition formelle, je sais où le chercher (et oui, j'ai les livres de référence dans ma bibliothèque personnelle). C'est la marque du développeur expérimenté, et non pas les connaissances acquises par le bourrage de certains livres scolaires.