Discussion :

[souviron34]

J Les expérimentés sont justement intéressant pour les cas difficiles et tordu, parce qu'ils ont déjà eu un jour un truc bizarre qui y ressemblait un peu et que peut-être en faisant un truc du même style, ça pourrait débloquer le bazar.

Cas qui justement ne tombent JAMAIS lors de tests "à froid", sur un langage ou une techno...

Car ces cas sont les combinaisons de différents facteurs, entre biblios, code, "limites" des langages et/ou de leur utilisation, charge de la machine, interactions avec d'autres softs, etc...


@imikado :

Ce qu'il faut comprendre et ce qu'on essaye de te dire, c'est que un vétéran qui n'a pas fait qu'une seule boite sur un seul projet, ce qui est le cas de 99.99% des personnes ayant de la bouteille, c'est que ce qu'ils apportent à l'entreprise / au projet n'est PAS la programmation, mais leur expérience....

Entre vision globale - donc de l'architecture, de la maintenance, de la pérennité des technos - relations - pour une demande d'aide sur un pbe particulier vers es gens qu'il a déjà cotoyé et estime - divers environnements de travail, de plateforme, etc, ça n'a rien à voir avec l'aspect "programmation pure", qui pourrait s efaire avec des tests et qui convient parfaitement à un débutant.. Si sur son CV il y a plusieurs langages, et que les projets sont cohérents et substantiels, il peut facilement apprendre ce qu'i; ne sait pas..

Le fond du test avec un vétéran c'est :

• est-ce qu'il est bon techniquement dans la partie qu'il met en avant dans son CV (pas forcément celle pour laquelle TOI tu le veux)
• est-ce qu'il s'intégre facilement dans une équipe.

Comme François, je me casse dès que je vois une boite qui veut me faire passer un test technique : je n'ai aucun intérêt pour l'entreprise, si elle n'a pas compris ce que c'était que la différence entre un débutant et un sénior. Et je sens qu'on ne s'entendra pas, donc pas la peine de perdre du temps..

[imikado]

@souviron34 dans ce cas, prenons un exemple simple et concret:

Vous avez dans votre entreprise, un projet qui arrive pour le mois prochain et au vue de la charge actuelle, vous allez avoir besoin d'employer un dev supplémentaire pour vous épauler afin de tenir les délais

Que faites vous ?

