Dois-je m'inquiéter de la sur-ingénierie des tâches de programmation données pendant le processus d'entrevue? [fermé]

27

J'ai récemment eu un entretien téléphonique avec une entreprise. Après cet entretien téléphonique, on m'a dit de terminer une courte mission de programmation (un petit programme; cela ne devrait pas prendre plus de trois heures). Je ne suis directement chargé de terminer la mission et de rendre le code. On m'a donné la liberté totale d'utiliser n'importe quelle langue que je souhaitais et on ne m'a pas dit exactement comment rendre le code.

Immédiatement, je prévoyais de le lancer sur Github, d'écrire une suite de tests pour celui-ci, d'utiliser Travis-CI (intégration continue gratuite pour les référentiels publics Github) pour exécuter les suites de tests et d'utiliser CMake pour créer les makefiles Linux pour Travis-CI. De cette façon, non seulement je peux démontrer que je comprends comment utiliser Git, CMake, Travis-CI et comment écrire des tests, mais je peux aussi simplement créer un lien vers la page Travis-CI afin qu'ils puissent voir la sortie des tests. J'ai pensé que cela le rendrait un peu plus pratique pour l'intervieweur.

Étant donné que je connais bien ces technologies, cela n'ajouterait essentiellement pas de temps à la mission.

Cependant, je suis un peu inquiet de voir que faire tout cela pour une tâche relativement simple serait mauvais. Bien que cela n'ajoute pas beaucoup de temps pour moi, je ne veux pas qu'ils pensent que je passe trop de temps sur des choses qui devraient être simples.

DormoTheNord
la source
5
Je serais prudent de mettre des réponses aux problèmes d'interview sur github, car certaines entreprises aiment garder leurs problèmes confidentiels.
Scroog1
7
Les questions sont accessibles au public sur leur blog (ils m'ont envoyé un lien vers le blog), donc je ne pense pas qu'ils soient concernés par cela.
DormoTheNord
3
@DormoTheNord Je dirais que vous n'êtes pas suringénierie: avoir un bon processus de développement est quelque chose de complètement différent de la suringénierie et c'est (IMO) un bon signe.
K.Steff
3
Je passerais une partie de ce temps supplémentaire à documenter les zones grises dans la spécification du problème, les hypothèses, les limites, .... Montrez que vous ne plongez pas seulement dans le codage, mais contemplez le problème et son contexte.
HABO
4
@DormoTheNord Les questions peuvent être publiques, mais vos réponses le seront aussi. Il sera disponible pour les autres personnes interrogées, si elles peuvent le trouver. Cela , ils n'aimeront probablement pas.
Izkata

Réponses:

29

En tant qu'intervieweur, je serais heureux de voir la connaissance du processus de développement de logiciels démontrée par cette approche; par opposition à la simple écriture du code.

En particulier, avoir une suite de tests pour des problèmes même très simples serait un bon signe (même au niveau FizzBuzz). J'ai vu des candidats soumettre des solutions qui n'ont même pas résolu le problème et un simple ensemble de tests leur aurait montré cela. De plus, avoir l'historique des validations me permet d'avoir une idée du processus de réflexion que le candidat a utilisé pour arriver à la solution.

D'un autre côté, je connais des personnes rejetées par certaines entreprises à un stade précoce du processus de suringénierie. Cependant, dans la plupart des cas, cela est dû à une ingénierie excessive de la solution, pas nécessairement aux processus utilisés.

Scroog1
la source
2
Seriez-vous prêt à dire que si une entreprise me rejetait pour avoir fait ce que j'avais l'intention de faire, ce serait un signe que l'entreprise ne respecte pas les méthodologies de développement logiciel et que je préfère ne pas travailler pour cette entreprise?
DormoTheNord
7
Je n'irais pas nécessairement aussi loin, car il y a une certaine chance (malheureusement). Vous pourriez avoir le seul intervieweur qui n'aimait pas cette approche; ou ils pourraient être de mauvaise humeur ce jour-là et ne pas vouloir parcourir les données supplémentaires fournies par cette approche. Cela dit, il n'y a généralement pas de mal à clarifier le niveau de détail qu'ils souhaitent. En outre, poser une ou deux questions de clarification peut également être un bon signe pour l'intervieweur (bien qu'il ne les bombarde pas continuellement avec des questions non informées, évidemment).
Scroog1
+1 - tant que vous ne portez pas atteinte à la solution, je voudrais voir les tests unitaires et tout ce que vous faites sans invite.
Telastyn
1
Le risque de regarder trop à travers pourrait être atténué en envoyant à la fois un lien github de base et un lien directement vers le code source du test pour les paresseux / occupés.
Dan Neely
15

