Quels signes permettent de déceler un candidat talentueux ?

[Luckyluke34]

Envoyé par Elbarto

si je veux employer un maçon je ne vais pas lui demander de construire un mur devant moi avant de l'embaucher, il a déjà un diplôme, peut-être un vécu, c'est un peu insultant de demander à quelqu'un de justifier de ses compétences via des tests, donc un programmeur très talentueux ressentira probablement le même sentiment d'inutilité de ces tests

Je me demande bien comment tu peux vérifier le talent de quelqu'un sans le voir à l'oeuvre.

Quand on postule pour travailler dans une organisation, il est absolument normal et pas "insultant" de se plier à quelques tests pour vérifier qu'on est bien compatible avec cette organisation et qu'on s'intègrera dans son environnement de travail sans problème.

Ce n'est pas d'une surabondance de tests de recrutement techniques dont les entreprises souffrent aujourd'hui mais bien d'un manque de ces tests à mon avis. Bien souvent ils se déroulent à l'oral, et un candidat qui aura révisé ses classiques passera la barrière sans problème sans que le recruteur ait vu une ligne de code à lui, ce qui est quand même un comble.

Certes, la période d'essai peut constituer une deuxième barrière, mais il me semble que la longue durée des périodes d'essai actuelles (bien souvent 4 mois + 3) encourage bien plus leur utilisation comme un outil de flexibilité (je t'embauche et je te jette quand la mission est finie) que comme une possibilité de corriger une erreur de recrutement après quelques semaines.

[sevyc64]

Envoyé par Luckyluke34

Ca dépend du problème en fait. S'il est simple, c'est faisable.

En 2h ? Faire tout ce qui est demandé ?
Je pense que tu peux te limiter à écrire une fonction qui additionne 2 nombres et retourne le résultat.

Envoyé par Luckyluke34

Pas d'accord. Ecrire du code lisible, documenté, que les autres développeurs comprennent est un talent aussi, et tout le monde est loin de l'avoir. 99% des entreprises ont besoin de ce genre de développeur bien plus que d'un génie qui serait incapable de communiquer l'intention de ce qu'il développe. Il ne faut pas oublier que tôt ou tard, le code sera repris par quelqu'un d'autre.

99% des entreprises en ont besoin, moins de 40% en ont conscience, encore moins le demande réellement et quasiment aucune ne t'accorde suffisamment de temps pour le faire réellement.
Et je fait l'impasse sur celles qui s'en foutent volontairement.

[Luckyluke34]

Envoyé par moustic98

Pas d'accord avec la correspondance immédiate que tu lie systématiquement à un génie, en affirment qu'il serai incapable de produire un travail de qualité, reste toujours que le génie est connu pour réaliser ce que la majorité des mortels ne comprenne même pas, et à ce moment la, il bénéficiera d'une confiance aveugle de la part de ces supérieurs car il fait ce que personne n'a réussi à faire avant lui, et ça aussi c'est un profile indispensable pour innové face à ces concurrent

Je n'ai pas dit que tous les génies étaient des autistes, mais il n'y a pas de raison qu'ils aient plus de talent pour travailler en équipe que le reste de la population (à moins que ce ne soient des génies de la communication, mais c'est autre chose...)

Après, à combien estimes-tu la population des "génies" parmi les développeurs ? 2, 3, 5% ?

Je ne vois pas vraiment ce qui vient invalider les arguments de l'article d'origine sachant que le titre est "hire a developer" et pas "hire a genius"

[spyserver]

J'ai l'impression que ce débat laisse entrevoir les "pro génie" utopistes et les plus pragmatiques, en vérité j'ai bien compris que la cause de ces malentendus provient du titre de l'article qui est tout simplement maladroit, "talentueux" n'est effectivement pas le terme adapté pour le profil recherché par ce messieur.En revanche dire que le dev. doit avoir de la liberté etc. pour laisser libre cours à son génie, c'est tout simplement utopique, comme c'est dit dans un com' plus haut, le génie c'est aussi d'être compris par tous ce qui est loin d'être le cas de tout le monde y compris les têtes !

D'ailleurs,pour l'anecdote, ds ma propre équipe, un consultant avait pour habitude de "loger" des traitements ds les accesseurs de ses classes, je n'avais jamais vu cette pratique et un jour, en faisant une analyse sur un bug, j'ai mis un certain tps à trouver le traitement ds le getter, et pourtant ce mec était très compétent, mais il avait une façon bien singulière de coder ... pas très mainstream disons ...

