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? .