Discussion :

[Matthieu Vergne]

Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?

On ne définit pas des tests en fonction des données qu'on va tester (sinon on appel ça un test biaisé), mais en fonction des propriétés qu'on veut y évaluer. Si on cherche un bon programmeur, qu'il soit vétéran ou non n'y change rien, mais encore faut-il que le test soit capable d'évaluer ce qu'on demande.

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

Déjà, ce n'est pas en demandant des compétences qui sont loin de la programmation : ce problème d'algorithmie est loin des problématiques de programmation (choix de langage, architecture, optimisation, etc.). On évalue ici ses compétences mathématiques avant tout (sinon on ne nous dit pas tout sur ce test). Un bon test montre que sur des cas fréquents mais piégeux tu arrives à trouver les pièges rapidement, contrairement à un débutant, et non pas que tu sais traiter un problème que seulement une poignée savent traiter (voire même comprennent). Expérience n'est pas intelligence.

Ce test, c'est l'étude des besoins qui précède la programmation : commence par comprendre le problème, ensuite trouve une solution, et enfin programme. Manque de bol on l'évalue partout sauf sur la dernière.

Pouvez-vous donner une solution au problème d’ensembles disjoints du vétéran ?

Avec un énoncé plus clair, probablement, avec le peu d'infos donné en revanche, c'est plus l'interprétation de l'exemple qui sera parlant (pour ma part, l'exemple ne correspond pas à l'explication en toute lettre). J'ai même envie de dire que ça en dit long sur ce qu'en a compris le testé. avant de donner une solution, il faut comprendre le problème, pas juste en avoir une vague idée.

[zaventem]

Ce qui est paradoxal avec ton test imikado, c'est qu'en voulant écarter les pires tu fait surtout fuir les meilleurs qui n'ont pas envie de perdre leur temps à te prouver qu'ils connaissent le BA BA de leur métier. Ils trouveront de toute manière un emploi et ce qu'ils veulent avant tout, c'est des défis sympas, pouvoir s'arracher les cheveux sur une saleté de problème que personne ne comprend... Ils aimeraient que tu les mettent au défi d'avaler une mygale grillée et toi tu leur propose un pauvre bout de jambon périmé depuis hier

Honnêtement, je ne vois pas ce que ton CRUD peut m'apporter. Qu'il sait se connecter à une base mysql? Le prochain projet c'est une base Oracle. Qu'il sait coder en Php? L'année prochaine, on fait du Java. etc.
La technique est un détail qui s'apprend vite, une tête bien faite, deux sous de bon sens , la capacité de se remettre en question et l'envie de progresser, tu les as ou pas.

[imikado]

Ce qui est paradoxal avec ton test imikado, c'est qu'en voulant écarter les pires tu fait surtout fuir les meilleurs qui n'ont pas envie de perdre leur temps à te prouver qu'ils connaissent le BA BA de leur métier. Ils trouveront de toute manière un emploi et ce qu'ils veulent avant tout, c'est des défis sympas, pouvoir s'arracher les cheveux sur une saleté de problème que personne ne comprend... Ils aimeraient que tu les mettent au défi d'avaler une mygale grillée et toi tu leur propose un pauvre bout de jambon périmé depuis hier

Oui c'est ce que je vois, et c'est dommage, mais la discussion et ces échanges permettent de se faire une idée, on va bien réussir à trouver une solution
Par exemple @LSMetag a donné une idée: plutot qu'une application simple comme un CRUD, un projet plus complexe et plus de temps, par exemple on pourrait demander de faire un forum mais pas tout, juste la structure et une partie, celle qu'il veut
On avance, je le répète le CRUD c'est mon idée de base, mais ça peut être autre chose, du moment qu'on peut savoir si le candidat sait estimer, et voir le code qu'il fait

Honnêtement, je ne vois pas ce que ton CRUD peut m'apporter. Qu'il sait se connecter à une base mysql? Le prochain projet c'est une base Oracle. Qu'il sait coder en Php? L'année prochaine, on fait du Java. etc.

Il a la doc pour ça, on ne veut pas savoir si il sait se connecter, faire une insertion, on veut savoir comme je l'ai listé:
1. si il sait estimer une charge: a-t-il le temps de faire l'applicaiton dans le temps imparti
2. si non, quel partie pense-t-il pouvoir faire dans ce temps
3. une fois l'heure passé, a-t-il respecté sa charge annoncé, si non en est il proche (on est pas des machines non plus
4. qu'estime-t-il avoir fait (pour savoir si il sait evaluer communiquer sur un existant, un candidat surévaluait: il etait toujours proche de la fin, alors qu'en fait pas du tout
5. l'application fonctionne-t-elle ? (il faut lui demander avant de tester)
6. regarder la qualité du code (noms des variables, des methodes, commentaires, code spaghetti ou factorisé...)
7. discuter de ce qu'il fairait si il avait plus de temps: securité/performance...