Quand on recrute des vétérans/confirmé, c'est que l'on ne veut pas un débutant qui se fasse la main (on en prend également) on veut un developpeur qui va être un minimum productif (pour que l'on puisse tenir nos délais)

Après peut etre que vous souhaitez un autre terme pour cela, personnellement je préfère le terme de "confirmé"

Ce que l'on attend de lui, c'est qu'il soit un minimum autonome et surtout soit capable d'estimer/respecter les charges qu'il indique
Car on a pas le temps de le chaperonner et de voir au jour le jour ce qu'il code, on prévoit des lots, et chacun code sa partie pour pouvoir présenter/livrer en test les lots

[souviron34]

Après peut etre que vous souhaitez un autre terme pour cela, personnellement je préfère le terme de "confirmé"

Non, vétéran me convient tout à fait : c'est le sujet du thread...

Et justement VOUS confondez vétéran et confirmé.. Vétéran, c'est plus de 15, voire 20 ans de métier..

Je ne prendrais pas un dev vétéran pour faire 10 lignes de code à faire vérifier par un supérieur... Soit je lui confie une partie entière, soit je cherche un jeune..

Faut pas trop prendre les gens pour des c.ns, non plus..

Mais je suppose que vous êtes dans l'optique SSII, gros turnover, vision à court-terme...

• Si vous vous apercevez avec juste un mois de recul que vous n'y arriverez pas, vous gérez mal vos projets.. ou votre boite : vous acceptez des choses que vous ne pouvez fournir..
• Et si c'est un projet long et que vous pensez qu'il vous faut un confirmé, alors vous devez être prêt à prendre le temps qu'il faut pour le trouver, et pas avec 15 jours de délai..

Mais je suppose que vous passez des annonces comme on en voit tous les jours, avec "expérimenté 3 à 5 ans d'XP"... ou "sénior 5 ans d'XP"..

[phili_b]

Mais je suppose que vous êtes dans l'optique SSII, gros turnover, vision à court-terme...

* Si vous vous apercevez avec juste un mois de recul que vous n'y arriverez pas, vous gérez mal vos projets.. ou votre boite : vous acceptez des choses que vous ne pouvez fournir..

Oui c'est qu'il me semblait aussi en lisant le dernier message d'imikado:

Comment on est déjà à la bourre ?!, on va chercher un dév qu'on va plonger dans le bain jusqu'au coup, comme s'il montait dans un train en marche, mais en plus au lieu de l'intégrer dans une équipe à l'agence, on va l'envoyer chez le client en première ligne, alors qu'on ne le connait pas, au milieu d'un projet déjà chaud...et on s'étonne que le mec psychote, alors qu'un type qu'on vient d'embaucher il faut peut-être ne pas le prendre sur un truc méga brulant non ?

@imikado:

Mais que le dév soit vétéran, confirmé, ou jeune ce ne sont pas les meilleures conditions pour commencer un projet. Même quelqu'un que tu sors d'un autre projet, que tu connais, pour aller sur ce projet aura peut-être du mal. Alors effectivement les gens qui sont limites niveau techniques ils vont couler direct. Mais rien ne dit que pour les autres ça marchera plus.

Vous avez dans votre entreprise, un projet qui arrive pour le mois prochain et au vue de la charge actuelle, vous allez avoir besoin d'employer un dev supplémentaire pour vous épauler afin de tenir les délais

Il faut changer l'intitulé de l'offre d'emploi, "recherche d'urgence développeur pour mission pompier" et là on saura à quoi s'en tenir. Et là oui le test est utile mais seulement pour ce genre de mission, car pondre du code au kilomètre dans l'urgence, ça ne va pas dire forcément que la personne a le savoir-être, le savoir-faire etc... pour les missions plus "normales". Et là effectivement un vétéran de faire du code au kilomètre sans réfléchir ça ne va pas l'amuser.

Donc oui il y a besoin quelque fois des gens pour des missions pompiers, mais ça ne devrait pas être un processus d'embauche habituel...ou alors c'est que tout les projets dérapent à 200% ou sont tous énormément sous-chiffrés.

[LSMetag]

@imikado

Je trouve les 2 derniers posts très pertinents.

Pour votre besoin, je pense qu'un bon développeur avec entre 2 et 5 ans d'expérience vous conviendrait. La méthode de test dont je vous ai parlé convient très bien pour ce type de profil.

Les gens qui ont 10/20 ans d'expérience ne sont plus des développeurs. Ils peuvent coder mais leur job en général relève plus de la direction de projet, de l'expertise ou de l'architecture. Et l'expertise comprend la R&D.
Tu en trouveras très peu qui accepteront de faire le job d'un simple développeur de 20 piges.
Tu en trouveras aussi qui n'ont pas codé depuis 5 ans. Tu as beau avoir été bon, arrêter de pratiquer pendant 2 ans suffit à complètement te faire perdre la main. Et après tu m'étonnes qu'un mec se plante le premier mois.

Petite anecdote perso : J'ai dû m'interrompre pendant 2 ans, gravement malade et alité en quasi permanence. Quand je suis revenu en entreprise, sur une techno que je n'avais jamais pratiqué qui plus est, le premier mois j'ai en effet eu l'air d'un gros débutant. Je posais beaucoup de questions, je faisais aussi des erreurs. Je n'avais rien pipeauté sur mon CV, les entretiens s'étaient très bien passé. Mais voila, ce mois a été nécessaire pour que je retrouve mes automatismes et que je m'adapte à la techno (je précise qu'on m'a changé au dernier moment de projet). Mes employeurs ont eu peur, mais tout s'est bien terminé.

[souviron34]

Et là effectivement un vétéran de faire du code au kilomètre sans réfléchir ça ne va pas l'amuser.

Si, sans doute, pour se faire des sous .. Mais en indépendant...

Car personne de censé n'aimerais être dans ce genre de boite.. Par contre, faire une mission court-terme en étant irremplaçable, et donc en demandant un max, pourquoi pas ?

[imikado]

Non, vétéran me convient tout à fait : c'est le sujet du thread...

Et justement VOUS confondez vétéran et confirmé.. Vétéran, c'est plus de 15, voire 20 ans de métier..

Il y a effectivement un soucis de vocabulaire, mon test concerne un confirmé

Je ne prendrais pas un dev vétéran pour faire 10 lignes de code à faire vérifier par un supérieur... Soit je lui confie une partie entière, soit je cherche un jeune..

Vous m'avez mal lu, ou je n'est pas été clair: c'est justement pour ne pas verifier derriere lui ce qu'il fait qu'il nous fallait un confirmé.
L'idée dans tous nos projets: on se voit avant avec la MOA.. pour bien exprimer le besoin, puis on se voit entre technique (dev+dba) pour imaginer une architecture, modeliser... et créer des lots
On se partage ensuite les lots avec une deadline de livraison en test
Donc non, il ne faut pas lire le code au jour le jour, chaque developpeur est autonome et travaille sur sa partie, bien sur toute l'équipe est dispo si question, bug complexe/conseil... il y a

Mais je suppose que vous êtes dans l'optique SSII, gros turnover, vision à court-terme...

Pas du tout: d'habitude on a des projets plus large et l'on prend des débutants, ce dernier cas est particulier, on attendai la confirmation (appel d'offre), on savait qu'on aurait besoin d'un confirmé pour m'épauler sur ce projet qui était assez lourd, trop pour que je le gère tout seul. L'idée et c'est ce qui avait été annoncé au dev, c'est que l'on se partage le boulot, les parties.
C'est ce qui a été fait, on a fait une estimation ensemble, rien à dire: toute la partie en amont c'est plutot bien passé, c'est lorsqu'on est arrivé au date de livrable des lots: je livrais mes parties, et lui ne pouvait toujours pas...
A deux, avec un vrai confirmé le projet aurait été très bien géré

Pour info, on passe par des SSII pour nous fournir des profils: on les prends en mission et si après le projet on trouve qu'il a bien travaillé il continue sur d'autres projets. ET si affinités (et budget) il peut par la suite intégrer l'équipe

[imikado]

Oui c'est qu'il me semblait aussi en lisant le dernier message d'imikado:

Comment on est déjà à la bourre ?!, on va chercher un dév qu'on va plonger dans le bain jusqu'au coup, comme s'il montait dans un train en marche, mais en plus au lieu de l'intégrer dans une équipe à l'agence, on va l'envoyer chez le client en première ligne, alors qu'on ne le connait pas, au milieu d'un projet déjà chaud...et on s'étonne que le mec psychote, alors qu'un type qu'on vient d'embaucher il faut peut-être ne pas le prendre sur un truc méga brulant non ?

Je n'ai jamais dit ça: quand notre dev a débuté, on a commencé les premières réunion normalement, comme je viens de le dire (précédent post) le projet ne tenait pas pour un développeur, mais était largement faisable par deux confirmés

Pour ce projet, j'aurais préféré avoir un débutant, car dès le départ je l'aurait managé, vu avec lui en détail les possibilités et choses à développé, fait des points réguliers... (hebdo/quotidien...)
Et on aurait fini dans les temps sans se mettre sous pression

Il faut changer l'intitulé de l'offre d'emploi, "recherche d'urgence développeur pour mission pompier" et là on saura à quoi s'en tenir. Et là oui le test est utile mais seulement pour ce genre de mission, car pondre du code au kilomètre dans l'urgence, ça ne va pas dire forcément que la personne a le savoir-être, le savoir-faire etc... pour les missions plus "normales". Et là effectivement un vétéran de faire du code au kilomètre sans réfléchir ça ne va pas l'amuser.

Je le répète ce n'était pas une mission pompier c'était un projet non gérable par un seul développeur, il nécéssitait un second et comme je l'ai dit à deux, même avec un débutant on aurait mené à bien ce projet.
Le problème ici: on a fait confiance à son status de vétéran (la quarantaine, un cv plus que correct...) et surtout lorsqu'on lui demandait ou il en était si il serait dans les clous, il répondait toujours que tout allait bien qu'il serait dans les temps juqu'à la livraison du premier lot ou ... (no comment)

[souviron34]

Pour info, on passe par des SSII pour nous fournir des profils

Pour info, les vrais bons tu les trouveras pas via des SSII..

Ils sont soit indépendants, soit salariés, et regardent de temps en temps si il y aurait un truc encore plus mieux...

Un vétéran, ce qu'il veut c'est un défi. Un confirmé, c'est entre un défi et un truc iextrêmement intéressant..

Je le répète ce n'était pas une mission pompier c'était un projet non gérable par un seul développeur, il nécéssitait un second et comme je l'ai dit à deux, même avec un débutant on aurait mené à bien ce projet.

Sauf que le délai avec lequel tu t'es aperçu que tu pourrais pas le faire seul était un mois...

[imikado]

Pour info, les vrais bons tu les trouveras pas via des SSII..

Ils sont soit indépendants, soit salariés, et regardent de temps en temps si il y aurait un truc encore plus mieux...

Un vétéran, ce qu'il veut c'est un défi. Un confirmé, c'est entre un défi et un truc iextrêmement intéressant..

Ca se tient, on a actuellement en mission un indépendant qui passe par une SSII, mais dans une boite on aime bien déléguer la partie recherche de profil à une ou plusieurs SSII ave qui on travaille
Ils nous connaissent, ils connaissent à priori leurs profils..

Sauf que le délai avec lequel tu t'es aperçu que tu pourrais pas le faire seul était un mois...

?
Il doit y avoir un quiproquo, l'histoire d'1 mois c'est un exemple
Je n'ai pas trop le droit d'etre plus précis sur le sujet, mais je peux juste dire que ce projet dépendait de la réponse à un appel d'offre: on ne pouvait donc pas commencer à developper avant d'avoir la réponse, et la deadline était déjà figée officiellement (donnée par le client)
Et le profil qu'on a rencontré, sur son CV, lors de l'entretien.. semblait convenir, d'autant qu'on lui avait parlé de la situation

[phili_b]

Pour ce projet, j'aurais préféré avoir un débutant, car dès le départ je l'aurait managé, vu avec lui en détail les possibilités et choses à développé, fait des points réguliers... (hebdo/quotidien...)

Autant les points quotidiens ça ne sert à rien, autant les points hebdos ça me parait indispensable, en tout cas au début de la mission qui démarre sur les chapeaux de roues et que tu ne connais pas la personne.

Après il faut que les points soient courts et efficaces et pas du flicage ou "moi je" sinon on risque l'affrontement. Mais avec tact il n'y a pas de soucis.

Je ne sais pas quelle est la solution mais laisser travailler quelqu'un pendant un mois sans avoir de nouvelles et sans le connaitre je ne comprends pas. "- Tout baigne ? - Tout baigne ^^' (gloups)." Et en plus il aurait très bien plus s'embourber, même en étant bon dans le langage que tu lui faisais faire, en allant dans une voie sans issue et ne sachant plus comment s'en sortir.

[imikado]

Autant les points quotidiens ça ne sert à rien, autant les points hebdos ça me parait indispensable, en tout cas au début de la mission qui démarre sur les chapeaux de roues et que tu ne connais pas la personne.

On travaillait l'un à coté de l'autre, et je demandais régulièrement si tout allait bien, et il me posait des fois des questions auquel je répondais
Pour les besoins, j'avais initié plusieurs documentation sur le projet pour indiquer certains points à respecter, certaines infos...

Après il faut que les points soient courts et efficaces et pas du flicage ou "moi je" sinon on risque l'affrontement. Mais avec tact il n'y a pas de soucis.

On ne le faisait pas au départ, on le pensait assez autonome, et puis au vue du retard qu'il prenait on a initié un standup tous les matins juste pour savoir sur quoi il avait pu avancé la veille le débloquer si besoin... et là on a commencé à vraiment avancer: en le gérant comme un débutant (me faisant perdre du temps entre le retard et son management

Je ne sais pas quelle est la solution mais laisser travailler quelqu'un pendant un mois sans avoir de nouvelles et sans le connaitre je ne comprends pas. "- Tout baigne ? - Tout baigne ^^'
(gloups)." Et en plus il aurait très bien plus s'embourber, même en étant bon dans le langage que tu lui faisais faire, en allant dans une voie sans issue et ne sachant plus comment s'en sortir.

Je bossais à coté de lui, et il n'hésitais pas à me poser des questions plusieurs fois par jour, et sa partie était la plus simple du projet
On a fini par travailler à 3 sur ce projet, un collègue reprenant la partie complexe de son lot qui avait entre temps diminué

[fcharton2]

Le problème ici: on a fait confiance à son status de vétéran (la quarantaine, un cv plus que correct...) et surtout lorsqu'on lui demandait ou il en était si il serait dans les clous, il répondait toujours que tout allait bien qu'il serait dans les temps juqu'à la livraison du premier lot ou ... (no comment)

Je pense que c'est le fond du problème. Intégrer quelqu'un dans une équipe, sur un projet en cours, et faire qu'il fonctionne sans qu'on ait à s'en occuper, cela demande bien plus qu'un mois, et ça n'a rien à voir avec la séniorité de la personne.

Mon expérience (en tant qu'éditeur) c'est qu'un sénior (10 à 20 ans d'expérience) est tout de suite efficace sur de petits problèmes précis (un bug, un cas particulier, une demande bien spécifiée), mais mettra entre 6 mois et un an à voler de ses propres ailes, et généralement sera indépendant après 18 mois. Dans la période intermédiaire, il faut l'encadrer, ou on va dans le mur, et ca coute cher.

Sur un projet court, prendre un senior permet de gagner du temps en développement, et d'avoir du premier coup une solution raisonnable sur un sujet précis (et si possible difficile, sinon à quoi bon payer un senior), mais cela ne dispense pas de lui spécifier le boulot, de suivre le temps passé, et de se méfier de ses estimations (je ne connais presque personne, junior ou senior, qui sache estimer correctement un temps de développement sur un projet nouveau).

Francois

[herdans]

Je rejoins erwanlb, les tests d'embauche d'informatique, c'est du temps perdu, pour le candidat et le testeur, à la rigueur poser 2, 3 questions bateau suffisent, histoire de pas tomber sur un charlatan. Dans un vrai métier, on ne fait jamais passer de test d'embauche aussi poussé, comme ça. Dans les vrais milieux professionnels, on sait qu'il y a toujours une période d'adaptation à la nouvelle recrue.

J'ai pas beaucoup d'expérience en tant qu'informaticien, et aucune en tant que recruteur, cependant, je pense que des solutions efficaces ont déjà été trouvé vis-à-vis de l'embauche de profil expérimenté.

Une solution parmi d'autres, s'appelle les références. Normalement, sur un CV non pipeauté, d'autant plus, sur un profil vétéran, il y a ce qu'on appelle des expériences. Il suffit alors de prendre son courage à deux mains, et d'appeler les anciens employeurs, pour voir ce qu'ils pensent de leurs anciens employés, à corréler éventuellement avec la version du candidat.

Faut arrêter de traiter différemment les informaticiens, considérons que c'est un métier normal, pas un métier spécial avec recrutement spécial, utilisons notre bon sens.

[imikado]

On passe par des SSII, on ne recrute pas en direct, pour moi c'est le travail de la SSII de bien connaitre les profils qu'elle nous envoie

[Invité]

Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?

En formation continue dans les années 80, un professionnel, enseignant à l’IUT, nous a concocté un DST dans lequel il posait une question intéressante, il s’agissait à partir d’une petite description de Base de Données et d’un ensemble de besoins utilisateur de concevoir l’écran approprié.

Sur la trentaine d’étudiants que nous étions, j’ai été le seul à proposer l’écran attendu. L’épreuve durait 2 heures et l’écran ne valait que 5 points mais j’ai flashé sur la question et j’y ai consacré 1h ½. La correction de l’écran a duré une heure pendant laquelle le prof a décortiqué le cheminement intellectuel ayant motivé ses choix. Du grand art ! Ayant suivi le même cheminement, j’ai eu l’impression de vivre une psychanalyse. Je ne suis pas un spécialiste du recrutement mais à mon avis ce genre d’épreuve révèlerait beaucoup de choses sur la technicité et la personnalité du développeur (ergonomie, convivialité, design).

Dans une autre discussion, j’ai évoqué la différence entre « ergonomie » et « convivialité ». J’ai eu cette réponse désarmante : « Il n'y a strictement aucune nuance entre "convivialité" et "ergonomie". Un logiciel convivial EST ergonomique et réciproquement un logiciel ergonomique EST convivial. »

Je n’ai pas insisté, cela revient à ne pas différencier le "signifié" du "signifiant", le "signifié" désignant la représentation mentale du concept associé au signe, tandis que le "signifiant" désigne la représentation mentale de la forme et de l'aspect matériel du signe.

De même qu’en linguistique, le signifié et le signifiant sont les deux faces complémentaires du concept de signe linguistique, la convivialité et l’ergonomie sont les deux faces complémentaires du concept d’écran. La convivialité sollicite la compréhension, l’ergonomie sollicite l’utilisation. Enfin, c’est comme ça que je vois les choses.

Exemple : le bouton « Démarrer » de Windows

Ergonomie : le bouton est physiquement placé en bas à gauche de la barre des tâches : pas de problème, sa place est incontestablement ici.

Convivialité : Le signifié "Démarrer" est anti convivial en ce sens que pour arrêter il faut cliquer sur "Démarrer". Depuis, Microsoft a compris l’incohérence et a changé son bouton "Démarrer" en bouton "Menu" en associant pédagogiquement le "Menu" au logo, ce que fait la touche « Windows » du clavier.

Design : c’est son aspect (forme, couleurs, éventuellement mouvement). Microsoft aurait pu, par exemple, choisir de représenter la touche « Windows » du clavier et simuler l’appui sur la touche lorsque l’on clique dessus. Mais le choix du bouton logo-menu rond et statique se retrouve dans Word, Excel, etc.

Liens :

Comment s'autoformer au design informatique ?
Ergonomie des interfaces, de Dunod

Tout ça pour dire qu’à partir d’un écran (ou d’un état, d’ailleurs), on peut estimer le degré de réflexion du développeur et déceler, par exemple, s’il tient compte ou non des difficultés visuelles de beaucoup d’utilisateurs, de leur éventuelle fatigue mentale, ou du fait que la plupart des gens ne lisent pas (états). La simple conception d’un écran met en évidence l’esprit d’analyse et de synthèse, la créativité, la technicité, la simplicité, la personnalité, l’humanité.

On peut certainement dire qu’il y a autant de versions d’écrans que de développeurs. Pourtant, à partir des mêmes besoins utilisateur, il ne devrait y avoir qu’une version idéale.

Au même titre que la graphologie est une technique d'analyse de l'écriture qui affirme pouvoir déduire systématiquement des caractéristiques psychologiques de la personnalité d’un individu à partir de l’observation de son écriture manuscrite, l’analyse d’un écran ou d’un état (Conceptologie ?) devrait pouvoir déduire la technicité et la personnalité du développeur.

Étonnant, non ?

Bof !... C’était la minute nécessaire de Monsieur Cyclopède.

[souviron34]

Bonjour

Je me suis reconnu dans l'abruti que tu cites et qui n'avait rien compris à ton éblouissante démonstration, mais je m'y recolle

Exemple : le bouton « Démarrer » de Windows

Ergonomie : le bouton est physiquement placé en bas à gauche de la barre des tâches : pas de problème, sa place est incontestablement ici.

Ceci est faux ...

En ergonomie la place du bouton est incontestablement à l'endroit où l'utilisateur s'attend dans la suite logique de ses actions à le trouver..

Pour nous qui lisons de gauche à droite et de haut en bas, on n'a donc que 2 cas :

• Si c'est la première des choses qu'on doit faire il doit être en haut à gauche.
• Si c'est la dernière, il devrait être en bas à droite..

(inverser gauche et droite pour les langues arabes par exemple et gauche et droite ET haut et bas pour les langues comme le chinois)

Convivialité : Le signifié "Démarrer" est anti convivial en ce sens que pour arrêter il faut cliquer sur "Démarrer". Depuis, Microsoft a compris l’incohérence et a changé son bouton "Démarrer" en bouton "Menu" en associant pédagogiquement le "Menu" au logo, ce que fait la touche « Windows » du clavier.

Encore une fois, ceci est faux

Le signfié devrait être "Marche/Arrêt". ou simplement "Arrêt" puisqu'à priori on ne le voit que quand ça a démarré... .. Ni "Menu" ni "Windows" ne signifient strictement rien quant à l'action suivante...

Design : c’est son aspect (forme, couleurs, éventuellement mouvement). Microsoft aurait pu, par exemple, choisir de représenter la touche « Windows » du clavier et simuler l’appui sur la touche lorsque l’on clique dessus. Mais le choix du bouton logo-menu rond et statique se retrouve dans Word, Excel, etc.

Là encore, il existe un standard électrique qui figure sur TOUS les appareils électroniques du monde :

• Soit un bouton bascule avec un caractère "I" et un caractère "O"
• Soit un bouton bascule Rouge/Vert (ou un simple bouton rouge "arrêt" ou "stop".. Ce qui figure bien dans Windows mais une fois qu'on a cliqué sur "démarrer")

Et Microsoft est un habitué de ce genre d'erreurs.. Dans les workshops des congrès internationaux d'ergonomie l'exemple le plus trivial de mauvaise ergonomie - jusqu'aux dernières versions sur Vista - était Word.. : alors qu'il existait un menu "Formatter", qui comprenait pratiquement tout ce qu'on pouvait imaginer formatter, les marges (et donc le format de la page) se trouvait dans le menu central (nommé "Fichier")... 100% des paticipants, lorsqu'ils avaient à placer les différents éléments dans les différents menus - en tenant compte uniquement de l'ergonomie et non pas de la connaissance déjà acquise - placent l'élément "formatter la page" (et même "définir les marges") dans le menu "Format"...


De plus, les éditeurs ayant suivi la norme "Windows" reproduisent extrêmement souvent le même type d'erreurs, ayant dans leurs applis un premier menu qui se dénomme "Fichier", même si leurs utilisateurs (et l'application) n'utilise aucun fichier, ou une fois / mois par exemple... (ce qui nécessite une formation et un apprentissage, et n'est donc pas ergonomique) Une recommandation ergonomique simple pour ces cas (qui sont la majorité) est de nommer le premier menu "Général"..



[EDIT]

Et pourtant, malgré toutes ces erreurs, je suis relativement d'accord avec :

Tout ça pour dire qu’à partir d’un écran (ou d’un état, d’ailleurs), on peut estimer le degré de réflexion du développeur et déceler, par exemple, s’il tient compte ou non des difficultés visuelles de beaucoup d’utilisateurs, de leur éventuelle fatigue mentale, ou du fait que la plupart des gens ne lisent pas (états). La simple conception d’un écran met en évidence l’esprit d’analyse et de synthèse, la créativité, la technicité, la simplicité, la personnalité, l’humanité.

[/EDIT]

[nycolas]

Personnellement je fais passer un test aux candidats lors du recrutement dans mon équipe. Je parle bien d'un test pour l'embauche d'un développeur, dont la tâche sera quasi exclusivement de coder.

Le test dure une heure, mon sujet de prédilection étant : coder le jeu de bataille navale tel que tout le monde y a joué (avec quelques simplifications, le côté "dur" du test étant : placer les bateaux aléatoirement sur la grille). Le candidat code dans le langage qu'il veut (ou même en algorithmique, en fait on se fixe de la syntaxe, le but n'est pas de voir si le candidat sait bien comment on déclare un tableau ou s'il met bien les points-virgules).

Je le briefe au départ sur ce qui est attendu, et sur les choses à faire en priorité. Et au bout d'une heure, en général le candidat n'a pas terminé, mais j'examine son code avec lui, il me le commente, m'explique ses choix. Comme j'ai fait faire de nombreuses fois ce test, je le connais bien donc je peux voir facilement les bugs classiques, et je l'aiguille afin de voir s'il les trouve, comment il les résout, je questionne sur comment faire évoluer son code, ajouter une option au sujet du test, etc.

Jusqu'à présent, ce test nous a permis d'éviter l'embauche de candidats qui présentaient bien et se vendaient bien lors de l'entretien d'embauche (que l'on fait juste avant le test), mais s'étaient révélés incapable de faire un début de quelque chose de cohérent pour ce test.

