Discussion :

[imikado]

moi je t'ai mis -1 imikado

Premièrement merci de me répondre et d'argumenter

Un CRUD, moi ça me ferai mal que tu me demandes ça, ça fait 15 ans que j'en fais, sauf que pendant 10 ans on appelait pas ça un CRUD.
Et puis ça sert à quoi de faire un CRUD si tu sais pas modéliser ?

La modélisation se fait en réunion avec d'autres développeurs/dba.. (selon la taille du projet) mais je suis d'accord qu'on pourrait rajouter des exercices de reflexion, par exemple un cas et on lui demanderait de modéliser une base pour répondre au besoin...
Des tests on peut en ajouter à foison, mais le test du CRUD j'ai suffisament détaillé et argumenté pour comprendre pourquoi ce test est interessant, ce que l'on apprend du candidat sur cette mini application

Après on peut imaginer juste un formulaire d'inscription avec un formulaire de login aussi
Le tout c'est de demander au candidat de coder quelque chose d'assez simple pour être faisable en 1h et assez complet pour pouvoir regarder plusieurs elements
Mais je ne suis pas braqué sur le CRUD, que proposez-vous comme application web à faire en 1H ou moins (pas trop long non plus, on va pas lasser le candidat

Plutôt que de demander un CRUD, déjà une jointure un peu complexe, et on va peut être plus rigoler, une requête sous requête avec un exist, une agrégation quelconque. 5 minutes et on rentre dans l'utile, pas dans le B.A.BA

Un test sQL peut venir s'ajouter en effet quelques petites requetes à faire pour retourner certains enregistrements
Mais pour moi ça complète, ça ne remplace pas: on veut savoir si quand il va commencer à coder en php, il sait coder/debuger... et surtout cette histoire d'estimation de charge

On est dans un métier où il faut être bon en tout, en tout cas moi je l'ai appris comme ça le métier.

+1

On m'a jamais demandé de faire des CRUD 40h/semaine,

Vous restez braqué sur le CRUD en entier, vous avez déjà coder en web, vous avez déjà lister des enregistrements (tableau, teléchargement d'excel...) et developpé des formulaires d'ajout/modification, non ? on parle déjà de CRU (le D n'est pas toujours développé selon les application) (on préfère changer un état que supprimer la donnée en base)

Et être adaptable, aimable, Agile comme la méthode avant même que vous en parliez dans vos grandes écoles...

Vos grandes écoles ?? Personnellement je suis autodidacte

Bref moi je suis pas un Ouvrier Spécialisé, mon CV c'est pas 30 lignes d'expériences de 3 mois, c'est 3 lignes qui durent plusieurs années, et plusieurs années à faire bien vivre des boites et des applis. Dans ce métier, dans ce secteur ça veut dire quelque chose. Et je bosse toujours hein...

Je n'en doute pas, le vétéran avec qui on a une mauvaise surprise ne manquait pas d'expérience, et on lui faisait confiance quand au contenu de son CV, ce n'est pas l'objet de mes propos, on veut savoir si le candidat sait estimer une charge... cf mon post précédent

Si je fais ce job avec ce parcours, et que tu lis mon CV et que tu comprends pas que je sais développer parce que rien dans mon profil ne me destine à ce job, t'es un gland, et tu mérites ta super-capote.

Je ne vois pas ce que supercapote fait là, pour information c'est un site de prévention que je développe depuis plusieurs années, c'est un moyen de prévention différent des sites AIDES, Actup.. qui complète d'une manière différente l'offre en manière de prévention

Tu fais un CRUD, et tu vois quoi en fin de compte de la personne ? rien nibe

J'ai détaillé dans mon post précédent tout ce que l'on peut voir avec cet exercice, mais je ne suis pas braqué sur le CRUD ça peut etre une autre application web, proposez, mais quelque chose de simple et rapide (moins d'1h)

Et si en plus tu fais ça avec un mec comme moi, 42 ans, vétéran selon la définition en informatique en France , tu passes à coté de tout l'impalpable, tout ce qui s'écrit pas dans un CV, [(...)
Mais ça t'es peut-être trop jeune pour comprendre ?

J'ai 31 ans pour information, mais je discute en entretien sans apriori et autre, d'ailleurs la discussion post exercice est interessante

Moi vous me faites sourire, c'est sur des brêles vous avez du en croiser, quand je vous lis, on dirait que vous êtes tous des cadors. Tu penses qu'à mon age les cadors, j'en ai croisé, surtout que je suis passé par des boites de haut vol, où toutes les grandes SSII sont présentes, et les cadors avec.
Et je pourrais en raconter, parce que c'est ça aussi l'expérience, c'est du recul.

Et donc ? que proposez-vous ? un mauvais choix fait perdre beaucoup de temps (on parle en mois) entre le temps de s'apercevoir du niveau réel et de voir que l'on a plus le temps de faire des recrutements pour former une nouvelle personne à nos environnements, au projet... et donc on doit continuer avec (reprendre des parties car il est trop en retard ou ne comprend pas assez vite...)

Mais bon je sais que vous n'êtes pas tous des cadors, loin s'en faut. Moi j'en suis pas un, mais je le sais. Et c'est un avantage.

Je n'ai jamais dit que j'étais un cador, on ne parle pas de ça ici

J'ai un bon salaire parce que je le mérite, pas par mon diplôme et la grille à la con, je le vole à personne, et je fais mon job parce qu'il m'amuse.

Tant mieux, personnellement je suis autodidacte, mon salaire reflète mon travail et non mon école/diplome

T'en as combien ici qui passé 25 ou 30 ans ne toucheront plus à rien de ce qu'ils n'ont pas fait à l'école, aussi grande l'école soit elle. Des mecs qui font du java du PHP ou du C depuis 15 ans et qui ne feront rien d'autre parce que c'est plus difficile de se remettre en question que de vivre sur ses acquis.

Je continue toujours de coder, c'est mon travail principal même si je commence à chapoter un peu plus certains projets d'autre developpeurs..
Et comme je l'ai dit je suis autodidacte, je suis arrivé dans la profession par PASSION


Et donc, que proposez-vous ? à part un test de requete SQL ?

[zaventem]

Et donc, que proposez-vous ? à part un test de requete SQL ?

En discutant moins d'un quart d'heure, tu sais si le gars en face de toi saura faire un CRUD ou pas. Après, le vrai boulot c'est pas de faire qu'un CRUD (ou on serait déjà tous remplacé par un stagiaire). Ce qu'on demande aux gens avec de l'expérience, c'est de pouvoir agir dans les cas tordus et délicats et pas de chance, ton test d'une heure ne leur permettra pas de montrer de quoi ils sont capables.

Passe cette heure à discuter avec eux, parle leur des cas tordu que t'as eu dernièrement et écoute leur avis, c'est le meilleur moyen de voir s'ils pourront t'apporter quelque chose.

[LSMetag]

moi je t'ai mis -1 imikado

De toute façon je vous lis tous depuis le début de ce post, et pffff....

Un CRUD, moi ça me ferai mal que tu me demandes ça, ça fait 15 ans que j'en fais, sauf que pendant 10 ans on appelait pas ça un CRUD.
Et puis ça sert à quoi de faire un CRUD si tu sais pas modéliser ?

Plutôt que de demander un CRUD, déjà une jointure un peu complexe, et on va peut être plus rigoler, une requête sous requête avec un exist, une agrégation quelconque. 5 minutes et on rentre dans l'utile, pas dans le B.A.BA

On est dans un métier où il faut être bon en tout, en tout cas moi je l'ai appris comme ça le métier.

On m'a jamais demandé de faire des CRUD 40h/semaine, on m'a demandé de faire de l'avant-vente, du conseil, de la mise en place de projets, du développement, de la modélisation, de l'admin serveurs et services, du dev et de l'admin SQL, de la sécurité, du support du 1er au 3 niveau, des DRP, des PRA, de la maintenance corrective et tout le reste; Pour des systèmes qui sont en prod, et pas depuis hier.

Et puis bon en tout, ça veut dire bon en HTML, CSS, JS, VB, Java, SQL, IIS, win server, réseaux, protocoles, PKI, ETL...
Et être adaptable, aimable, Agile comme la méthode avant même que vous en parliez dans vos grandes écoles...

Bref moi je suis pas un Ouvrier Spécialisé, mon CV c'est pas 30 lignes d'expériences de 3 mois, c'est 3 lignes qui durent plusieurs années, et plusieurs années à faire bien vivre des boites et des applis. Dans ce métier, dans ce secteur ça veut dire quelque chose. Et je bosse toujours hein...

Un truc que tu pourras pas voir dans ce CV, ça fait 10 ans que je fais vivre ma boite tout seul, que je suis le seul technicien, le seul. Alors je suis pas un crack, mais je suis fiable, plus fiable que les machines que t'achètes chez ton fournisseur préféré. Mais ça tu le vois pas dans le CV ou bien à me faire faire un CRUD en 1 heure.

Tu verras pas non plus que j'ai pas de chef, que je suis autonome, que je me démerde toute l'année (et ça putain tu vas pas le voir avec ton test en temps chrono), que mon boss et mes clients sont à 400 bornes, que je gère et que je me gère. Le boss envoie les factures, les clients paient, et tout le monde sourit.

Et moi dans ce CV je vais baratiner personne, c'est marqué que mon seul diplôme reconnu par l'état c'est un diplôme de psycho, et que j'ai fait une formation non diplômante de webmaster, datant d'il y a 15 ans. Que j'ai été community manager avant, avant que le nom même existe, et infographiste aussi, sur photoshop ou director, pas pour faire mumuse, on m'a toujours payé pour ça.

Si je fais ce job avec ce parcours, et que tu lis mon CV et que tu comprends pas que je sais développer parce que rien dans mon profil ne me destine à ce job, t'es un gland, et tu mérites ta super-capote.

Et là encore tu ne vois que la partie pro, parce que la partie bénévolat, c'est FAI à ma petite échelle, réseaux radios longue distance, bonne connaissance voire expertise sur les réseaux 802.11, plus là encore projets à défendre, budgets, se prendre par la main tout seul, faire vivre une association et faire en sorte que ça marche sur le long terme...

Tu fais un CRUD, et tu vois quoi en fin de compte de la personne ? rien nibe

Et si en plus tu fais ça avec un mec comme moi, 42 ans, vétéran selon la définition en informatique en France , tu passes à coté de tout l'impalpable, tout ce qui s'écrit pas dans un CV, l'expérience , celle des problèmes, des situations difficiles, des mises en prod réussies ou touchy, des migrations de données incontournables pour gagner le marché, l'expérience des cons, collègues ou clients, le savoir-vivre que n'ont pas tous "les trous du cul".
Je connais comment marche le métier, ses acteurs, les SSII, les DSI, mais aussi et ça c'est plus rare, j'ai le contact des utilisateurs finaux, pour mon cas, les gens du marcom, de la comm, de la créa, de la prod audiovisuel, de la pub.

Mais ça t'es peut-être trop jeune pour comprendre ?

Moi vous me faites sourire, c'est sur des brêles vous avez du en croiser, quand je vous lis, on dirait que vous êtes tous des cadors. Tu penses qu'à mon age les cadors, j'en ai croisé, surtout que je suis passé par des boites de haut vol, où toutes les grandes SSII sont présentes, et les cadors avec.
Et je pourrais en raconter, parce que c'est ça aussi l'expérience, c'est du recul.

Mais bon je sais que vous n'êtes pas tous des cadors, loin s'en faut. Moi j'en suis pas un, mais je le sais. Et c'est un avantage.

Allez pour finir, le vétéran, ben tu vois en plus de son job en ce moment, ben il est encore à fond, il s'est remis au linux après 14 ans, et ça se passe bien. Pas pour faire du dual-boot, pour faire de la prod serveur, fiable, sure, sans souci. l même prod que tu attendrais de ton admin sys.

Je me démerde, je m'amuse... Parce que je m'amuse moi dans ce métier.

Quand j'étais gamin, je m'amusais de l'informatique, aujourd'hui c'est toujours vrai. Je me fais plaisir.
Ca tu peux le demander en entretien. Un mec passionné, une fille qui s'amuse au boulot, ça c'est valable à embaucher.


J'ai un bon salaire parce que je le mérite, pas par mon diplôme et la grille à la con, je le vole à personne, et je fais mon job parce qu'il m'amuse.
T'en as combien qui font ce job pour le bon salaire, pour le statut et le diplôme et parce qu'ils vont pas se salir les mains ? Moi j'ai pas peur de me salir les mains, j'ai appris et depuis toujours en mettant les mains dans le moteur.
Tu vas le voir ça avec ton test de CRUD ?

Je me forme avec délectation à javascript en ce moment, que je connais depuis toujours, mais que je ne connais pas en fait. Je me régale, et avec mon recul, je sais ce que beaucoup de cadors ici ne savent pas de ce langage, de ce qu'il apporte, de sa puissance.

T'en as combien ici qui passé 25 ou 30 ans ne toucheront plus à rien de ce qu'ils n'ont pas fait à l'école, aussi grande l'école soit elle. Des mecs qui font du java du PHP ou du C depuis 15 ans et qui ne feront rien d'autre parce que c'est plus difficile de se remettre en question que de vivre sur ses acquis.

Et qui, pour les lire ici ou ailleurs, ont tous les arguments pour casser ce qui pourrait justement les remettre en question. Ceux là seront surement bons dans ton CRUD mais est ce que ce sera de bons éléments, pas dans les 6 mois, échelle de temps SSII, mais dans les 10 ans, échelle de temps des PME et du reste de l'économie non boursière ?
Des mecs conservateurs, des masses d'inertie, t'en as foison dans ce métier, et pourtant c'est la révolution tous les 6 mois dans le numérique.

Voilà, un recrutement c'est forcément complexe, c'est (surtout en France) forcément des risques, mais quand on définit un profil, ok mettez les 10000 technos à maitriser dans l'annonce papier, mais cogiter aussi à tout le reste, surtout pour les entretiens, tout ce qui n'est pas du factuel technique immédiat.

Enfin pour terminer, je me forme en général à la source, c'est à dire chez les anglo-saxons. C'est frappant de voir le nombre de toques grises qui perdurent dans le métier là-bas, aussi bien en dev qu'en admin ou en réseau.
C'est frappant surtout pour un français, d'autant plus quand il lit le forum ci-présent.

Je l'aurais pas dit comme ça, mais c'est également ce que je pense. J'ai abandonné les SSII parce que ce qui m'énerve, c'est que si t'as bossé sur une techno dans une autre boîte, on va vouloir te caser dans cette techno alors que quand t'es passionné, tu veux voir autre chose. On va aussi vouloir que tu sois "conforme", dans une grille. On n'aime pas les électrons libres, surtout ceux qui critiquent les choix du DSI, même quand ils ont raison (ce qui a donné des utilisateurs très mécontents).

Bref, actuellement, à 29 ans, je m'amuse sur un projet perso en DART, base NoSQL, Web Service WCF et je me documente sur le langage Scala, qui peut creuser son trou dans quelques années. Peu de chance de voir ça en entreprise.

Le défis est de trouver une petite boîte qui te prend pour ce que tu es et ce que tu peux lui apporter, pas pour ce qu'ils veulent que tu sois.
Et voila, le test technique en CRUD en temps limité, ça va pas me donner envie. J'aurai juste l'impression qu'on veut embaucher un pisseur de code, un exécutant docile, qui devra demander l'autorisation pour corriger un bug non rapporté par l'utilisateur (et qui pourra le planter dans 6 mois), assumer une technique figée (ou régie par des contrats), pour être obligé à 40 ans de quitter la technique parce qu'on aura trouvé aussi bien à 25 ans. Le tout au mépris de la qualité du produit.
Derrière, il n'y aura pas d'analyse et de conception. On ne verra pas non plus sa capacité à localiser et solutionner un problème.

[phili_b]

Et donc, que proposez-vous ?

Mais ça ne prouve rien un CRUD. Comme dit fredoche, être informaticien c'est un tout (savoir-faire, savoir-être, plusieurs compétences, etc). En fait en faisant faire un CRUD tu vas effectivement rejeter quelqu'un qui ne sait pas programmer, mais combien en auras tu rejeté qui sont stressés par les tests, qui sont des diesels (qui mettent du temps à s'y mettre), qui ne peuvent travailler que sur une vraie problématique et pas sur une fausse mise en situation.

Ce qui est clair c'est que même si tu tiens à faire ton CRUD il ne faut pas qu'il soit éliminatoire. Et inversement ne pas embaucher quelqu'un forcément parce qu’il a réussi son CRUD. En effet tu peux embaucher un dieu apparent du dév, mais qui ne testera pas ce qu'il fait, qui dit à ses chefs que ça fonctionne alors qu'il a a oublié plein de cas et que c'est buggé.

En plus ce qui est gênant dans ce post c'est l'aspect "vétéran". Putain j'ai 43 ans , et je croyais que les vétérans c'était les gens qui ont fait la guerre. D'ailleurs quand on regarde la définition cela parle des gens qui ont obtenu leur congé après avoir longtemps servi. Ou alors dans le domaine sportif cela parle des gens ayant atteinte la limite d'age à 40 ans. Donc même si certains sens de mot sont respectueux, le sens que tu lui donnes est limite méprisant. Tu rejoins les gens qui disent qu'après 40 ans on ne devrait plus programmer, et tu nous en donne 20 ans de plus. C'est marrant bien que je suis dans le monde de la BI, je n'ai jamais complétement arrêté de programmer, il faut dire que j'ai fait du Delphi avant la BI. J'ai appris le jython y'a 3 ans et le php actuellement, et bien plus que le "hello world".

Et pour revenir à la fausse mise en situation, cela déclenche pour moi le même rejet que les jeux de rôle en entretien. Bon par contre des mini-tests ou des question sur ce que c'est un pointeur, un curseur, pourquoi pas.

[imikado]

En discutant moins d'un quart d'heure, tu sais si le gars en face de toi saura faire un CRUD ou pas. Après, le vrai boulot c'est pas de faire qu'un CRUD (ou on serait déjà tous remplacé par un stagiaire). Ce qu'on demande aux gens avec de l'expérience, c'est de pouvoir agir dans les cas tordus et délicats et pas de chance, ton test d'une heure ne leur permettra pas de montrer de quoi ils sont capables.

Le cas que j'ai en tête, le developpeur avait de la bouteille, savais faire du php, et en avait déjà fait, pour son cas, l'entretien oral : pas de soucis, mais quand il a fallu coder il faisait des estimations de charge à l'ouest, ne les respectait pas et quand j'ai du le suivre pas à pas pour qu'il avance sur sa partie (qui n'a cessé de diminué au vue de l'ampleur du retard qu'il nous faisait prendre)
Et avant que j'arrive dans cette boite, ils avaient eu des developpeurs dans ce genre, mais malheureusement, comme avec celui-ci on ne faisait que des entretiens oraux, on discutait de lui, son expérience, de 2-3 concepts... mais on ne les faisait pas coder

Et pour lui, ce test de CRUD en 1h nous aurait montré
- qu'il ne savait pas estimer une charge
- qu'il n'aurait pas fini la parti qu'il aurai prévu de faire
- des nommages de codes allambiqués
- qu'il faisait des erreurs de débutant malgré son expérience

Passe cette heure à discuter avec eux, parle leur des cas tordu que t'as eu dernièrement et écoute leur avis, c'est le meilleur moyen de voir s'ils pourront t'apporter quelque chose.

Ce n'est pas une mauvaise idée de faire reflechir le candidat à un cas à résoudre, ou comme dit fredoche une modelisation de base pour répondre à un cas d'exemple.

Comme je le dis, depuis le début, je suis ouvert à toute proposition qui permettrait de ne pas avoir de nouvelles mauvaises surprises

[imikado]

Mais ça ne prouve rien un CRUD. Comme dit fredoche, être informaticien c'est un tout (savoir-faire, savoir-être, plusieurs compétences, etc). En fait en faisant faire un CRUD tu vas effectivement rejeter quelqu'un qui ne sait pas programmer, mais combien en auras tu rejeté qui sont stressés par les tests, qui sont des diesels (qui mettent du temps à s'y mettre), qui ne peuvent travailler que sur une vraie problématique et pas sur une fausse mise en situation.

Le CRUD en lui-meme est un test d'application concrete et simple qui permet de voir plusieurs choses que j'ai cité et listé
Mais après je suis ouvert aux idées, j'aime bien celle de faire un formulaire d'inscription avec une page de login
Du moment que le candidat fait une application en un temps limité :
- qu'il sait évaluer si il pourra la faire dans le temps imparti
- qu'une fois le temps fini, il sache faire un résumé de ce qu'il a réussi à faire, ce qu'il n'a pas fini...
- regarder le code écrit pour voir les noms des variables, commentaires...
- discuter avec lui des éléménts à améliorer si il avait plus de temps: sécurité, performances...
C'est facile de répéter la définition du XSS,XSRF... c'est autre chose d'expliquer comment le mettre en application concrètement

Ce qui est clair c'est que même si tu tiens à faire ton CRUD il ne faut pas qu'il soit éliminatoire. Et inversement ne pas embaucher quelqu'un forcément parce qu’il a réussi son CRUD. En effet tu peux embaucher un dieu apparent du dév, mais qui ne testera pas ce qu'il fait, qui dit à ses chefs que ça fonctionne alors qu'il a a oublié plein de cas et que c'est buggé.

On est humain je le répète, bien sur qu'il faut prendre en compte le facteur stress de l'entretien, l'editeur de code qui n'est pas forcément le sien et auquel il n'est pas habitué.
C'est pas grave si il ne finit pas dans les temps, il faut voir ce qu'il a eu le temps de faire par rapport à ce qu'il avait estimé avoir le temps de faire:
Il peut très bien dire: en 1h je peux faire le CR mais pas le UD, c'est important de savoir estimer une charge
Il faut voir cette applicatin/exercice comme une base concrète de discussion

En plus ce qui est gênant dans ce post c'est l'aspect "vétéran". Putain j'ai 43 ans , et je croyais que les vétérans c'était les gens qui ont fait la guerre. D'ailleurs quand on regarde la définition cela parle des gens qui ont obtenu leur congé après avoir longtemps servi. Ou alors dans le domaine sportif cela parle des gens ayant atteinte la limite d'age à 40 ans. Donc même si certains sens de mot sont respectueux, le sens que tu lui donnes est limite méprisant. Tu rejoins les gens qui disent qu'après 40 ans on ne devrait plus programmer, et tu nous en donne 20 ans de plus. C'est marrant bien que je suis dans le monde de la BI, je n'ai jamais complétement arrêté de programmer, il faut dire que j'ai fait du Delphi avant la BI. J'ai appris le jython y'a 3 ans et le php actuellement, et bien plus que le "hello world".

Personnellement "vétéran" n'est pas dévalorisant, on peut le remplacer par "confirmé" si vous souhaitez par opposition à débutant/junior

Et pour revenir à la fausse mise en situation, cela déclenche pour moi le même rejet que les jeux de rôle en entretien. Bon par contre des mini-tests ou des question sur ce que c'est un pointeur, un curseur, pourquoi pas.

Pour du web (en php) parler de pointeur, curseur... on peut toujours discuter de DRY/MVC/DAO/ORM... mais ça c'est la partie entretien oral, qui je le répète ne suffit pas

[fredoche]

Pour les brêles et les cadors, je ne m'adressais pas à toi imikado , mais à plusieurs que j'ai lu dans les pages précédentes, même un qui parle de défoncer son interlocuteur, même si il ne va pas plus dans ton sens.


C'est un truc que l'on vit souvent le mesurage ( de compétences, de diplômes, de b...agnoles...)

Et le pfff... c'est parce que sur ce site, pas que sur ce sujet, ça casse quand même quand t'es pas bac +5 (école groupe machin), moins de 30 ans, célibataire prêt à aller à l'autre bout du monde demain ou hier.

Alors que bon pour moi c'est une éclate quotidienne, je me sens jeune, et bien meilleur que 15 ans en arrière. je me sens comme une éponge, j'accumule du savoir, des expériences, c'est fou et c'est jouissif. Et j'en apprends tout le temps...

super pour ton site, je vais aller jeter un œil , c'était pour faire un mot, tu me l'as bien renvoyé

Et j'ai pas de solutions pour ton embauche. Je pense qu'on m'a toujours embauché au feeling, et ma foi j'ai fait en sorte de leur donner raison, parce que c'est du donnant donnant, ils me donnent de la confiance, je rends du bon boulot.
Je pense que j'irais aussi au feeling, plus sur des questions générales, des trucs un peu inattendu, genre comment marche une résolution DNS, comment on va gagner 75% de temps d'exec sur tels scripts, je vais creuser et prendre le temps, mais pas du code.

Mon 1er entretien à la sortie de formation, on m'a demandé de coder la vérification d'un numéro de carte bleue, je sortais webmaster, pas développeur... bah j'ai pas été pris, mais c'est surtout que je n'ai jamais su si ce que j'avais fait était bon ou pas. Je pense que oui, mais je ne sais pas.

15 ans après ça me turlupine toujours, et quand tu as ce type de souci, cette forme de persévérance intellectuelle, tua s un bon dev face à toi je pense. M

Donc voilà si tu fais faire un CRUD, tu corriges après avec le gars, ça c'est utile et respectueux.

[imikado]

Pour les brêles et les cadors, je ne m'adressais pas à toi imikado , mais à plusieurs que j'ai lu dans les pages précédentes, même un qui parle de défoncer son interlocuteur, même si il ne va pas plus dans ton sens.

Ok, autant pour moi

Et le pfff... c'est parce que sur ce site, pas que sur ce sujet, ça casse quand même quand t'es pas bac +5 (école groupe machin), moins de 30 ans, célibataire prêt à aller à l'autre bout du monde demain ou hier.

Developez est un très bon site, qui regroupe des profils tous différents les uns que les autres, vous trouverez des profils pour discuter/argumenter très interessant comme des petits jeunes qui découvre le site et ont une vision un peu fermée. Personnellement, quand j'ai commencé j'avais des posts moins arguménté qu'aujourd'hui (on s'assagi avec l'age et les gosses

Alors que bon pour moi c'est une éclate quotidienne, je me sens jeune, et bien meilleur que 15 ans en arrière. je me sens comme une éponge, j'accumule du savoir, des expériences, c'est fou et c'est jouissif. Et j'en apprends tout le temps...

C'est vrai que l'on peut distinguer deux grands types de developpeurs: ceux qui travaille dans ce milieu parce que ça paie bien, et ceux qui aime ce boulot
Vous devriez apprécier le podcast suivant: nipDev, cf mon billet http://blog.developpez.com/ducodeetd...ppement-nipdev

super pour ton site, je vais aller jeter un œil , c'était pour faire un mot, tu me l'as bien renvoyé

Merci, c'est un de mes sites, au menu:
Supercapote: http://supercapote.com (site de prévention)
Dupot.org: http://dupot.org (mon blog plutot nunux)
Mkdevs.com http://mkdevs.com (le site de mon framework hebergé également sur dvp)

Et j'ai pas de solutions pour ton embauche. Je pense qu'on m'a toujours embauché au feeling, et ma foi j'ai fait en sorte de leur donner raison, parce que c'est du donnant donnant, ils me donnent de la confiance, je rends du bon boulot.
Je pense que j'irais aussi au feeling, plus sur des questions générales, des trucs un peu inattendu, genre comment marche une résolution DNS, comment on va gagner 75% de temps d'exec sur tels scripts, je vais creuser et prendre le temps, mais pas du code.

Le feeling rentre en ligne de compte et sera toujours pris en compte: entre deux personnes compétentes, ce sera toujours le feeling qui fera pencher la balance (motivé, passionné, calme...)

Mon 1er entretien à la sortie de formation, on m'a demandé de coder la vérification d'un numéro de carte bleue, je sortais webmaster, pas développeur... bah j'ai pas été pris, mais c'est surtout que je n'ai jamais su si ce que j'avais fait était bon ou pas. Je pense que oui, mais je ne sais pas.
Donc voilà si tu fais faire un CRUD, tu corriges après avec le gars, ça c'est utile et respectueux.

C'est nul: l'intéret de mon CRUD ou autre application simple c'est de voir le comportement en situation réel, voir son code, et en discuter
On est pas à l'école: c'est pas une copie qu'on rend et qu'on note

[LSMetag]

Comme je le dis, depuis le début, je suis ouvert à toute proposition qui permettrait de ne pas avoir de nouvelles mauvaises surprises

Comme je t'ai dit, tu fais plusieurs entretiens en parallèle.
Tu fais l'entretien oral classique (en 30 minutes) et à la fin de celui-ci, tu soumets un mini-projet au candidat. Tu lui donnes oralement l'énoncé. Tu regardes déja si il prend des notes. Tu lui laisse ensuite 20 minutes pour y réfléchir, faire une analyse, estimer une charge et préparer des questions. Si ça te semble correctement engagé, tu le laisse faire le projet, en conditions réelles, sur une machine avec internet, à son idée.

Par contre, il ne faut pas que ce soit un truc plus stressant qu'à l'accoutumée. Comme dit précédemment, il y a les diesels, les personnes qui ont du mal avec les chronos,... Un truc qui peut être estimé entre 2 et 4h. J'imagine que les recruteurs ont tendance à partir vers 20h le soir.
Dès qu'une personne a commencé à développer, tu prends le candidat suivant. Comme ça tu peux en faire 8 par jour (avec un horaire serré). Ceux que tu auras fait passer le matin, tu les auditionnes l'après midi en live, c'est à dire en testant leur appli et en discutant de leur code. Même si ça ne te convient pas, si ces personnes défendent bien leur bifteak, ça peut quand même le faire.

Evidemment, quand une personne arrive à la fin de la charge qu'elle s'est fixée, va juste lui demander comment ça se passe. Ne pas la stresser mais voir si elle est quand même dans les clous (s'il lui manque 30 minutes, c'est pas très grave par exemple). Evidemment, à 20h, tout le monde dehors.

C'est compliqué mais c'est ce qui me semble le plus proche de la réalité.

[souviron34]

Maintenant, tu ne cherches sans doute pas des profils comme le mien...

Je crois, comme le dit fredoche, que l'illusion des jeunes, c'est qu'un vétéran se mesure à la même aune qu'un jeune...

Il leur faut les langages X, Y, Z, la techno machin-chose, et répondre au questionnaire tictactoc..

Ce qu'ils ne comprennnent pas, c'est que la plupart des vétérans (les vrais, comme toi, moi et même frédoche (bien que plus jeune), et un certain nombre d'autres ici) pourraient être - ou sont - non seulement leurs chefs, mais sans doute les chefs de leur boite, ou du plus gros projet sur lequel ils ont bossé...

Et que, à cause de l'expérience, les critères ne peuvent pas être techniques purs.. Surtout pas des "tests"...

Passe cette heure à discuter avec eux, parle leur des cas tordu que t'as eu dernièrement et écoute leur avis, c'est le meilleur moyen de voir s'ils pourront t'apporter quelque chose.

re

Enfin pour terminer, je me forme en général à la source, c'est à dire chez les anglo-saxons. C'est frappant de voir le nombre de toques grises qui perdurent dans le métier là-bas, aussi bien en dev qu'en admin ou en réseau.
C'est frappant surtout pour un français, d'autant plus quand il lit le forum ci-présent.

Le dernier boulot que j'ai eu à Montréal, après lecture de mon CV, entretien par téléphone de 10 minutes..

Questions :

1) dans votre dernier grand projet national, quelles techniques avez-vous utliilsées pour optimiser votre code en C ?
2) vous êtes dispo quand ?

C'est tout.. Embauché à 53 ans, alors que depuis 2 ans pas un seul retour en France...

Et tout le monde était parfaitement satisfait : je correspondais aux attentes, et réciproquement le mec avec qui j'ai eu l'entretien téléphonique aussi...

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

[fcharton2]

Et donc que proposez-vous ? si vous avez beaucoup de bouteille (et je n'en doute pas) ça ne devrait pas vous effrayer de faire un CRUD en 1H

Ce n'est pas le problème. Quand on a un peu d'expérience on a généralement un CV qui justifie nos compétences, avec des références que le recruteur peut appeler s'il a un doute. Il peut challenger tel ou tel point en entretien, mais faire passer un examen, ça ne donne pas une très bonne opinion de l'entreprise.

Personnellement, je n'irais pas dans une entreprise dont le responsable technique met en doute mon CV. Je ferais sans doute les tests (puisque je suis là), mais je ne prendrais pas le poste.

Vous avez déjà du recruter des personnes d'experience ? Je le rappelle on ne parle pas ici des débutants (cf le sujet du topic)
VOus ne leur avez pas fait passer de tests ?

Ben non. Autant les tests ont un sens pour des débutants qui arrivent avec un diplome qu'on ne connait pas et peu d'expérience, autant pour un senior avec un CV et des références, plus l'entretien qui permet de dépister un énorme mensonge et vérifier qu'on s'entend, je ne vois pas l'intéret.

Et de toutes façons, il y a toujours de la casse lors de la période d'essai, mais rarement sur les compétences techniques, plutôt sur l'attitude, la résistance au stress, le "cout de maintenance" du salarié...

Francois

[imikado]

Comme je t'ai dit, tu fais plusieurs entretiens en parallèle.
Tu fais l'entretien oral classique (en 30 minutes) et à la fin de celui-ci, tu soumets un mini-projet au candidat. Tu lui donnes oralement l'énoncé. Tu regardes déja si il prend des notes. Tu lui laisse ensuite 20 minutes pour y réfléchir, faire une analyse, estimer une charge et préparer des questions. Si ça te semble correctement engagé, tu le laisse faire le projet, en conditions réelles, sur une machine avec internet, à son idée.

Donc plutot de demander en 1H de faire une application simple, vous proposer en combien de temps de faire quel type d'application ? une application lourde, comme une appli de e-commercre ? un forum ?

Par contre, il ne faut pas que ce soit un truc plus stressant qu'à l'accoutumée. Comme dit précédemment, il y a les diesels, les personnes qui ont du mal avec les chronos,... Un truc qui peut être estimé entre 2 et 4h. J'imagine que les recruteurs ont tendance à partir vers 20h le soir.
Dès qu'une personne a commencé à développer, tu prends le candidat suivant. Comme ça tu peux en faire 8 par jour (avec un horaire serré). Ceux que tu auras fait passer le matin, tu les auditionnes l'après midi en live, c'est à dire en testant leur appli et en discutant de leur code. Même si ça ne te convient pas, si ces personnes défendent bien leur bifteak, ça peut quand même le faire.

Il faut prévoir une journée complète pour tester 2-3 candidats, pourquoi pas
Par contre j'ai peur que le fait d'avoir plusieurs candidats en meme temps génère un stress concernant cette "compétition"

[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

[Invité]

Les tests sont à la hauteur de ce que valent les recruteurs : si ce ne sont pas des psychologues diplômés épaulés par de solides informaticiens, ça part souvent en couilles avec des délires pas possibles et des choses irréalisables en 20 mn. Qui solutionne un problème relativement complexe en 20 mn, sauf les génies ?
Ce qui compte, c'est plutôt de pouvoir appréhender comment une personne va se comporter en situation réelle : travail en équipe, plantage en production, solution à trouver assez vite (et ça veut pas dire 20 mn, hein !), arbitrage entre deux solutions, connaissances d'un langage de programmation (et de ses pièges) via un QCM (on entend parfois des choses surprenantes sur certaines instructions). Bref, c'est quoi, faire passer un test de programmation ? C'est trop vaste. Et un féru d'algo aura toujours de bonnes notes de toute manière.

[LSMetag]

@imikado

Evidemment vous aviez 1 chance sur 100 de tomber sur ce genre de cas. J'ai l'impression que ça vous a traumatisé.

Les tests techniques ne prouvent pas grand chose. Parfois, la personne peut savoir faire parce qu'elle a bien appris sa leçon avant de venir.

Le mieux c'est de permettre à la personne de montrer qui elle est.

Tu peux leur donner un sujet au choix.
Ils font ce qu'ils veulent avec. Pour faire les fonctionnalités minimum disons qu'il faut grosso modo 1h ou 2h. Mais si tu leur donne 4h, d'une part ça les sécurisera et d'autre part ils s'approprieront le projet. D'autres pourront juste faire le minimum en 1 ou 2h si ça les gave.

Après c'est le moment d'un debrief convivial. Tu fais le ratio temps passé/fonctionnalités mises en places/qualité de code/feeling/méthodologie,...

[imikado]

@imikado

Evidemment vous aviez 1 chance sur 100 de tomber sur ce genre de cas. J'ai l'impression que ça vous a traumatisé.

1. ma boite recrute régulièrement pour des poojets, en 6 ans la boite en a eu 4-5, j'en ai connu 2 un confirmé et une debutante (diplomée bac+5)
2. je confirme que je m'en inquiète désormais et veux trouver un moyen pour ne pas que ça se reproduise (horraires à rallonge, travail le week end, travail sous pression... à cause d'un mauvais profil qui nous fait perdre du temps)

Les tests techniques ne prouvent pas grand chose. Parfois, la personne peut savoir faire parce qu'elle a bien appris sa leçon avant de venir.

Apprendre sa lecon ? comme je le dis le CRUD n'est pas forcément la bonne chose, je change mon exercice pour l'application d'authentification avec un formulaire d'inscription, et une formulaire d'authentification, c'est pas mal, il y a de la requete, du formulaire, de la gestion de session...
Donc pour mon cas, on oublie le CRUD on passe à cette petite application avec un accès privé

Tu peux leur donner un sujet au choix.
Ils font ce qu'ils veulent avec. Pour faire les fonctionnalités minimum disons qu'il faut grosso modo 1h ou 2h. Mais si tu leur donne 4h, d'une part ça les sécurisera et d'autre part ils s'approprieront le projet. D'autres pourront juste faire le minimum en 1 ou 2h si ça les gave.

Oui c'est une idée de laissé une plage et il "rend sa copie" quand il veut, il peut ainsi en 30min faire une partie "à fond" en respectant la sécurité, bien commenté... et dire voila ce que j'ai fait en 30 min: voila comment je code, on peut discutter
C'est une solution aussi, j'aime bien
Je pense que pour mon exercice j'ouvrirais cette possibilité, mais 4h ça fait une demi journée, je ne voudrais pas bloquer 4 candidats une demi journée

Après c'est le moment d'un debrief convivial. Tu fais le ratio temps passé/fonctionnalités mises en places/qualité de code/feeling/méthodologie,...

Oui ce qui est important c'est de pouvoir discuter avec comme base ce code, l'entretien technique a ainsi une base de discussion (par exemple si on lit des choses incohérente, on peut demander d'expliquer pourquoi il à fait ceci, c'est peut etre pertient