Question:
Dois-je envoyer un errata après un entretien technique?
le_douard
2013-08-06 14:49:50 UTC
view on stackexchange narkive permalink

J'ai eu un entretien technique avec une entreprise prestigieuse et je me suis plutôt bien débrouillé pendant toutes les questions et l'intervieweur a semblé satisfait de moi ... mais après l'interview j'ai remarqué que le code que j'ai écrit avait un bug (pas un très gros un mais quand même). J'ai repéré les erreurs quelques secondes après avoir quitté l'interview.

Serait-ce une bonne idée pour moi d'inclure également un "errata" dans mon message de remerciement à l'intervieweur? Je l'inclurais en tant que " post scriptum ", ou devrais-je l'écrire comme un message séparé pour que mon e-mail ne paraisse pas trop long?

Personnellement, je suis le genre de personne qui sera gêné en laissant ma solution telle quelle. Mais je ne veux pas compromettre mes chances en envoyant un errata si cela est considéré comme une mauvaise chose.

MISE À JOUR: Donc pour conclure mon histoire. En fin de compte, j'ai envoyé l'errata et il a été bien reçu et j'ai été accepté pour la prochaine "phase" du processus de candidature au sein de cette entreprise. Pour donner plus de contexte, nous parlons d'une entreprise américaine implantée dans plusieurs pays. Elle est également reconnue pour la qualité de son processus de recrutement et la qualité de ses ingénieurs / programmeurs. Bien entendu, je ne vous donnerai pas le nom de cette société.

Merci à tous pour vos réponses.

Personnellement, je vous donnerais des points bonus pour l'avoir signalé. Cela montre que vous vous souciez de votre travail. Chaque développeur sait que des bogues se produisent et le fait que vous en ayez écrit un est moins important que le fait que vous l'ayez remarqué et corrigé. Aussi, ne l'envoyez pas en tant que PS, mais pas non plus comme première chose. Faites-le simplement partie de votre note de remerciement en tant que "au fait, peu de temps après l'interview, j'ai remarqué que ..."
@gnat J'ai vu toutes les questions jusqu'à la page 10 et je n'ai pas pu en trouver.
J'ai déjà fait ça. De retour à la maison après l'entretien, j'ai juste remarqué qu'une de mes réponses était fausse. J'ai appelé l'intervieweur et lui ai dit si je pouvais envoyer la bonne réponse dès mon retour à la maison. Je ne sais pas ce que l'enquêteur a pensé, mais j'ai envoyé la bonne réponse et j'ai été approuvé. (Au final j'ai décliné l'offre ...)
Je n'écrirais pas sur l'erreur uniquement si c'est quelque chose de très petit (comme une faute de frappe) ou quelque chose qui pourrait être légèrement optimisé (comme la réorganisation des clauses if-else).
Cela peut sembler obsessionnel et pédant dans le pire des cas, et ne fera aucune différence positive, alors laissez-le être.
Six réponses:
#1
+26
back2dos
2013-08-06 16:21:57 UTC
view on stackexchange narkive permalink

Personnellement, je suis le genre de personne qui sera dérangée en laissant ma solution telle quelle. Mais je ne veux pas compromettre mes chances en envoyant un errata si cela est considéré comme une mauvaise chose.

Si c'est ce que vous ressentez et que vous êtes ainsi, je pense que c'est malhonnête et finalement contre-productif de le cacher. Ce sont les personnes avec lesquelles vous allez potentiellement travailler pendant des années, voire des décennies.

Essayer de dissimuler ou de supprimer vos traits de caractère finira par rendre votre personne et les personnes dépendant de vous malheureuses. Si vous considérez qu'il s'agit d'un trait de caractère négatif (personnellement, je crois le contraire), sur lequel vous aimeriez travailler, dites-le simplement. Ou si vous vous sentez un peu gêné par l'envoi d'errata, vous pouvez également exprimer cela - faire quelque chose d'inhabituel (ce qui serait) sans le reconnaître peut également donner une mauvaise impression.

La communication est importante. Si vous parvenez à être ouvert, amical et concis, vous le faites correctement;)

#2
+16
Ross Patterson
2013-08-06 15:46:04 UTC
view on stackexchange narkive permalink

Je ne peux pas parler de l'expérience britannique, mais en tant que programmeur professionnel et gestionnaire de geeks ici aux États-Unis, je peux dire que ce serait inhabituel. Comment le responsable du recrutement répondra est susceptible d'être un problème très personnel pour eux. Moi-même, je le verrais comme un bon indicateur - le candidat est peut-être un peu trop fastidieux, mais il a reconnu un problème et a attiré l'attention sur lui. Je vous suggère de penser à la personne spécifique à laquelle vous vous adressez et d'essayer de la voir davantage du point de vue de cette personne que d'un cas général.

