Comment éviter de sauter vers une solution sous pression? [fermé]


18

Lorsque je suis dans un délai de programmation particulièrement strict (comme une heure), si je panique, ma tendance est de sauter dans le codage sans plan réel et j'espère le comprendre au fur et à mesure. Avec suffisamment de temps, cela peut fonctionner, mais dans une interview, cela a été plutôt infructueux, voire carrément contre-productif. Je ne suis pas toujours à l'aise assis là à penser pendant que l'horloge tourne.

Existe-t-il une liste de contrôle ou existe-t-il des techniques pour reconnaître lorsque vous comprenez assez bien le problème pour commencer à coder? Quand est-il le plus productif de penser et de concevoir davantage par rapport au code de certaines expériences et de comprendre la conception globale plus tard?

Voici une liste de techniques pour passer un test de mathématiques et une autre pour passer un examen oral . Existe-t-il une liste similaire de techniques pour gérer un problème de programmation sous pression?

RÉPONSES: Je pense que c'est une réponse valable: comment le résoudre . J'ai trouvé ce lien comme réponse aux étapes à résoudre ou à l'approche d'une solution . Il y avait aussi de très bons conseils à Penser à haute voix lors d'une interview est-il vraiment la meilleure stratégie? . Un argument génial et concis pour TDD est la première réponse au code d'écriture TDD vs trouver la réponse à un problème? .


2
C'est différent pour tout le monde. J'avais l'habitude de connaître quelqu'un qui ne toucherait pas à un clavier pendant une longue période de temps, puis il pourrait éliminer une bonne solution en un rien de temps. Pour moi, je trouve que TDD achemine ma vue vers la bonne solution le plus rapidement. Personne ne peut vous dire ce qui fonctionnera pour vous.
pdr

1
Eh bien, c'est deux techniques. Si les gens énuméraient suffisamment de techniques, différentes techniques fonctionneraient pour différentes personnes.
GlenPeterson

2
Je crains qu'il n'y ait aucun nombre fini de programmeurs qui peuvent vous aider. Normalement, les programmeurs comprennent le problème, et ils le font simplement en ... le comprenant. Il existe un certain nombre de méthodes triviales pour vous assurer de bien faire les choses, mais il est difficile, voire impossible, d'en trouver une pour vous, étant donné qu'elles devraient être évidentes. Le genre de précipitation que vous décrivez semble ... un peu fou? Avez-vous essayé de vous entraîner davantage, avec des tests chronométrés réels? Avez-vous envisagé de demander de l'aide psychologique pour l'anxiété, ou du moins de lire des livres d'auto-assistance sur le travail dans des conditions stressantes?
ZJR

2
@ZJR - Bonnes suggestions pour pratiquer avec des tests chronométrés et rechercher des sources psychologiques de meilleures performances sous stress. Je suis peut-être négatif ici, mais une partie de votre commentaire se lit comme si vous pensiez que je n'avais pas de talent ou que j'avais un problème psychologique clinique. Aie!
GlenPeterson

1
Découvrez d'abord ce qui est EXACTEMENT requis ou attendu. QUOI résoudre est souvent plus difficile que comment le résoudre nécessite plus d'analyse et révèle souvent une question complètement différente.
moinsSeven

Réponses:


17

Je me souviens avoir lu une étude sur la façon dont les commissaires d'incendie forment un plan d'action à leur arrivée sur les lieux d'un incendie; l'étude les a observés (et condamnés) pour avoir proposé une idée, puis avoir poursuivi cette première idée immédiatement. En raison de la pression du temps, c'était à peu près "ça pourrait marcher" suivi de "ok, faisons ça". L'étude a noté que des options meilleures, plus rapides et plus sûres étaient disponibles, mais elles n'ont pas été suivies simplement parce que les commissaires n'y ont pas pensé en premier.

Si vous voulez une approche structurée pour faire face aux "incendies", prenez peut-être une feuille de leur (nouveau) livre qui prescrit plusieurs phases:

RRAPID

  1. Réaction - Mobiliser des ressources en cas d'incident
  2. Reconnaissance - Recueillir des données sur la situation
  3. Appréciation - Choisissez un plan d'action basé sur les meilleurs et les pires scénarios
  4. Plan - élaborer un plan basé sur le plan d'action
  5. Délivrance des commandes - Utilisez le format de briefing standard
  6. Déploiement - Exécuter et surveiller