[gangsoleil]

Envoyé par Luckyluke34

Quand on postule pour travailler dans une organisation, il est absolument normal et pas "insultant" de se plier à quelques tests pour vérifier qu'on est bien compatible avec cette organisation et qu'on s'intègrera dans son environnement de travail sans problème.

Repondre a quelques questions, pourquoi pas. Mais de la a passer 7 ou 8 entretiens avec autant de personnes differentes, dont certains entretiens techniques sur 2 ou 3 heures, non. Or on voit de plus en plus ce genre d'aberrations.

Envoyé par Luckyluke34

Ce n'est pas d'une surabondance de tests de recrutement techniques dont les entreprises souffrent aujourd'hui mais bien d'un manque de ces tests à mon avis. Bien souvent ils se déroulent à l'oral, et un candidat qui aura révisé ses classiques passera la barrière sans problème sans que le recruteur ait vu une ligne de code à lui, ce qui est quand même un comble.

Un bon test a l'oral, ca ne dure pas plus d'une heure, et je te promets que tu auras beau reviser, tu ne passeras pas si tu n'as pas les connaissances. Mais ca demande 3 personnes techniques et competentes de l'entreprise, ce qui est tout a fait trouvable, mais que peu d'entreprises sont disposees a laisser faire.

Envoyé par Luckyluke34

