Quels signes permettent de déceler un candidat talentueux ?

Citation:

---

Envoyé par pmithrandir

en fait, ca permet malgré tout d'en filtrer certains. Sur les 50-60 candidats que j'ai vu cette année, environ 10-15 se sont vautré dessus, dont 5 qui nous avait entourloupé en entretien sur des notions de programmation.
(.../...)

---

Voilà, c'est ça que je voulais dire. C'est un test simple, et ça permet d'éliminer entre 25% et 50% des candidats(suivant le profil). Ensuite, on passe aux choses sérieuses.

Et là, on va plus cibler. Pour recruter mon remplaçant, l'idéal serait une double rupture, pour comparer des fichiers. Parceque généralement, on fait beaucoup plus que comparer les fichiers, et un outil de comparaison standard ne permet pas de faire ce que l'on fait - mais en entretien, on a pas le temps d'aller jusqu'à une solution complète à un problème complet. D'autres métiers auront d'autres exigences.

Mais ça ne sert à rien de sortir la grosse artillerie pour des gens qui ne savent même pas faire un fizzbuzz. D'ou son utilité.


Sinon, j'ai fait mon Lycée en 90-93, et je n'ai jamais entendu parler de Fibonacci. Jusqu'à il y a quelques mois(en cherchant sur le net une astuce technique). Si le recruteur demande "la solution à la suite de Fobonacci", effectivement, il va recruter un matheux, pas un programmeux. Si par contre il dit "tiens, on cherche à mettre en place une fonction qui rende 1 pour 1 ou deux, et au delà additionne les deux chiffres précédents", là, il fait appel au programmeur.

Citation:

---

Envoyé par Bluedeep

D'où ma surprise car le lycée d'avant 1979 que j'ai connu ne devait pas être très différent du lycée d'avant 1976 dont tu parles, sauf erreur de ma part.

---

:mrgreen: ben si, justement.. Puisque justement j'étais dans l'année de test pour les maths modernes... Une seule fois... L'année d'après, c'était passé dans les programmes.. Mais moi j'ai terminé ma scolarité en maths anciennes.. :P

Bon, ça n'a guère d'importance, mais je trouve juste que ce genre de questions est un peu aberrante, et ne saisit pas ce que l'on attend réellement...

Citation:

---

Envoyé par Nasky

Les entretiens où faut donner la définition de "classe", "polymorphisme", etc. ne donnent aucune indication. N'importe quelle personne est capable d'apprendre ça en 5 minutes si elle ne le sait pas.

---

Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal. Après si le mec ne prends pas l'initiative tu enchaines de toi même sur les design pattern, tu lui en fais coder un, tu lui demandes quels sont les avantages/inconvénients de tel ou tel pattern, lesquels il connait, lesquels il a réellement utilisés, pourquoi, etc ...

Ca permet au minimum de pouvoir détecter les imposteurs, et sinon ça te donnera son autonomie dans ton architecture et quel investissement en temps il va falloir lui consacrer.

En revanche quelqu'un qui me dit qu'on apprend la POO en 5 minutes je le classe direct dans la catégorie des branquignols, finance ou pas.

Citation:

---

Envoyé par Nasky

Par exemple, écrire un code qui calcule le N-ième élément d'une suite de Fibonacci. Si tu fais du récurssif, c'est direct out.

---

Même si c'est du récursif terminal ?

Citation:

---

Envoyé par deadalnix

En plus d'être impossible dans le cas de fibonacci (cette suite est doublement récursive), c'est inutile car ne change pas la complexité algoritmique.

Cette technique permet simplement de ne pas faire de stack overflow et de gagner en performance sur les fonction récursives, rien de plus. Ce ne sont pas les problèmes posés par Fibonacci.

---

Voici pourtant une fonction fibo en récursivité terminale, avec une complexité temporelle linéaire en fonction de n :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

#include <stdio.h> #include <stdlib.h> #include <assert.h> /* tail recursive */ int fibo_aux (int u2, int u1, int i) { if (i == 0) return u1; else return fibo_aux (u1, u1 + u2, i - 1); } int fibo (int n) { assert (n >= 0); if (n <= 1) return n; else return fibo_aux (0, 1, n); } int main (int argc, char *argv[]) { if (argc == 2) printf ("%d\n", fibo (atoi (argv [1]))); else printf ("%d\n", fibo (20)); return EXIT_SUCCESS; }

---

