Entretien technique quand on n'en fait plus depuis 3 ans

🎯 Contexte

Aujourd’hui, j’ai passé un entretien technique.

Cela faisait trois ans que je n’en avais pas passé, et encore moins en Go. Autant dire que j’étais un peu rouillé sur l’exercice en lui-même : coder devant quelqu’un, en étant observé, ce n’est jamais tout à fait comme coder seul.

Petit retour d’expérience, à chaud, sur ce qui s’est bien passé, ce qui s’est moins bien passé, et ce que j’en retiens.

Vue d’ensemble des 3 exercices :

🤝 Le déroulement

Premier point positif : l’ambiance.

L’entretien s’est déroulé dans la bienveillance, et je pense qu’ils ont vite senti que je n’étais pas totalement à l’aise avec l’exercice.

Je suis quelqu’un qui a besoin de prendre son temps pour bien comprendre un problème, et en particulier pour comprendre l’énoncé d’un exercice de programmation, que je ne trouve pas toujours très explicite.

Ça s’est d’ailleurs vu : même après avoir réussi à installer les projets (avec une petite frayeur sur leur projet Go qui ne voulait pas s’importer correctement dans GoLand), il m’a fallu un moment pour vraiment démarrer.

🐛 Exercice 1 — un bug fix, et un vrai rappel sur le TDD

Sur ce premier exercice, un des interlocuteurs m’a arrêté net quand il m’a vu modifier le test.
Et il avait totalement raison. Le but n’était pas de faire évoluer un comportement pour une nouvelle fonctionnalité, mais de corriger un bug : le test était volontairement rédigé pour faire échouer le programme. C’est donc le code de prod qu’il fallait corriger, pas le test.

En clair : l’étape « red » du TDD était déjà faite. Il ne restait que le reste du cycle :

Une évidence sur le papier, beaucoup moins évidente sous le stress d’un entretien, il m’a fallu une bonne dizaine de minutes pour vraiment comprendre le sujet.

Une fois le déclic fait, j’ai itéré assez vite, mais l’exercice m’a quand même pris une vingtaine de minutes au total, bien trop long pour ce qu’il demandait (je pense qu’il aurait dû me prendre 5 à 10 minutes).

En appliquant mes réflexes TDD, que j’ai beaucoup pratiqués par le passé, j’ai découvert au passage un petit bug dans l’ordonnancement de leurs tests. L’occasion d’échanger sur nos manières de tester : j’ai l’habitude du table testing, ou de tests avec une ou deux assertions pour la partie erreur en Go, alors que mes interlocuteurs avaient plutôt l’habitude de faire évoluer un même test avec plusieurs assertions pour couvrir davantage de cas. Intéressant de voir la différence d’habitudes selon les équipes.

🔀 Le piège du tri de slice

Le test suivant portait sur le tri d’un slice. Pas que je ne savais pas faire, avec l’autocomplétion actuelle, c’est même plutôt rapide, mais je me suis fait avoir sur quelque chose que je connais pourtant bien : un slice en Go pointe vers une structure sous-jacente, donc la modifier modifie l’état interne partagé.

Morale : pensez à cloner vos slices quand vous voulez préserver leur état d’origine.

🧮 Range indexé vs range over, et une histoire d’allocation

Le dernier test de cet exercice, une recherche basique, s’est réglé rapidement. Il a surtout donné lieu à un échange intéressant : je n’ai pas utilisé de range classique mais un range indexé, ce qui a un peu surpris un des interlocuteurs.

La raison : chez mon client actuel, une règle de lint nous rappelle le fameux piège du « copy over range » en Go, et nous pousse à indexer nos slices pour limiter les allocations mémoire inutiles. Mon interlocuteur est resté perplexe sur ce point, une divergence de pratiques entre équipes, sans doute.

Sur ce même sujet, j’ai laissé passer une triple allocation en boucle qui aurait pu être faite une seule fois, alors que c’est justement le genre de chose à laquelle je suis normalement sensible (allocation mémoire, temps de réponse).
Là-dessus, ils avaient parfaitement raison de le relever.

⚡ Exercice 2 — rapide, mais pas assez

Le deuxième exercice portait sur une situation de mutation, que j’ai identifiée assez vite. Ça m’a pris 5 à 10 minutes, alors que ça aurait dû être quasi instantané (2 minutes grand maximum). Rien à redire sur le fond, seulement sur le temps que j’ai mis.

🔄 Exercice 3 — concurrence, et un énoncé perfectible

Le troisième exercice, sans doute le plus long mais pas le pire, portait sur la concurrence en Go : channels et goroutines. Le test était lui aussi buggé, tout comme le code de prod, avec pour objectif de vérifier la maîtrise de ces sujets. Je trouve honnêtement l’exercice mal posé.

J’ai vite repéré un premier problème (un WaitGroup mal géré), mais j’ai eu davantage de mal à trouver le bug principal, une dizaine, quinzaine de minutes de réflexion.

C’est en grande partie dû au fait que je trouvais le code déjà mal structuré au départ.
À un moment, j’ai fini par verbaliser mon ressenti à l’interlocuteur en lui expliquant un truc bizarre que je trouvais qu’il faisait dans leur code :

faire transiter un message via une structure de comportement plutôt qu’une structure de données.

👉C’était bel et bien le second problème.

Vu que jusqu’à maintenant le code était général correct avec de petites modifications à apporter, je ne me suis pas douté que je pouvais faire des gros changements.

Une fois qu’il m’a donné carte blanche pour tout défaire et refaire, j’ai corrigé assez rapidement, jusqu’à buter sur un tout dernier point de blocage. Le problème était identifié, j’ai mis quelques minutes à le résoudre, là aussi j’aurais dû être bien plus rapide.

🧠 Bilan

J’ai raté cet entretien technique en beauté, sur des trucs basiques.

Ce n’est pas grave, ça arrive, et ça m’a surtout permis de me rendre compte de quelque chose :

Me voilà motivé pour ne plus rater les prochains 🚀

Désormais retrouver le détail de chaque exercice que je reprendrais à tête reposée dans des articles dédiés.