Certes, la période d'essai peut constituer une deuxième barrière, mais il me semble que la longue durée des périodes d'essai actuelles (bien souvent 4 mois + 3) encourage bien plus leur utilisation comme un outil de flexibilité (je t'embauche et je te jette quand la mission est finie) que comme une possibilité de corriger une erreur de recrutement après quelques semaines.

C'est effectivement comme ca que sont vues les periodes d'essai en France, du moins de plus en plus, malheureusement. Alors que cette periode ultra-longue de 7 mois (beaucoup plus longue que dans les pays dits "liberaux", dans lesquels le salaire est beaucoup moins protege) devrait ne servir qu'a valider, ou infirmer, les impressions de l'entretien d'embauche.

[Freem]

Envoyé par sevyc64

Surtout écrire une doc complète, en 2h, tu écris à peine le sommaire !

Il n'est nulle part question de "doc complète" mais de "javadoc complète".
La différence est de taille pour moi, parce que écrire:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Foo
{
public:
void FooBar(std::string const &foo) const throw();
private:
int m_bar;
};

/**
 * Do something with bar
 * \param foo some useles string
 * \return nothing, can't you see that it's void?
 * \throw I said, NOTHING!
 */
void Foo::FooBar(std::string const &foo) const throw()
{
return;
}

(Bon, ok, sans le côté humoristique qui montre mon grand manque d'imagination pour les exemples bidon...)

Au lieu de ceci:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
class Foo
{
public:
void FooBar(std::string const &foo) const throw();
private:
int m_bar;
};

void Foo::FooBar(std::string const &foo) const throw()
{
return;
}

Bah, franchement, c'est pas bien long. Surtout que les IDE modernes ajoutent d'eux-même le plus gros, et il n'y a plus qu'a compléter. En fait, ce type de commentaires remplace ceux que l'on colle dans le code, surtout couplés à des noms parlants.
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.

Pour le reste, les tests unitaires, je ne sais simplement pas les faire, mais c'est certain qu'avec des tests le coût immédiat est plus élevé. Du coup, pas bon pour les SSII, puisqu'elle ne peuvent plus vendre de corrections
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.
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.

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.
Et on ne mesure pas la motivation par un test de code.

[erwanlb]

Envoyé par Luckyluke34

Je me demande bien comment tu peux vérifier le talent de quelqu'un sans le voir à l'oeuvre.

Quand on postule pour travailler dans une organisation, il est absolument normal et pas "insultant" de se plier à quelques tests pour vérifier qu'on est bien compatible avec cette organisation et qu'on s'intègrera dans son environnement de travail sans problème.

Ce n'est pas d'une surabondance de tests de recrutement techniques dont les entreprises souffrent aujourd'hui mais bien d'un manque de ces tests à mon avis. Bien souvent ils se déroulent à l'oral, et un candidat qui aura révisé ses classiques passera la barrière sans problème sans que le recruteur ait vu une ligne de code à lui, ce qui est quand même un comble.

Certes, la période d'essai peut constituer une deuxième barrière, mais il me semble que la longue durée des périodes d'essai actuelles (bien souvent 4 mois + 3) encourage bien plus leur utilisation comme un outil de flexibilité (je t'embauche et je te jette quand la mission est finie) que comme une possibilité de corriger une erreur de recrutement après quelques semaines.

Si on met tout le monde à "égalité" en ce qui concerne un recrutement (autant pour celui qui cherche un boulot que pour le recruteur), il n'y a pas de tests à passer car il y a quantité de boulot où tu ne peux pas appliquer des tests "grandeur nature"...

[Luckyluke34]

Envoyé par gangsoleil

Repondre a quelques questions, pourquoi pas. Mais de la a passer 7 ou 8 entretiens avec autant de personnes differentes, dont certains entretiens techniques sur 2 ou 3 heures, non. Or on voit de plus en plus ce genre d'aberrations.

Entièrement d'accord. Mais je ne vois pas où on parle de 7 ou 8 entretiens dans l'article, il est juste question d'un entretien de 2 heures.

Envoyé par gangsoleil

Un bon test a l'oral, ca ne dure pas plus d'une heure, et je te promets que tu auras beau reviser, tu ne passeras pas si tu n'as pas les connaissances. Mais ca demande 3 personnes techniques et competentes de l'entreprise, ce qui est tout a fait trouvable, mais que peu d'entreprises sont disposees a laisser faire.

Tout à fait, et j'ai vu (et passé) des tests comme ça, mais pour moi ce n'est pas assez. Entre autres, ça n'en révèle pas suffisamment sur la façon de développer du candidat, à moins de le faire coder "à l'oral" ce qui est peu pratique.

[erwanlb]

Envoyé par Luckyluke34

Entièrement d'accord. Mais je ne vois pas où on parle de 7 ou 8 entretiens dans l'article, il est juste question d'un entretien de 2 heures.


Tout à fait, et j'ai vu (et passé) des tests comme ça, mais pour moi ce n'est pas assez. Entre autres, ça n'en révèle pas suffisamment sur la façon de développer du candidat, à moins de le faire coder "à l'oral" ce qui est peu pratique.

Vouloir aller plus loin c'est pour trouver le bon mec qu'il faut ou pour pallier aux faiblesses du recruteur et/ou au manque de prise de risque de la boite ?

J'ai l'impression qu'on met les faiblesses de la boite directement sur le dos du mec qui cherche un boulot sans même être pris pour le poste...

C'est à l'image, dans l'industrie, de la prise de responsabilité croissante des "ouvriers" qui ont comme responsable des personnes de moins en moins responsables...

[sevyc64]

Envoyé par Freem

Il n'est nulle part question de "doc complète" mais de "javadoc complète".

Je ne l'invente pas, c'est écrit noir sur blanc :

2. They write full documentation

Certes il rajoute dans le texte

...that he created full Javadoc and comments for his code...

Je suis d'accord avec toi, ce n'est pas la même chose.
Au mieux l'auteur ne s'y connais finalement pas tant que ça, au pire, il nous induit volontairement en erreur en mélangeant les choses et ne cherche finalement qu'à faire du sensationnel.

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.

Moi ça ne me choque pas.
Si ta conception est correctement faite tu dois pouvoir écrire le squelette complet de ton application, ses principales méthodes notamment les publiques et leurs signatures sans avoir même commencer à penser ne serait-ce qu'à ce que serait ensuite le code à l'intérieur. Sauf à rencontrer des problèmes majeurs, ou à avoir une évolution du cahier des charges, une conception bien faite ne devrait pas avoir à évoluer en cours de développement.

C'est généralement comme ça que je travaille, lorsque le temps me le permet et que la conception est suffisamment détaillée et pertinente. J’écris mon squelette avec toutes mes méthodes et leur signatures en partant des fonctions macro et allant vers les micro. Quant au code, après vérification du squelette, je le fais en sens inverse, du micro vers le macro.
A mon sens, ça permet d'avoir déjà figer 99% de la structure lorsqu'on commence le code, d'avoir bien en tête cette structure et de ne pas partir dans tous les sens au niveau code.

Envoyé par Freem

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.

D'autant plus, qu'à mon avis, refactoriser le code ne doit pas être un but absolu. Ce n'est pas toujours (voire pas souvent) la solution idéale.
Il faut connaitre et "sentir" la totalité du code pour savoir là ou il est utile et nécessaire de factoriser et là ou il est judicieux et intelligent de s'abstenir.
Et tout cela, de l'étude, la conception, le codage puis la doc, quelque soit le projet, ça prend bien plus de 2H.

[Luckyluke34]

Envoyé par sevyc64

D'autant plus, qu'à mon avis, refactoriser le code ne doit pas être un but absolu. Ce n'est pas toujours (voire pas souvent) la solution idéale.
Il faut connaitre et "sentir" la totalité du code pour savoir là ou il est utile et nécessaire de factoriser et là ou il est judicieux et intelligent de s'abstenir.

C'est un peu ce que dit l'article :

This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship).

Envoyé par sevyc64

Et tout cela, de l'étude, la conception, le codage puis la doc, quelque soit le projet, ça prend bien plus de 2H.

Je crois qu'il y a malentendu sur le contenu de ces tests. Comme l'a dit Freem, il s'agit de Javadoc, pas de doc complète au sens document formel rédigé de toutes pièces. Et il n'est pas fait mention d'une phase d'étude préalable.

Il s'agit bien évidemment de problèmes qui tiennent en 2 heures. Un développeur expérimenté peut écrire les tests, le code et la javadoc d'un problème type calcul de scores de bowling ou Conway's game of life en 2 heures. Un développeur plus débutant peut écrire les tests, le code et la javadoc d'un problème type suite de Fibonacci ou calcul de réductions sur des produits en 2 heures, et en proposer plusieurs implémentations.

a number of small problems to solve

On ne demande bien sûr pas au candidat de réaliser un mini-projet de bout en bout avec un dossier d'analyse, de conception, une interface graphique hyper léchée...

[pseudocode]

Je me demande s'il a, ne serait-ce qu'une fois, rencontré un candidat qui répondait à tous ses critères.

Ca m'a plutôt l'air d'être la wishlist de son candidat idéal... ou, à l'inverse, une critique déguisée sur les candidats actuels qu'il rencontre.

[Nemek]

Comme beaucoup l'ont mentionné ici, je pense que ce sont pas nécessairement de bons critères pour pêcher un "bon développeur". A la rigueur un bon relecteur, ou un ingénieur qualité.

Plutôt que de dire que "99% des entreprises n'ont nécessairement besoin d'avoir de bon développeur", je dirai plutôt que "100% des entreprises ont besoin de faire de l'argent". Et, par expérience, je suis pas sûr que passe pas par quelqu'un de très méticuleux. En revanche, quelqu'un qui saura quand il faut l'être, et quelqu'un qui saura l'être (encore mieux si c'est la même personne), pourra faire gagner plus d'argent à une boîte.

La discussion rejoint ce fil : http://www.developpez.net/forums/d12...t-developpeur/

[gene69]

est ce qu'on peut demander à une entreprise de payer le candidat pour tester les fonctions administratives de celle-ci ?

[moustic98]

Envoyé par gene69

est ce qu'on peut demander à une entreprise de payer le candidat pour tester les fonctions administratives de celle-ci ?

Le cv doit faire largement fois, et si on doit être ammené a faire valoir toutes notre vie nos compétance aquise durant tous notre cursus, je considère cela comme ignoble et grotesque, l'entreprise n'a aussi qu'a avoir des personne plus qualifier pour faire passer les entretien opérationnel, car il lui suffirait de poser deux ou trois question plutôt qu'un teste qui ne reflette rien, sauf à démontrer au recruteur jusqu'où ira ce candidat en terme de respect des ordre et en terme d'adaptabilité, il doit pouvoir réparer Intenet si demain y en avais plus au siège

[gangsoleil]

Envoyé par Luckyluke34

Entièrement d'accord. Mais je ne vois pas où on parle de 7 ou 8 entretiens dans l'article, il est juste question d'un entretien de 2 heures.

Non, d'un test technique de 2 heures si je ne me trompe pas. Ce qui aurait tendance a faire penser soit a un entretien particulierement long (bla bal de debut, debriefing de fin, tu ne t'en tires pas a moins de 3h30 ou 4h), soit a une multitude d'entretiens, et j'ai remarque que ca va souvent de paire.