Je reconnais cependant que la version itérative est bien plus simple à écrire.

Salut,

Citation:

---

Envoyé par el_slapper

Et là, on va plus cibler. Pour recruter mon remplaçant, l'idéal serait une double rupture, pour comparer des fichiers. Parceque généralement, on fait beaucoup plus que comparer les fichiers, et un outil de comparaison standard ne permet pas de faire ce que l'on fait - mais en entretien, on a pas le temps d'aller jusqu'à une solution complète à un problème complet. D'autres métiers auront d'autres exigences.

---

Ah, les ruptures...

Ce n'était pas pour une comparaison de fichiers, mais pour un examen... d'algorithmie lors de mes cours.

J'ai du en gérer 7 :P en cinq minutes j'avais une réponse qui aurait suffit à mon prof, mais, comme j'avais deux heures à tirer, je lui ai sorti le nassi-schneiderman complet pour le problème qu'il me posait ;)

Ceci dit, c'est quelque chose qui a tendance à faire fuir pas mal de gens :D

Citation:

---

Envoyé par Marco46

Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal.

---

Et encore...

Demandes moi de te parler de polymorphisme, je te parlerai de substituabilité (sans doute de liskov), d'adaptabilité du comportement, mais la factory, je n'en parlerai sans doute pas sur ce sujet.

Par contre, demandes moi ce que je préconise lorsqu'une classe doit utiliser un objet polymorphe, et là, tu auras droit à la factory, avec en plus un petit détour par SRP et autres ISP ;)

Citation:

---

Envoyé par el_slapper

Sinon, j'ai fait mon Lycée en 90-93, et je n'ai jamais entendu parler de Fibonacci. Jusqu'à il y a quelques mois(en cherchant sur le net une astuce technique). Si le recruteur demande "la solution à la suite de Fobonacci", effectivement, il va recruter un matheux, pas un programmeux. Si par contre il dit "tiens, on cherche à mettre en place une fonction qui rende 1 pour 1 ou deux, et au delà additionne les deux chiffres précédents", là, il fait appel au programmeur.

---

On est d'accord, le but n'est pas de tester si le candidat connais ou pas fibonacci, mais s'il est capable, pour peut qu'on lui donne la formule, de pondre la fonction qui le calcule. Dans ton cas donc, c'est bien la seconde question qui a du sens, la première permettant avant tout de trouver des singes savant, et pas forcement des gens intelligents.

Et ensuite de voir s'il se rend compte que la solution naïve à une complexité exponentielle, et s'il est capable d'en trouver une un peu plus maligne (j'ai donné la solution, c'est ~10 lignes de code avec une boucle, on ne parle donc pas ici d'un truc de haut vol) en O(n).

Je suis quand même vraiment étonné de voir les gens ici s'étonner d'une telle question. La solution est très simple. Certains demandaient si j'avais pondu le code de mémoire, et bien absolument pas ! Je l'ai écris en live dans mon précédent post, en moins de 5 minutes.

La solution naïve est vraiment un problème du même niveau que fizzbuzz, mais ça permet d'ouvrir sur une question de complexité algorithmique, ce qui est un moyen de transitionner dans l'interview.

Citation:

---

Envoyé par I_believe_in_code

Voici pourtant une fonction fibo en récursivité terminale, avec une complexité temporelle linéaire en fonction de n :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

#include <stdio.h> #include <stdlib.h> #include <assert.h> /* tail recursive */ int fibo_aux (int u2, int u1, int i) { if (i == 0) return u1; else return fibo_aux (u1, u1 + u2, i - 1); } int fibo (int n) { assert (n >= 0); if (n <= 1) return n; else return fibo_aux (0, 1, n); } int main (int argc, char *argv[]) { if (argc == 2) printf ("%d\n", fibo (atoi (argv [1]))); else printf ("%d\n", fibo (20)); return EXIT_SUCCESS; }

---

Je reconnais cependant que la version itérative est bien plus simple à écrire.

---