Avoir comme interviewé quelqu'un qui a compris des choses comme le contrôle de version, l'IC, les tests unitaires et autres serait un pas en avant par rapport à ce que je vois habituellement.

Bien que, pour moi, la chose la plus importante soit que le problème soit résolu et bien résolu, sachant que le candidat comprenait des façons d'améliorer la qualité de son produit livrable attirerait certainement mon attention.

Ce que je vois généralement, ce sont des gens qui non seulement ne comprenaient pas le problème, mais qui ne comprenaient pas non plus comment résoudre le problème - et ils seraient ignorés quel que soit le nombre d'outils supplémentaires qu'ils utilisaient dans le processus.

Steve Hill
la source
6

Gardez à l'esprit qu'il y a une limite de temps. L'intervieweur le sait, donc cela signifie (si j'étais l'intervieweur) qu'il verra non seulement que vous avez résolu le problème dans le délai imparti, mais qu'il l'a fait si rapidement qu'il vous restait du temps pour le placage à l'or, ce qui est un bon signe de votre capacités de résolution de problèmes ainsi que votre appréciation de la rigueur et de la diligence.

La suringénierie est un mauvais mot lorsque vous créez des adaptateurs AbstractFactoryManager qui sont branchés pour distribuer BuzzManager et FizzManager juste pour résoudre FizzBuzz.

Ce que vous faites, c'est une diligence excessive, ce qui n'est même pas une chose (bien que la sous-diligence le soit certainement).

Cela dit, si vous vous retrouvez avec le temps ou avec une solution à moitié piratée parce que vous avez utilisé votre temps sur les extras que vous prétendez "n'ajoutez pas de temps du tout", cela semblera comme si vous avez une très mauvaise compréhension de la taille apparemment petite les tâches peuvent être. Cela peut être un attribut dangereux chez un ingénieur et trop courant chez les juniors. Établissez les priorités de manière appropriée et n'effectuez les opérations de crédit supplémentaire qu'après avoir terminé la solution requise .

Jimmy Hoffa
la source
Il n'y a pas de limite de temps, mais juste une note disant que l'affectation ne devrait pas prendre plus de trois heures à un programmeur décent. Voudraient-ils vraiment vérifier mon journal git pour m'assurer que je n'y ai passé que trois heures entre le commit # 1 et le commit final?
DormoTheNord
2
@DormoTheNord s'il n'y a pas de limite de temps, alors le temps non consacré à la solution demandée peut être considéré comme une mauvaise priorisation. Malheureusement, les ingénieurs sont tous des penseurs indépendants et ont donc leurs propres opinions sur ces choses de l'un à l'autre. trier pour le voir comme une grande aubaine. J'ai connu de grands ingénieurs des deux courbes. Dans ces cas, cela se résume à ce que vous appréciez, affichez cela et quelqu'un qui apprécie la même chose que vous l'apprécierez, c'est avec qui vous voulez travailler.
Jimmy Hoffa
C'est ce que je déteste dans les entretiens d'embauche ... la chance qu'implique de plaire aux préférences personnelles de l'intervieweur. Peut-être que cela devrait être standardisé :)
DormoTheNord
Ne vous inquiétez pas, la chance se doublera au cours de votre carrière. Vous avez juste besoin d'être chanceux quand vous obtenez la bonne chance et quand vous obtenez le mauvais :)
Scroog1
1
Je serais prudent en le décrivant comme un «placage d'or» car ce terme est généralement supposé être une mauvaise chose: en.wikipedia.org/wiki/Gold_plating_%28analogy%29
whatsisname
6

Un autre point de vue à considérer est que votre approche n'est ni bonne ni mauvaise. Je peux imaginer des interviewers qui y penseraient trop et je peux imaginer des interviewers qui aimeraient encore plus d'ingénierie.