[djnos]

Clair qu'il a intérêt d'avoir fini le code du test avant d'en proposer la doc, parce que là on peut s'interroger sur ses compétences à respecter des délais et surtout à se concentrer sur les priorités business.

Les tests et la doc, c'est super, mais cela a un coût à prendre en compte dans la réalisation du projet : la condition est donc qu'on nous en donne les moyens.

Par ailleurs une doc sur une api paraît essentielle, une phpdoc sur un domaine en particulier au sein d'une appli web l'est peu être un peu moins, cela est aussi valable pour les tests.

[kolodz]

Envoyé par djnos

Clair qu'il a intérêt d'avoir fini le code du test avant d'en proposer la doc, parce que là on peut s'interroger sur ses compétences à respecter des délais et surtout à se concentrer sur les priorités business.

Les tests et la doc, c'est super, mais cela a un coût à prendre en compte dans la réalisation du projet : la condition est donc qu'on nous en donne les moyens.

Par ailleurs une doc sur une api paraît essentielle, une phpdoc sur un domaine en particulier au sein d'une appli web l'est peu être un peu moins, cela est aussi valable pour les tests.

Les entreprises commencent à comprendre qu'un projet informatique ça se voit dans le long termes. Qu'il est probable que la personne qui développe l'application ne soit pas celle qui la maintient. Lors de l’émergence de des projets informatiques, les projets n'étaient pas gérer pour durée dans le temps, mais pour être opérationnel le plus tôt possible. Ce qui est de moins en moins le cas.