Attention, je n'ai pas dit que c'était impossible (ou alors j'ai parlé trop vite) mais que ce n'était possible sur la solution récursive naïve (car doublement récursive justement). Alors que le memoize le permet (au prix d'une consommation mémoire en O(n), il n'y a pas de magie).

Une autre chose qui m'a surpris : que l'on considère la récursivité terminal comme académique. Pourtant, c'est une optimisation très courante, que presque tous les compilateurs font (et c'est bon à savoir car ça peut changer la tête des stack traces). De plus, le fonctionnel en général est la meilleur réponse que l'on ai à l'heure actuelle pour la programmation parallèle (l'OOP est carrément mauvaise sur ce sujet). Il y a du multicore jusque dans votre téléphone maintenant, ça devient urgent de s'y mettre.

Citation:

---

Envoyé par Marco46

Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.
Tu vois sur quoi le candidat débouches, par exemple quelqu'un qui me parle de polymorphisme et qui ne me parle pas de Factory j'ai du mal. Après si le mec ne prends pas l'initiative tu enchaines de toi même sur les design pattern, tu lui en fais coder un, tu lui demandes quels sont les avantages/inconvénients de tel ou tel pattern, lesquels il connait, lesquels il a réellement utilisés, pourquoi, etc ...

---

Plus que de voir si le candidat sait placer des mots-clefs, je pense qu'il faut lui demander quelle est la bonne utilisation. Par exemple, quelle est la bonne longueur pour une classe, ou bien combien de niveaux d'heritages sont raisonnables dans un projet.

Le soucis pour le recruteur, c'est qu'il n'existe pas de reponse toute faite, et que donc ca demande de reflechir, de pousser le candidat pour savoir ce qu'il a vraiment compris de ces concepts.

Exemple de mauvaise reponse, que j'ai vue en entretien : L'heritage ? Pas plus de 40 niveaux, et ca roule.

Citation:

---

Envoyé par Freem

La ou les propos me choque, cela dis, c'est quand il dit que le gars à écris la javadoc AVANT le code... comment donc qu'il a fait, il est tellement fort que sa conception est pile poil le résultat final? Nan parce que, chez moi, la conception dégrossis pas mal, c'est vrai, mais elle évolue au fur et a mesure que le code progresse.

---

(bon, je sais, j'arrive deux guerres en retards :? )
Hé bien, honnêtement, tu devrais essayer...

Sincèrement, le fait d'écrire la javadoc (la documentation doxygen) au moment où tu n'en est qu'à la création de l'interface de ta classe t'oblige à concevoir clairement:

• le but recherché par ta classe
• La responsabilité que tu veux donner à ta classe, et donc, à veiller qu'elle reste unique
• les pré / post conditions et les invariants de tes fonctions
• l'utilisation qui sera faite des arguments que tu vas passer
• les exceptions éventuellement lancées

Cela te permet, éventuellement, de mettre le doigt sur d'autres problèmes de conception ;)

En plus, cela te donne à la limite "tout ce qu'il faut" pour te permettre d'au moins définir les tests unitaires qui sont à faire (quitte à ce que ce ne soit que l'algorithme de tests, si tu ne sais pas quelle bibliothèque est utilisée par la société).

Si tu as la chance de pouvoir travailler en binôme, tu te trouves dans une situation idyllique:

Tu "fourgue" ta classe documentée, non implémentée, à ton binome qui va écrire les tests unitaires sur base de ce qu'il lit dans la doc (que tu viens de créer), et, pendant ce temps, tu implémentes les différentes fonctions "à ton rythme".

Si tu as bien écrit ta doc, ton binôme doit pouvoir comprendre ce que tu as écrit sans avoir à te demander quoi que ce soit, et, si tu as correctement suivi ce que tu as mis dans la doc, tous les tests unitaires devraient passer, y compris ceux qui vérifient que tu lances une exception ou les cas hors conditions ;)

Citation:

---

Pour le reste, les tests unitaires, je ne sais simplement pas les faire

---

Et pourtant, si tu garde des fonctions simples, correctement nommées, et qui ne font qu'une chose, c'est simple :

1. tu testes le résultat obtenu avec deux ou trois cas "de base", qui doivent passer
2. tu testes le résultat obtenu avec les cas "hors limites" en terme de pré/post conditon / invariant
3. Une division se teste avec un dénominateur nul, pour voir comment cela se passe
4. Tu rajoutes quelques cas "border line" qui pourraient te venir à l'esprit ;)

Citation:

---

Refactorer le code intelligemment, en revanche, ça implique de maîtriser entièrement l'existant. En 2H, il vaut mieux ne pas avoir 10K lignes de code à lire.

---

Ne t'en fais pas, tu n'auras pas 10 K lignes de code à analyser pendant ton test...

Mais bon, tu peux très bien tomber sur une fonction de 150 lignes qui mout le café, lance la machine à laver et fait la vaisselle...

