Discussion :

[GagnantPerdant]

J'ai toujours grugé à tous les tests techniques en ligne! Que ce soit le test d'entrée en formation il y a plus de 10 ans ou maintenant avec les CodinGame à la con juste pour pouvoir postuler à une offre.

Comme j'ai pas mal de potes dev qui galèrent parce qu'ils ne savent pas gruger les tests, j'ai monté mon site/SaaS pour proposer mes services! Avec essai gratuit proposé pour vérifier que c'est pas une arnaque!

Pour l'instant ça ne fait que CodinGame parce que ce sont les plus répandus chez nous mais je prévois de faire les tests HackerRank (plutôt sur le marché anglo-saxon) ou d'autres aussi s'il y a de la demande.

S'il y en a que ça intéresse...
https://www.passtest.fr

[new_wave]

C'est trop génial.

Merci.

Je refléchis à une lettre que jen pourrais envoyer aux concepteurs des tests coding game.

Et pourquoi pas un patchwork de tous les avis que j'ai récoltés sur ce site.

Ils en prendraient plein la gu.....

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

J'ai toujours grugé à tous les tests techniques en ligne! Que ce soit le test d'entrée en formation il y a plus de 10 ans ou maintenant avec les CodinGame à la con juste pour pouvoir postuler à une offre.
Comme j'ai pas mal de potes dev qui galèrent parce qu'ils ne savent pas gruger les tests, j'ai monté mon site/SaaS pour proposer mes services! Avec essai gratuit proposé pour vérifier que c'est pas une arnaque!
Pour l'instant ça ne fait que CodinGame parce que ce sont les plus répandus chez nous mais je prévois de faire les tests HackerRank (plutôt sur le marché anglo-saxon) ou d'autres aussi s'il y a de la demande.

Ça a l'air bien légal ton affaire.

[jacjac]

J'ai toujours grugé à tous les tests techniques en ligne! Que ce soit le test d'entrée en formation il y a plus de 10 ans ou maintenant avec les CodinGame à la con juste pour pouvoir postuler à une offre.

Comme j'ai pas mal de potes dev qui galèrent parce qu'ils ne savent pas gruger les tests, j'ai monté mon site/SaaS pour proposer mes services! Avec essai gratuit proposé pour vérifier que c'est pas une arnaque!

Pour l'instant ça ne fait que CodinGame parce que ce sont les plus répandus chez nous mais je prévois de faire les tests HackerRank (plutôt sur le marché anglo-saxon) ou d'autres aussi s'il y a de la demande.

S'il y en a que ça intéresse...
https://www.passtest.fr

Aya, prochain test, je prend ce service
Par contre c'est indétectable et tu utilise pas d'onglet avec internet pour faire les tests ?

[kbadache]

Pourquoi vous n'aimez pas ce genre de tests ?

Je me souviens qu'il y a quelques années tout le monde râler parce que les devs préféraient être tester sur le capacité à dev plutôt qu'a connaitre toutes les API par cœur du langage utilisé par l'entreprise.
C'est aussi mon cas.
Je suis pas du genre à apprendre les sdk par cœur, par contre, je sais résoudre des problèmes, c'est ça mon métier.
je préfère être testé sur ma capacité à analyser et à fournir du code qui maintenable que de savoir combien il y a de méthode dans la classe String de Java.

[GagnantPerdant]

Pourquoi vous n'aimez pas ce genre de tests ?

Je me souviens qu'il y a quelques années tout le monde râler parce que les devs préféraient être tester sur le capacité à dev plutôt qu'a connaitre toutes les API par cœur du langage utilisé par l'entreprise.
C'est aussi mon cas.
Je suis pas du genre à apprendre les sdk par cœur, par contre, je sais résoudre des problèmes, c'est ça mon métier.
je préfère être testé sur ma capacité à analyser et à fournir du code qui maintenable que de savoir combien il y a de méthode dans la classe String de Java.