Ne t'inquiète pas autant. Au lieu de cela, résolvez le problème de la manière que vous jugez la meilleure et vous recevrez probablement des offres d'emploi de personnes qui sont d'accord avec vous. C'est une excellente première étape vers un environnement de travail productif. N'oubliez pas que les entretiens vont de deux manières. La réponse de l'intervieweur à votre solution vous en dira également long. Voulez-vous vraiment travailler avec des gens qui croient que votre instinct de développement et votre philosophie sont mauvais?

Marche de Corbin
la source
3

En réalité, personne ne se soucie de savoir si le candidat peut concocter un dépôt git ou créer des makefiles à la hâte, parce que c'est juste rappeler ce qu'il a appris par cœur. Ce sont des compétences secondaires à l'aspect réel de la résolution de problèmes et de la conception de la question d'entrevue.

Alors oui, votre intuition est sur le point que cela semble potentiellement mauvais, car il peut sembler que le candidat croit que quelqu'un qui peut régurgiter quelques commandes et modèles mémorisés pour créer un squelette de projet possède des compétences logicielles impressionnantes.

L'aspect de la suite de tests de la solution est cependant bon. Fournir une réponse avec une suite de tests de régression gagnera probablement vos points. D'autant plus que votre suite de tests exerce les cas saillants du code. La suite de tests n'a pas besoin d'avoir beaucoup de pièges formels et de s'appuyer sur des outils; le simple fait que vous en ayez un soit suffisant pour une interview. Il est plus ou moins évident que si vous pouvez mettre en place des tests unitaires ad hoc dans un quiz d'entrevue, vous pouvez le faire avec des outils sur un vrai projet.

Kaz
la source
1

J'ai récemment eu un entretien téléphonique avec une entreprise. Après cet entretien téléphonique, on m'a dit de terminer une courte mission de programmation (un petit programme; cela ne devrait pas prendre plus de trois heures).

Je procéderais avec prudence. Évaluez la pertinence du défi pour l'emploi et assurez-vous que le remboursement futur de l'employeur fera valoir 3 heures de votre temps.

Je remets en question la valeur de ces types de tests, et je préfère juger quelqu'un sur ses réalisations passées. Une tâche courte prédéfinie ne peut rien dire à l'employeur de ce que vous pouvez faire. Seulement ce que vous ne pouvez pas faire, et cela peut être rapidement déterminé avec quelques questions par téléphone.