Il est assez facile dans de telles conditons de la diviser en trois fonctions distinctes, non :question:

Citation:

---

Quant aux solutions multiples, ça dépend tellement du problème que je trouve ça limite ridicule. Sinon, donnez-moi 3 solutions pour récupérer la valeur max entre 2 entiers? Bref, selon le niveau d'abstraction du problème et selon la situation, on ne peut pas nécessairement avoir tant de solutions que ça.

---

Peut etre pas pour un cas aussi basique, mais si tu savais le nombre de fois où je répond à des questions sur ce forum en donnant au moins deux solutions, après avoir ré exprimé les besoins du PO car il s'attaque au problème à l'envers ou parce qu'il a manqué de précision dans sa demande... Tu serais sans doute surpris ;)

Citation:

---

Et au final, je rejoins certains qui estiment que la motivation du type en face est importante. Un génie qui s'ennuye ne sera pas forcément aussi productif qu'un idiot qui se fait plaisir.

---

Je ne crois pas qu'il faille forcément être un génie, mais il ne faut en tout cas certainement pas être idiot...

Je crois d'abord et avant tout qu'il faut arriver à mettre en oeuvre la deuxième ligne de ma signature et arriver à comprendre ce que les gens demandent.

Citation:

---

Et on ne mesure pas la motivation par un test de code.

---

Très certainement pas la motivation, ca, je te l'accorde sans le moindre problème.

Par contre, leur capacité d'analyse et leur compétence, voire leur débrouillardise et leur capacité d'adaptation, ca, presque sans aucun doute ;)

Citation:

---

Envoyé par Marco46

Bien sur que si ça a un intérêt, ça te donne le degré de compétence en POO du candidat, ça peut être très varié. Ca te permet aussi de voir s'il est capable de s'exprimer de manière intelligible pour transmettre ses compétences.

---

Pour la dernière partie, d'accord.

Pour la première, en revanche, être compétent en OO n'en fait pas un bon programmeur/concepteur..

Le mec qui fait 250 000 classes pour modéliser quelque chose qui se ferait simplement avec 2 ou 3 en procédural est à mon avis un mauvais concepteur... :P

Mais je sais que je ne suis pas "in"... :aie:

(comme j'ai cité ci-dessus : faire des gettr/setter pour récupérer un élément d'une structure aussi simple qu'un point est une absurdité de modélisation)

Citation:

---

Envoyé par souviron34

(comme j'ai cité ci-dessus : faire des gettr/setter pour récupérer un élément d'une structure aussi simple qu'un point est une absurdité de modélisation)

---

Faire un mutateur sur un point, très certainement...

Faire un accesseur sur un point, cela peut encore se discuter ;)

Plus sérieusement : si le point représente une caractéristique de ton objet à laquelle tu dois pouvoir accéder, cela peut se comprendre (pour l'accesseur, car, pour le mutateur, le comportement idéal sera sans doute beaucoup plus proche de move (direction + distance) ou de move(position finale) .

Par contre, de manière générale (et bien que l'on puisse trouver des exceptions, comme partout ;)) placer un mutateur sur une classe ayant sémantique de valeur sera très souvent une aberration de conception.

Et, de manière encore plus générale, si A utilise B en interne et que B utilise C en interne, il serait totalement aberrant que tu doive connaitre C pour pouvoir manipuler B depuis A ;)

Citation:

---

Envoyé par souviron34

:mrgreen: ben si, justement.. Puisque justement j'étais dans l'année de test pour les maths modernes... Une seule fois... L'année d'après, c'était passé dans les programmes.. Mais moi j'ai terminé ma scolarité en maths anciennes.. :P
(.../...)

---

un peu de hors sujet, mais rigolons un peu avec les maths modernes(en anglais)

Citation:

---

Envoyé par souviron34

Le mec qui fait 250 000 classes pour modéliser quelque chose qui se ferait simplement avec 2 ou 3 en procédural est à mon avis un mauvais concepteur... :P

Mais je sais que je ne suis pas "in"... :aie:

---

Non, tu es raisonné. Les design patterns ou les best practice (ou quoi que ce soit d'autre) servent à résoudre des problèmes. Si tu n'as pas le problème, les utiliser n'a pas de sens.

Ceci dit, j'ai aussi travaillé avecd es gens qui étaient alergique au découpage, et c'est pas franchement mieux. Il y a un équilibre à trouver.