Comment gérer une interview «mauvais code»? [fermé]


12

Une interview «mauvais code» est une interview dans laquelle on montre à l'interviewé un extrait de «mauvais code» et on lui demande de le corriger ou de signaler des choses qui ne vont pas. J'ai des problèmes avec ces interviews car cela me prend un certain temps pour lire le code, comprendre ce qu'il fait et signaler les défauts. Dans une situation où le temps presse, j'ai tendance à geler et je vois que le code «devrait» fonctionner, même quand ce n'est pas le cas.

Quelle est la bonne façon de gérer ce type d'interview et, plus généralement, quelles sont les bonnes techniques pour lire et comprendre rapidement le code ?


8
Pourquoi "rapidement"? Si vous avez besoin de temps pour réfléchir, qu'est-ce qui ne va pas avec le temps de réfléchir?
S.Lott

Cela fait-il partie du test écrit / d'aptitude? Ensuite, vous devez faire vos devoirs sur ce type de tests pour les entreprises concernées.
Aditya P

@ S.Lott Eh bien, je voulais principalement des techniques qui m'aideraient à éviter le verrouillage cognitif dans ce genre de situation. Les techniques qui peuvent être appliquées rapidement fonctionnent mieux pour moi.
quanticle

@AdityaGameProgrammer Eh bien, ce n'est pas un test écrit. On vous remet une feuille avec le code source dessus, et vous devez parcourir la source et discuter de ses défauts. Il serait en fait préférable que ce soit un test écrit, car je me sens moins sous pression dans un format écrit.
quanticle

@quanticle: Comment "arrêter et penser" n'est-il pas la première "technique" que vous utiliseriez? En effet, quelle autre technique existe-t-il que "s'arrêter et réfléchir"?
S.Lott

Réponses:


18

Les entrevues de mauvais code (si elles sont effectuées correctement) devraient vous montrer le code avec les éléments suivants:

  • Une mauvaise technique de langage (ne pas utiliser l' usinginstruction en C # en cas de besoin, ou utiliser un ArrayListau lieu d'un List<T>)
  • Une mauvaise décision de conception (pourquoi diable passons-nous des chaînes partout, ou utilisons ref-nous outautant de paramètres?)
  • Erreurs de syntaxe (cela ne devrait même pas être compilé!)
  • Erreurs d'exécution (telles qu'un débordement de pile provoqué par une propriété se référant à elle-même en C #)

Il y a une liste de contrôle mental que vous devez parcourir, en touchant chacun des points ci-dessus. Si vous ne pouvez pas regarder le code et le faire, c'est un point d'amélioration. Quelle que soit la langue dans laquelle vous prétendez être «compétent», vous devriez pouvoir regarder un bloc de code et signaler ces quatre types d'erreurs.

J'ai récemment blogué sur un morceau de code qui présentait tous ces problèmes , cela devrait vous aider à passer par le même processus mental.

Ayende va plus loin avec sa série Wages of Sin .


Merci pour l'idée de la liste de contrôle. Ce sont des choses assez `` évidentes '', mais dans la situation, il est facile de perdre la trace de certaines de ces choses si vous ne les gardez pas consciemment dans votre tête pendant que vous lisez le code.
quanticle

Excellent article de blog. Toujours plus drôle quand le morceau de code que l'expert montre comme exemple a d'énormes bugs. J'espère que mon commentaire ne poursuivra pas la démonstration de bogue que vous et Scott avez faite.
Ben Voigt

L'autre chose qui est utilisée dans une mauvaise interview de code est une erreur logique. Par exemple, ils vous montrent une petite fonction, ils vous disent ce que c'est censé faire et vous devez leur dire pourquoi cela ne le fera pas ou dans quel cas cela ne fonctionnera pas.
HoLyVieR

+1. Un point de plus pour la liste de contrôle: Vérifiez comment le code gère les cas de bordure (liste vide, chaîne vide, 0, Inf / NaN pour les nombres à virgule flottante, un List<T>qui contient des nulléléments ...)
nikie

9

N'essayez pas de le comprendre rapidement. Le but ici n'est pas de voir si vous pouvez comprendre le code comme un gourou, mais plutôt de voir comment vous pensez.

L'IMO clé est simplement de penser à haute voix. Donc, même si vous vous figez - alors dites simplement: "Je suis stressé ici, mais laissez-moi passer cela lentement à voix haute".

En supposant que vous ayez la compétence de penser à haute voix, vous ralentirez suffisamment pour vous remettre en forme. Si les entretiens sont assez avertis, ils verront votre situation et vous aideront jusqu'à ce que vous réfléchissiez clairement. Ils ne sont pas là pour essayer de vous inciter à avoir l'air stupide - juste une technique puissante pour voir comment vous pensez.


2

Les chances sont que la «pression du temps» que vous ressentez est entièrement auto-imposée. Cela a plus à voir avec vos propres sentiments d'insécurité et de vous inquiéter de votre niveau de performance.

Le meilleur conseil que l'on puisse donner est: Détendez-vous. Prenez votre temps, regardez le code et parlez simplement de ce que vous voyez tel que vous le voyez. N'hésitez pas à parler des bonnes et des mauvaises parties; cela vous aidera à réduire votre nervosité et à vous inquiéter du fait que trop de temps passe.

