La société où je travaille va engager prochainement 2 développeurs c++; parmis les tests d'embauches, le candidat devra écrire en pseudo-code un algorithme. Je cherche des idées à ce sujet, qqch de général (pas spécifique à notre métier), qui montre que le candidat a une bonne 'logique informatique'. Si possible je préfère éviter les grands classiques (calcul de factorielle en récursif, un tri quicksort, ...). Des suggestions ?

Tu peux lui faire retourner une liste, en iteratif et en recursif.
 
Pose lui aussi des questions sur les opérations sur les bits, comme
les gens que je connais qui n'ont fait que de l'informatique à l'école
n'ont aucune idée à quoi servent les opérateurs bits à bits (and, xor, décalages, etc.)
Par exemple, extraire le log de deux d'un nombre. Compter le nombre de bits
mis à un 1 dans une représentation binaire d'un nombre entier etc.
 
Sinon des questions plus compliquées mais ça dépend du niveau de candidats que vous recherchez.
 
LeGreg

Le pb du sac à dos (appelé knap sack, mais je ne suis pas sûr de l'orthographe). C'est un pb qui revient souvent sur le tapis dans pas mal de domaines.

Ca s'appelle la logique combinatoire.

 
Alors la, je ne suis même pas sûr que tout le monde y arrive !    

En prenant l'idée de logique combinatoire, tu peux lui demander de faire un petit programme qui lui demande d'entrer une adresse ip (elle devra être stocké dans un entier). Ensuite, avec cette IP, il t'affiche le netmask, broadcast, ...
 
et tout ca en utilisant la logique combinatoire
 
(mais bon, je trouve ça un peu vache quand même car la logique combinatoire ne doit pas  être très très utilisé, et c'est vite prise de tête)

moi je serais plus pour filer du code buggué c/c++ style époque vc6, et de demander au dev de proposer une correction plus c++ iènne (stl...)

Euh si c'est un programmeur objet, lui demander de dessiner en UML un ou deux design pattern semble pas mal.

 
si ça tombe sur moi, je serai recalé alors  

demande lui d'écrire plusieurs manières de créer des singleton en C++
 
puis de les commenter
 
/slvn

 
D'abord, il faut être conscient que tester les compétences algorithmiques d'un candidat, ne donnera même pas un pale reflet de son niveau en C++. Après, proposer un algorithme complexe en temps limité, c'est pas forcément évident (surtout mal assis, en costar, avec une cravate qui te sert la gorge). Je verrais bien plusieurs algorithmes moyennement complexe, à faire assez rapidement, touchant des domaines différents. Eventuellement faire en sorte que le candidat ne puisse pas finir, pour voir quel exercice le rend le plus à l'aise.  
J'éviterais aussi les "classiques" que le candidat ferait de mémoire, ainsi que tout algorithmes qui demanderait des connaissances autre qu'algorithmiques.
Disons un algo plutot gestion, un algo mathématique, pourquoi pas un algo en rapport avec votre métier ? (voir s'il le fait au début ou à la fin), un algo en rapport avec la spécialité du candidat.
 
Exemple pour le domaine Math : donner un ensemble de points, un ensemble de cercle ( rayon, centre ), et trouver le cercle qui contient le plus de points. Ou voir si au moins un point appartient à plus d'un cercle, etc.
Je pense que ce niveau de complexité est raisonnable. Dans la pratique, pour un poste de débutant, j'ai eu des tests encore plus faciles, mais nombreux.
 

moi je pense que pas d'algo et pas de jeu de mémoire du tout c'est bien, c'est comme ça que j'ai été recruté et je suis bien content de ma boite, l'inverse est vrai aussi.
 
J'ai tappé un peu de code, mais avec le recruteur à côté, et on a discuté, c'est là qu'il a vu ma logique (ne pas retourner la liste mais la wrapper, puis quand il a insisté pour une inversion et place, lui dire que sur une liste chaînée c'est débile, lui expliquer RandomAccess qu'il connaissait pas etc.)
 
Sélectionner sur du code sur papier, je trouve ça bidon, c'est trop loin des conditions réelles. Et si c'est quelqu'un comme moi, ce que j'apporte c'est pas des connaissances violentes, mais une capacité à utiliser google.

S'il s'agit de tests de C++, rien ne vaut un bon fact/exp/hanoi/boucle_for en meta-prog.

Ce qui sert beaucoup c'est la capacité du développeur à trouver la bonne classe dans la bonne bibliothèque.
 
Un test sur savoir utiliser google + msdn semble plus utile que des tests de rédaction d'algo bruts.
Disons à partir de nombreux problèmes bidons, tu places le candidat en face d'un pc et tu lui demandes quelles seraient les classes à utiliser pour chaque problème.

+1 nraynaud
 
Il vaut mieux s'écarter des tests d'embauche aux allures scolaires pour laisser le candidat déballer ce qu'il a de mieux à offrir, et ensuite le cuisiner à feu vif et bien assaisoné pour voir si c'est pas de l'esbrouffe.

Je dirais que la capacité a pondre un algo (théorique) ne signifie pas:
1- que le type sais le coder dans un language
2- que le type connais le c++
 
De plus les algo les plus courant on les trouve dans les bouquins et programmer sans bouquins/docs c'est aller droit au mur! (avis perso en tout cas)
 
donc
+1 nraynaud
+1 pains-aux-raisins
 
Je rajouterai quelque test pour voir si le type sais voir un probleme de facon "objet"

C++ ne signifie pas prog objet, s'ils font du C++ soupe-de-templates-et-de-casts c'est pas la peine de l'emmerder avec la liaison retardée.

Faudrait d'abord savoir ce qu'on entend par C++.
 
J'ai eu une drôle de discussion avec une chargée RH en informatique qui pensait que C++, Visual C++ et MFC c'était la même chose.
 
Par C++ vous entendez quoi ? Maîtrise des concepts et programmation objet, connaissance de C++ et de la STL, tests d'algorithmie, aptitude à se démerder tout seul ?
 
Sinon, notez que les programmeurs C++ se font rares; dixit mes contacts de recrutement. Si vous donnez envie au candidat de fuir dès l'entretien, pas sûr qu'il reste pour signer.

Je crois bien qu'un recruteur se marrerait bien en lisant ce thread
Dans RH, il y a *Humaine*, ils sont la pour recruter des personnes. Ils ont probablement à cerner le profil psychologique du candidat; suivant son caractère, s'il s'integrera bien dans une équipe, ou s'il sera capable de travailler seul, de bien s'entendre avec M. X, etc.
Pour certains postes (surtout débutant), il est probable que l'aspect purement humain soit plus important que le niveau technique. Comme me l'a répété un ami recruteur : "un débutant, ça ne s'embauche pas sur ses compétences, mais sur son potentiel". Après, si le recruteur est chargé d'embaucher un expert. Il n'a pas le droit à l'erreur parce qu'il coute cher. S'il est pas bête et s'il y a la compétence, il se fera seconder par un expert technique (ou sous-traitera).
 
Enfin, si on observe la diversité de la communauté C++, qu'on apprécie particulièrement bien sur les idées des 4/5 postes précédents (la metaprog,  la capacité à trouver/évaluer/utiliser des bibliothèques C++,  l'Objet, la programmation générique, le C++ m$, la capacité à exprimer un algorithme, etc), et si on observe aussi la diversité des profils recherchés (débutant, expert, (ass)sociable, (in)soumis, ...), je comprend que les avis soit extrèmement divergeant.

 
soupe-de-templates-***et-de-casts*** ?

fab > je parlais pas trop du truc avec les parenthèses, mais plutôt quand les mecs s'amusent à surcharger les opérateurs (y compris de cast) pour tout rendre compatible avec tout. genre quand string devient compatible avec char *.

Je comprends cast C-style ?
 

C'est un paradigme que je n'ai jamais vu. Je crois que c'était légion -- et souvent involontaire -- avant la standardisation du C++. Epoque à laquelle le mot clé explicit n'existait pas; et chaque classe qui avait un constructeur pouvant prendre un paramètre, fournissait alors +- volontairement une conversion implicite.
 
 

 
Ahah ça me fait penser à un candidat qu'on interviewait par téléphone, il mettait toujours une minute à répondre
mais trouvait toujours une définition exacte aux questions orientées "connaissances".
En fait c'était clair que le type googlait les réponses aux questions.. Ça donne pas trop envie de l'embaucher malgré tout. (de toute façon on a toujours un entretien sur place après l'entretien téléphonique).
 
Sinon pour le retournement de liste, je ne m'attends pas à ce que quelqu'un sache le faire de tête (ou s'il sait le faire de tête, encore plus de respect), mais qu'il sache redériver l'algo en temps réel, éventuellement avec les indications qu'on lui donne (ici ça ne marche pas, pourquoi ?).
 
Mais bon c'est vrai qu'embaucher un bon candidat c'est un problème "dur", quelles que soit les questions posées et si l'on ne veut pas y passer des journées (déjà vu dans certaines boites, où ils font venir les candidats pendant plusieurs jours en leur payant l'hotel), c'est pas évident de trouver une bonne corrélation entre ce qu'a fait le candidat à l'entretien et sa future performance au boulot (surtout si c'est dans un domaine qui ne s'apprend que sur le tas). Du coup on a tendance à overshooter (ou undershooter en prenant le risque que le candidat ne s'adaptera pas).

Chez moi on dit overkiller ou underkiller

perso, c'est comme ça que je me présente aux entretiens : "moi j'ai pas de mémoire et je récite rien par coeur, mais j'utilise google mieux que les autres. D'autre part, je connais aucun algo par coeur, par contre, je sais quand utiliser un treeSet ou un hashSet" (tiens, petite interro : quel est le critère déterminant pour utiliser un treeSet, qui s'utilise très rarement)
 
Franchement, je pense pas qu'on puisse embaucher quelqu'un sur des connaissances, on l'embauche sur une manière de voir les choses. Si on prend un premier de la classe, on sait qu'il discutera pas les ordres, sera productif mais il faudra le cadrer, si on prend un mec comme moi, on sait qu'il faudra prendre des premier de la classe à côté parce que je suis pas un furieux du clavier, par contre, je sais aller chercher un chignon au fond d'un plat de spaguettis pour le descendre dans un testbed.

 
Lui demander comment sont fabriqués les émemens, qu'il raconte un peu les projets qu'il a fait, quel était le pire beug de sa vie ... je trouve que ca sert à rien de lui faire faire des trucs algorithmiques y qu'a regarder ses relevés de notes pour ça.

 
émemens, kesako ?

pour nous, les omes

 
critère déterminant pour utiliser un treeset ? ... avoir une fonction de comparaison et des clés uniques de comparaison pour chaque noeud au risque d'écraser une valeur ou bien d'ignorer son ajout (cas java mais dépend de l'implémentation de l'arbre), c'est ça maître ?
 
 
moi non plus jsuis pas un 1er de la classe   je serais plutot comme toi.

j'aurai plustôt dit que le treeSet (enfin un arbre) c'est pour conserver l'ordre, alors qu'une table de hashage t'en a rien à secouer de l'ordre, mais autrement je sais pas...

ok les nains, on vous rappellera.
 
c'est tout connement si tu va tenter d'aller chercher une tête (tout les éléments inférieurs à une certaine valeur) ou une queue du set (tous les élément supérieurs à une certaine valeur.
 
edit : ou quand on veut faire un tri à l'insertion, mais attention c'est en général plus long que de trier un tableau

personellemnt, je pense toujours que LE critère déterminant
entre un arbre et une table de hachage, c est la capicité d avoir une  
fonction de hachage qui soit correcte (traitement des collisions)
 
or la fonction de hachage dépend des valeurs de ta table

ok, on vous rappellera si tous les autres sont morts.

Les éménems pardon ...  
 
Serieu, j'ai un pote qui a passé un entretien et il a eut ça comme question genre comment ils font les éménems pourqu'ils soient aussi ronds et qu'il n'y est pas de trace de moule ... j'ai pas trouvé et mon pote non plus  ( il a pas été embauché pour d'autres raisons je pense )

 
C'est pour chopper le max en O(1) quoi ... quand on en a besoin souvent ca peut etre pratique en effet.
 
Et les LinkedHashSet ca s'emploi souvent ?

 
Éventuellement si le but de la question c'est de voir si le candidat a de l'imagination pourquoi pas. De toute façon je ne pense pas qu'il y ait une "bonne réponse" et je doute que la personne qui la pose en sache beaucoup plus sur la question..  
 
Intérêt pas bien grand. En 3/4 d'heures d'entretien, tu dois faire un choix de questions, alors tu peux essayer de dresser le profil psychologique de la personne en face mais sachant que tu n'es pas toi-même psychologue je ne pense pas que ça ira bien loin..  
 
Ou alors tu peux essayer de voir comment elle se débrouille sur des problèmes réels, à quel point elle a été formée ou s'est informée sur son domaine et si l'expérience mise sur le CV correspond à des connaissances acquises et non pas bidon ("j'ai fait beaucoup de C++", "pouvez vous m'écrire un cas d'utilisation d'une fonction virtuelle ?", "une quoi ?" ).
 
Si les gens posent toujours les mêmes questions genre "quel a été ton pire bug ?", alors les candidats peuvent s'y préparer et ça va être le test de celui qui tchatche le mieux (à défaut d'avoir vraiment eu un bug intéressant comme d'avoir fait sauter la fusée ariane, là ça en ferait des choses à raconter à ses petits enfants).  
 
Je sais c'est pour ça que je suis ingénieur et pas rh..
 
LeGreg

 
merci blanche neige je me coucherai en nain moins con ce soir

 
C'était un entretient d'embauche chez Microsoft, qui durais plus d'une demi-journée (à la suite d'une heure d'entretien au téléphone en anglais) et je peux t'assurer que  l'embauche la bas ne se fait pas par une équipe de geek mais par des gars bien avertis.
 
Le profil psychologique ? ca ne sert à rien d'aller aussi loin, mais il peut être important de connaitre le temperament d'une personne quand elle est confrontée a un problème qui éventuellement dépasse ses capacités, voir sa premiere réaction etc ...
Donc ce genre de questions ( il y en a eut une dizaine éparpillés parmi des questions plus axé infos genre pourquoi java ou C++, des question d'algos etc ... )  peut avoir son importance.

À mon avis, donner au candidat un morçeau de code C++ à corriger est sûrement le test le plus complet: lecture de code, compréhension de l'algorithme, aptitude à reprendre un travail, connaissance algorithmique pour corriger, et codage C++.
 

Vous dites tous plus ou moins la même chose: l'arbre est une structure ordonnée, la table de hachage non.
Les LinkedHashSet s'emploient quand tu a besoin de parcourrir tous les éléments dans un ordre qui ne dépend pas d'une clé.
 

Ça me rappelle l'IUT info, on faisait des concours de recherches pendant l'interclasse. Quelqu'un choisissait une question, de préférence un truc hyper compliqué, donnait le top, et les autres se ruaient sur leur claviers
 
Question: vous faites quoi quand google ne trouve pas le résultat?

j'utilise le téléphone et des bouquins. Si c'est vraiment la merde, j'ai quelques amis dans des secteurs intéressants.