La suringénierie est-elle un signe d'avertissement? [fermé]

Nous présentons donc un exercice de codage simple aux nouveaux candidats avec des exigences bien définies. Parfois, nous recevons des solutions qui ne résolvent pas vraiment le problème actuel, mais qui sont trop conçues pour résoudre un problème perçu - souvent en dehors des limites de l'exercice.

Maintenant ma question est, est-ce un signe d'avertissement?

EDIT: Une bonne partie de la discussion est basée sur le défaut du test - ce qui est un bon point. Comme je l'ai décrit dans un commentaire, la prémisse de base du test est de montrer comment vous pouvez lire les données du fichier de manière sensée (et vous seriez étonné de la variété des approches que nous voyons), et comment faire correspondre le avant de calculer la latence entre les mises à jour. Maintenant, pour que cela fonctionne, certaines hypothèses doivent être faites sur les données, et nous recherchons ces hypothèses, et nous déclarons également explicitement que nous voulons voir l'approche que vous adoptez (y compris l'approche OO, etc.) Tout cela en deux heures Plage de temps.

À mon humble avis, lors de mon entretien, c'était l'exercice le plus complet que j'ai rencontré.

Le scénario particulier que je réfléchis est celui où un candidat, plutôt que de lire le fichier, a accepté l'entrée "réseau" dans une application multithread, ce qui n'est clairement pas dans la portée.

Le problème est que le test est biaisé. Vous demandez à quelqu'un de démontrer sa capacité à écrire des logiciels complexes au niveau de l'entreprise à l'aide d'un simple exercice ne prenant que quelques minutes. Il y a d'autres interviewers dans d'autres entreprises qui se plaignent que les candidats ne montrent pas assez de compétences en conception orientée objet avec ces exercices, donc les gens ont tendance à surcompenser. Cela ne signifie pas nécessairement que votre candidat est incapable d'utiliser du code plus simple lorsque la situation le justifie.

Si vous voulez savoir si c'est le cas de votre candidat, demandez-lui simplement de le refaire en lui donnant des directives précises. Dites: «Je peux voir que vous présentiez vos compétences en conception orientée objet, mais cela semble exagéré pour un problème aussi simple. Pouvez-vous le réécrire en utilisant seulement deux petites fonctions?

Je dirais que c'est un signe d'avertissement clair, mais pas nécessairement disqualifiant pour un candidat.

Les candidats semblent rencontrer deux problèmes distincts:

1. Manquer le point de l'exercice - C'est assez alarmant. Toutes les compétences de programmation dans le monde ne créeront pas un bon résultat si quelqu'un est incapable de lancer le problème qu'il résout correctement. J'ai trouvé que les ingénieurs les plus productifs sont ceux qui sont capables d'identifier le vrai problème à résoudre, même si ce n'est pas exactement le problème posé. Avoir la capacité de penser de manière critique à la question posée et peut-être de la reformuler en quelque chose de plus simple à résoudre est une compétence critique. Manquer le point où le problème est clairement énoncé devrait être un gros drapeau rouge.
2. Suringénierie de la solution - Ceci est un problème secondaire et est souvent le résultat du premier problème. Il existe quelques pathologies différentes qui peuvent avoir ce résultat. Premièrement, ne pas bien comprendre le problème ou le formuler trop largement peut aboutir à une solution qui est tout simplement trop complexe. Ceci est clairement lié au premier point ci-dessus. Deuxièmement, essayer de se «montrer» en réfléchissant à des scénarios futurs qui pourraient ne pas être vraiment pertinents. Cela peut être problématique car cela indique que le candidat n'a pas compris la valeur de la simplicité dans les solutions et le report de la complexité jusqu'à ce qu'elle soit vraiment nécessaire. C'est quelque chose qui peut être corrigé avec de bons conseils, mais c'est une attention lorsque vous faites entrer quelqu'un dans l'organisation.

Je suggère de faire un suivi auprès du candidat au sujet de sa réponse au cours du processus. Plutôt que de simplement regarder leur résultat, essayez de déterminer ce qui les a menés au résultat, et en leur donnant quelques conseils, comment ils réagiraient et changeraient leur réponse. Cela sera probablement plus révélateur de leurs capacités que leur réponse directe au problème. Les «pourquoi» de leur approche peuvent vous donner une idée de savoir s'ils ne comprennent tout simplement pas, ou si leur compréhension n'était que légèrement différente de la façon dont ils ont choisi de répondre. Ce type de suivi en révélera également plus sur leur approche globale de la résolution de problèmes.

En outre, réexaminez le problème lui-même et voyez si ce n'est peut-être pas clair et peut-être amener les gens à se tromper de chemin lorsqu'ils formulent leurs réponses.

Non, pas lors d'un entretien d'embauche. Trop d'intervieweurs font des choses comme sous-spécifient intentionnellement les exigences et s'attendent à ce que l'interviewé pose d'autres questions, ou se penche sur les problèmes du monde réel qui ne sont pas explicitement mentionnés.

Voici certaines choses, du haut de ma tête, que vos exigences n'ont probablement pas mentionnées:

• Normes de codage

• commentaires

• Gestion des exceptions

• Noms descriptifs des variables, classes, méthodes

• Suite à une utilisation idiomatique de la langue

• Conception orientée objet appropriée

• Attention aux éventuels problèmes de concurrence

• Écriture de cas de test pour le code

Avez-vous prêté attention à une seule de ces choses sans l'énoncer explicitement? Comment le candidat pourrait-il savoir lesquels vous intéressent et lesquels ne vous intéressent pas?

Une interview est un environnement hautement artificiel. L'enquêteur essaie souvent de "tromper" un peu le candidat afin qu'il soit difficile pour l'interviewé de lui dire ce qu'il veut entendre, et l'interviewé essaie de deviner ce que l'enquêteur veut vraiment .

En général, faire une erreur sur cette supposition est assez différent de faire une erreur sur les décisions de conception du monde réel. Si vous voulez savoir si quelqu'un sur-ingénie des choses, vous devez probablement parler de conception plutôt que de regarder un exercice de codage très artificiel.

À mon humble avis, la réponse est clairement oui , c'est un signe d'avertissement, si

• l'exercice de codage avait une tâche claire
• a des exigences bien définies (et aussi bien écrites),
• les candidats ont eu la possibilité de poser des questions pour s'assurer qu'ils résolvent le problème correct.
• vous voulez des gens intelligents et qui font avancer les choses dans votre équipe, pas des astronautes d'architecture .

Pas aussi grand d'un signe d'avertissement que de ne pas résoudre le problème actuel . Le fait qu'il ait échoué au questionnaire et n'a pas fourni la bonne solution est un signe d'avertissement. Ce n'est pas nécessairement un scénario d'interdiction, car cela dépend de la manière et de la raison pour lesquelles il n'a pas fourni la bonne solution.

Souvent, la question est complètement merdique et simplement sans réponse. Ne prétendez pas que les enquêteurs ne font jamais d'erreurs. C'est toujours un échec de sa part de savoir pourquoi la question est de la merde. Si vous embauchez un ingénieur qui devrait aider à établir les exigences, c'est un problème. Si vous embauchez un codeur, vous ne vous attendez pas à ce qu'il le fasse.

En présumant que l'exercice de codage n'est pas horriblement gâché, il semble que la façon dont il a échoué a mal interprété le problème et s'est envolé dans les mauvaises herbes en essayant de résoudre un problème qui n'était pas là. Oui, c'est un signe d'avertissement.

Peut être.

Ne pas résoudre le problème est bien sûr un signe d’avertissement clair que quelque chose ne va pas. Qu'est ce qui ne s'est pas bien passé? Soit ils ont mal compris le problème, soit ils ont fait une mauvaise solution. Une mauvaise solution pour quelque chose de simple est un signe clair que le candidat est pauvre.

S'ils ont mal compris le problème, examinez attentivement vos besoins. Même des choses qui vous semblent limpides peuvent ne pas être claires pour d'autres qui ne sont pas familiers avec un domaine ou qui viennent d'un milieu différent (paramètres régionaux, âge, éducation). Si le candidat était là dans la salle avec vous, ou offrait la possibilité de poser des questions et échouait toujours, je considérerais cela comme un échec de leur part. Si les exigences étaient jetées par-dessus le mur, je leur donnerais probablement le bénéfice du doute (et penserais à fixer le processus d'entrevue).

