et ensuite viennent quelques pensées qu'il en tire, avec en premier : "I think it’s the simple, idiomatic versions that are the most telling. This is the code programmers are likely to write in real life.", alors que j'ai prouvé ci-dessus que ce n'est pas le cas, les developpeurs ne ponderont pas tous le même code dans la vie réelle, il existera des versions différentes avec des performances elles aussi bien différentes.
Pas tous, mais la majorité, en ayant les mêmes contraintes que celles posées. Mais cela ne signifie pas que c'est la version finale de la majorité, mais le premier truc qui vient à l'esprit d'une personne pas trop perchée. Et sur ce point justement, il dit bien que ce qui l'intéresse c'est que les devs connaissent et comprennent assez ces aspects (comment sont géré les tableaux de hachage, les performances des entrées/sorties et des routines de tri intégrées) de leur langage de prédilection et non des concepts algorithmiques très avancés que peu mettent en œuvre au final (encore en général, et ça vise les petites entreprises qui veulent faire des entretiens à la Foogle/Gacebook pour finalement vous faire pondre des petits trucs bien loin de là) : « I think this is a good interview question because it’s somewhat harder to solve than FizzBuzz, but it doesn’t suffer from the "invert a binary tree on this whiteboard" issue. It’s the kind of thing a programmer might have to write a script for in real life, and it shows whether they understand file I/O, hash tables (maps), and how to use their language’s sort function. There’s a little bit of trickiness in the sorting part, because most hash tables aren’t ordered, and if they are, it’s by key or insertion order and not by value. »
Le problème est certainement lié à une autre de ses pensées : "I still think this interview question is a good one for a coding question". Si cette question m'était posée telle que lors d'un entretien (hypothèse improbable), je demanderais à l'examinateur dans quel contexte le programme est censé s'exécuter, quels sont les critères importants : performance à tout prix ? code facile à maintenir même 20 ans plus tard par un nouvel arrivant ? Empreinte mémoire minimale ? Espace disque ou IO minimum ? ... Même si dans la vie réelle c'est souvent un équilibre entre tous ces critères, rien ne permet de deviner le choix de l'examinateur. Au final il y aura autant de versions que ce choix d'équilibre entre ces critères.
De ce que j'ai vu pour avoir fait passer un certain nombre d'entretiens et pour en avoir subi de bien costaudes aussi, on ne pense pas forcément à faire le malin ni à donner une réponse exhaustive quand on pense à tout les points que tu évoques. Les examinateurs pas fêlés n'ont normalement pas de choix et veulent juste voir comment est esquissée la solution (et là, en proposant celle de Ben tu le rassures que tu sauras répondre aux urgences au lieu de pinailler quand il y a le feu ; et si en plus tu mets les réserves citées par vous deux, ça montre que tu connais ton langage et sauras optimiser le moment venu)
Mais sinon, c'est un peu la seconde partie de l'entretien déjà... « After the candidate has a basic solution, you can push it in all sorts of different directions: what about capitalization? punctuation? how does it order two words with the same frequency? what’s the performance bottleneck likely to be? how does it fare in terms of big-O? what’s the memory usage? roughly how long would your program take to process a 1GB file? would your solution still work for 1TB? and so on. Or you can take it in a "software engineering" direction and talk about error handling, testability, turning it into a hardened command line utility, etc. »
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Des choux et des carottes...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust. Évalué à 1.
Pas tous, mais la majorité, en ayant les mêmes contraintes que celles posées. Mais cela ne signifie pas que c'est la version finale de la majorité, mais le premier truc qui vient à l'esprit d'une personne pas trop perchée. Et sur ce point justement, il dit bien que ce qui l'intéresse c'est que les devs connaissent et comprennent assez ces aspects (comment sont géré les tableaux de hachage, les performances des entrées/sorties et des routines de tri intégrées) de leur langage de prédilection et non des concepts algorithmiques très avancés que peu mettent en œuvre au final (encore en général, et ça vise les petites entreprises qui veulent faire des entretiens à la Foogle/Gacebook pour finalement vous faire pondre des petits trucs bien loin de là) : « I think this is a good interview question because it’s somewhat harder to solve than FizzBuzz, but it doesn’t suffer from the "invert a binary tree on this whiteboard" issue. It’s the kind of thing a programmer might have to write a script for in real life, and it shows whether they understand file I/O, hash tables (maps), and how to use their language’s sort function. There’s a little bit of trickiness in the sorting part, because most hash tables aren’t ordered, and if they are, it’s by key or insertion order and not by value. »
De ce que j'ai vu pour avoir fait passer un certain nombre d'entretiens et pour en avoir subi de bien costaudes aussi, on ne pense pas forcément à faire le malin ni à donner une réponse exhaustive quand on pense à tout les points que tu évoques. Les examinateurs pas fêlés n'ont normalement pas de choix et veulent juste voir comment est esquissée la solution (et là, en proposant celle de Ben tu le rassures que tu sauras répondre aux urgences au lieu de pinailler quand il y a le feu ; et si en plus tu mets les réserves citées par vous deux, ça montre que tu connais ton langage et sauras optimiser le moment venu)
Mais sinon, c'est un peu la seconde partie de l'entretien déjà... « After the candidate has a basic solution, you can push it in all sorts of different directions: what about capitalization? punctuation? how does it order two words with the same frequency? what’s the performance bottleneck likely to be? how does it fare in terms of big-O? what’s the memory usage? roughly how long would your program take to process a 1GB file? would your solution still work for 1TB? and so on. Or you can take it in a "software engineering" direction and talk about error handling, testability, turning it into a hardened command line utility, etc. »
"It is seldom that liberty of any kind is lost all at once." ― David Hume