L'algorithmique pour les entretiens

Bonjour a tous.

Ma recherche de stage de M2 info va commencer, et je sais que les entretiens techniques ne sont pas rare. Je suis le genre d’élève avec un mémoire vraiment merdique, j’ai beau avoir fait de l’algorithmique dans mon parcours, si je ne pratique pas des notions souvent, je les oublie ! Et c’est un gros souci pour moi.

Du coup, je vais me lancer dans un entrainement/revision sur l’algo en vu des entretiens, et juste pour moi aussi quoi.

Par contre, c’est tellement vaste que j’ai aucune foutu idée de par ou commencer, quels sujets privilégier, quels sont les bases absolues à avoir au minimum, j’aimerais faire les choses bien, vous pouvez m’aider a établir une liste des trucs que je devrais revoir/apprendre ? des bases jusqu’à un niveau plus ou moins élevé.

Et peut etre me partager vos astuces ou ressources. (détail : j’aime beaucoup la programmation fonctionnelle)

Bonsoir,

Avant de continuer, tu comptes programmer dans quelles branches d’activités ?

• Sites & Applications Web (PME / agences de communication)
• Clients lourds (SSII)
• API / Plugins (prestataires de services)
• Systèmes intégrés / IOT (constructeurs ou assimilés)
• Jeux vidéos (boîtes de jeux / indés)
• Big Data / Machine Learning (entreprises de la tech)

En général les exercices algorithmiques dans les tests techniques sont je crois vraiment bateau, c’est juste histoire de voir si t’as déjà codé dans ta vie. Là où on va plutôt te juger c’est sur ta connaissance des technos répandues sur le coeur de métier et sur ta façon d’aborder les problèmes.

Les tests d’algo des entretiens, généralement c’était vraiment très bas niveau.

Il faut se rendre compte qu’un FizzBuzz déjà c’est compliqué.

Le plus dur que j’ai eu, c’est chronométré, un exercice qui t’embrouille avec les noms de variables.