Chose que savant les recruteurs, c'est que les génies ça courent pas les rues...
Si un projet est fait par une personne ayant du génie et que celui-ci n'est plus là pour la maintenir. Êtes-vous sûr qu'un développeur lambda sera la maintenir ? (En gros, ce que vous trouvez facilement sur le marché)
Après, cette question posez-vous la même mais avec une développeur moyen qui fait de la doc et des tests.


Pour moi, un application à la conception simple avec de la documentation et des tests ça ressemble à un chef-d’œuvre.
Comme quoi le talant ça se travail !

[Schim59]

Pour débusquer un programmeur au dessus de la moyenne, je pense qu'il faut tester son intelligence en dehors du contexte de programmation.

Commenter un code, rédiger une notice, n'importe qui peut le faire, il suffit de lui demander. C'est peut être à ça que l'on reconnait un bon manager , il formule ce qu'il attend du programmeur.

[Freem]

Envoyé par Schim59

Pour débusquer un programmeur au dessus de la moyenne, je pense qu'il faut tester son intelligence en dehors du contexte de programmation.

Commenter un code, rédiger une notice, n'importe qui peut le faire, il suffit de lui demander. C'est peut être à ça que l'on reconnait un bon manager , il formule ce qu'il attend du programmeur.

C'est complètement faux. Tout le monde ne peut pas rédiger une doc type doxygen correctement, c'est à dire, être extrêmement bref tout en n'omettant rien de ce que fait la fonction.
Accessoirement, pour ce type de doc, il faut être capable de comprendre le code, et c'est aussi pour ça que c'est au développeur qui écrit le code de faire cette portion de doc: il est le mieux placé pour savoir ce que le code fait, et pour y placer des "warning" à destination de l'utilisateur (et ici, par utilisateur, je parle du collègue qui aura a maintenir ou exploiter la fonction lorsque le 1er dev sera en vacance... ou aura changé d'entreprise.)

Quand aux notices, ce n'est pas non plus si simple. En fait, il s'agit même d'un métier, car écrire un texte clair et exempt de fautes n'est pas à la portée de tous, y compris avec les outils dont on dispose de nos jours.
Une preuve?
Je ne quoterait pas de post par respect, mais il suffit de suivre l'actu de dvp pour y trouver nombre de réponses bourrées de fautes, que ce soit d'orthographe, de conjugaison ou, pire, de syntaxe!