Anecdote: la seule personne ayant abandonné pendant le test m'avait donné comme l'une de ses grandes qualités pendant l'entretien : "la persévérance"...!!

Et aussi, mon préféré : nous recevions à 2 un candidat qui ne présentait pas bien du tout : au chômage depuis de longues années, très timide et pas sûr de lui, il disait tout ce qu'il ne faut surtout pas dire à un entretien d'embauche, ayant échoué à l'embauche dans toutes les entreprises d'informatique du coin, etc. Après l'entretien avec le candidat, mon collègue était convaincu qu'il ne fallait surtout pas l'embaucher. J'ai malgré tout fait passer le test au candidat : et il s'est révélé être celui qui, a ce jour, a réalisé pour ce test le meilleur code que j'ai vu : il a été embauché, et s'est révélé être l'un des meilleurs de l'équipe, relationnellement, il s'est très bien intégré.

Au final je dirais qu'un test de code doit notamment :
- être simple à comprendre par le candidat
- être fait en temps limité
- être maîtrisé par celui qui le fait passer.
- avoir matière à comparer, donc le faire faire systématiquement

Un tel test s'avère très utile pour débusquer les canards boiteux, mais permet difficilement de faire la différence entre un programmeur moyen et un bon.

[Yepazix]

Je ne suis pas un pro de la programmation mais je voudrais vous soumettre cette petite réflexion que certains trouveront peut-être provocatrice :

