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

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.

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.

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.

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 .

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?

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.

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.

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.