Les tests codingame c'est 40 questions QCM (donc le "par coeur" que tu dis détester) et 2 ou 3 algos à coder qui n'ont rien à voir avec de l'analyse métier.
Quant à fournir du code de qualité et maintenable, ce n'est pas ce qui est demandé vu que c'est chronométré et que les tests sont pré-écrits.
On est dans du par coeur et du pissage de code.

[fred1599]

Pourquoi vous n'aimez pas ce genre de tests ?

1. Vitesse et précipitation amènent souvent à de bons développeurs de passer à côté d'une bonne opportunité (le développement informatique ce n'est pas une course [pisseurs de code])
2. Les tests peuvent donner une idée fausse aux développeurs du besoin métier
3. Techniquement c'est basique, pour un junior ça pourrait passer et encore (qu'est-ce que ça coûte de créer un petit test avec le dev et en parler ?), pour un senior, mieux vaut créer son propre test technique amenant à des choix techniques plus élaborés (bonnes pratiques)

Perso quand je fais passer des tests techniques, je ne regarde pas le résultat, mais la réflexion par laquelle est passée le dev pour essayer de résoudre une problématique. Ça amène à des discussions techniques et permet d'analyser l'ouverture d'esprit du dev à vouloir progresser et améliorer ses compétences. Il m'est déjà arriver de choisir des devs n'ayant pas réussi le test au dépend de celui les réussissant.

Rarement je me trompe, au pire je lui apprends plus, je prends plus de temps, mais le fait qu'il est un bon esprit, lui permet d'apprendre vite et sur des bases solides.

Perso, le dernier test coding game que j'ai passé, j'ai eu 98% sur du python, et au final j'ai perdu 1h de mon temps, car le projet n'était pas ce que j'attendais, y compris l'organisation de l'équipe et la manière dont été amené le projet. J'aurai préféré discuter avant de passer ce fichu test, je perdais une heure au lieu de deux. Concernant le test, il était totalement non représentatif du projet.

Sur ce sujet il y a beaucoup de progrès à faire, beaucoup de Lead Dev, CEO ou CTO n'ont pas d'idées précises sur la recherche de développeurs ayant du potentiel (j'insiste vraiment sur ce terme).
Et vous pouvez me croire j'en ai rencontré une paire de Lead Dev dont le management est catastrophique et ça loupe pas, tout est lié au recrutement.

[kbadache]

1. Vitesse et précipitation amènent souvent à de bons développeurs de passer à côté d'une bonne opportunité (le développement informatique ce n'est pas une course [pisseurs de code])
2. Les tests peuvent donner une idée fausse aux développeurs du besoin métier
3. Techniquement c'est basique, pour un junior ça pourrait passer et encore (qu'est-ce que ça coûte de créer un petit test avec le dev et en parler ?), pour un senior, mieux vaut créer son propre test technique amenant à des choix techniques plus élaborés (bonnes pratiques)

Perso quand je fais passer des tests techniques, je ne regarde pas le résultat, mais la réflexion par laquelle est passée le dev pour essayer de résoudre une problématique. Ça amène à des discussions techniques et permet d'analyser l'ouverture d'esprit du dev à vouloir progresser et améliorer ses compétences. Il m'est déjà arriver de choisir des devs n'ayant pas réussi le test au dépend de celui les réussissant.

Rarement je me trompe, au pire je lui apprends plus, je prends plus de temps, mais le fait qu'il est un bon esprit, lui permet d'apprendre vite et sur des bases solides.

Perso, le dernier test coding game que j'ai passé, j'ai eu 98% sur du python, et au final j'ai perdu 1h de mon temps, car le projet n'était pas ce que j'attendais, y compris l'organisation de l'équipe et la manière dont été amené le projet. J'aurai préféré discuter avant de passer ce fichu test, je perdais une heure au lieu de deux. Concernant le test, il était totalement non représentatif du projet.