Si la solution était correcte, elle devient moins claire. Personnellement, je pense qu'un certain nombre de personnes prennent YAGNI trop loin. Si vous pouvez prendre un problème spécifique et créer une solution générale sans augmenter la complexité ou nuire à la maintenabilité, alors pourquoi ne pas faire la solution générale? (Pensez à inverser une chaîne par rapport à inverser n'importe quelle collection) Ce type de "suringénierie" est clairement bon à mon avis.

Tout le reste est ce terrain d'entente gris. La solution aborde-t-elle les axes de changement probables? La solution ajoute-t-elle de la complexité ou nuit-elle à la maintenabilité? Ajout d'un peu de complexité pour résoudre les problèmes futurs qui sont presque garantis pour une victoire. Nuire grandement à la maintenabilité pour tenir compte de quelque chose qui est totalement improbable ne l'est pas.

Être un bon ingénieur logiciel signifie trouver le bon équilibre ici. Être un bon intervieweur signifie trouver le bon jugement / inférence sur comment et pourquoi le candidat a choisi cet équilibre, en utilisant souvent d'autres parties de l'entretien pour évaluer.

Peut-être, mais considérez ce qui suit:

• Les entretiens sont durs: les gens sont stressés. Cela devrait être pris en compte dans tout problème que vous donnez à quelqu'un

