Quels signes permettent de déceler un candidat talentueux ?

[jouana]

Le problème vient du niveau, de la logique et de la façons de faire qui différent entre les individus.

Et la dessus je rejoins topdawg, même si un code se suffit ce n'est pas une raison de ne pas le documenter, le passage d'informations est primordial et sans documentation tu risque de passer à coté de beaucoup de choses.

Le soucis qui ressort le plus est la variable temps plus qu'une faiblesse dans la langue française.

J'ai eu le cas du code propre se suffit à lui même il n'y a pas longtemps, je n'accepte toujours pas l'idée et si ont me bloque sur mon temps de travail pour faire la documentation je pense le faire sur mon temps libre.

Pour le code propre personnellement, je découpe au maximum mon code dans le but d'avoir un code propre, souple mais je reconnais qu'il n'est pas toujours d'une lisibilité absolu.

En plus c'est toujours sympas d'avoir une phrase pour expliquer le traitement plutôt que de se taper X ligne de code pour assimiler la logique du code afin de dire ça fait ça, c'est une grosse perte de temps (d'argent) si tu fais le cumule de cette activité sur plusieurs moi en plus du code que tu lis pour rien.

Sans oublié que le code dans le temps avec le nb de gens à passer dessus ça vieilli super mal.

[Mat.M]

Envoyé par topdawg

@Mat.M:
Ça ne m'étonne pas que t'arrives à comprendre. D'abord, j'ai écrit
(plus court chemin, Dijkstra… c'est un peu immédiat. En l'occurrence, dans mon cas, c'est une version particulière de l'algorithme que j'applique).

je croyais que le forum de developpez.net était un espace d'expression cordial
Or il faut toujours que des personnes s'irritent sur ce forum je n'arrive pas à comprendre cela...


ensuite mea culpa comme tu as écris un long texte j'ai zappé je n'ai pas lu que tu voulais faire un tel algorithme donc j'ai vu juste..
Donc ne pas s'énerver comme ça,on se détend et on échange avec courtoisie
Moi je prends plaisir à lire les interventions sur ce forum malheureusement il faut toujours que des personnes s'énervent.

[pmithrandir]

Envoyé par jouana

En plus c'est toujours sympas d'avoir une phrase pour expliquer le traitement plutôt que de se taper X ligne de code pour assimiler la logique du code afin de dire ça fait ça, c'est une grosse perte de temps (d'argent) si tu fais le cumule de cette activité sur plusieurs moi en plus du code que tu lis pour rien.

En fait, dans mon expérience, j'ai croisé 3 ou 4 methodes qui étaient complexes à comprendre, a cause de spécificité métiers le plus souvent. (par exemple, dans tel cas, attribuer un code 0, parce que c'est la loi, point. Pas de logique la dedans)

le plus souvent, le nom de la méthode m'aide bien plus qu'un français souvent incompréhensible(on parle de code imbuvable, mais de la doc, souvent c'est pas mal non plus).

getCodeFournisseur($label) est pour moi aussi parlant que :

Code :

1
2
3
4
5
//Cette méthode va vous retourner le code fournisseur en fonction du label.
getCodeF$value){
...
}

En plus, cerise sur le gateau, je n'ai meêm pas besoin d'ouvrir le fichier pour comprendre ce qu'elle fait. Et si je dois la modifier, j'ai 10 lignes de code à lire, et même avec de la doc, je devrais les lires.

le seul cas, en dehors du business ou je trouve la doc nécessaire, c'est quand on décide d'un comportement arbitrairement. Il faut alors expliquer pourquoi on a fait ce choix et ce que ca implique.

[ManusDei]

Personnellement je vois suffisamment de macros et fonctions en code assembleur pour penser que l'absence ou le peu de commentaires... c'est une chose qui ne devrait pas exister et dont l'auteur doit être ERADIQUE A LA TRONCONNEUSE RAAAHHHHHHAHHAAHAHAH

Pareil pour les fonctions C bas-niveau qui communiquent souvent directement avec le hardware, et où on place les bits un à un sur les registres physiques.

PS : Je sais que c'est une branche particulière de l'informatique.

[souviron34]

Envoyé par ManusDei

Pareil pour les fonctions C bas-niveau qui communiquent souvent directement avec le hardware, et où on place les bits un à un sur les registres physiques.

PS : Je sais que c'est une branche particulière de l'informatique.

C'est vrai que c'est un champ particulier, mais j'ai également en horreur les codes avec des shifts de bits ou des assignations ou tests en hexa sans aucune explication à côté...