Le principe même d'un test dans une branche telle que celle de la programmation est en fait de déterminer la capacité du candidat à faire selon des procédures pré-établie, à suivre des règles, etc... NON ?
Dans ce cas que reste t-il comme place à l'innovation à la créativité et donc simplement au progrès.
Sur les deux derniers millénaires il existe de nombreux exemples historiques qui démontrent que souvent dans des branches "scientifiques" et donc à priori "rigides" le progrès est le résultat d'erreurs ou d'un travail brouillon.

Je vous invite par exemple à lire Léonard de Vinci paru chez Marcel Brion on y explique comment "le bordel" dans lequel il vivait et travaillait d'une manière plus que brouillonne passant d'une chose à l'autre à permis la résolution de problème considérés par les méthodistes (au sens de l'adjectif par religieux) comme insolubles.

Les 100 dernières années ont été riches en progrès mais pour continuer dans cette voie il faut maintenant que les choses se débloquent. Il faut arrêter les méthodes, les process, les structures et mettre un peu de chaos dans ce monde trop bien rangé.

Quand mon entreprise sera assez grande et que je passerai une annonce pour engager un informaticien elle ressemblera à ceci :

Cherche informaticien avec un minimum de connaissances techniques et prêt à toutes les sacrifiées sur l'autel de sa créativité.

Ceci n'est que l'avis d'un pauvre philosophe perdu...

[olivier2013]

Ben alors là c'est simple: si on refaisait passer le capes et l'agreg chaque année aux enseignants, il est évident qu'ils ne pourraient pas revalider car ce sont des concours spécifiques et chronophages n'ayant rien à voir avec l'expérience professionnelle. La réponse sur l'utilité des tests est donc claire, leur existence est simplement liée au nombre de candidats.