Genre:

  const char* laluneEstBleu = "La lune est rouge";
  const char* laMuleEstRouge = "La lune est Jaune";
  const char* laLuneEstBleu = "La mule est bleu";

  if(t == 1) {
    puts(laLuneEstBleue);
  else if(t == 2) {
    puts(laLuneEstBleu);
  } else {
    puts(laMuleEstRouge);
  }

Quand t == 3 qu’affiche ce programme ?

• laMuleEstRouge
• La lune est bleu.
• La lune est jaune.
• Le programme ne compile pas.

Tu prends plus de cas et tu changes t == 3 par un truc moins évident.

Salut, dans ma boite nous codons surtout en python du coup les tests sont basés sur :

• l’utilisation des listes, tuples, dictionnaires (tri d’une liste, manipulation de données via des dictionnaires …)

• comme nous travaillons beaucoup sur des graph, l’exo le plus important à nos yeux est un exo de récursivité /utilisation d’une doc technique simple (dans lequel, il faut retrouver un nœud précis en utilisant nos API => une doc minimale est fournie évidemment!)

Même une personne qui ne connait pas python doit être capable de faire le second exercice mais une personne ayant mentionné sur son CV python doit pouvoir faire les premiers

Mon expérience est assez proche de ce qu'@Angelo raconte :

• Des tests de screening tous nuls comme le FizzBuzz pour s’assurer que tu sais coder,
• Des questions généralement courtes pour s’assurer que tu connais la techno s’ils filtrent là-dessus,
• Plus tard, éventuellement un test algorithmique non trivial, et souvent ça va piocher dans des problèmes de graphes mais ça va rarement plus loin que de savoir calculer la complexité d’un code,
• Plus tard (mais souvent c’est réservé à des profils senior), des exercices d’architecture où on te demande en plus avec quelles technos tu ferais ça, comment tu gererais une connexion reseau qui tombe, où on essaye de te faire mentionner le théorème CAP, etc.

Il faut garder en tête que la partie technique est la moins importante en général : du moment que tu ne te démontes pas, que tu sais dire "je sais pas" et que tu es capable de penser à voix haute, ça va généralement passer.

Le plus important c’est l’aspect communication. Il vaut mieux ne pas savoir quelque chose et le dire que tout savoir mais être incapable de l’expliquer.

Aucune idée, j’allais d’ailleurs faire un autre topic pour demander de l’aide aussi sur ça.

Je sais que j’aime la prog fonctionnelle et que j’aimerais approfondir et en faire dans mon taff.

Mais j’ai choisit mes matières du M2 pour avoir un parcours axé fiabilité/sûreté des programmes (vérification de programme, analyse statique, typage etc). C’est ça que j’aime mais je sais absolument pas quels boîtes je devrais viser pour continuer a faire tout ça.

Après au delà de ça, même pour mon plaisir personnel j’aimerais avoir une bonne culture algorithmique et de bonne bases. + histoire de pas être ridicule dans mon futur boulot. (J’oublie vite encore une fois).

Merci pour vos réponses en tout cas, ça rassure un peu quand même.

Après au delà de ça, même pour mon plaisir personnel j’aimerais avoir une bonne culture algorithmique et de bonne bases. + histoire de pas être ridicule dans mon futur boulot. (J’oublie vite encore une fois).

On a tous une mémoire différente, mais si tu en fais ton travail et que tu aimes ça, tu vas retenir l’information simplement parce que tu y seras exposé. C’est parfois fou les choses qu’on retient simplement parce qu’on baigne dans un contexte. Je m’inquiéterais pas de ça si j’étais toi. Ce que tu peux faire, c’est simplement relire tes notes de cours à ce sujet ou des documents dessus régulièrement. Tu n’as pas besoin de te forcer à retenir les choses, ni te mettre la pression. On oublie tous les trucs qu’on ne pratique pas, la solution contre ça est de s’exposer à l’information régulièrement.

Il y a des sites qui proposent des questions d’algorithmique type entretien (leetcode, hackerrank par exemple).

Pour le côté industrie peut-être que l’entreprise Tarides (https://tarides.com/) peut t’intéresser (je sais pas si ils prennent des stagiaires), ils travaillent avec OCaml.

Sinon les sujets que tu évoquent c’est plutôt de la recherche, il faut voir des équipes d’INRIA / CNRS comme INRIA Cambium par exemple (et dans ce genre d’équipes je ne pense pas que tu auras des questions d’algo). Et si la recherche t’intéresse, tu peux aussi t’adresser directement aux professeurs des cours qui t’ont intéressé.

Bonne recherche !

Le problème de "programmation fonctionnelle" c’est que l’on met des langages comme Lisp ou OCaml mais en réalité tous les langages aujourd’hui peuvent avoir ce type de comportement … On peut coder en Javascript, Python ou PHP avec la logique de la programmation fonctionnelle. Honnêtement, je trouve ce terme beaucoup trop vieux - ça ne veut plus rien dire aujourd’hui.

Je te conseillerai bien d’apprendre le langage R mais … ce n’est pas la question. Alors je te dirai juste de t’entraîner sur des sites comme CodinGame pour que tu entretiennes cette réflexion autour de l’algorithmie - peu importe le langage.

Le problème de "programmation fonctionnelle" c’est que l’on met des langages comme Lisp ou OCaml mais en réalité tous les langages aujourd’hui peuvent avoir ce type de comportement … On peut coder en Javascript, Python ou PHP avec la logique de la programmation fonctionnelle. Honnêtement, je trouve ce terme beaucoup trop vieux - ça ne veut plus rien dire aujourd’hui.

C’est assez difficile de faire de la programmation fonctionnelle performante et idiomatique quand ton langage n’est pas fait pour. Ceci dit, c’est rare que les langages modernes soient purement fonctionnels (ou purement quoi que ce soit d’ailleurs). C’est tant mieux d’ailleurs, parce que les paradigmes ne sont pas égaux face à différents types de problèmes.

J’aime beaucoup faire du Haskell et de l’OCaml si tu préfère. J’ai demandé a quelques pro Haskell si je pouvais trouver du taff ou ils l’utilisent, ils m’ont dit de me mettre a scala

Merci a tous pour vos réponse, merci a Aabu pour ma sous-question pour les entreprises !

Si tu pars plutôt sur du Scala, au vu des jobs proposés, tu es en plein dans "Big Data / Machine Learning (entreprises de la tech)". A un moment donné, tu vas devoir manger du Java et/ou du Python. D’un point de vue algorithmique, on est plus sur de l’agrégation de données ; je te conseille d’apprendre MapReduce. Essentiel dans le calcul distribué et dans la simplification algorithmique. C’est un gros morceau, tu ne vas pas tout comprendre d’un seul coup (ce n’est pas grave) mais il est incontournable ! Après ça, on pense les données d’une autre manière.

On peut coder en Javascript, Python ou PHP avec la logique de la programmation fonctionnelle.

Je ne connais pas JS et PHP suffisamment pour en juger (cela dit j’imagine que c’est pareil), mais la programmation fonctionnelle en Python est une vaste blague. On ne peut pas construire d’abstractions intéressantes et utiles (ne parlons pas des performances) dans un style fonctionnel en Python parce qu’il n’y a pas les outils qui rendent ça possible dans les langages à forte dominante fonctionnelle (l’éléphant étant l’absence de monades).

Même quand c’est possible, c’est pénible à utiliser (la composition de fonction notamment, où tu dois te traîner des *args et des **kwargs explicite dans tous les sens avec aucune façon de s’assurer de la cohérence des types). Le fait qu’il y a un contrôle inexistant sur les effets de bords n’arrange rien pour aider à écrire un code clair et maintenable par un humain (c’est littéralement la raison de l’introduction de yield from pour pouvoir combiner des générateurs sans s’arracher les cheveux avec les protocoles associés aux coroutines).

Certes, on peut vaguement écrire des trucs très simples dans un style fonctionnel, mais dire que l’on peut faire de la programmation fonctionnelle en Python est un peu tiré par les cheveux. C’est un langage fortement orienté sur l’écriture d’interfaces dans un style orienté objet. Dire qu’on peut programmer de façon fonctionnelle en Python parce que les fonctions sont des first-class citizens, c’est un peu comme dire qu’on peut faire de la POO en C parce que struct existe. Il manque beaucoup trop de choses qui rendent ces styles de programmation intéressants (notamment pour écrire des abstractions puissantes).

Ouais j’ai bien l’impression que dans tout les cas je vais devoir toucher a du java et du python. C’est peut etre de l’immaturité de ma part mais j’ai énormément tendance a fonctionner a la techno, genre la j’écume les offres de stages depuis quelques jours, et si c’est pas du OCaml ou Haskell, je passe mon tour, meme si le sujet a l’air intéréssant.

Je suis peut etre un peu matrixé par le fait que la découverte de la prog fonctionnelle (surtout des langages dont c’est le noyau) a été comme une redécouverte de la prog en general pour moi, et que j’ai commencé a la considérer comme superieure a tout le reste dans les problematiques de sureté et fiabilité de ce qu’on code.

Immaturité non. C’est logique de vouloir rechercher un job en choisissant le plus confortable dans son domaine de compétences. De toute façon, une fois en entreprise tu es lâché sur des projets qui vont toujours bien au-delà de ton confort technique & intellectuel. Pour l’exemple, en ce moment je code en renfort pour une boîte partenaire sur du Angular (Typescript / Javascript) ; pourtant y’a pas un seul projet dans l’entreprise en Angular … au final je m’en plains pas, je suis payé pour apprendre & coder dans une autre techno, même si c’est pas ma techno de prédilection je ressens tout de même du plaisir à coder.

@Adri1 : je n’ai pas envie de débattre sur quelque chose qui n’a pas lieu d’être. Python a implémenté depuis plusieurs versions déjà, différentes méthodes pour approcher la programmation fonctionnelle : voir la doc officielle. De la même façon que Javascript et PHP permet d’utiliser aisément le paradigme fonctionnel. Bien entendu qu’il existe des langages spécialisés (Aabu l’a rappelé plus tôt en soulevant l’aspect idiomatique), tout comme il en existe pour la POO. En soit cette question de "programmation fonctionnelle" ne doit pas être un critère pour choisir son taff ou sa techno. Si on est plus à l’aise dans un premier temps avec le paradigme de programmation fonctionnelle, on peut le mettre en oeuvre sans attendre du langage qu’il soit parfaitement normé.

En soit cette question de "programmation fonctionnelle" ne doit pas être un critère pour choisir son taff ou sa techno.

Bien sûr, mais ça n’a rien à voir avec le point que je soulève.

Si on est plus à l’aise dans un premier temps avec le paradigme de programmation fonctionnelle, on peut le mettre en oeuvre sans attendre du langage qu’il soit parfaitement normé.

Il serait absurde de vouloir appliquer le paradigme fonctionnel même "dans un premier temps" à Python. Ce serait la meilleure façon d’utiliser des anti-patterns et de produire du code de mauvaise qualité tant en terme de maintenabilité que de performances (d’ailleurs, si tu as toi-même lu la doc que tu pointes, tu voies que ça parle plutôt d’emprunts très épars et localisés au monde de la programmation fonctionnelle plutôt que de programmation dans le paradigme fonctionnel). On n’en est pas à discuter si le langage est "parfaitement normé" ou non pour la programmation fonctionnel, la différence est beaucoup plus fondamentale. Vouloir utiliser Python comme un langage fonctionnel alors que c’est juste pas pratique et hautement inefficace, c’est aussi absurde que de rejeter en bloc les autres paradigmes pour choisir son taf.

Au contraire, quitte à utiliser Python, autant embrasser son modèle de duck-typing focalisé à mort sur les interfaces et de flow géré notamment par les exceptions. Ce ne sont pas des choses qu’on trouve classiquement en programmation fonctionnelle alors que ce sont des constructions intéressantes et puissantes en elles-mêmes. C’est une autre façon de gérer respectivement la généricité et la propagation d’erreur (ça me rappelle un talk à la PyCon où un type émulait un comportement monadique à coup d’exceptions, c’était horrible à voir et clairement pas pratique, mais très fun).

C’est peut etre de l’immaturité de ma part mais j’ai énormément tendance a fonctionner a la techno, genre la j’écume les offres de stages depuis quelques jours, et si c’est pas du OCaml ou Haskell, je passe mon tour, meme si le sujet a l’air intéréssant.

C’est pas de l’immaturité. C’est comme ça que fonctionnent les devs juniors, et c’est comme ça que la plupart des boîtes recrutent quand elles ne savent pas ce qu’elles cherchent (c’est-à-dire le plus souvent) : à la techno.

Tout comme le fait de te focaliser sur la programmation fonctionnelle, ça aura de grandes chances de te passer quand tu auras traversé plusieurs postes qui te donneront l’occasion de t’apercevoir que ces détails techniques sont, le plus souvent, sans grande importance et que 90% des problèmes en informatique sont humains. Mais en attendant, c’est comme un passage obligé : c’est lié au fait que le métier lui-même est beaucoup plus complexe que l’on ne se le représente, ou que l’on nous le représente à l’école et dans les bouquins. Pour aborder cette complexité, on a tendance à se concentrer sur les détails que l’on maîtrise. C’est humain.