Ces codeurs devraient effectivement être passés à la tronçonneuse

[pmithrandir]

Je comprend mieux votre point de vue

Pour moi, le code est très verbeux, et si les noms de méthodes sont explicites, souvent le commentaire est plus une gène qu'autre chose(entre autre parce qu'il fait doublon et prend de la place en empêchant de lire la méthode sans "scroller".

Mais effectivement, si quelqu'un me rend un truc avec des codes hexa sans doc, je le passe au marteau piqueur !!!

[Bluedeep]

Envoyé par pmithrandir

prend de la place en empêchant de lire la méthode sans "scroller

Passer l'écran en mode portrait.

[el_slapper]

Envoyé par Bluedeep, portraitiste

Passer l'écran en mode portrait.

C'est un classique. Comme de toutes façons une ligne longue est assez difficille à lire... mon écran du boulot est en portrait(900*1440), pas pour cette raison, mais ça me donne aussi une meilleur vision sur les paragraphes qui s'enchainent.

ça a aussi ses défauts(les specs arrivent souvent sur des excel qui s'étalent en largeur, et je scrolle beaucoup horizontalement), mais c'est à essayer.

[Nasky]

Dans mon domaine (finance), on cherche surtout des gens capables de réfléchir et apprendre vite. Ce qu'on sait au moment de l'entretien n'est pas le plus important. Bien que je ne sois pas dans le domaine de l'IT pur, les entretiens où on pose des questions d'informatique sont fréquents.

Et en général, ce sont des questions pour voir comment le candidat réfléchit. 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. Ensuite viennent des questions du type écrire un code qui mélange aléatoirement des chiffres d'un tableau, déterminer sa complexité, prouver qu'on ne peut pas trouver un algo de tri meilleur qu'une certaine complexité (nlog(n) par exemple), etc.

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.

C'est pour cette raison, qu'en plus des codes orientées logiques, ils posent surtout des questions de maths logiques. Des questions de probas, des énigmes, etc.

Ce genre d'entretien est très fréquent chez les grandes entreprises comme Google, IBM, Amazon... Etre un "pisseur de code" n'est pas ce qu'ils recherchent. Ils veulent quelqu'un capable d'innover, d'apprendre rapidement et d'apporter des idées nouvelles.

[deadalnix]

Envoyé par Nasky

Et en général, ce sont des questions pour voir comment le candidat réfléchit. 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.

Memoize ?

Envoyé par Nasky

Ensuite viennent des questions du type écrire un code qui mélange aléatoirement des chiffres d'un tableau, déterminer sa complexité, prouver qu'on ne peut pas trouver un algo de tri meilleur qu'une certaine complexité (nlog(n) par exemple), etc.

radix ?

Envoyé par Nasky

Ce genre d'entretien est très fréquent chez les grandes entreprises comme Google, IBM, Amazon... Etre un "pisseur de code" n'est pas ce qu'ils recherchent. Ils veulent quelqu'un capable d'innover, d'apprendre rapidement et d'apporter des idées nouvelles.

Je ne pense pas non. Chez google, amazon et co, ils connaissent les deux éléments su-cités.

Note que je suis tombé en entretiens (en tant que candidat) sur gens qui pensaient que n*log(n) était une limite pour les tris, ça fait très mauvais genre.

[ulspider]

Envoyé par Nasky

Et en général, ce sont des questions pour voir comment le candidat réfléchit. 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. Ensuite viennent des questions du type écrire un code qui mélange aléatoirement des chiffres d'un tableau, déterminer sa complexité, prouver qu'on ne peut pas trouver un algo de tri meilleur qu'une certaine complexité (nlog(n) par exemple), etc.

Eh bien je suis rapidement recaler

Ce qu'il faut comprendre aujourd'hui c'est que ce n'est pas l'information qui est importante mais la rapidité avec laquelle on l'a trouve.

L'exemple de Fibonacci que tu cites est relativement ridicule. A part d'avoir travailler ou étudier les techniques d'optimisation du calcul de cette suite, tu ne peux pas répondre à cela en entretien.

En entretien, je poserai plutôt des questions sur les technologies, en rebondissant notamment sur l'expérience professionnel de la personne (pour une personne expérimentée) ou sur des questions de cours pour un jeune diplômé, sans rentrer dans des détails.

[el_slapper]

Envoyé par ulspider

Eh bien je suis rapidement recaler

Ce qu'il faut comprendre aujourd'hui c'est que ce n'est pas l'information qui est importante mais la rapidité avec laquelle on l'a trouve.

ça dépend.....

Envoyé par ulspider

L'exemple de Fibonacci que tu cites est relativement ridicule. A part d'avoir travailler ou étudier les techniques d'optimisation du calcul de cette suite, tu ne peux pas répondre à cela en entretien.

le role d'un fizzbuzz, d'une Fibonacci ou d'une question de ce genre n'est pas de déterminer si la personne connait la fonction(d'ailleurs, idéalement, on modifie un peu l'énonçé standard pour avoir un truc un peu original), mais de voir si elle sait coder un algo quelqconque(parcequ'à un moment ou à un autre, on a toujours besoin d'algorithmiqye).

Envoyé par ulspider

En entretien, je poserai plutôt des questions sur les technologies, en rebondissant notamment sur l'expérience professionnel de la personne (pour une personne expérimentée) ou sur des questions de cours pour un jeune diplômé, sans rentrer dans des détails.

Donc, mieux vaut une tête bien pleine qu'une tête bien faite?

Je ne sais plus ou j'ai vu un truc que j'expérimenterais bien si j'avais à recruter - et les moyens de le faire : trouver un langage que l'interviewé ne connait pas, puis lui demander une tâche simple dans ce langage(doc disponible, évidemment). Là, je sais que la personne sait s'adapter. Ou pas.

[ulspider]

Envoyé par el_slapper

ça dépend.....



le role d'un fizzbuzz, d'une Fibonacci ou d'une question de ce genre n'est pas de déterminer si la personne connait la fonction(d'ailleurs, idéalement, on modifie un peu l'énonçé standard pour avoir un truc un peu original), mais de voir si elle sait coder un algo quelqconque(parcequ'à un moment ou à un autre, on a toujours besoin d'algorithmiqye).



Donc, mieux vaut une tête bien pleine qu'une tête bien faite?

Je ne sais plus ou j'ai vu un truc que j'expérimenterais bien si j'avais à recruter - et les moyens de le faire : trouver un langage que l'interviewé ne connait pas, puis lui demander une tâche simple dans ce langage(doc disponible, évidemment). Là, je sais que la personne sait s'adapter. Ou pas.

Pour Fibonacci, je suis d'accord avec toi sur le fait que c'est une bonne question si l'on demande à la personne de coder avec un algorithme quelconque mais comme le dis Nasky, lui s'attend à avoir un algorithme optimisé et tu ne peux pas en entretien demander cela.

Si je cherche un ingénieur, je cherche à la fois une tête bien faite et une tête pleine. C'est d'ailleurs pour ça que je préfère laisser la personne présenter son expérience (voir un peu ce qu'elle a fait) et rebondir sur son expérience afin de lui poser des questions techniques dessus (pour tester la tête pleine), et en bonus des questions "jackpot" qui sorte un peu de ce cadre (tête bien faite), mais toujours en rapport avec son expérience.

[Glutinus]

Envoyé par el_slapper

le role d'un fizzbuzz, d'une Fibonacci ou d'une question de ce genre n'est pas de déterminer si la personne connait la fonction

Le FizzBuzz, c'est pas éliminatoire, si on connaît la réponse ?

- Êtes-vous capable de me citer le n-ième élément d'une suite de Fibonacci ?
- Heu...
- Et connaissez-vous le FizzBuzz ?
- Ha oui, ça c'est un jeu à se bourrer la gueule où il faut dire Buzz quand... quand... heu... Pourquoi avez-vous l'air consterné tout d'un coup ?

[gl]

Envoyé par deadalnix

Memoize ?

Ou sous forme récursive terminale.

[deadalnix]

Envoyé par ulspider

L'exemple de Fibonacci que tu cites est relativement ridicule. A part d'avoir travailler ou étudier les techniques d'optimisation du calcul de cette suite, tu ne peux pas répondre à cela en entretien.

Si tu ne sais pas programmer une suite de fibonacci, ni voir que la solution naïve à une complexité abhérante, ne blame pas la recruteur. C'est un problème simple, que tu dois pouvoir résoudre même si tu ne connais pas le problème. C'est un problème simple, mêm si on ne le connais pas.

Envoyé par gl

Ou sous forme récursive terminale.

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.

[nfluch]

Envoyé par Nasky

Et en général, ce sont des questions pour voir comment le candidat réfléchit. 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. Ensuite viennent des questions du type écrire un code qui mélange aléatoirement des chiffres d'un tableau, déterminer sa complexité, prouver qu'on ne peut pas trouver un algo de tri meilleur qu'une certaine complexité (nlog(n) par exemple), etc.

pas mal, ça permet d'éliminer les personnes qui veulent absolument résoudre un problème simple de manière complexe
par contre si la personne ne souvient plus de ce qu'est la suite de fibonacci il y a un cours de rattrapage avant le bout de code ?

[edit]
comme bout de code je verrais plutôt un diagramme de bifurcation par contre
même type qu'une suite donc la recursivité est éliminatoire
et ça permet aussi de voir si le candidat utilise des objets ou des structures spontanémment

[Nasky]

Envoyé par deadalnix

Je ne pense pas non. Chez google, amazon et co, ils connaissent les deux éléments su-cités.

Note que je suis tombé en entretiens (en tant que candidat) sur gens qui pensaient que n*log(n) était une limite pour les tris, ça fait très mauvais genre.

Si, ce sont des questions posées chez Google et Amazon, entres autres. Ils posent des questions élémentaires comme des questions de logique poussées. Il faut également différencier selon le niveau du poste...

Pour le tri, c'est une question de chez Google justement... Le but n'est pas de dire que c'est une limite (ça ne l'est pas en effet) mais de faire une démo qui tient la route.

[pmithrandir]

J'avoue que si on me demandait la suite de Fibonacci, déjà, il faudrait me l'expliquer... au bout de 30 secondes, comme ce qui vient de se passer sur wikipedia, j'en aurait plus rien a faire de l'entretien et j'aurai qu'une envie, me lever et partir.
- Je pige plus rien aux suites après 10 ans sans faire de math.
- je penserai que mon recruteur est un crétin de mathématicien.

A coté de ca, si vraiment j'avais faim, je resterai peut être et je sortirai l'algo de base, je ne pense pas qu'on puisse demander plus a quelqu'un en entretien qui en connait pas déjà le problème, et donc sa solution(parce que c'est le risque, de finalement ne retenir que ceux qui ont appris par cœur la solution ou qui ont vu en cour qu'il y avait un piège).

Après, si on compare ça a fizzbuzz, c'est le jour et la nuit, on a un algo débile, digne d'un étudiant après 3 cours d’algorithmique, et que je sache, pas spécialement optimisable. J'en ai vu des dizaines de versions en entretien, et ca tourne toujours autour des même façon de faire, très proche de la solution intuitive.

La seule chose que l'on teste la, c'est la capacité a comprendre que le cas fizzbuzz doit être traité avant fizz ou buzz si on veut qu'il soit pris en compte... et encore.

De la même façon, la complexité d'un algorithme, je n'en ai jamais eu besoin encore. Parce que des algo j'en ai pas beaucoup écrit de bien complexe... $
En général, ce qui rame le plus, c'est la BDD, puis la machine trop lente, et ensuite seulement on regarde l'algo, on vérifie si on ne calcule pas n fois la même valeur pour rien(extraire les "constantes" des boucles) et on arrive a un résultat suffisant d'un point de vue performance pour le besoin.

Après, vous travailler peu être a créer le cœur du moteur oracle, ou avec plusieurs milliards de valeur, etc... mais moi je n'ai pas encore eu cette chance.

En général, en informatique, ce que j'observe, c'est que si la solution requiert des compétence avancée en algorithmique, c'est souvent la plus mauvaise en terme de cout.

[gangsoleil]

Demander de pondre un algorithme, ca denote la tete bien pleine, pas bien faite. De meme pour la demonstration sur la limite du tri.

Tout ca, ce sont des questions de forme, qui permettent de savoir si la personne a bien revise son cours sur Fibonacci ou pas, mais qui ne vous dira absolument pas si la personne est competente dans son domaine. D'ailleurs, vous avez tous recrute de bons mathematiciens, c'est bien, je vous les laisse, moi je cherche des informaticiens.

Et d'ailleurs, c'est bien la qu'est le probleme : les tests ne sont quasiment jamais adaptes aux postes :
Qsort est, dans la plupart des cas, en N log(N). Mais il ne faut pas oublier que sur des entrees deja triees, on est en N2, et que c'est pour ca que, dans les vrais codes de la vraie vie, il est conseille de faire un random sur les entrees -- la probabilite d'obtenir des donnees triees etant tres faible.

Si le candidat connait ce point particulier, vous avez affaire a une personne qui a deja eu des problemes de performances lors de l'utilisation d'un qsort ; si c'est ce que vous recherchez, c'est un bon candidat ; sinon, poser cette question ne vous apporte pas grand chose.

Poser des questions intelligentes est complexe, mais si au moins elles etaient adaptees au poste, ca serait deja beaucoup.