La technique est un détail qui s'apprend vite, une tête bien faite, deux sous de bon sens , la capacité de se remettre en question et l'envie de progresser, tu les as ou pas.

On parle ici de vétéran/confirmé, le test porterai forcément sur une techno web qu'il "maitrise" donc ici, il faut prendre les éléments cités au dessus, le but n'est pas de le bloquer ou le faire tomber avec un problème difficile à résoudre, c'est plutot de voir comment il travaille sur une techno qu'il connait (où il est à l'aise)

[zaventem]

On parle ici de vétéran/confirmé, le test porterai forcément sur une techno web qu'il "maitrise" donc ici, il faut prendre les éléments cités au dessus, le but n'est pas de le bloquer ou le faire tomber avec un problème difficile à résoudre, c'est plutot de voir comment il travaille sur une techno qu'il connait (où il est à l'aise)

Je crois que c'est là le problème: pour un vétéran (ou disons plus simplement un gars qui commence a avoir un peu de bouteille), on se moque de la technique, il connait plusieurs langage, il les a utilisé dans des contextes variés et il n'y a pas à s'en faire, les bases, il connait (à moins d'avoir un génie du pipautage que tu recaseras en commercial d'enfer). 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.

[imikado]

@zaventem cette idée de test c'est pour confirmer que c'est bien le cas
Le dev qui nous avais surpris avait un discours de vétéran, un cv de vétéran et pourtant quand il a commencé à coder ... on aurait dit un débutant, et encore on aurait préféré un débutant
Car un débutant on sait à quoi s'en tenir, on lui en demande moins, on l'encadre plus Je précise qu'on emploi les deux profils sur nos missions, pour une fois qu'on prend un "confirmé", on a trop fait confiance à l'entretien oral

[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..

[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.

[damedom41]

Selon moi un bon programmeur est un programmeur "flemmard" qui ne réinvente pas la brouette à chaque besoin. Personnellement, j'ai bâti une bibliothèque de fonctions (crées par moi, ou piquées sur le net) que j'ai comprises, mais que j'utilise sans avoir à en mémoriser le détail.
J'essaie de leur donner des noms courts mais pertinents, je les documente, et je les classe dans des "sous modules".
Impossible à utiliser dans un test, mais cela pourrait faire partie d'une sorte de press book à montrer à un recruteur !

[MicBru]

Article très intéressant, de même pour les commentaires des intervenants.

En résumé, ce test est complètement IDIOT !

Depuis octobre 1980, j'ai travaillé dans le service informatique de différentes entreprises en tant qu'analyste-programmeur ou administrateur de base de données côté développement. Je suis donc un dinosaure.

Ce test correspond plus à un exercice de mathématiques que de programmation : il s'agit de la notion d'union et d'intersection.
En deux secondes, j'ai trouvé la solution grâce à la théorie des ensembles.
Le programmer N'a PAS d'intérêt !
De plus, j'aimerais que quelqu'un me cite un cas où une entreprise a besoin d'informatiser ce type de problématique.

[Gouyon]

Allons y dans le délire des cabinets de recrutement avec des tests de compétence absurdes . C'est le rêve de tout DRH d'avoir le test qui lui permettra de trouver la personne dont sa boite à besoin. Sauf que:

1. Le besoin a t'il bien été exprimé et bien compris par le recruteur
2. La perle rare n'existe pas forcément (10 ans d'expérience acceptant d'être payé au smig pour une durée de travail hebdomadaire de 80h )
3. Il n'y a pas que les compétences qui compte, il y a aussi le coté humain et social de la personne qui est recrutée (je suis très compétent comme le prouve le test que je viens de passer brillamment mais je suis juste un eu psychopathe et asocial )

La période d'essais c'est pas fait pour les chiens. De plus interdire d'utiliser les outils tel que les forums ou "Google" est absurde. Au contraire il faudrait plutôt questionner le candidat sur que faites vous quand vous êtes coincé? La réponse me semble plus intéressante que de savoir faire un algorithme dont la solution est connue sans doute depuis longtemps et parfaitement optimisé.

[imikado]

La période d'essais c'est pas fait pour les chiens.

Il faut relire les posts précédents, on a déjà indiqué qu'on avait plusieurs profils à évaluer et qu'on allait pas tous les mettre en periode d'essai ce qui couterait cher et ferait perdre beaucoup trop de temps à tout le monde (formations...) sans parler de la place (3-4 bureaux équipés de PC

De plus interdire d'utiliser les outils tel que les forums ou "Google" est absurde.

Déjà évoqué précédement: on veut sur des questions simples avec doc à l'appui de voir ce que donne le candidat, on ne veut pas savoir si il sait faire du copier coller

On a déjà évoqué l'idée de faire faire une application (avec documentation) dans un temps limité pour savoir si il était capable d'estimer une charge et de s'y tenir...

[Gouyon]

Il faut relire les posts précédents, on a déjà indiqué qu'on avait plusieurs profils à évaluer et qu'on allait pas tous les mettre en periode d'essai ce qui couterait cher et ferait perdre beaucoup trop de temps à tout le monde (formations...) sans parler de la place (3-4 bureaux équipés de PC

Ah je ne savais pas que ce post était destiné aux recruteurs et qu'il y avait un cas test unique. Ceci dit ça reste valable s'il faut embaucher plusieurs personnes.

Déjà évoqué précédement: on veut sur des questions simples avec doc à l'appui de voir ce que donne le candidat, on ne veut pas savoir si il sait faire du copier coller

On a déjà évoqué l'idée de faire faire une application (avec documentation) dans un temps limité pour savoir si il était capable d'estimer une charge et de s'y tenir...

Oui c'est mieux de tester s'il est capable de réinventer l'eau chaude Sinon il y a une autre solution très éprouvée par les grandes écoles et les administrations ça s’appelle les concours. En plus si c'est bien fait on récupère le résultat à la fin et on n'a plus besoin d'embaucher vu que le boulot est déjà fait

Je ne suis pas recruteur et ce n'est pas mon métier. Par contre j'ai un CV avec des références vérifiables et une certaine expérience. Et je pense que si on me sélectionne sur mon CV l'entretient qui suit doit déterminer si je n'ai pas bidonné mon CV (ça peux arriver et quelques questions techniques peuvent le déterminer sans pour autant me faire passer un test) et surtout d'évaluer ma capacité à m'intégrer dans l'entreprise.

Me faire faire un test me vexerai particulièrement surtout si c'est lié au fait que je sois un vétéran ou un sénior (autrement dit un vieux c..) et je ne pense pas que j'irais travailler chez eux (sauf si je meurs de faim ).

[jouana]

Je pense que le problème c'est la veille technologique et les bases.
Y a de tout sur le marché du travail, c'est chiant mais au bout du compte on est contant d'être épaulé par des gens compétent.

Après y a test et test, les gens prêtes beaucoup d'importance à la partie algo mais néglige pas mal les bases du développement.

Perso j'ai pas beaucoup d'experience sur le marché du travail -1 ans.
Mais quand je peux gagner des jours de dev grâce à des trucs du genre champ de bits ou que je met en avant un bug en parlant de stack pour m'assurer que la bêtise ne soit pas refaite et que j'ai des gars avec plus d'xp qui me font la grimace ça fait mal au cul.

Après j'ai fait 5 ans d'étude en partant du principe que c'est 5 ans sacrifié pour l'informatique et je continu à l'étudier sur mon temps libres afin d'être à la page.

Je demande pas aux autres de faire la même chose mais ma vision des bases de l'informatiques me fait douter des compétence de beaucoup :/

Après pour le test de l'article faut voir le context

[imikado]

Ah je ne savais pas que ce post était destiné aux recruteurs et qu'il y avait un cas test unique. Ceci dit ça reste valable s'il faut embaucher plusieurs personnes.

Il faut définir "recruteurs", mais dans le cas où l'on a besoin d'un developpeur en entreprise, on va choisir parmi 3-4 profils pour être sur de choisir le bon.

Oui c'est mieux de tester s'il est capable de réinventer l'eau chaude

? pour rappeler les 2 tests évoqué au choix : Un CRUD ou une application sécurisé avec formulaire d'inscription + formulaire d'authentification + page privé) , le tout en 1h

Je ne suis pas recruteur et ce n'est pas mon métier. Par contre j'ai un CV avec des références vérifiables et une certaine expérience. Et je pense que si on me sélectionne sur mon CV l'entretient qui suit doit déterminer si je n'ai pas bidonné mon CV (ça peux arriver et quelques questions techniques peuvent le déterminer sans pour autant me faire passer un test) et surtout d'évaluer ma capacité à m'intégrer dans l'entreprise.

Me faire faire un test me vexerai particulièrement surtout si c'est lié au fait que je sois un vétéran ou un sénior (autrement dit un vieux c..) et je ne pense pas que j'irais travailler chez eux (sauf si je meurs de faim ).

Idem, relisez les postes précédents, j'ai raconté l'anecdote d'un profil expérimenté, ok sur le CV, idem pour l'entretien technique (la personne avait une quarantaine d'années)
Mais c'est lorsqu'il a été confronté à son clavier (avec internet...) qu'il nous a énormément déçu (très très peu productif, butait sur des erreurs php/sql "simples" nous menait en bateau sur son avancement...)
Bref, avec ce genre de test, on l'aurait vu tout de suite

C'est pour vérifier la véracité du CV que l'on parle de test, si dans votre société vous faites faire des entretiens pour avoir des collègues sur un projet, vous repenserez à ce topic en vous disant (et si j'avais lu/écouté ces témoignages... ça n'arrive pas qu'aux autres de tomber sur des profils atroce)
Le pire, c'est que cette personne non seulement nous a fait perdre beaucoup de temps (obligeant petit à petit à reprendre certaines parties qu'il devait faire...) mais une fois le projet fini, j'ai pu voir des choses que j'avais remonté (best practices* à suivre...) non suivi et pire mal suivi ce qui obligea à réecrire certaine partie...
Mais le plus grave, c'est que travaillant en SSII elle a été replacé ailleurs, je lui ai vivement conseillé de suivre des formations mais il l'a assez mal pris

PS:* pour les best practices, elles sont le résultat de plusieurs réunions / discussions avec l'ensemble des développeur de la société. (ce ne sont pas mes best practices, mais NOS best practices) qu'il a accepté dès le début du projet (mais n'a pas respecté )

[souviron34]

Tiens, un follow-up sur ce qui avait été énoncé par IFA2377 en ce qui concerne l'ergonomie, et mes posts précédents lui répondant :

Exemple : le bouton « Démarrer » de Windows
....
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.

Windows 8.1 : le bouton démarrer fait son retour

[lysandro]

Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?

A priori, l'évaluation devrait tenir compte de l'expérience demandée par l'employeur ou proposée par le candidat.

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

La meilleure ? aucune idée. Subjectivement, un entretien technique pur assez court pour s'assurer du niveau de compétences, et une partie plus générale sur l'approche du développement et de ses contraintes : humaines, environementale (ressources réseaux, processeur, disques, etc), interoperabilité, mode dégradé, ...

« collaboration, recherche sur Google ou encore les forums comme Stack Overflow »

va plutot dans le bon sens.

Pouvez-vous donner une solution au problème d’ensembles disjoints du vétéran ?

En fait je ne comprends pas bien l'enoncé ... J'ai lu la réponse de laerne mais ça n'a pas éclairé ma lanterne plutot éteinte même ! Je n'ai pas trop le niveau en math. Mais bref

C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule

alors je me lance.

L'idée est de répertorier les intersections par élément, puis de reconstruire les ensembles disjoints en fonction des intersections. Tous les éléments appartenant à une même intersection sont dans un même ensemble. Mais je suis bien incapable de dire si cela répond ou non à l'énoncé. Le résultat est celui attendu toutefois.

Un bout de javascript qui implémente ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
function resolve ( sets ) {
	var intersections = {};
	
	for( var i = 0; i < sets.length; ++i ) {
		for( var j = 0, set = sets[i]; j < set.length; ++j ) {
			var element = set[j];
			
			if ( !(element in intersections) )
				intersections[element] = ""+i;
			else
				intersections[element] += ","+i;
		}
	}

	var disjoint_sets = [];
	var intersections_sets = {};
	
	for( var element in intersections ) {
		var intersection = intersections[element];
		
		if ( !(intersection in intersections_sets) ) {
			intersections_sets[intersection] = disjoint_sets.length;
			disjoint_sets[intersections_sets[intersection]] = [];
		}
		disjoint_sets[intersections_sets[intersection]].push(element);
	}

	return disjoint_sets;
}

PS : Je n'avais pas tout lu ... C'est une réponse similaire à celle qu'avait déjà faite alphamax666. Sauf qu'en ce qui me concerne ça m'a pris plusieurs heures ... :-))