ou en termes plus généraux:

  1. Réveillez tout le monde et faites-les bouger
  2. Découvrez ce qui se passe
  3. Solutions de remue-méninges
  4. Choisissez-en un et planifiez-le
  5. Dites à tout le monde quel est son travail
  6. Exécuter et surveiller

1

Je commence toujours par comprendre les exigences et rechercher les lacunes qui nécessitent des réponses.

Puis j'esquisse (très grossièrement et sur papier ou tableau blanc) deux ou trois solutions possibles. Ensuite, je me demande: "Y a-t-il autre chose que je dois savoir pour mettre en œuvre ces éléments?"

Une fois que j'ai posé mes premières questions (il y a des questions à 100% du temps, si vous n'en avez pas, vous n'avez pas vraiment examiné l'exigence en profondeur.), Je retourne vers les parties prenantes pour obtenir mes réponses.

Pendant que j'attends leurs réponses, je considère mes solutions et je vois si certaines sont meilleures que les autres ou seraient meilleures une fois que j'aurai les réponses aux questions. Par exemple, si la question de savoir combien de temps en avez-vous besoin est immédiate, je pourrais opter pour celle avec le développement le plus rapide mais en laissant un moyen d'améliorer la conception plus tard. S'ils me disent que la performance est critique, alors je regarde les solutions et détermine laquelle est la plus susceptible de mieux performer (ce sont des suppositions à ce stade, mais en général celles qui sont éclairées). Si une interface graphique est impliquée, je pourrais créer un prototype papier de plusieurs conceptions différentes et demander aux parties prenantes de les regarder avant de coder quoi que ce soit (généralement, ils verront qu'ils ont oublié de vous parler de XYZ, ce qui est au cœur de la conception!)

Une fois que j'ai obtenu mes réponses, je choisis une conception approximative, puis je fais une liste de toutes les choses que je devrai faire pour la mettre en œuvre. Ensuite, je commence à coder.


1

... ma tendance est de sauter dans le codage sans plan réel et j'espère le découvrir au fur et à mesure.

Je l'ai fait à l'université. Il est devenu un vrai problème et entraînerait généralement la réécriture du code. J'ai commencé à résoudre ce problème en n'écrivant pas de code. J'ai mis l'accent sur la réflexion sur le problème. Avec suffisamment de pratique, je cherche instinctivement mes pensées plutôt qu'un clavier.

... dans une interview, cela a été plutôt infructueux, voire carrément contre-productif. Je ne suis pas toujours à l'aise assis là à penser pendant que l'horloge tourne.

Dans une interview, il doit y avoir une mise en œuvre raisonnée et réfléchie d'une solution et cela n'est pas toujours facile. Ce que vous ne voulez pas faire, c'est laisser échapper des réponses sans réfléchir. Si vous connaissez la réponse, donnez-la rapidement. Si ce n'est pas le cas, comptez sur vos pensées pour trouver une solution. Indiquez toujours quand vous ne savez pas et montrez comment vous vous y prendriez pour trouver une solution.

Existe-t-il une liste de contrôle ou existe-t-il des techniques pour reconnaître lorsque vous comprenez assez bien le problème pour commencer à coder?

Je découragerais cela parce que vous pouvez vous y fier de manière rigide. Demandez-vous plutôt si vous comprenez assez bien le problème pour commencer à coder. Comment saurais tu? Parce que lorsque vous raisonnez votre approche puis l'examinez, compte tenu de votre connaissance actuelle de la langue, cela aura un sens. Ayez toujours un plan et une approche. Souvenez-vous également que le code n'est jamais terminé et que le code qui n'a pas évolué mourra, alors attendez-vous à y revenir souvent.

Quand est-il le plus productif de penser et de concevoir davantage par rapport au code de certaines expériences et de comprendre la conception globale plus tard?

Vous voudrez connaître la conception globale et y réfléchir. Ensuite, vous commencez à créer la structure de classe et les talons. Revoyez-le ensuite. Est-ce que ça fait du sens? Les expériences de codage sont un excellent moyen de démontrer que quelque chose fonctionne bien et doivent être utilisées mais ne doivent pas être utilisées pour façonner ou façonner le code que vous écrivez.

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.