L'auteur de cette article propose de savoir écrire les yeux fermé des algo comme A*, des parcours de graph et autre algo de trie. La facilité de faire cela serait un bon moyen d'être embauché.
En France non. Autrement cela me semble assez vrai vu les différents entretiens que j'ai pu faire.
En fait le truc c'est d'être capable de démarrer rapidement à froid et de garder la gymnastique que tu pouvais avoir à la fac. C'est certe un exercice très artificiel, auquel je suis mauvais, mais ca paie aussi dans la vraie vie. Dès que tu as besoin de faire un peu plus que manipuler l'API standard (mauvaise performance de l'implémentation par défaut, overhead mémoire, faire juste job qu'on te demande etc.)
Mais quel informaticien écrit en moyenne par mois, de tel algo ?
Écrire du code avec ce genre de gymnastique, cela m'arrive fréquemment alors que je dev majoritairement en Java.
Personne ou presque. Un codeur passe son temps à architecturer du code, prévoir plus ou moins l'avenir, revoir les besoins du "clients", debuguer. Mais certain aucun temps à faire ce genre d'exercice.
C'est vrai. Le reste c'est extra bonus pour ceux qui font du code qui doit répondre à un besoin précis et pour lequel optimiser quelques trucs après mesure à un sens par rapport au coût de dev (hello big data, langage à la con où le boxing des types primitifs est hors de prix ou bibliothèques largement réutilisées).
Regarde un peu ce qui est open-sourcé par Google, Twitter, Linked-in et tous les autres. C'est bourré de choses de ce genre par ce qu'on en à besoin et que les runtimes standards ne fournissent pas ce qu'il faut.
Concernant les structures de données, il ne sert à rien d'avoir des collections complexe pour des tailles inférieurs à 100. Le O(1) cache souvent un cout fixe énorme, il ne faut pas jeter trop vite les bon vieux tableaux ou liste chainé.
Déjà des gens qui comprennent le Big O ca court pas les rues. Si en plus tu essaies de leurs faire comprendre le k ou simplement les choix d'implémentation par rapport à comment fonctionne une machine, ca va faire beaucoup. Ils pourraient du coût être amené à écrire le genre de code dont on parlait ou comprendre qu'en réécrivant 15 lignes ils diminuent par 10 la conso mémoire ;)
[^] # Re: quelques points
Posté par ckyl . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 6.
En France non. Autrement cela me semble assez vrai vu les différents entretiens que j'ai pu faire.
En fait le truc c'est d'être capable de démarrer rapidement à froid et de garder la gymnastique que tu pouvais avoir à la fac. C'est certe un exercice très artificiel, auquel je suis mauvais, mais ca paie aussi dans la vraie vie. Dès que tu as besoin de faire un peu plus que manipuler l'API standard (mauvaise performance de l'implémentation par défaut, overhead mémoire, faire juste job qu'on te demande etc.)
Écrire du code avec ce genre de gymnastique, cela m'arrive fréquemment alors que je dev majoritairement en Java.
C'est vrai. Le reste c'est extra bonus pour ceux qui font du code qui doit répondre à un besoin précis et pour lequel optimiser quelques trucs après mesure à un sens par rapport au coût de dev (hello big data, langage à la con où le boxing des types primitifs est hors de prix ou bibliothèques largement réutilisées).
Regarde un peu ce qui est open-sourcé par Google, Twitter, Linked-in et tous les autres. C'est bourré de choses de ce genre par ce qu'on en à besoin et que les runtimes standards ne fournissent pas ce qu'il faut.
Déjà des gens qui comprennent le Big O ca court pas les rues. Si en plus tu essaies de leurs faire comprendre le k ou simplement les choix d'implémentation par rapport à comment fonctionne une machine, ca va faire beaucoup. Ils pourraient du coût être amené à écrire le genre de code dont on parlait ou comprendre qu'en réécrivant 15 lignes ils diminuent par 10 la conso mémoire ;)