Étant moi-même en position de recruter et gérer une équipe, mais qui déteste ça (désolé les humains mais c'est les ordis que j'aime :D), l'article m'a vachement plu.
Personnellement devoir passer 4 à 6h de travail à la maison pour un recrutement me refroidis beaucoup, je n'ai pas se temps là de disponible. Les pseudo tests techniques pendant les entretiens je suis pas fan non plus, c'est souvent très scolaires (les coding games encore plus).
Bref je suis de la "veille école", entretien technique, échange et questions réponses suffise pour moi à se faire une idée de la personne. Et si on se trompe, la période d'essai est la pour ça, que ça soit côté salarié comme employeur.
On est sur un bête marché avec offres vs demandes. Si tu reçoit X candidatures spontanées par mois, tu peux te permettre de perde du monde par un processus trop long et trop exigeant. Mais si tu as du mal à recruter, demander un test de 6h, tu passe peu être à côté d'un bon profil qui a juste une vie familiale.
Posté par gUI (Mastodon) .
Évalué à 10.
Dernière modification le 07 avril 2022 à 15:06.
A plus de 20 ans d'expérience j'ai passé mon premier test technique il y a peu (poste que j'occupe actuellement)… et c'était plutôt pas mal en fait :
Il y avait eu un soucis avec la personne précédente, donc l'équipe était un peu "méfiante" (je trouve pas d'autre mot, mais faut pas non plus exagérer). Ils me l'ont expliqué très rapidement, donc j'ai compris le contexte et accepté le test technique sans pb, alors que sinon j'aurais vraiment trouvé ça bizarre
Mon futur collègue en présentiel, une personne avec qui je dois interagir quasi quotidiennement (anglo-saxonne) en visio, et tout le test se passe en Anglais
Rien de tordu, c'était vraiment des questions assez générales et c'est ma façon de répondre qui les importait bcp plus que la précision des réponses (on a tous Internet au bureau… )
Le poste est pour du C dans l'embarqué (modules IoT industriels), et les questions étaient du style :
voici le code d'une interruption, qu'est-ce que tu peux en dire (il a suffit que je tombe de la chaise en y voyant un printf() pour qu'ils soient contents de ma réponse)
que signifie le mot clé static en C pour une variable ? pour une fonction ?
je me rappelle plus trop du reste mais un truc autour des buffers tournants je crois…
Bref c'était à la fois précis sur les besoins du poste (de la technique directement appliquée, pas des algos à la con que tu n'utiliseras jamais) et peu précis dans l'attente des réponses : ils voulaient savoir si j'allais me démerder, pas si je savais tout par cœur.
De plus ça a été torché en 1h tout compris, sachant que à chaque fois on discutait un peu autour, du contexte, de l'anecdote… bref plutôt détendu et sympa quoi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Personnellement devoir passer 4 à 6h de travail à la maison pour un recrutement me refroidis beaucoup, je n'ai pas se temps là de disponible.
Ca me parait pas délirant pour moi. On te file un problème ou deux, tu les résouds, tu montres ton code à l'entretien. 4 à 6h quand tu veux changer de boulot, tu les trouves (ou alors c'est que t'es pas motivé). Et pendant l'entretien ça peut servir comme départ de discussion.
Et si t'y connais rien de rien, personne perd de temps. Et rien que le sujet donné, ça peut aussi dissuader un candidat, s'il voit que c'est à des kilomètres de ce qu'il imaginait.
Les pseudo tests techniques pendant les entretiens je suis pas fan non plus, c'est souvent très scolaires (les coding games encore plus).
Bah on attend d'un dev qu'il publie du code quand même, non? Et je préfère 100x qu'on me demande de coder un fizzbuzz plutôt qu'on me demande pour la 1000e fois mes diplômes et qu'on me fasse une analyse graphologique suivie des questions 3 qualités 3 défauts et où vous vous voyez dans 5 ans?
Bref je suis de la "veille école", entretien technique
faut définir ce que tu entends par "entretien technique". Juste au dessus tu dis "je ne suis pas fan".
Bah on attend d'un dev qu'il publie du code quand même, non? Et je préfère 100x qu'on me demande de coder un fizzbuzz plutôt qu'on me demande pour la 1000e fois mes diplômes et qu'on me fasse une analyse graphologique suivie des questions 3 qualités 3 défauts et où vous vous voyez dans 5 ans?
Bah ni l'un ni l'autre ne m'enchante.
Déjà les tests techniques sur papier/tableau blanc c'est ridicule, PERSONNE ne développe dans cette situation. On a tous notre environnement préféré, bien configuré, avec de l'autocomplétion, de la coloration syntaxique, de la suggestion de correction… et un accès Internet sur lequel on peut aller chercher de la doc' et/ou des exemples.
Et sur la façon de procéder par l'OP de l'article, j'appelle ça "faire travailler quelqu'un gratos". Alors oui, il confronte le candidat à ce qu'il va vraiment devoir affronter s'il est engagé. Mais en attendant, il gagne potentiellement 4/6H de travail non-rémunéré. Si on fait ça avec des centaines de candidats, on peut p'têtre sortir un produit sans même avoir lâché le moindre centime pour la force de travaille accaparée.
Le rêve capitaliste sans doute. Mais bien loin de mes idéaux. Je suis en entretient pour monnayer ma force de travail, il est évident que si l'on me demande de travailler sans rémunération, j'irai voir ailleurs. Peu importe la qualité du poste et de la rémunération.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Déjà les tests techniques sur papier/tableau blanc c'est ridicule, PERSONNE ne développe dans cette situation.
Je parlais pas d'un tableau blanc, mais d'un PC devant lequel on te colle pour faire un exo. Après, un tableau blanc pour écrire du pseudo code, ça peut aussi le faire.
Et sur la façon de procéder par l'OP de l'article, j'appelle ça "faire travailler quelqu'un gratos". Alors oui, il confronte le candidat à ce qu'il va vraiment devoir affronter s'il est engagé. Mais en attendant, il gagne potentiellement 4/6H de travail non-rémunéré.
N'exagérons pas. Je parle de petites épreuves qui ont été travaillées par l'équipe de recrutement. Et je m'attends pas à retrouver le code produit dans un logiciel (Et imaginer qu'une boite puisse sortir un logiciel uniquement en comptant sur les recrutements, ça me parait assez bancal).
A côté de ça, peaufiner ton CV et ta lettre de motivation ça a du demander quelques heures? (enfin, c'est ce que j'ai fait plusieurs fois pour des postes, se renseigner sur la boite, etc..). Donc bon, publier quelques lignes de code et les expliquer, ça me parait pas le bout du monde.
Et pour le côté "gratos", est-ce que tu vas parler de tes expériences dans l'ancienne boîte? Des projets en cours? Des clients? De contrats chiffrés? D'un organigramme? Ce genre d'infos ça vaut largement plus que 4h de dev à mon avis…
Par entretien technique j'entends des questions réponses, échange sur des problématiques, retour d'expériences etc…
Parce que les tests du genre : trouve l undefined behavior dans du code c d'exemples que tu aurais jamais écrit de cette manière là, niveau pertinence c'est bien nulle je trouve.
J'ai fait passer pas mal d'entretien tous niveau (plutôt orienté C embarquée), rien qu'avec quelques questions basique du style : Qu'est ce que les design pattern, citez en moi 3 et à quoi ils servent, tu vois vite le niveau.
Entre ceux qui savent même pas ce que c'est, ce qui te cite le singleton uniquement, ceux qui te sorte la factory mais maîtrise pas le concept et ceux qui maîtrise le sujet, tu le vois vite, pas besoin d'écrire la moindre ligne de code.
Et pour du niveau plus technique tu peux aller chercher le niveau de curiosité du profil, si pour du C orienté embarqué, la personne est capable de t'expliquer le programmation asynchrone (event loop /libuv base de nodejs) ou de t'expliquer le modèle derrière les goroutines de go, tu sais que tu as à faire à quelqu'un de curieux et qui est pas resté bloqué sur le seul modèle multithread/mutex appris à l'école.
Pas besoin de code pour ça.
Pour mesurer la capacité des gens à faire de l'analyse de bugfix, pas besoin d'exercices pour ça non plus.
Après je recherche des personnes au profil complet, je veux dire par là que sa capacité à "pisser" de la ligne de code n'est qu'une petite portion.
Je ne vois pas trop la différence en fait :-) Toi, ton besoin est de savoir si la personne qui candidate connait le design pattern ; l'autre son besoin est de savoir si la personne sait traiter le genre de problématique qui sera rencontré dans un délai raisonnable (noter que les quatre heures ne sont pas imposées et que les six heures sont une limite fixée mais non vérifiée.) L'assertion selon laquelle on fait faire du travail gratos ne tient que si le code en question va entrer en prod, alors que là ça va servir de base de discussion entre les deux parties tout en faisant ressortir clairement les besoins (là par exemple on s'en fiche que la personne puisse citer trois forme de design pattern mais on veut plustôt voir voir si elle en a identifié et utilisé puis discuter de son choix et des approches choisies.)
Je ne pense pas qu'il soit vraiment suggéré que c'est La Méthode universelle non plus, mais que c'est un exemple de ce qui a été mis en place après avoir identifié les besoins (dans ton cas ça peut se faire en deux out trois questions et tant mieux pour toi) et les écueils qu'on aimerait éviter (ici en pas induire le syndrome du tableau blanc mais laisser les candidats coder dans leurs environnements et en ayant accès aux ressources, etc.)
Bien sûr, si tu n'as pas Ce Temps, pas de souci ; ce n'est pas une entreprise faite pour toi et tu ne le découvres pas sur le tard. Moi par exemple, j'évite les boîtes qui me demande un CV word (aucun lien avec les tests techniques mais c'est pour l'idée) parce-que je n'ai pas le temps et la motivation de m'inscrire dans ce genre de truc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
J'ai fait passer pas mal d'entretien tous niveau (plutôt orienté C embarquée), rien qu'avec quelques questions basique du style : Qu'est ce que les design pattern, citez en moi 3 et à quoi ils servent, tu vois vite le niveau.
Avec ton processus, tu me recalerais sûrement très rapidement. Honnêtement j'ai dû coder dans suffisamment de bases de code pour avoir rencontré une énorme quantité de "design patterns". Ce que je fais, c'est lire le code, voir comment il fonctionne, quelle est la logique et l'organisation, puis corriger les bugs ou implémenter des trucs en suivant la même logique et organisation. Connaître le nom de ce "pattern" n'a strictement aucun intérêt pour moi, sauf peut-être à sortir des grands mots lors des soirées de l'ambassadeur geeks.
Même les design patterns que j'ai appris dans mes études et donc dont je connaissais même le nom et la logique théorique (en plus de la compréhension pratique car quand je lis du code bien organisé, je suis pas stupide et je comprends tout aussi bien la logique derrière les divers choix organisationnels sans avoir besoin du nom), je suis pas sûr si je saurais retrouver les noms facilement (faudrait fouiller dans ma mémoire). En fait tout ces trucs de par cœur (genre retenir des noms qu'une personne lambda — sûrement un manager — s'est juste dit un jour qu'elle pourrait nommer un concept, pour ensuite balancer ça dans un livre quelconque, alors que tout ceux qui codent vraiment au jour le jour utilisent sans se poser ce genre de questions de nommage étrange), je comprendrais jamais et je m'empresse d'oublier. Perso j'exècre le par-cœur. Je lis mon code, je réfléchis, je recherche, j'échange avec d'autres développeurs au besoin, et j'essaie de trouver des solutions aux problèmes et d'organiser le code de manière propre et maintenable. Je me pose pas la question de savoir si l'arrangement de mon code a un nom ou si je devrais le nommer.
Enfin bon, tout ça pour dire qu'avec de telles questions totalement ridicules (pour qui fait du code en vrai, pas du nommage), tu m'aurais simplement disqualifié d'office. Pourtant je suis persuadé que j'aurais aucun mal à travailler sur du C orienté embarqué (pas que j'en ai beaucoup fait, en tous cas pas professionnellement pour ce qui est du côté "embarqué", mais bon… je sais que j'ai le niveau pour apprendre rapidement puisque j'apprends constamment des trucs en codant… en vrai, pas avec des mots tirés de livres; quant au C, je pense que la preuve de mon expérience et la qualité de mon code n'est plus à faire avec la quantité de code public donc rembarrer des candidats sur des histoires de nommage serait ridicule).
Tout ça pour dire que ramener un "test" à la maison ne m'enchanterait certes pas (genre on se croirait à l'école, on ramène des devoirs). Mais à la limite, et au moins, on me demanderait de faire du vrai code, pas de régurgiter des mots appris par cœur, tirés d'un livre quelconque sur les design patterns, ou autre.
la personne est capable de t'expliquer le programmation asynchrone (event loop /libuv base de nodejs) ou de t'expliquer le modèle derrière les goroutines de go, tu sais que tu as à faire à quelqu'un de curieux et qui est pas resté bloqué sur le seul modèle multithread/mutex appris à l'école.
Pareil, c'est n'importe quoi. Je n'utilise pas nodejs ni n'ai jamais rien écrit en go. Je pourrais pas t'expliquer ce que permet libuv (donc une bibliothèque C pour nodejs d'après une rapide recherche; y a des bibliothèques en quantité extraordinaire et genre tu vas considérer que la connaissance de cette bibliothèque est éliminatoire, comme si un bon dév qui ne la connaîtrait pas déjà ne pourrait pas — je sais pas moi, au hasard… — apprendre! 🙄) ou comment marchent les goroutines de go (voire même ce que c'est tout court). Par contre ça ne veut aucunement dire que je ne pourrais pas écrire du js avec Node.js ou du go! Si on me plonge dans un code que je dois débugger alors déjà le fait de lire, on commence rapidement à comprendre les bases logiques du langage. Rien que ça permet déjà de corriger des bugs, même dans des langages qu'on n'a jamais utilisés auparavant (sisi, je l'ai déjà fait plusieurs fois; il m'est arrivé de contribuer des patchs à des projets dont je n'avais jamais utilisé le langage de programmation avant, puis possiblement jamais après; et mes patchs ont été acceptés). Puis après, pour aller plus loin, il y a ce truc intéressant qui s'appelle "Internet" (pour ceux qui connaissent) et cette sous-partie surtout appelée "web". On peut y faire des recherches et y a des gens qui y laissent des docs pour quasi tout. Sisi, je vous jure! Donc franchement, si un boulot m'intéresse et qu'il nécessite d'apprendre de nouvelles technologies, ben je les apprendrai, pas de problème. Mais si avant même d'avoir le boulot, on essaie de me tendre des pièges en demandant des trucs sur les technologies que je devrais apprendre… comment dire… ce serait insultant et totalement hors de propos?
Enfin bon, interroger un candidat sur des technologies particulières et en tirer des conclusions genre "c'est pas quelqu'un de curieux"… je veux même pas chercher à nommer une telle attitude. Je sais écrire du code dans sûrement plus d'une dizaine de langages (mais clairement, il y en a certains que je pratique plus que d'autres), et non j'apprends pas de nouveaux langages de programmation par "curiosité". J'ai aussi utilisé quantité de plateformes logicielles, une de plus ou de moins n'est pas un problème. J'apprends déjà bien assez de trucs quasi tous les jours pour ne pas avoir à justifier quoi que ce soit si j'étais un candidat pour un emploi. J'apprends donc ce qui me sert (ce qui peut être un nouveau langage si je dois l'utiliser pas juste "par curiosité").
Et je pense que si je te faisais la liste des technologies et langages que j'ai utilisés pour du vrai code (pas des exercices) — et encore maintenant j'apprends constamment de nouveaux trucs — tu te permettrais pas de sortir qu'un gars comme moi est pas curieux et est resté bloqué à l'école (en fait ça me fait plus penser l'inverse, de croire que les technologies qu'on utilise soi-même sont forcément les plus importantes donc que toute personne qui ne les connaît pas ne serait pas un programmeur curieux ou de bon niveau me donne une étrange impression de fermeture d'esprit technique).
En tant que mainteneur de GIMP, je suis au contraire très conscient de ce que je connais ou non tout en accueillant à bras ouvert ceux qui apportent des choses nouvelles et qui savent des trucs que moi j'ignore. Je leur demande pas de savoir la même chose que moi, ça permet aux contributeurs comme à moi-même de constamment évoluer ensemble, en coopération. Typiquement il m'arrive d'expliquer un truc que je connais depuis des années (et donc que je pourrais considérer comme "basique" sauf que non justement!) à un contributeur qui serait extrêmement doué, voire expérimenté, mais n'a simplement pas eu la même histoire et les mêmes expériences que moi. Jamais il ne me vient à l'esprit de me dire "quoi il connaît même pas ça? Il est nul!" Ce serait totalement ridicule, contre-productif, insultant et faux. De même très régulièrement j'apprends moi-même des trucs nouveaux qui sont apportés/expliqués par d'autres contributeurs qui ont d'autres connaissances que moi. Parfois (souvent?) j'apprends même des trucs de jeunes développeurs beaucoup moins expérimentés et qui font parfois même des erreurs de débutants et pourtant ont un potentiel énorme et ont des connaissances complémentaires (donc au final, j'apprends aussi).
En conclusion, je trouve perso que se permettre de juger des candidats sur des trucs genre des questions théoriques de cours ("design pattern") ou des détails de technologies particulières (plateformes, langages, logiciels…), ce serait insultant et exactement le genre d'entreprises que j'éviterais. Perso je promeus le respect des gens en plus (rapport aux "tu vois vite le niveau" et "tu sais que tu as à faire à quelqu'un de curieux" -> c'est d'un tel niveau raz-des-pâquerettes humainement, d'oser sortir cela, que ça m'as fait sauté au plafond).
Pour l'article en lien, je ne saurais dire si je suis d'accord sur tout, mais je trouve la démarche intéressante et j'aime beaucoup que l'auteur a une réflexion et un processus très humains (c'est à dire qu'il cherche à considérer le candidat comme un être humain et à avoir un rapport agréable, qu'il le sélectionne ou non au final). D'ailleurs cette personne explique ne pas vraiment donner un devoir et abandonner le candidat mais en gros, communiquer ensemble comme dans une vraie équipe. C'est assez intéressant. Je cherche pas de boulot (je suis de toutes façons très sélectif sur pour qui j'accepte de travailler), mais à la limite si je devais, ça me tenterait déjà plus de faire un tel entretien plutôt que celui que tu proposerais.
P.S.: en fait ce qui m'a choqué dans ce commentaire, c'est le coup du "tu vois vite le niveau" et "quelqu'un de curieux et qui est pas resté bloqué", tout ce côté insultant dans la vision qu'un employeur ne devrait surtout pas avoir d'un candidat (mais malheureusement c'est trop souvent le cas), et en plus le fait que le moindre de tes exemples que tu sembles considérer éliminatoire, j'aurais échoué. Alors que je pense que quiconque oserait dire qu'un profil comme le mien ne serait pas capable de travailler sur du C embarqué, ce serait ridicule. Que je sois pas le meilleur candidat parmi d'autres, sûrement (notamment si d'autres ont déjà de l'expérience dans un emploi similaire et connaissent déjà toutes les technologies en question), mais de là à être éliminé direct avec mentions "pas le niveau" et "pas curieux", ben tu vois, je met sérieusement en doute ton système de recrutement. Ensuite je veux bien mettre cela sur le fait que tu t'es peut-être mal exprimé et que peut-être une entrevue se passerait un peu différemment, c'est à dire mieux que ce que tu laisses entendre dans tes dires. Mais là comme ça, ça donne pas envie. 😜
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
AMHA il faut voir la question des design pattern comme juger le niveau en anglais. Les 2 ont a même fonction : permettre de communiquer. Perso mon niveau d'anglais est éliminatoire pour beaucoup d'entreprises que l'anglais soit effectivement une langue du quotidien ou non dans le poste visé.
Posté par gUI (Mastodon) .
Évalué à 8.
Dernière modification le 08 avril 2022 à 11:15.
Perso mon niveau d'anglais est éliminatoire pour beaucoup d'entreprises
Voilà, excellent exemple de recaler qqu'un pour rien : avec mon niveau d'Anglais de merde j'ai quand même été pris chez Intel (environnement ultra international, travail quotidien avec des Américains, des Indiens et des Chinois). Oui, j'ai galéré… 3 mois. Après c'était plus un problème. J'y suis resté 7 ans. Maintenant j'ai un niveau sympa qui me permet de bosser à l'aise.
Alors à moins de vouloir juste embaucher le mec pour 6 mois, je pense que en faire un critère éliminatoire reste une erreur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc… Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc…
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.
Ok c'est effectivement plus acceptable présenté ainsi. 🙂
Pour revenir sur la connaissance de certains concepts, genre la programmation par évènement, un bon programmeur débutant pourrait ne pas connaître cela mais apprendre très vite (c'est vraiment pas si compliqué une fois qu'on a pigé la logique). Dans les débutants qu'on voit qui font des patchs dans GIMP, certains vont certes avoir des problèmes sur les trucs les plus basiques (et tu vas faire 10 A/R juste pour des détails genre le style de code, pour lesquels certains ne semblent pas piger l'idée derrière les instructions donc le font mal 9 fois de suite). Mais y en a certains qui pigent tout super vite. Et oui à un moment, en proposant des patchs de plus en plus compliqués, ils en viennent nécessairement à devoir faire de la gestions de signaux ou autres évènements asynchrones. Et là on voit tout de suite que la personne qui pige vite, ben elle va aussi piger ça très vite. Certes le premier patch, elle fera des erreurs basiques de logique (quand elle découvre le concept), puis plus ça va, moins il y a d'erreur et plus on voit qu'elle comprend et devient efficace.
Si ça avait été un recrutement comme tu proposes (et non un logiciel libre) et que je lui avais demandé si elle connaissait des concepts de programmation asynchrone (pour répondre à ta remarque si ce terme est trop théorique pour moi: ça va, "synchrone/asynchrone", je classe pas ça dans la théorie 🤣. C'est pas un nom abscons de bouquin pour une bête organisation de code, c'est un mot de tous les jours qui a un sens même en dehors du logiciel; et en développement on retrouve même ces termes dans les noms de fonctions… genre tout le temps 🙄), à la limite la personne connaîtrait pas, ça me gênerait pas plus que ça si j'ai vu son code et que je me ferais pas de doute qu'elle comprendrait alors très vite. Toi tu lui aurais donné un malus dans ton évaluation et ça se trouve, tu passais à côté d'une perle.
Je dis ce genre de trucs avec l'expérience d'avoir vu passer et fait la revue de code de plusieurs centaines de patchs (je vois que — depuis qu'on utilise Gitlab, soit 2018 — nous avons mergé 443 merge requests — dont la plupart j'ai fait la revue personnellement, sans compter les gens qui mettent simplement des fichiers *.patch dans les rapports de bug; et avant d'avoir Gitlab, on utilisait Bugzilla donc c'est un chiffre très partiel; ça en fait du code dont j'ai fait la revue, des patchs basiques de warnings aux trucs les plus complexes). Dernièrement par exemple, on a un jeune très doué qui s'est mis à faire plein de patchs. Il fait encore des erreurs régulièrement, et je vois bien qu'il découvre la plupart des notions nouvelles qu'une base de code comme la notre contient. Mais on voit aussi qu'il a vraiment envie d'apprendre, il pose des questions sur IRC (notamment sur la théorie des couleurs puisqu'il souhaite proposer de travailler dessus pour un gsoc, et on voit vraiment qu'il absorbe nos réponses pour partir étudier davantage dans son coin, car c'est des sujets très très compliqués; et bien sûr aussi quelques questions sur du code), et quand je lui fais une revue, j'ai juste à lui dire une fois, puis il corrige direct bien (même quand c'est un truc compliqué et possiblement nouveau pour lui, mais je suppose qu'il fait comme tous les bons développeurs apprennent à faire: quand on comprend pas la revue, on relit le code autant de fois qu'il le faut pour essayer de comprendre ce qui a été dit, et éventuellement on fait des recherches avec les mots clés donnés; puis à la fin, on demande si on comprend vraiment pas, mais en général, une bonne revue donne tous les mots clés suffisants pour découvrir et comprendre par soi-même). En tous cas, je suis persuadé que s'il continue, il pourrait devenir un très bon développeur et pourtant il ne serait possiblement pas capable de répondre à aucune de tes questions ni à même de faire mes réponses puisqu'il faut souvent avoir l'expérience pour pouvoir répondre à quelqu'un que sa question théorique ne sert à rien ou bien que ce qu'il ne sait pas, il l'apprendra vite (un débutant n'aurait pas forcément le recul pour répondre ainsi). Et c'est là où j'ai le sentiment que ton processus de sélection a un gros défaut (par rapport à ce que tu en dis du moins)
Par contre, échanger avec ce débutant autour de code, tu vois tout de suite qu'il évoluera vite. 😛
Donc perso je suis pas sûr si vraiment ce genre de question est très pertinent (enfin sauf si tu ne veux absolument pas engager de débutant bien sûr). Enfin bon, ensuite chacun son expérience et ses choix. :-)
Et bon, j'ai bien compris que tu ne jugerais pas que sur ça de toutes façons.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En général je fais peu d'entretiens et je passe au moins deux heures pour chacun.
Dans le cas présent, tu es fixé sur ce qui est attendu en face (ça va donc plus vite que la période d'essai qui ne servira alors plus qu'à découvrir les collègues et l'outillage mis en place.) Et la vieille école est encore plus axée sur des tests scolaires qui n'ont rien à voir avec le poste en général, ce qui est un peu en contradiction avec ce que tu réclames non ? Tu trouves que montrer ton savoir-faire sur une presque vraie problématique en étant au chaud est plus long que se taper : 1h aller + 1h retour + temps de préparation avant (sauf si t'y vas à poil et au saut du lit) + temps d'attente + au moins une demie heures de questions scolaires à mille lieu de ce que tu auras à faire (pour l'instant j'exclus le blah-blah autour) + plus le temps de préparation chez soi à ce genre de trucs (c'est certes mutualisé si t'arrives à faire un certain nombre d'entretiens) + lettre de motivation manuscrite pour le graphologue + le questionnaire de magazine de jeu pour le psychologue, bref 4h ou plus d'agitation inutile tout en ayant une vie familiale.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je me permet de clarifier et compléter mon propos qui est pas mal détourné.
L'entretien technique est généralement fait en visio, 1h de créneau est demandé mais généralement ça dure que 30 minutes. L'idée est de ne pas faire perdre de temps à la fois au recruteur et à la fois au candidat. C'est le fait de vouloir faire les choses rapidement qui vous choque ?
Encore une fois, plus un processus est long et ou exigeant plus tu risques de perdre du monde en cours de route. Parce que ce que vous semblez oublier ici, c'est qu'un candidat a assez souvent plusieurs pistes en parallèle, si chaque société demande 4h de travail c'est vite infernal.
Et encore une fois, la période d'essai reste importante et elle est finalement le "vrai" test, travail au quotidien et sur le temps longs. Des deux côtés on veut se rassurer mais vouloir faire une "micro période essai" en amont de l'entretien ne me paraît vraiment pas mieux ni plus humain.
Parce que en période d'essai, la loi protège le salarié et c'est temps mieux, si jamais l'employeur te dit que ça le fait pas, tu te retrouve pas sans rien.
# Chouette
Posté par cg . Évalué à 6.
Étant moi-même en position de recruter et gérer une équipe, mais qui déteste ça (désolé les humains mais c'est les ordis que j'aime :D), l'article m'a vachement plu.
Ça m'a fait penser à cette article (en Anglais) : https://m.signalvnoise.com/hiring-programmers-with-a-take-home-test/
[^] # Re: Chouette
Posté par Tangi Colin . Évalué à 10.
Personnellement devoir passer 4 à 6h de travail à la maison pour un recrutement me refroidis beaucoup, je n'ai pas se temps là de disponible. Les pseudo tests techniques pendant les entretiens je suis pas fan non plus, c'est souvent très scolaires (les coding games encore plus).
Bref je suis de la "veille école", entretien technique, échange et questions réponses suffise pour moi à se faire une idée de la personne. Et si on se trompe, la période d'essai est la pour ça, que ça soit côté salarié comme employeur.
On est sur un bête marché avec offres vs demandes. Si tu reçoit X candidatures spontanées par mois, tu peux te permettre de perde du monde par un processus trop long et trop exigeant. Mais si tu as du mal à recruter, demander un test de 6h, tu passe peu être à côté d'un bon profil qui a juste une vie familiale.
[^] # Re: Chouette
Posté par PR . Évalué à 1. Dernière modification le 07 avril 2022 à 12:57.
Bah, le vrai test, c’est de savoir le degré de soumission du candidat…
Mort aux cons !
[^] # Re: Chouette
Posté par Misc (site web personnel) . Évalué à 5.
Mais non, suffit de le faire sur tes horaires de boulot, en expliquant que tu évalues une nouvelle méthode de recruter dans la boite.
[^] # Re: Chouette
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 07 avril 2022 à 15:06.
A plus de 20 ans d'expérience j'ai passé mon premier test technique il y a peu (poste que j'occupe actuellement)… et c'était plutôt pas mal en fait :
printf()pour qu'ils soient contents de ma réponse)staticen C pour une variable ? pour une fonction ?Bref c'était à la fois précis sur les besoins du poste (de la technique directement appliquée, pas des algos à la con que tu n'utiliseras jamais) et peu précis dans l'attente des réponses : ils voulaient savoir si j'allais me démerder, pas si je savais tout par cœur.
De plus ça a été torché en 1h tout compris, sachant que à chaque fois on discutait un peu autour, du contexte, de l'anecdote… bref plutôt détendu et sympa quoi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Chouette
Posté par octane . Évalué à 6.
Ca me parait pas délirant pour moi. On te file un problème ou deux, tu les résouds, tu montres ton code à l'entretien. 4 à 6h quand tu veux changer de boulot, tu les trouves (ou alors c'est que t'es pas motivé). Et pendant l'entretien ça peut servir comme départ de discussion.
Et si t'y connais rien de rien, personne perd de temps. Et rien que le sujet donné, ça peut aussi dissuader un candidat, s'il voit que c'est à des kilomètres de ce qu'il imaginait.
Bah on attend d'un dev qu'il publie du code quand même, non? Et je préfère 100x qu'on me demande de coder un fizzbuzz plutôt qu'on me demande pour la 1000e fois mes diplômes et qu'on me fasse une analyse graphologique suivie des questions 3 qualités 3 défauts et où vous vous voyez dans 5 ans?
faut définir ce que tu entends par "entretien technique". Juste au dessus tu dis "je ne suis pas fan".
[^] # Re: Chouette
Posté par Nibel . Évalué à 3.
Bah ni l'un ni l'autre ne m'enchante.
Déjà les tests techniques sur papier/tableau blanc c'est ridicule, PERSONNE ne développe dans cette situation. On a tous notre environnement préféré, bien configuré, avec de l'autocomplétion, de la coloration syntaxique, de la suggestion de correction… et un accès Internet sur lequel on peut aller chercher de la doc' et/ou des exemples.
Et sur la façon de procéder par l'OP de l'article, j'appelle ça "faire travailler quelqu'un gratos". Alors oui, il confronte le candidat à ce qu'il va vraiment devoir affronter s'il est engagé. Mais en attendant, il gagne potentiellement 4/6H de travail non-rémunéré. Si on fait ça avec des centaines de candidats, on peut p'têtre sortir un produit sans même avoir lâché le moindre centime pour la force de travaille accaparée.
Le rêve capitaliste sans doute. Mais bien loin de mes idéaux. Je suis en entretient pour monnayer ma force de travail, il est évident que si l'on me demande de travailler sans rémunération, j'irai voir ailleurs. Peu importe la qualité du poste et de la rémunération.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Chouette
Posté par octane . Évalué à 3.
Je parlais pas d'un tableau blanc, mais d'un PC devant lequel on te colle pour faire un exo. Après, un tableau blanc pour écrire du pseudo code, ça peut aussi le faire.
N'exagérons pas. Je parle de petites épreuves qui ont été travaillées par l'équipe de recrutement. Et je m'attends pas à retrouver le code produit dans un logiciel (Et imaginer qu'une boite puisse sortir un logiciel uniquement en comptant sur les recrutements, ça me parait assez bancal).
A côté de ça, peaufiner ton CV et ta lettre de motivation ça a du demander quelques heures? (enfin, c'est ce que j'ai fait plusieurs fois pour des postes, se renseigner sur la boite, etc..). Donc bon, publier quelques lignes de code et les expliquer, ça me parait pas le bout du monde.
Et pour le côté "gratos", est-ce que tu vas parler de tes expériences dans l'ancienne boîte? Des projets en cours? Des clients? De contrats chiffrés? D'un organigramme? Ce genre d'infos ça vaut largement plus que 4h de dev à mon avis…
[^] # Re: Chouette
Posté par Tangi Colin . Évalué à 3.
Par entretien technique j'entends des questions réponses, échange sur des problématiques, retour d'expériences etc…
Parce que les tests du genre : trouve l undefined behavior dans du code c d'exemples que tu aurais jamais écrit de cette manière là, niveau pertinence c'est bien nulle je trouve.
J'ai fait passer pas mal d'entretien tous niveau (plutôt orienté C embarquée), rien qu'avec quelques questions basique du style : Qu'est ce que les design pattern, citez en moi 3 et à quoi ils servent, tu vois vite le niveau.
Entre ceux qui savent même pas ce que c'est, ce qui te cite le singleton uniquement, ceux qui te sorte la factory mais maîtrise pas le concept et ceux qui maîtrise le sujet, tu le vois vite, pas besoin d'écrire la moindre ligne de code.
Et pour du niveau plus technique tu peux aller chercher le niveau de curiosité du profil, si pour du C orienté embarqué, la personne est capable de t'expliquer le programmation asynchrone (event loop /libuv base de nodejs) ou de t'expliquer le modèle derrière les goroutines de go, tu sais que tu as à faire à quelqu'un de curieux et qui est pas resté bloqué sur le seul modèle multithread/mutex appris à l'école.
Pas besoin de code pour ça.
Pour mesurer la capacité des gens à faire de l'analyse de bugfix, pas besoin d'exercices pour ça non plus.
Après je recherche des personnes au profil complet, je veux dire par là que sa capacité à "pisser" de la ligne de code n'est qu'une petite portion.
[^] # Re: Chouette
Posté par octane . Évalué à 4.
intéressant, merci
[^] # Re: Chouette
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Je ne vois pas trop la différence en fait :-) Toi, ton besoin est de savoir si la personne qui candidate connait le design pattern ; l'autre son besoin est de savoir si la personne sait traiter le genre de problématique qui sera rencontré dans un délai raisonnable (noter que les quatre heures ne sont pas imposées et que les six heures sont une limite fixée mais non vérifiée.) L'assertion selon laquelle on fait faire du travail gratos ne tient que si le code en question va entrer en prod, alors que là ça va servir de base de discussion entre les deux parties tout en faisant ressortir clairement les besoins (là par exemple on s'en fiche que la personne puisse citer trois forme de design pattern mais on veut plustôt voir voir si elle en a identifié et utilisé puis discuter de son choix et des approches choisies.)
Je ne pense pas qu'il soit vraiment suggéré que c'est La Méthode universelle non plus, mais que c'est un exemple de ce qui a été mis en place après avoir identifié les besoins (dans ton cas ça peut se faire en deux out trois questions et tant mieux pour toi) et les écueils qu'on aimerait éviter (ici en pas induire le syndrome du tableau blanc mais laisser les candidats coder dans leurs environnements et en ayant accès aux ressources, etc.)
Bien sûr, si tu n'as pas Ce Temps, pas de souci ; ce n'est pas une entreprise faite pour toi et tu ne le découvres pas sur le tard. Moi par exemple, j'évite les boîtes qui me demande un CV word (aucun lien avec les tests techniques mais c'est pour l'idée) parce-que je n'ai pas le temps et la motivation de m'inscrire dans ce genre de truc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Chouette
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Avec ton processus, tu me recalerais sûrement très rapidement. Honnêtement j'ai dû coder dans suffisamment de bases de code pour avoir rencontré une énorme quantité de "design patterns". Ce que je fais, c'est lire le code, voir comment il fonctionne, quelle est la logique et l'organisation, puis corriger les bugs ou implémenter des trucs en suivant la même logique et organisation. Connaître le nom de ce "pattern" n'a strictement aucun intérêt pour moi, sauf peut-être à sortir des grands mots lors des soirées de
l'ambassadeurgeeks.Même les design patterns que j'ai appris dans mes études et donc dont je connaissais même le nom et la logique théorique (en plus de la compréhension pratique car quand je lis du code bien organisé, je suis pas stupide et je comprends tout aussi bien la logique derrière les divers choix organisationnels sans avoir besoin du nom), je suis pas sûr si je saurais retrouver les noms facilement (faudrait fouiller dans ma mémoire). En fait tout ces trucs de par cœur (genre retenir des noms qu'une personne lambda — sûrement un manager — s'est juste dit un jour qu'elle pourrait nommer un concept, pour ensuite balancer ça dans un livre quelconque, alors que tout ceux qui codent vraiment au jour le jour utilisent sans se poser ce genre de questions de nommage étrange), je comprendrais jamais et je m'empresse d'oublier. Perso j'exècre le par-cœur. Je lis mon code, je réfléchis, je recherche, j'échange avec d'autres développeurs au besoin, et j'essaie de trouver des solutions aux problèmes et d'organiser le code de manière propre et maintenable. Je me pose pas la question de savoir si l'arrangement de mon code a un nom ou si je devrais le nommer.
Enfin bon, tout ça pour dire qu'avec de telles questions totalement ridicules (pour qui fait du code en vrai, pas du nommage), tu m'aurais simplement disqualifié d'office. Pourtant je suis persuadé que j'aurais aucun mal à travailler sur du C orienté embarqué (pas que j'en ai beaucoup fait, en tous cas pas professionnellement pour ce qui est du côté "embarqué", mais bon… je sais que j'ai le niveau pour apprendre rapidement puisque j'apprends constamment des trucs en codant… en vrai, pas avec des mots tirés de livres; quant au C, je pense que la preuve de mon expérience et la qualité de mon code n'est plus à faire avec la quantité de code public donc rembarrer des candidats sur des histoires de nommage serait ridicule).
Tout ça pour dire que ramener un "test" à la maison ne m'enchanterait certes pas (genre on se croirait à l'école, on ramène des devoirs). Mais à la limite, et au moins, on me demanderait de faire du vrai code, pas de régurgiter des mots appris par cœur, tirés d'un livre quelconque sur les design patterns, ou autre.
Pareil, c'est n'importe quoi. Je n'utilise pas nodejs ni n'ai jamais rien écrit en go. Je pourrais pas t'expliquer ce que permet
libuv(donc une bibliothèque C pour nodejs d'après une rapide recherche; y a des bibliothèques en quantité extraordinaire et genre tu vas considérer que la connaissance de cette bibliothèque est éliminatoire, comme si un bon dév qui ne la connaîtrait pas déjà ne pourrait pas — je sais pas moi, au hasard… — apprendre! 🙄) ou comment marchent les goroutines de go (voire même ce que c'est tout court). Par contre ça ne veut aucunement dire que je ne pourrais pas écrire du js avec Node.js ou du go! Si on me plonge dans un code que je dois débugger alors déjà le fait de lire, on commence rapidement à comprendre les bases logiques du langage. Rien que ça permet déjà de corriger des bugs, même dans des langages qu'on n'a jamais utilisés auparavant (sisi, je l'ai déjà fait plusieurs fois; il m'est arrivé de contribuer des patchs à des projets dont je n'avais jamais utilisé le langage de programmation avant, puis possiblement jamais après; et mes patchs ont été acceptés). Puis après, pour aller plus loin, il y a ce truc intéressant qui s'appelle "Internet" (pour ceux qui connaissent) et cette sous-partie surtout appelée "web". On peut y faire des recherches et y a des gens qui y laissent des docs pour quasi tout. Sisi, je vous jure! Donc franchement, si un boulot m'intéresse et qu'il nécessite d'apprendre de nouvelles technologies, ben je les apprendrai, pas de problème. Mais si avant même d'avoir le boulot, on essaie de me tendre des pièges en demandant des trucs sur les technologies que je devrais apprendre… comment dire… ce serait insultant et totalement hors de propos?Enfin bon, interroger un candidat sur des technologies particulières et en tirer des conclusions genre "c'est pas quelqu'un de curieux"… je veux même pas chercher à nommer une telle attitude. Je sais écrire du code dans sûrement plus d'une dizaine de langages (mais clairement, il y en a certains que je pratique plus que d'autres), et non j'apprends pas de nouveaux langages de programmation par "curiosité". J'ai aussi utilisé quantité de plateformes logicielles, une de plus ou de moins n'est pas un problème. J'apprends déjà bien assez de trucs quasi tous les jours pour ne pas avoir à justifier quoi que ce soit si j'étais un candidat pour un emploi. J'apprends donc ce qui me sert (ce qui peut être un nouveau langage si je dois l'utiliser pas juste "par curiosité").
Et je pense que si je te faisais la liste des technologies et langages que j'ai utilisés pour du vrai code (pas des exercices) — et encore maintenant j'apprends constamment de nouveaux trucs — tu te permettrais pas de sortir qu'un gars comme moi est pas curieux et est resté bloqué à l'école (en fait ça me fait plus penser l'inverse, de croire que les technologies qu'on utilise soi-même sont forcément les plus importantes donc que toute personne qui ne les connaît pas ne serait pas un programmeur curieux ou de bon niveau me donne une étrange impression de fermeture d'esprit technique).
En tant que mainteneur de GIMP, je suis au contraire très conscient de ce que je connais ou non tout en accueillant à bras ouvert ceux qui apportent des choses nouvelles et qui savent des trucs que moi j'ignore. Je leur demande pas de savoir la même chose que moi, ça permet aux contributeurs comme à moi-même de constamment évoluer ensemble, en coopération. Typiquement il m'arrive d'expliquer un truc que je connais depuis des années (et donc que je pourrais considérer comme "basique" sauf que non justement!) à un contributeur qui serait extrêmement doué, voire expérimenté, mais n'a simplement pas eu la même histoire et les mêmes expériences que moi. Jamais il ne me vient à l'esprit de me dire "quoi il connaît même pas ça? Il est nul!" Ce serait totalement ridicule, contre-productif, insultant et faux. De même très régulièrement j'apprends moi-même des trucs nouveaux qui sont apportés/expliqués par d'autres contributeurs qui ont d'autres connaissances que moi. Parfois (souvent?) j'apprends même des trucs de jeunes développeurs beaucoup moins expérimentés et qui font parfois même des erreurs de débutants et pourtant ont un potentiel énorme et ont des connaissances complémentaires (donc au final, j'apprends aussi).
En conclusion, je trouve perso que se permettre de juger des candidats sur des trucs genre des questions théoriques de cours ("design pattern") ou des détails de technologies particulières (plateformes, langages, logiciels…), ce serait insultant et exactement le genre d'entreprises que j'éviterais. Perso je promeus le respect des gens en plus (rapport aux "tu vois vite le niveau" et "tu sais que tu as à faire à quelqu'un de curieux" -> c'est d'un tel niveau raz-des-pâquerettes humainement, d'oser sortir cela, que ça m'as fait sauté au plafond).
Pour l'article en lien, je ne saurais dire si je suis d'accord sur tout, mais je trouve la démarche intéressante et j'aime beaucoup que l'auteur a une réflexion et un processus très humains (c'est à dire qu'il cherche à considérer le candidat comme un être humain et à avoir un rapport agréable, qu'il le sélectionne ou non au final). D'ailleurs cette personne explique ne pas vraiment donner un devoir et abandonner le candidat mais en gros, communiquer ensemble comme dans une vraie équipe. C'est assez intéressant. Je cherche pas de boulot (je suis de toutes façons très sélectif sur pour qui j'accepte de travailler), mais à la limite si je devais, ça me tenterait déjà plus de faire un tel entretien plutôt que celui que tu proposerais.
P.S.: en fait ce qui m'a choqué dans ce commentaire, c'est le coup du "tu vois vite le niveau" et "quelqu'un de curieux et qui est pas resté bloqué", tout ce côté insultant dans la vision qu'un employeur ne devrait surtout pas avoir d'un candidat (mais malheureusement c'est trop souvent le cas), et en plus le fait que le moindre de tes exemples que tu sembles considérer éliminatoire, j'aurais échoué. Alors que je pense que quiconque oserait dire qu'un profil comme le mien ne serait pas capable de travailler sur du C embarqué, ce serait ridicule. Que je sois pas le meilleur candidat parmi d'autres, sûrement (notamment si d'autres ont déjà de l'expérience dans un emploi similaire et connaissent déjà toutes les technologies en question), mais de là à être éliminé direct avec mentions "pas le niveau" et "pas curieux", ben tu vois, je met sérieusement en doute ton système de recrutement. Ensuite je veux bien mettre cela sur le fait que tu t'es peut-être mal exprimé et que peut-être une entrevue se passerait un peu différemment, c'est à dire mieux que ce que tu laisses entendre dans tes dires. Mais là comme ça, ça donne pas envie. 😜
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chouette
Posté par barmic 🦦 . Évalué à 4.
AMHA il faut voir la question des design pattern comme juger le niveau en anglais. Les 2 ont a même fonction : permettre de communiquer. Perso mon niveau d'anglais est éliminatoire pour beaucoup d'entreprises que l'anglais soit effectivement une langue du quotidien ou non dans le poste visé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Chouette
Posté par gUI (Mastodon) . Évalué à 8. Dernière modification le 08 avril 2022 à 11:15.
Voilà, excellent exemple de recaler qqu'un pour rien : avec mon niveau d'Anglais de merde j'ai quand même été pris chez Intel (environnement ultra international, travail quotidien avec des Américains, des Indiens et des Chinois). Oui, j'ai galéré… 3 mois. Après c'était plus un problème. J'y suis resté 7 ans. Maintenant j'ai un niveau sympa qui me permet de bosser à l'aise.
Alors à moins de vouloir juste embaucher le mec pour 6 mois, je pense que en faire un critère éliminatoire reste une erreur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Chouette
Posté par Tangi Colin . Évalué à 2.
Je vois que mes explications ton choqué (tu dis que je t'ai fait sauter au plafond) et je m'en excuse alors mais je pense que tu as mal perçu mon propos, sans doute un soucis de passer par l'écris, je pense pas que tu aurais eu ce genre de réaction avec moi à l'oral. Je sais pas comment te convaincre mais je m'estime plutôt bienveillant pendant mes entretiens, j'explique le processus de question/réponse (qui n'ai pas un script fixe écrit à l'avance d'ailleurs mais plutôt un échange avec le candidat par rapport à son expérience passé et ses envies futures), qu'il n'y pas de mauvaise réponse, que rien n'est éliminatoire etc… Et j'ai plutôt des bon retours sur les candidats que j'auditionne par rapport à ma bienveillance donc bref je suis pas la bête inhumaine de recruteur que tu as lu entre mes lignes.
J'ai vu des personnes ultra stressé qui trouver plus leur mot, et à ce moment tu prends le temps pour justement éviter un avis trop hâtifs, tu tente de le rassurer, tu pose des questions lié à l'expérience du candidat avant de retourner à des questions plus pointus etc…
Dans ton commentaire, y a plusieurs points sur lesquels j'aimerai rebondir:
Ta réponse de dire:
"Je connais pas les notions théoriques/le nommage précis derrière les design pattern mais je m'en fiche parce que c'est pas ce que je fais au quotidien, je lis beaucoup de code existant et je sais m'intégrer avec et ceci dans des projets open-source important" est pour moi une réponse VALIDE.
On aurait échangé la dessus et j'aurais certainement mis un avis positif à la sortie. Ici je résume ma vision d'un entretien technique, en réel je pose plus que 3 questions mais quelques soit la questions aucune réponse même "mauvaise" n'est éliminatoire, c'est sur l'ensemble que j'apporte un jugement.
Alors le fait de porter un jugement sur quelqu'un t'hérisse peut être le poil mais c'est le but même d'un entretien, émettre un avis sur quelqu'un pour savoir si il pourra répondre au besoin ou non et je vais te choquer mais c'est en plus complétement subjectif comme processus, tu évalue à la fois la technique mais aussi la capacité de la personne à discuter de sa technique, parce que aujourd'hui je recrute des personnes pour du travail en équipe. ça m'est arrivé de mettre un avis négatif à un profil ultra compétant mais totalement imbue de sa personne et je voulais pas prendre le risque d'avoir un TechLead compétant mais toxique pour l'équipe (c'est que les Rh appelle soft & hard skill).
Concernant libuv tu m'as mal compris, c'était juste un exemple, je demande pas la maitrise de libuv ou libev ou autres, je demande la maitrise/compréhension des concepts de la programmation orienté asynchrone (avec des callback quoi si le terme "programmation asynchrone est trop théorique pour toi).
Pourquoi je le demande, parce que c'est rarement un mode de programmation qui est appris en école (les écoles s'arrête généralement au multithread avec mutex). Donc si la personne connait la programmation asynchrone pour du C bas niveau, ça montre une personne curieuse, qui regarde ce qui se fait ailleurs, bref fait une veille techno ce qui est pour moi un critère très important. Encore une fois ici, c'est un plus, un bon indicateur mais c'est pas éliminatoire.
Et pour revenir au débat initiale, le "faire un test 4 à 6H pour évaluer ton niveau technique" à faire chez soi est pas forcément plus humain, ça peut être vu comme vexant pour des profils expérimenter de devoir passer par ce "devoir à la maison". Bref y a pas de solution parfaite mais je trouve la moins invasive (tout en restant efficace) pour un candidat, reste encore l'entretient technique avec questions-réponses, partage d'expérience et des ses envies futures.
[^] # Re: Chouette
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 08 avril 2022 à 15:09.
Ok c'est effectivement plus acceptable présenté ainsi. 🙂
Pour revenir sur la connaissance de certains concepts, genre la programmation par évènement, un bon programmeur débutant pourrait ne pas connaître cela mais apprendre très vite (c'est vraiment pas si compliqué une fois qu'on a pigé la logique). Dans les débutants qu'on voit qui font des patchs dans GIMP, certains vont certes avoir des problèmes sur les trucs les plus basiques (et tu vas faire 10 A/R juste pour des détails genre le style de code, pour lesquels certains ne semblent pas piger l'idée derrière les instructions donc le font mal 9 fois de suite). Mais y en a certains qui pigent tout super vite. Et oui à un moment, en proposant des patchs de plus en plus compliqués, ils en viennent nécessairement à devoir faire de la gestions de signaux ou autres évènements asynchrones. Et là on voit tout de suite que la personne qui pige vite, ben elle va aussi piger ça très vite. Certes le premier patch, elle fera des erreurs basiques de logique (quand elle découvre le concept), puis plus ça va, moins il y a d'erreur et plus on voit qu'elle comprend et devient efficace.
Si ça avait été un recrutement comme tu proposes (et non un logiciel libre) et que je lui avais demandé si elle connaissait des concepts de programmation asynchrone (pour répondre à ta remarque si ce terme est trop théorique pour moi: ça va, "synchrone/asynchrone", je classe pas ça dans la théorie 🤣. C'est pas un nom abscons de bouquin pour une bête organisation de code, c'est un mot de tous les jours qui a un sens même en dehors du logiciel; et en développement on retrouve même ces termes dans les noms de fonctions… genre tout le temps 🙄), à la limite la personne connaîtrait pas, ça me gênerait pas plus que ça si j'ai vu son code et que je me ferais pas de doute qu'elle comprendrait alors très vite. Toi tu lui aurais donné un malus dans ton évaluation et ça se trouve, tu passais à côté d'une perle.
Je dis ce genre de trucs avec l'expérience d'avoir vu passer et fait la revue de code de plusieurs centaines de patchs (je vois que — depuis qu'on utilise Gitlab, soit 2018 — nous avons mergé 443 merge requests — dont la plupart j'ai fait la revue personnellement, sans compter les gens qui mettent simplement des fichiers
*.patchdans les rapports de bug; et avant d'avoir Gitlab, on utilisait Bugzilla donc c'est un chiffre très partiel; ça en fait du code dont j'ai fait la revue, des patchs basiques de warnings aux trucs les plus complexes). Dernièrement par exemple, on a un jeune très doué qui s'est mis à faire plein de patchs. Il fait encore des erreurs régulièrement, et je vois bien qu'il découvre la plupart des notions nouvelles qu'une base de code comme la notre contient. Mais on voit aussi qu'il a vraiment envie d'apprendre, il pose des questions sur IRC (notamment sur la théorie des couleurs puisqu'il souhaite proposer de travailler dessus pour un gsoc, et on voit vraiment qu'il absorbe nos réponses pour partir étudier davantage dans son coin, car c'est des sujets très très compliqués; et bien sûr aussi quelques questions sur du code), et quand je lui fais une revue, j'ai juste à lui dire une fois, puis il corrige direct bien (même quand c'est un truc compliqué et possiblement nouveau pour lui, mais je suppose qu'il fait comme tous les bons développeurs apprennent à faire: quand on comprend pas la revue, on relit le code autant de fois qu'il le faut pour essayer de comprendre ce qui a été dit, et éventuellement on fait des recherches avec les mots clés donnés; puis à la fin, on demande si on comprend vraiment pas, mais en général, une bonne revue donne tous les mots clés suffisants pour découvrir et comprendre par soi-même). En tous cas, je suis persuadé que s'il continue, il pourrait devenir un très bon développeur et pourtant il ne serait possiblement pas capable de répondre à aucune de tes questions ni à même de faire mes réponses puisqu'il faut souvent avoir l'expérience pour pouvoir répondre à quelqu'un que sa question théorique ne sert à rien ou bien que ce qu'il ne sait pas, il l'apprendra vite (un débutant n'aurait pas forcément le recul pour répondre ainsi). Et c'est là où j'ai le sentiment que ton processus de sélection a un gros défaut (par rapport à ce que tu en dis du moins)Par contre, échanger avec ce débutant autour de code, tu vois tout de suite qu'il évoluera vite. 😛
Donc perso je suis pas sûr si vraiment ce genre de question est très pertinent (enfin sauf si tu ne veux absolument pas engager de débutant bien sûr). Enfin bon, ensuite chacun son expérience et ses choix. :-)
Et bon, j'ai bien compris que tu ne jugerais pas que sur ça de toutes façons.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Chouette
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
En général je fais peu d'entretiens et je passe au moins deux heures pour chacun.
Dans le cas présent, tu es fixé sur ce qui est attendu en face (ça va donc plus vite que la période d'essai qui ne servira alors plus qu'à découvrir les collègues et l'outillage mis en place.) Et la vieille école est encore plus axée sur des tests scolaires qui n'ont rien à voir avec le poste en général, ce qui est un peu en contradiction avec ce que tu réclames non ? Tu trouves que montrer ton savoir-faire sur une presque vraie problématique en étant au chaud est plus long que se taper : 1h aller + 1h retour + temps de préparation avant (sauf si t'y vas à poil et au saut du lit) + temps d'attente + au moins une demie heures de questions scolaires à mille lieu de ce que tu auras à faire (pour l'instant j'exclus le blah-blah autour) + plus le temps de préparation chez soi à ce genre de trucs (c'est certes mutualisé si t'arrives à faire un certain nombre d'entretiens) + lettre de motivation manuscrite pour le graphologue + le questionnaire de magazine de jeu pour le psychologue, bref 4h ou plus d'agitation inutile tout en ayant une vie familiale.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Chouette
Posté par Tangi Colin . Évalué à 1.
Je me permet de clarifier et compléter mon propos qui est pas mal détourné.
L'entretien technique est généralement fait en visio, 1h de créneau est demandé mais généralement ça dure que 30 minutes. L'idée est de ne pas faire perdre de temps à la fois au recruteur et à la fois au candidat. C'est le fait de vouloir faire les choses rapidement qui vous choque ?
Encore une fois, plus un processus est long et ou exigeant plus tu risques de perdre du monde en cours de route. Parce que ce que vous semblez oublier ici, c'est qu'un candidat a assez souvent plusieurs pistes en parallèle, si chaque société demande 4h de travail c'est vite infernal.
Et encore une fois, la période d'essai reste importante et elle est finalement le "vrai" test, travail au quotidien et sur le temps longs. Des deux côtés on veut se rassurer mais vouloir faire une "micro période essai" en amont de l'entretien ne me paraît vraiment pas mieux ni plus humain.
Parce que en période d'essai, la loi protège le salarié et c'est temps mieux, si jamais l'employeur te dit que ça le fait pas, tu te retrouve pas sans rien.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.