Alors non, la doc, ce n'est pas à la portée de tout le monde, et le manager, ce n'est pas non plus son job. En fait, le mot français de manager, c'est gestionnaire. Et ça indique ce qu'est son taf: gérer.
Gérer, ce n'est pas produire. Ecrire une doc, c'est produire.
Et sincèrement, je ne parle que d'écrire correctement. Maintenant, le contraire est vrai aussi: pour écrire une doc, il faut comprendre correctement, et la encore, sur les forums internet, il n'y a pas besoin de chercher longtemps pour trouver des quiproquos, ou des gens qui parlent la même langue mais pas de la même façons (références culturelles changeantes. Par exemple, pour un québecois, un français ou un suisse, il est évident que certains mots n'auront pas la même connotation.)

Envoyé par pseudocode

Ca m'a plutôt l'air d'être la wishlist de son candidat idéal... ou, à l'inverse, une critique déguisée sur les candidats actuels qu'il rencontre.

Non, c'est liste des points qui font que si un candidat en respecte au moins un, il faut lui demander immédiatement de bosser pour vous.
En fait, quelqu'un respectant l'un de ces points sera très probablement, pour l'auteur, d'une grande valeur ajoutée pour l'équipe en place. Il n'est pas dit qu'il faut que le candidat corresponde à tous les points...

Envoyé par moustic98

Le cv doit faire largement fois, et si on doit être ammené a faire valoir toutes notre vie nos compétance aquise durant tous notre cursus, je considère cela comme ignoble et grotesque, l'entreprise n'a aussi qu'a avoir des personne plus qualifier pour faire passer les entretien opérationnel, car il lui suffirait de poser deux ou trois question plutôt qu'un teste qui ne reflette rien, sauf à démontrer au recruteur jusqu'où ira ce candidat en terme de respect des ordre et en terme d'adaptabilité, il doit pouvoir réparer Intenet si demain y en avais plus au siège

Le CV n'est PAS suffisant. Il suffit de regarder dans son entourage pour s'en rendre compte... Ou de faire ces foutus ateliers CV qu'on nous impose quand on tombe au chômage.
Quand on postule pour une boîte, on fait une lettre de motivation qui devrait être ciblée, mais le CV aussi devrait l'être, si le candidat n'est pas fainéant... Ou plutôt s'il veut optimiser ses chances.
Personnellement, je connais plusieurs personnes qui ont eu leur travail actuel ou des contrats passés en mentant sur le CV. Rien de bien grave, juste cacher une période de chômage en prolongeant un contrat fini un peu trop tôt... Mais bon, ça ne reflétait pas la vérité pure. (Et dans le cas auquel je pense, la boîte en question semble y avoir gagné, puisqu'elle n'arrête pas d'augmenter l'individu en question )

Bref, un CV ne suffit en aucun cas.
Autre détail:
Les CV contiennent parfois des noms d'entreprise et d'écoles prestigieuses. Mais, ce n'est pas parce que j'ai bossé 2 ans chez microsoft ou google que j'ai participé a des tâches importantes, et ce n'est pas parce que j'ai eu mon diplôme dans une école à 20k€/mois que j'ai vraiment des connaissances.
Le contraire est tout aussi vrai, d'ailleurs. Le type qui a étudié dans une école minable et bossé dans des petites boîtes peut très bien être super compétent.
Parfois même, certains n'ayant pas de diplômes sont meilleurs que des supers intelligents aux parents bourrés de pognon qui les ont envoyés dans les écoles les plus prestigieuses (comment ça, je donne l'impression que je n'ai pas de respect pour les bouts de papier diplômes de haut niveau?)


Et pour finir ce (long) post, à ceux qui trouvent que la javadoc (ou doxygen ou autre) ne sert à rien...
Personnellement, en écrivant la doc d'une fonction que je viens d'écrire, il m'arrive de souligner des incohérences, que je corrige avant les problèmes, du coup.
Vous savez, c'est le fameux: "ce qui est bien compris est clairement énoncé".
Quand vous commencez à détailler les multiples fonctionnalités d'une seule et même fonction, c'est qu'il faut la découper.
Et en procédant à ce découpage, on augmente:
1) la ré-utilisabilité du code
2) la facilité de débogage
3) le respect des responsabilités (j'ai déjà vu des codes ou les gens voulant tout faire dans la même fonction on dû passer des pointeurs n'ayant à voir qu'avec une seule fonctionnalité).
Autre point, en écrivant la doc, on peut écrire les post et pré-conditions et ce, de façon claire. Ca permet de détailler les raisons qui font qu'un code l'utilisant pourrait crasher, et ça accélère donc le débogage. A moins que quelqu'un ici puisse écrire du code qui ne plante jamais? Au delà du "hello world" je doute que ce soit réaliste de penser ainsi.

Pour moi, la doc du code est clairement quelque chose d'important. Au même titre que les commentaires le sont pour d'autres, en fait. Je ne commente pas mon code, je préfère le documenter.
D'ailleurs, pour faire de la doc au lieu d'un commentaire, avec doxygen et en C++, il suffit de taper "//!" au lieu de "//". C'est vrai que c'est fichtrement épuisant. (Utile pour les FIXME, NOTE, TODO et autres annotations. Ca permet de générer un document à l'usage des collègues qui leur permettra de comprendre quels point de votre code vous semblent bancals, mais pour lesquels vous n'avez pas eu le temps d'atteindre un niveau perfection suffisant, peu importe la raison (chef trop pressé?))