De plus, le fait de passer par différentes «passes» pourrait faciliter un peu la détection de détails spécifiques. Faites un seul passage à la recherche d'accolades ou de fautes de frappe incompatibles. Faites un autre passage à la recherche de lignes obscurcies. Prenez-en un autre à la recherche de bretzels sémantiques. Se concentrer sur un type de «mauvaise chose» pourrait faciliter la détection de ces détails et (encore une fois) réduire votre voix intérieure en vous demandant si vous le faites rapidement / assez bien.

Surtout, parlez de ce que vous faites et pensez - cela vous aidera, vous et l'intervieweur, tous les deux.


1

Je n'ai jamais participé à ce genre d'interview, mais lorsque j'essaie de travailler sur un morceau de code délicat que je soupçonne d'être mauvais, je me parle parfois tranquillement. Je trouve que la vocalisation aide parfois à résoudre les problèmes. Toujours dans une interview, vous pouvez essayer de retracer les étapes de l'exécution sous forme de diagramme ou de quelque chose avec un crayon et du papier. Cela fonctionnait pour moi à l'école, je le fais toujours parfois au travail. YMMV, bien sûr ...


1

Je pense qu'un bon point de départ (si vous ne voyez rien d'évident) serait de le "déboguer". Sauf si vous voyez des problèmes possibles dès le départ, un bon point de départ est de faire une petite liste de valeurs de test. Les bonnes valeurs sont une valeur «normale» (normale), une valeur «zéro» ou «vide», des valeurs nulles, une très petite valeur (une chaîne de 1 caractère, l'int 1, etc.), une très grande ou très longue et des valeurs «étranges» spécifiques au type (par exemple, caractères Unicode pour les chaînes, nombres négatifs pour les entiers, etc.). Cela ne ferait pas de mal de mentionner que normalement vous écririez des tests unitaires en utilisant ces valeurs pour tester le code, et les exécuteriez simplement pour vérifier la fonction.

Commencez par parcourir vos valeurs de chemin heureux. Pour une fonction d'addition, vous pouvez commencer par 3 ou 4. Examinez chaque ligne pour les fautes de frappe et les erreurs logiques, en suivant les valeurs des variables locales au fur et à mesure. J'espère que vous trouverez quelques bugs. Lorsque vous aurez terminé avec le chemin heureux, vous aurez une meilleure idée du code et, espérons-le, vous vous sentirez un peu moins submergé - alors dites quelque chose comme: "Maintenant que j'ai une meilleure idée de ce que fait ce code, je suis va prendre du recul et y jeter un œil ", alors faites juste cela - en recherchant des choses qui vous paraissent différentes comme des choses que vous auriez faites différemment (mauvaises décisions de conception, variables mal nommées, enquêter sur des bogues possibles, etc.).

Si cela ne vous mène nulle part, ou si vous avez l'impression de manquer de choses à dire, revenez à votre liste de valeurs de test et parcourez-la à nouveau avec une nouvelle qui, selon vous, est susceptible de causer des problèmes.

Cela vous permettra au moins de démarrer.


0

Comme l'a dit Stephen Bailey, penser à haute voix est une excellente technique dans cette situation car elle permet à vos enquêteurs de voir votre processus de réflexion. Expliquez en quelque sorte ce que vous essayez de comprendre. L'autre chose que vous pourriez faire est de faire savoir aux enquêteurs que vous allez lire le code correctement avant de fournir un diagnostic sur la méchanceté du code. J'ai été des deux côtés de la table et je sais que cela peut être frustrant pour les deux parties dans ces situations.


0

Si vous ressentez moins de pression à le faire comme un test écrit, sortez votre ordinateur portable et commencez à prendre des notes. J'ai sorti un cahier et commencé à esquisser des notes dans le cadre de mon processus de réflexion dans une interview. Avoir un carnet et un stylo vous donne même l'air organisé. Vous pourriez noter quelques points à rechercher, la syntaxe, les erreurs logiques, les incompatibilités de types de données, les valeurs des variables locales (la liste peut varier en fonction du type de code que vous avez obtenu, ma liste pour un élément complexe de SQL serait être différent de quelqu'un qui a obtenu un morceau de code qui n'était pas centré sur les données) au cours du processus, etc. Une fois que vous en avez écrit quelques-uns, commencez à les rechercher. De cette façon, même si vous ne trouvez pas tous les problèmes avant que l'enquêteur ne souhaite passer à autre chose, il / elle pourra voir une liste des choses que vous alliez vérifier. Si vous créez au préalable une liste de contrôle des choses que vous voudrez peut-être rechercher, vous vous sentirez plus en confiance en commençant le processus en sachant quelles choses vous avez prévu de regarder. Habituellement, ces questions portent davantage sur la façon dont vous trouveriez les erreurs que sur la recherche de toutes.


0

Je suis un peu en retard à cette fête, mais une technique que vous pourriez utiliser serait d'écrire des tests unitaires pour le code en question. Ensuite, vous pouvez vous concentrer moins sur ce qui est subtilement faux avec le code et plus sur les résultats attendus que vous recherchez. Je préfère embaucher quelqu'un qui peut écrire de bons tests que quelqu'un qui peut immédiatement détecter ce qui ne va pas avec un morceau de code.


0

Il peut y avoir deux problèmes:

Il peut s'agir d'une "interview sur le stress" http://en.wikipedia.org/wiki/Job_interview#Stress . L'enquêteur essaie de voir comment vous gérez le stress, car son environnement de travail est tel.

OU

Vous pourriez être stressé vous-même. Dans ce cas, vous devrez gérer ce stress, par exemple, faire preuve d'introspection et voir comment vous pouvez rester calme.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.