J'ai échoué FizzBuzz, voudriez-vous m'engager?
Je suis développeur avec un diplôme CS et j'ai une expérience de travail en développement dans plusieurs langues depuis près de 3 ans.
Aujourd'hui, j'ai eu une interview, dans l'ensemble ça s'est plutôt bien passé, je me suis préparé à la plupart des questions et je me sentais prêt à tout. À la fin de l'interview, ils m'ont donné UNE question de programmation ... un problème comme FizzBuzz (sans l'imprimer la partie numérique). Je crois que j'ai fait trop d'erreurs et que je l'ai donc "échoué". Tout espoir est-il perdu pour moi?
Voici mon code:
void FizzBuzz()
{
for(int i = 0; i <= 100; i++)
{
bool isThree = i % 3;
bool isFive = i % 5;
if (isThree)
{
print "Fizz\n";
}
else if(isFive)
{
print "Buzz\n";
}
else
{
print "FizzBuzz\n";
}
}
}
Comme vous pouvez le voir, j'ai foiré les bools qui devraient avoir la syntaxe i% 3 == 0; Si je me souviens bien de la question, j'ai également mis un autre au lieu d'un autre avec isThree && isFive. J'étais assez stressé, mais ce n'est pas une excuse pour manquer un simple problème.
La question est donc de savoir dans quelle mesure est-il important de produire un code de travail sur place par rapport à d'autres facteurs, tels que l'expérience et la personnalité? Par exemple, le code ci-dessus serait-il une rupture de marché?
Le but de FizzBuzz est de montrer que vous avez réellement savoir programmer , pas que vous avez mémorisé toutes les règles de syntaxe plus fines du langage dans lequel vous avez été invité à programmer (bien que cela ait de l'importance, s'ils veulent savoir à quel point vous êtes expérimenté dans la langue).
Si vous êtes allé aussi loin dans le stress d'un environnement d'entrevue et pouvez montrer que vous comprenez les erreurs que vous avez faites, je dirais que vous avez réussi.
Oui
La plupart des personnes que j'ai interviewées qui ont échoué la partie exercice de code sur une syntaxe mineure ou une logique légèrement décalée ont fini par être les meilleures recrues.
Obtenir l'idée de base de la logique (ce que vous avez fait) et le convertir en quelque chose de décent et concis d'un point de vue de code (ce que je pense que vous avez surtout fait) est beaucoup plus important pour moi que de le rendre absolument parfait.
J'achète un IDE pour que sa vérification de syntaxe n'engage pas de développeur pour cela, et vous auriez réalisé les autres erreurs dans les instants de votre premier débogage.
Vous êtes passé de l'exigence initiale à une première tentative assez directement et sans rien faire de terrible. C'est plus précieux dans de nombreux environnements que la perfection en l'absence de rétroaction. Si l'employeur est accroché aux détails que vous avez manqués, cela pourrait être un signe de l'environnement à venir de toute façon.
Si la tâche était la variante des numéros d'impression, manquer le détail serait un peu mauvais, mais cela n'aurait pas assez de poids pour changer ma décision si je vous aimais pour le poste autrement.
[Modifier] Comme Alex l'a souligné, il y a aussi l'aspect réaction et calme. Personnellement, j'essaie de supprimer cela avant de passer aux exercices pratiques en essayant de coincer la personne interrogée sur quelque chose un peu en dehors de son expérience, mais certains peuvent choisir de combiner les deux. De temps en temps, je rencontre quelqu'un qui n'a que des connaissances en manuels et qui navigue à travers les questions théoriques et de fond, mais qui se demande sérieusement où commencer l'exercice pratique. Certains ne savent même pas par où commencer.
Ces personnes sont exactement ce que je veux éliminer avec cet exercice.
Donc, à moins que vous ayez pris 20 minutes pour que l'intervieweur clarifie l'exigence, j'imagine que votre solution était plus ou moins votre première tentative avec éventuellement quelques corrections au fur et à mesure. Si vous avez obtenu ce que vous avez mis ci-dessus en moins de 5 minutes, vous avez montré que vous pouviez penser suffisamment à mes normes.
Le code ci-dessus serait probablement une rupture pour moi si je n'avais rien d'autre à faire. S'ils suivent le style d'interview de Microsoft, la personne qui vous a posé cette question vous bloquera probablement - et c'est souvent tout ce qu'il faut.
Ce qui me déconcerte, c'est que l'intervieweur ne vous a pas posé de questions sur ce code. Un bon intervieweur a vu suffisamment de son propre code pour savoir que les gens font des erreurs - surtout lorsqu'ils sont pressés. Habituellement, ils disent: "Maintenant, voyez-vous quelque chose de mal avec ce code?" "Non? Eh bien, testons-le". Vous venez avec quelques jeux de résultats, puis exécutez-le via la fonction. Ensuite, vous dites: "Oh merde, cela n'a pas fonctionné." "D'accord, comment le réparerais-tu ..." et ainsi de suite. Si vous survivez à ce dialogue, il est en fait assez impressionnant et démontre une capacité à penser de manière critique, à proposer des cas de test et à déboguer votre propre code.
Notez également qu'ils ne recherchent généralement pas de "code de travail". Qui produit le premier essai de toute façon? Mais logiquement correct avec la gestion des erreurs et de bons ensembles de tests est un bon objectif.
De plus, cela peut vous surprendre, mais vous êtes en concurrence avec de nombreuses personnes qui ne peuvent même pas se lancer sur fizzbuzz. Nous avons tendance à supposer que tout le monde traverse des arbres b + dans leur sommeil ... mais en réalité, ils ne peuvent même pas comprendre des multiples de 3 et 5 et utiliser un opérateur de module. Vous serez peut-être agréablement surpris de voir à quel point vous avez fait mieux que les autres candidats.
Mon conseil, il suffit de le brosser. J'ai récemment interviewé dans de grandes sociétés de logiciels (Microsoft, Amazon, etc.), et c'était la première fois que je passais par un processus d'entretien aussi approfondi. Je me suis ridiculisé lors d'une interview sur place de Microsoft, principalement à cause des nerfs, mais aussi, je ne savais pas à quoi m'attendre ou exactement ce qu'ils recherchaient. J'ai cloué un problème de chemin le plus court pour faire exploser des problèmes vraiment simples. J'ai sauté des valeurs de la mauvaise extrémité d'une pile, j'ai oublié dans une implémentation int atoi(char* value) que int val = value[i] - '0'; me donnerait la valeur entière du caractère, et plusieurs autres erreurs stupides. J'étais pour la plupart satisfait de l'entretien, mais je comprenais toujours pourquoi je n'avais pas reçu d'offre. Je devais réaliser que ce n'était pas tant une réflexion sur mes capacités que c'était un indicateur que j'avais juste besoin de continuer à l'essayer jusqu'à ce que je sois capable de maîtriser mes nerfs. Finalement, j'ai réussi quelques interviews avec des questions beaucoup plus difficiles et j'ai décroché mon emploi de rêve. C'est vraiment - pour la plupart des gens qui savent réellement ce qu'ils font - juste une question de comprendre ce que les enquêteurs veulent, d'avoir confiance en soi et de le leur donner. Cela prend du temps.
Je dois dire non, mais pas pour la raison que vous avez donnée, mais que vous avez mis la section FizzBuzz en dernier. Avec la façon dont votre code fonctionne, il n'imprimera jamais FizzBuzz lorsque vous vous y attendez. Comme Lee l'a commenté, il l'imprimera pour chaque valeur pas divisible par 3 ou 5.
Mais l'essentiel est que vous en tiriez des enseignements. J'aime le fait que vous soyez ici pour savoir comment vous auriez pu faire mieux. Assurez-vous de faire quelques casse-tête de code et de rechercher des questions d'entrevue courantes. Essayez également de vous chronométrer ou de faire quelque chose d'autre qui augmenterait la pression afin que vous puissiez essayer d'imiter le sentiment que vous allez ressentir lors d'une entrevue. Et préparez-vous, préparez-vous et faites plus de préparation pour l'entrevue si vous voulez vraiment la sortir du parc.
Non. Le but de FizzBuzz est de voir si vous êtes capable de travailler sur une logique conditionnelle de base, qui couvre tous les cas. Contrairement à l'opinion de certaines personnes, FizzBuzz ne concerne pas l'opérateur de module, connaissant les opérations ternaires ou les opérandes booléens. C'est un simple exercice conditionnel et vous l'avez échoué.
Le problème est structuré de sorte que tout le code "élégant" ne couvre pas au moins un cas.
Réponses acceptables:
if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x
if div3 {
print fizz;
if div5 {
print buzz;
}
} else {
if div5 {
print buzz;
} else {
print x;
}
}
Je donne aux gens des problèmes de programmation triviaux à faire sur le tableau blanc. Que le code résultant soit exempt de bogues n'est pas du tout le point de décision. Au lieu de cela, je me soucie d'un certain nombre de comportements exposés lors de l'écriture du code. C'est interactif et j'apprends beaucoup sur les candidats pendant que ça se passe.
Je vais plus en détail sur "Test" du tableau blanc pendant une interview: moyen légitime de sauvegarder votre code (tableau blanc)?
Bien sûr, votre intervieweur ne ressemble peut-être pas à moi. Mais il est tout à fait possible pour vous d'avoir passé une interview avec moi tout en produisant du code qui est un tout petit peu plus loin, et tout à fait possible d'avoir échoué avec l'identique code.
Si j'évaluais cela, je chercherais les choses suivantes:
- Le candidat essaie-t-il de bien comprendre les exigences avant de passer à la mise en œuvre? Le candidat cherche-t-il à résoudre mon problème ou à utiliser ses outils favoris dans sa boîte à outils de programmation? Comment le candidat résout-il ses problèmes?
- Le candidat parle-t-il couramment au moins un langage de programmation?
- Le candidat a-t-il une compréhension de la logique booléenne?
- Que fait le candidat pour assurer la qualité de ses solutions?
- Comment le candidat réagit-il aux commentaires sur son code?
-
C'est difficile à dire sur # 1. Votre question indique que votre problème ne comprenait pas la partie "numéro d'impression", et votre solution ne comprend pas en fait cela. Je n'ai pas d'autre choix que de prendre votre Word pour cela, mais si en fait c'était le problème classique de FizzBuzz qui comprenait l'impression des nombres qui n'étaient pas divisibles non plus, alors il semble que vous ayez sauté à une solution avant de bien comprendre les exigences, ce qui serait une marque.
Je vous donnerais un crédit partiel pour les numéros 2 et 3. Vous saviez utiliser l'opérateur de module et possédiez la structure d'une solution de travail, mais vous avez manqué des parties des deux.
Il semble que vous n'ayez pas fait # 4, ce qui vous marquerait. À l'avenir, je recommanderais de prendre du recul par rapport au tableau blanc et d'examiner votre solution avant de l'appeler terminée. Je voudrais également (sans être invité) passer par quelques tests unitaires pour votre solution, qui auraient rapidement démontré où vous aviez gâché.
Ils ne vous ont pas donné de chance sur # 5, ce qui est regrettable. Mais le fait est que je ne veux pas quelqu'un qui pense que chaque ligne de code qu'ils ont jamais écrite est de l'or pur qui ne pourrait pas être amélioré, mais plutôt quelqu'un prêt à accepter les commentaires sur ses solutions et à engager une conversation sur son approche .
-
Donc, si j'évaluais cela, je voterais "Non embauché". Des choses comme ça sont en quelque sorte mesurer un art de la performance plutôt que la capacité de programmation , mais le maîtriser peut encore aider votre carrière. Donc, mes recommandations pour les futures entrevues technologiques seraient:
Avant l'entretien, pratiquez quelques-uns de ces types d'exercices à froid, en utilisant le moins possible de ressources extérieures. Pas pour mémoriser des solutions, mais pour être sûr que vous êtes à l'aise avec votre langue préférée
Posez des questions sur le problème pour valider vos hypothèses.
Avant d'annoncer que votre solution est terminée, prenez du recul par rapport au tableau blanc et examinez-la, puis parcourez quelques cas de tests unitaires simples.
Demander à quelqu'un de résoudre un problème sans lui donner la possibilité d'obtenir des commentaires sur sa solution est une approche discutable, car ils ne sont pas autorisés à s'améliorer.
Tout ce test nous apprend que vous n'avez pas démontré de très bonnes compétences de résolution de problèmes "haut de gamme".
Cela pourrait être l'un des éléments de la décision de vous embaucher ou non, mais pour moi, ce ne devrait certainement pas être le seul.
S'ils vous auraient fourni un environnement de test ou d'exécution unitaire, les erreurs que vous avez commises auraient été moins excusables.