• Longueur de l'exigence: Quelle est la durée et la simplicité des exigences? Les avez-vous rendus plus verbeux pour vous assurer que vous avez tout inclus. En conséquence, ils peuvent être clairs pour vous, mais les exigences peuvent être trop conçues! J'ai passé un entretien d'embauche une fois pour un problème d'une heure avec environ 3 pages de texte pour un problème qui était relativement simple. Parfois, tout ce texte peut être difficile à lire et à interpréter lors d'une interview et peut également être mal interprété.

• Parfois, moins c'est plus: je préfère de loin avoir quelques puces, phrases et / ou exemples montrant les principales exigences, puis une discussion avec quelqu'un pour poser des questions et peut-être tendre la main si nécessaire. Je suppose que ce que j'essaie de dire, c'est que vous devez d'abord vérifier que vos exigences de test ne sont pas trop compliquées pour un problème simple.

• Compétence de communication: vous devez d'abord tester la capacité des candidats à communiquer et à poser des questions intelligentes sur le problème et une fois que vous savez qu'ils ont démontré qu'ils comprennent le problème, vous pouvez les exposer sur leur mise en œuvre.

• Bottom Line: Si vous n'avez pas vérifié que le problème est compris, vous ne savez vraiment pas quoi faire de l'ingénierie excessive. Comme d'autres l'ont dit, cela pourrait être une bonne ou une mauvaise chose, mais si vous n'avez pas vérifié la compréhension ou communiqué avec le candidat au sujet du problème à l'avance, il est plus difficile de connaître leur compréhension générale du problème et ce qu'il faut en faire.

Une grande partie de cela pourrait être attribuée à la façon dont vous formulez la question et à la façon dont vous avez mis l'intégralité de l'interview en perspective.

C'est comme "Voyons à quel point vous êtes créatif. Qu'est-ce que 2 + 2?" Quatre? Tout ce que vous pourriez trouver, c'est la réponse la plus simple, la plus évidente et la plus précise? Les développeurs jeunes / débutants qui sont si désireux d'impressionner lors d'une interview prendront le "Nous voulons tester vos compétences en codage ou voir à quel point vous êtes un programmeur." pour signifier "faire quelque chose de très sophistiqué". Nous aimons tous penser que la simplicité est préférable, sauf lorsqu'elle rend les choses plus difficiles.

Il existe des moyens de voir si quelqu'un est enclin à toujours être trop ingénieux. Donnez un exemple de code de quelque chose de trop complexe et demandez une solution plus simple. Lorsque quelqu'un propose une solution qui, selon vous, ne fonctionnera pas, c'est une excellente occasion de voir comment il réagit aux critiques. Personnellement, j'aimerais que quelqu'un soit ouvert à de nouvelles idées et reconnaisse une meilleure solution que quelqu'un qui va faire les mêmes erreurs encore et encore.

Et en réalité, n'avons-nous pas toujours la possibilité de changer notre code quand cela ne fonctionne pas? Vous pouvez sous-concevoir ou sur-concevoir initialement. Une fois que vous avez reconnu la solution simple, ne devrait-elle pas être plus facile à mettre en œuvre?

Cela dépend, mais généralement non.

Le design en général est une compétence acquise avec l'expérience. La description d' Aaronaught de cette progression liée par Marjan est généralement bonne.

La communication sous quelque forme que ce soit dépend également beaucoup du contexte. Ce qui peut sembler parfaitement clair pour signifier une chose dans un contexte, peut tout aussi clairement signifier autre chose dans un contexte différent. Savoir quelles questions poser est aussi quelque chose qui vient avec l'expérience.

Leur réflexion et la façon dont ils raisonnent leurs décisions sont bien plus importantes que leur solution. Sans passer en revue leur solution et leurs décisions avec eux, vous ne pouvez pas évaluer pleinement le contexte dans lequel elle a été développée.

Compte tenu de la progression ci-dessus, un candidat avec la solution sur-conçue pourrait bien être plus avancé que le candidat avec la solution simple.

Aussi: Pour quel poste de niveau embauchez-vous? La suringénierie d'un candidat d'entrée ou de niveau intermédiaire est moins problématique que la suringénierie d'un candidat de niveau supérieur.

Si le programmeur n'a pas résolu le problème, alors tout le code supplémentaire est la tentative du codeur pour masquer la non-réponse. Il s'agit de la même technique utilisée dans un test de dissertation par un étudiant qui ne connaît pas grand-chose au sujet. Il ou elle parlera d'un sujet convaincant, mais sans rapport avec l'espoir que son ignorance est masquée par le nombre de mots.

Si le programmeur a résolu le problème mais a ajouté beaucoup plus de code, considérez le contexte du programmeur, car certains domaines de programmation nécessitent des tolérances plus importantes que d'autres.

Par exemple, le code exécutant le pilote automatique dans un avion de ligne commercial a beaucoup moins de tolérances à l'échec qu'un jeu Android gratuit. Un développeur habitué à programmer des appareils intégrés difficiles à atteindre et presque impossibles à mettre à jour aura tendance à coder davantage ce qu'il en est alors un développeur qui peut publier 15 mises à jour en une journée.