L'honnêteté et l'intégrité sont des traits clés ici au Royaume-Uni, et envoyer une correction ou reconnaître un problème serait considéré comme un signe d'intégrité.
L'honnêteté et l'intégrité sont également importantes aux États-Unis. Je ne vois pas que l'envoi d'une correction possède l'un ou l'autre de ces attributs.
#3
+11
user8365
2013-08-06 21:37:23 UTC
view on stackexchange narkive permalink

Envoyez votre e-mail de remerciement et incluez le correctif de code avec une petite explication. Ils peuvent choisir de l'ignorer.

Personnellement, je suis le genre de personne qui sera dérangé en laissant ma solution telle quelle.

Si cette entreprise considère c'est inapproprié, vous ne voulez probablement pas y travailler. En tant que programmeurs, nous compromettons souvent notre niveau de «assez bon» par des contraintes externes, alors pourquoi vous imposer cela? Pour moi, tous les programmeurs ou tout autre professionnel qui crée et répare des choses pour gagner sa vie devraient avoir un peu d'aversion pour les erreurs, mais pas au point de paralyser votre productivité.

Je pense que c'est la bonne réponse. J'ai été le destinataire de l'un d'entre eux - et même si c'était inhabituel, je l'ai vu comme une chose positive. Il communique "c'est une personne réfléchie et approfondie".
#4
+3
emory
2013-08-06 19:18:38 UTC
view on stackexchange narkive permalink

Vous devriez discuter du bogue - mais pas nécessairement le corriger - dans un e-mail de remerciement de suivi. Ne prenez pas trop de temps avec le suivi.

Si vous envoyez un court e-mail pour discuter du bogue avant de prendre une décision, cela peut vous aider. Si vous envoyez un e-mail brillant qui corrige, ils prennent une décision, il sera trop tard.

De plus, si vous corrigez le bogue, vous pourriez créer un nouveau bogue, qui ne vous aidera pas.

Ceci est formulé un peu bizarre. Vous vouliez dire "ne prenez pas trop de temps pour envoyer le suivi", mais vous avez dit "ne corrigez pas le bogue". Il a dit que c'était un bug mineur qu'il avait remarqué en sortant, donc il a probablement déjà le correctif
Dans mon cas, c'est un élément important, qui rompt la fonction, mais qui est résolu de manière très évidente. Mais j'aime cette réponse car parfois vous devrez peut-être revoir le code que vous avez donné et il est vrai que plus vous écrivez de lignes, plus vous risquez d'introduire de bogues à nouveau. Je garderai certainement cela à l'esprit si je me trouve dans une situation où l'erreur porte sur une question plus large.
@MichaelMrozek Je conviens que mon libellé était médiocre. Je pense toujours que discuter du bogue est plus important que de le corriger. Si vous faites juste une solution d'une ligne, je m'en fiche. Dites-moi pourquoi votre solution en une ligne est importante, quelles sont les mauvaises choses qui se passeront sans elle, etc. Pourquoi devrais-je me soucier de votre solution?
#5
+2
Petter Nordlander
2013-08-07 15:23:09 UTC
view on stackexchange narkive permalink

D'après mon expérience, ces entretiens visent à avoir une idée de vos compétences techniques. Un suivi ne changerait probablement pas vos chances en tant que tel, car les situations du monde réel diffèrent beaucoup des configurations d'entrevue.

Cependant, l'envoi de l'errata vous fera ressembler davantage à un perfectionniste. Si cela est bon ou mauvais, cela dépend de votre employeur, s'ils réalisent des bénéfices par «quick n dirty» ou «perfect».

Savoir qui est l'employeur potentiel qui me rassure réellement. Ils sont connus pour leur excellence en matière de codage. Merci +1 pour le soulagement moral.
#6
  0
kolsyra
2018-01-26 18:18:36 UTC
view on stackexchange narkive permalink

Reconnaître ses propres défauts est une compétence qu'aucun employeur ne devrait sous-évaluer. Lorsque vous reconnaissez des failles dans votre code avant qu'il ne soit signalé, c'est une compétence à apprécier.

Vous pouvez être à peu près sûr que vous ne serez pas le premier programmeur à écrire du code sans défaut et à quel point vous êtes bon pour identifier votre propre erreur, c'est essentiellement la petite taille de votre propre angle mort.

Il y a cependant une chose qui va plus loin ici. Comment votre employeur réagit-il à vos propres défauts que vous signalez vous-même? Serez-vous puni? Ou serez-vous récompensé pour avoir corrigé des erreurs? Les entreprises qui réussissent vous encouragent à échouer souvent et à échouer rapidement. En d'autres termes, il s'agit d'une excellente occasion pour vous de tester la réaction de votre employeur aux erreurs .



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...