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 ]
[^] # Re: Chouette
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien Avez vous déjà vu... ? (du recrutement, spécialement informatique). É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'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.
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 ]