Les tests ont leur place. Posez-vous les questions suivantes sur le test et répondez en conséquence.

  1. Le test est-il équitable compte tenu de votre niveau de carrière actuel?
  2. Le test a-t-il une réponse correcte clairement définie?
  3. L'enquêteur s'intéresse-t-il à votre potentiel en tant que personne ou manifeste-t-il plus d'intérêt pour les résultats des tests (c'est-à-dire que les agences de recrutement sont terribles pour cela).
  4. Le test représente-t-il le type de travail que vous aimeriez faire ou est-ce une vérification ambiguë des compétences (c'est-à-dire un test si vous connaissez la syntaxe Java)?

Je ne suis directement chargé de terminer la mission et de rendre le code.

Vous venez de répondre à votre propre question.

Immédiatement, je prévoyais de le lancer sur Github, d'écrire une suite de tests pour celui-ci, d'utiliser Travis-CI (intégration continue gratuite pour les référentiels publics Github) pour exécuter les suites de tests et d'utiliser CMake pour créer les makefiles Linux pour Travis-CI.

Non, ce n'est pas ce qu'ils vous ont demandé de faire.

De cette façon, non seulement je peux démontrer que je comprends comment utiliser Git, CMake, Travis-CI et comment écrire des tests, mais je peux aussi simplement créer un lien vers la page Travis-CI afin qu'ils puissent voir la sortie des tests. J'ai pensé que cela le rendrait un peu plus pratique pour l'intervieweur.

Je ferais attention de démontrer mes compétences trop tôt ou trop tard dans le processus d'entrevue. Si vous sentez que vous n'avez pas bien réussi lors de l'entretien et que vous essayez maintenant de compenser, cela ne fonctionnera pas. D'un autre côté, faire trop quand on ne le demande pas trop montre un empressement. Cela pourrait amener l'employeur à contrer avec une offre de salaire inférieure à ce que vous attendiez.

Cependant, je suis un peu inquiet de voir que faire tout cela pour une tâche relativement simple serait mauvais.

Oui, ça a l'air mauvais. Résoudre leur défi avec une seule ligne de code sera bien plus impressionnant qu'un projet entièrement débusqué.

D'après mon expérience, ce n'est pas comme ça que vous gagnez l'entretien d'embauche, mais c'est une façon de perdre le travail. Le test de code est un problème de contrôle qualité. Chaque entreprise qui utilise des tests de code lors de l'embauche de personnes le fait, car auparavant, elle n'utilisait pas de tests de code. Ils ont eu une mauvaise expérience de quelqu'un qui a glissé à travers les fissures du processus d'entrevue qui n'aurait pas dû.

Ils prendront votre code source et le feront circuler au bureau. Les gens vont commenter cela, et ce que vous ne voulez pas qu'ils disent, c'est "Il a fait cette erreur? Mais passait du temps à utiliser Git, CMake et Travis-CI. Quel idiot d'avoir raté cette erreur."

C'est ça. Tu as perdu.

Ils veulent savoir que vous pouvez coder, car ils ne peuvent pas vous l'apprendre. Git, CMake et Travis-CI peuvent facilement être enseignés.

Reactgular
la source
2
@JimmyHoffa êtes-vous en désaccord avec toute ma réponse ou tout simplement mes commentaires sur les tests? Peut-être que je n'ai pas exprimé correctement mon point de vue, ou peut-être pas? Pour moi, j'apprécie davantage la composante humaine qu'un test écrit. Un candidat qui échoue à FizzBuzz ne prouve rien pour moi. Je dois parler à cette personne pour comprendre pourquoi. mais je veux embaucher (toujours) des travailleurs qualifiés. Je ne pense tout simplement pas rentrer à la maison écrire ce test et revenir. Est un moyen efficace de le faire. Je préfère poser la question FizzBuzz et les regarder travailler. Comprenez vous?
Reactgular
1
@JimmyHoffa Je pense que cela se résume aux attentes des employeurs pour une location. Cela dit, je me balance plus à vos côtés plus je lis sur les tests FizzBuzz. Un programmeur qui ne peut réussir à aucun niveau de carrière a des problèmes. Je ne suis tout simplement pas sûr que ce type de test soit le même que l'OP. Voir cette question connexe: stackoverflow.com/questions/117812/…
Reactgular
Autrement dit, je suis un fan des processus d'entrevue ardus et des candidats qui tentent d'aller au-delà (sans compromettre les demandes de base; sinon, ils priorisent mal leur temps). Votre réponse entière semble dénoncer ces deux choses.
Jimmy Hoffa
@JimmyHoffa Je pense que mon attitude vient du travail en freelance dans le domaine créatif où les clients demandent souvent à un fournisseur de terminer un travail créatif ou des tests dans le cadre de leur processus d'enchères pré-travail. Je ne fais pas ce genre de travail, car si je passais des heures sur chaque prospect, je ne ferais aucun travail facturable. Lorsque j'ai dit au PO de procéder avec prudence, c'était dans l'espoir de l'empêcher de perdre du temps. Le PO voulait investir du temps pour faire beaucoup de travail supplémentaire. C'est une tentation, mais le gain en vaut-il la peine? Peut-être, mais le PO n'a pas clarifié cela. Il pourrait s'agir de travaux à court terme.
Reactgular
0

Je pense que votre approche n'est ni bonne ni mauvaise en soi . Je demanderais à l'intervieweur s'il est acceptable d'utiliser Github et les autres outils. Comme @Izkata l'a souligné dans les commentaires, vous rendez votre solution publique.

En tant qu'intervieweur, je savais qu'il n'y avait généralement aucun mal à ce que le candidat essaie de clarifier certaines choses. En outre, poser une ou deux questions peut être un bon signe, car vous ne vous précipitez pas pour faire des choses que vous n'avez pas comprises.

N'oubliez pas, cependant, que la chose la plus importante est que le problème est résolu et bien résolu. À cet égard, tout le monde convient qu'une suite de tests est utile. Mais, pour cela, il vous suffit peut-être d'envoyer quelques classes de test avec votre projet / solution.

Hbas
la source