Sur ce sujet il y a beaucoup de progrès à faire, beaucoup de Lead Dev, CEO ou CTO n'ont pas d'idées précises sur la recherche de développeurs ayant du potentiel (j'insiste vraiment sur ce terme).
Et vous pouvez me croire j'en ai rencontré une paire de Lead Dev dont le management est catastrophique et ça loupe pas, tout est lié au recrutement.

Je suis d'accord avec pas mal de tes points.
Si le tests demande d'aller vite, c'est un mauvais test.
Si il n'y a pas de discussion derrière, pareils, le tests est mauvais.
Un bon test technique doit montrer un capacité à comprendre et résoudre un problème ET a écrire un code maintenable et lisible...
Regarder simplement si le test répond au besoin, là aussi c'est un mauvais tests.

Par contre, sur le point : "Les tests peuvent donner une idée fausse aux développeurs du besoin métier", je ne partage pas ton avis.
Ce n'est pas le but du test, de montrer les besoins métier que l'entreprise a. Ca pourrait, mais ce n'est pas l'objectif, là on parle de tester les compétences technique d'un candidat.
Évidemment, un bon process de recrutement doit passer par une phase d'explication du métier, du quotidien des devs au sein de l'entreprise... mais c'est une phase différente.
C'est pour ça qu'il y a souvent plusieurs entretiens, un avec un RH pour échanger justement sur ce que recherche l'entreprise et ce que recherche le candidat (faut pas hésiter à poser des questions), puis un entretien technique.

[fred1599]

Par contre, sur le point : "Les tests peuvent donner une idée fausse aux développeurs du besoin métier", je ne partage pas ton avis.
Ce n'est pas le but du test, de montrer les besoins métier que l'entreprise a. Ca pourrait, mais ce n'est pas l'objectif, là on parle de tester les compétences technique d'un candidat.

Ah bon, si je recherche un dev qui travaillera sur la partie API du projet, le langage seul va-t-il suffire ? Pas me concernant en tout cas... je créerai un petit test sur ce sujet, c'est une compétence technique et un besoin métier.
Le dev va bosser sur le framework Django, je ne teste pas sa maîtrise sur ce framework ? Connaître Python suffirait ? Je peux t'assurer que non !

Du coup on est pas d'accord, mais notre expérience amène à diverger sur certains points, ce qui me semble compréhensible.

[Pyramidev]

Perso quand je fais passer des tests techniques, je ne regarde pas le résultat, mais la réflexion par laquelle est passée le dev pour essayer de résoudre une problématique. Ça amène à des discussions techniques et permet d'analyser l'ouverture d'esprit du dev à vouloir progresser et améliorer ses compétences. Il m'est déjà arriver de choisir des devs n'ayant pas réussi le test au dépend de celui les réussissant.

Rarement je me trompe, au pire je lui apprends plus, je prends plus de temps, mais le fait qu'il est un bon esprit, lui permet d'apprendre vite et sur des bases solides.

[…]

Sur ce sujet il y a beaucoup de progrès à faire, beaucoup de Lead Dev, CEO ou CTO n'ont pas d'idées précises sur la recherche de développeurs ayant du potentiel (j'insiste vraiment sur ce terme).
Et vous pouvez me croire j'en ai rencontré une paire de Lead Dev dont le management est catastrophique et ça loupe pas, tout est lié au recrutement.

Ah bon, si je recherche un dev qui travaillera sur la partie API du projet, le langage seul va-t-il suffire ? Pas me concernant en tout cas... je créerai un petit test sur ce sujet, c'est une compétence technique et un besoin métier.
Le dev va bosser sur le framework Django, je ne teste pas sa maîtrise sur ce framework ? Connaître Python suffirait ? Je peux t'assurer que non !

J'ai l'impression d'un énorme contraste entre ces deux messages.

Il existe des entreprises qui recherchent des candidats en priorité sur des compétences qui ne sont pas spécifiques aux technologies utilisées. Par exemple, j'ai connu une entreprise française qui utilisait Scala et qui était prête à recruter de temps en temps des développeurs qui n'avaient pas encore programmé en Scala. C'est dans ce genre de cas qu'on parle d'entreprises qui recherchent des candidats qui apprennent "vite et sur des bases solides".

Par contraste, toujours en France, le pire que j'ai vu, c'est le monde fermé des développeurs Django. Parmi les entreprises qui recrutent pour du Django, pour certaines d'entre elles, les seules années d'expérience qui ont de la valeur sont celles où on a fait du Django. Pour toute expérience en programmation mais sans Python, ou en Python mais hors API HTTP ou même avec Python en FastAPI, si on remplaçait par "boulanger-pâtisser", cela aurait eu la même valeur sur le CV. Si l'expérience dans laquelle on a utilisé Django n'a duré que 2 ans, on est junior, quel que soit le nombre d'années d'expérience en programmation.

Des fois, c'est à se demander si, dans ce genre d'entreprise, les développeurs Django sont vraiment développeurs ou bien seulement des experts en édition de configurations écrites en Django.

Normalement, quand on a un système avec beaucoup de logique métier et une complexité croissante, la compétence la plus précieuse, c'est le génie logiciel. Par expérience, peu de développeurs sont capables de construire un système à la fois complexe et maintenable.

[fred1599]

Salut @Pyramidev,

J'ai l'impression d'un énorme contraste entre ces deux messages.

J'ai du mal m'exprimer alors, mais c'est peut-être parce-que Python et Django n'est pas le bon exemple à prendre...

Il existe des entreprises qui recherchent des candidats en priorité sur des compétences qui ne sont pas spécifiques aux technologies utilisées

Je l'ai vu pour des jeunes sortant des études pour alimenter les ESN.

Par exemple, j'ai connu une entreprise française qui utilisait Scala et qui était prête à recruter de temps en temps des développeurs qui n'avaient pas encore programmé en Scala. C'est dans ce genre de cas qu'on parle d'entreprises qui recherchent des candidats qui apprennent "vite et sur des bases solides".

Oui ou pour des entreprises dont les connaissances se perdent pour des langages anciens comme COBOL.
Mais je dois avouer que j'en vois très peu... j'ai un exemple où l'entreprise recherchait un développeur python pour faire du ruby.

Par contraste, toujours en France, le pire que j'ai vu, c'est le monde fermé des développeurs Django. Parmi les entreprises qui recrutent pour du Django, pour certaines d'entre elles, les seules années d'expérience qui ont de la valeur sont celles où on a fait du Django. Pour toute expérience en programmation mais sans Python, ou en Python mais hors API HTTP ou même avec Python en FastAPI, si on remplaçait par "boulanger-pâtisser", cela aurait eu la même valeur sur le CV. Si l'expérience dans laquelle on a utilisé Django n'a duré que 2 ans, on est junior, quel que soit le nombre d'années d'expérience en programmation.

C'est tout à fait ça, on sort avec Django des techniques habituelles utilisables avec le langage python, l'apprentissage du framework prend un temps non négligeable, qui puis est, on a plusieurs possibilités de faire les mêmes choses, et selon l'expérience et les habitudes qu'on a prisent, on est pas tous d'accord sur la manière de l'utiliser. C'est une machine avec des rouages qui sortent un peu de la manière de penser le développement informatique et dont le but est de simplifier et développer plus rapidement.

Des fois, c'est à se demander si, dans ce genre d'entreprise, les développeurs Django sont vraiment développeurs ou bien seulement des experts en édition de configurations écrites en Django

Avant d'écrire avec Django, il faut bien comprendre ce que l'on veut et le maîtriser, puis on sait où chercher dans la documentation Django pour appliquer.
Mais ce temps de recherches, de tests, comme dit plus haut prend un temps assez important, et ce temps là, beaucoup d'entreprises n'acceptent pas de le prendre, c'est pour cela qu'on a souvent dans le recrutement "développeur Python - Django" plutôt que "développeur Python".
Je peux t'assurer que tu développes vraiment en python, mais faut avouer que Django maîtrisé, fait gagner un gain de temps dans le développement web important et permet de se préoccuper pleinement de la logique métier.
En FastAPI, c'est déjà différent, on doit bien réfléchir à l'architecture, là où on aura moins de flexibilité sur cette partie en Django.

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Les tests codingame c'est 40 questions QCM (donc le "par coeur" que tu dis détester) et 2 ou 3 algos à coder qui n'ont rien à voir avec de l'analyse métier.
Quant à fournir du code de qualité et maintenable, ce n'est pas ce qui est demandé vu que c'est chronométré et que les tests sont pré-écrits.
On est dans du par coeur et du pissage de code.

Pour l'avoir fait avec du SQL, c'était beaucoup de petites requêtes, avec le copier-coller désactivé (!!!) des noms de table et de colonne et sans aucun auto-complete...
Avoir des réponses fausses à cause d'une faute de frappe dans un nom d'objet, c'est de la malhonnêteté pure en 2023.
Tout comme passer plus de temps à vérifier sa frappe qu'à réfléchir...
De plus, passer un test SQL générique quand tu es dba MS Sql Server, c'est comme tester ton aptitude à conduire une voiture alors que tu conduis des 40 tonnes tous les jours... Le résultat n'a rien de très sérieux.

[GagnantPerdant]

Pour l'avoir fait avec du SQL, c'était beaucoup de petites requêtes, avec le copier-coller désactivé (!!!) des noms de table et de colonne et sans aucun auto-complete...
Avoir des réponses fausses à cause d'une faute de frappe dans un nom d'objet, c'est de la malhonnêteté pure en 2023.
Tout comme passer plus de temps à vérifier sa frappe qu'à réfléchir...
De plus, passer un test SQL générique quand tu es dba MS Sql Server, c'est comme tester ton aptitude à conduire une voiture alors que tu conduis des 40 tonnes tous les jours... Le résultat n'a rien de très sérieux.

Quelques précisions :
1) Le copier-coller n'est pas désactivé, pour la simple et bonne raison que leur système "anti-triche" (c'est ainsi qu'il est nommé) remonte justement les coller au recruteur.
2) De même, l'auto-completion par ctrl+espace fonctionne.
3) En revanche, si tu parles de copier depuis l'intitulé de l'exercice, c'est effectivement désactivé, ça fait partie là aussi de leur système "anti-triche". Là en effet ça conduit à une perte de productivité/temps du développeur et à des erreurs dues à des fautes de frappes, et je suis parfaitement d'accord avec toi.

[kbadache]

Ah bon, si je recherche un dev qui travaillera sur la partie API du projet, le langage seul va-t-il suffire ? Pas me concernant en tout cas... je créerai un petit test sur ce sujet, c'est une compétence technique et un besoin métier.
Le dev va bosser sur le framework Django, je ne teste pas sa maîtrise sur ce framework ? Connaître Python suffirait ? Je peux t'assurer que non !

Du coup on est pas d'accord, mais notre expérience amène à diverger sur certains points, ce qui me semble compréhensible.

Django ça reste du domaine technique, donc ça va avec le fait de tester les compétences en Python...
On peut très bien imaginer un test qui demande de créer une API.

Mais oui moi je suis plutôt du genre à penser qu'il faut tester des compétences plus global (compréhension de problème, analyse, résolution) peu importe le langage ou framework.
Tu peux prendre n'importe quel dev sénior, il est capable de répondre à un besoins avec n'importe quel langage si tu lui laisse le temps et les resourses (internet) pour le faire.
Tester les compétences spécifique à une techno à pour moi peu d’intérêt, sauf si il y a un vrai besoin d'expertise.