Discussion :

[foetus]

Tu es trop émotif

Tu as loupé le test, c'est comme cela, on ne peut pas revenir en arrière.
Attention, moi aussi je suis dans la même situation : avec mon profil jugé "très mauvais", je sais qu'il faut que j'ai minimum 16 - 17 sur 20 pour commencer à espérer qu'1 recruteur se dise "tiens pourquoi pas".
Et à chaque question loupée, à chaque test pas terrible, j'ai ce coup au moral ... amplifié par la stupidité des questions et que je suis encore au même point niveau recherche emploi (<- soit nul part)

Il faut se dire que si 1 employeur/ recruteur préfère choisir sur 1 heure de codingame que X mois de travail réel, il ne te mérite pas. Mais tant que la décision n'est pas prise, il faut garder le cap et continuer comme si rien n'était.
De toute manière, en étant mauvais et anxieux tu t'enfonces encore +

[Pyramidev]

@SieKensou, je viens de relire des fils que tu as créés pour ton changement de poste et tu stressais déjà avant même que le poste ne commence :

• Mai : Avis suite démission poste développeur front end
• Juin : Perte de compétences développement front suite inactivité

Je lis ici que tu as 10 ans d'expériences en web, dont plus de 7 dans le front.

Je ne sais pas comment raisonnent tes collègues mais, en tout cas, la productivité d'un développeur ne dépend pas seulement de ses bonnes connaissances sur les technos qu'il utilise. Il y a aussi d'autres choses auxquelles il faut faire attention, dont :

• la communication sur l'expression du besoin ;
• la communication sur la gestion de la dette technique ;
• la mise à jour de la documentation ;
• de manière générale, transmettre aux collègues les infos dont ils ont besoin ;
• écrire du code lisible, bien séparer les responsabilités, éviter les duplications de code, etc. ;
• écrire du code testable et des tests automatisés par dessus ;
• bien penser aux cas particuliers pour réduire le nombre de bogues qui échappent aux tests automatisés.

[SieKensou]

Rebonjour,

Dans les faits, je travaille depuis 2010 et oui j'ai sur le papier 7 ans dans le front. Maintenant, les technos évoluent et je ne fais plus trop attention à ces chiffres qui ne me servent pas au quotidien.

Si je suis émotif, sans doute. Je dirai que je suis saoulé d'être observé et ce test coding game m'a mis un coup sur la tête. Après voilà c'est un passage temporaire et je vais passer à autre chose prochainement en me remettant sur les rails.

Je suis assez assidu dans mon travail et je le fais sérieusement.

Je ne voudrais juste pas qu'une période d'essai soit rompue à cause de mauvais résultat voilà tout.
Pour le reste, je fais le nécessaire pour respecter tous les points qui ont été cités par pyramidev. Actuellement, je n'ai pas de regret car je fais mon maximum.

Ce message est en effet une suite à mes précédents postes et oui, cela ne date pas d'hier ce sentiment de doute. Je le traine depuis très longtemps.

[Glutinus]

Bonjour,

Tu te focalises trop sur les résultats techniques. Tu as 10 ans d'expérience, tu as acquis des expériences. Prends une feuille de papier et note :
- Le nombre de fois où t'as sauvé les fesses d'un projet. Même si c'est rester jusqu'à 22h pour finalement pas faire grand-chose.
- Ce bug technique dans le framework bizarre qui fait qu'une variable déclarée en Integer est devenu un decimal sans qu'on comprenne pourquoi, et qui mériterait que tu ouvres un billet de blog parce que tu n'as jamais réussi à googler le truc.
- Cette modélisation "outside the box" qui a désamorcé un noeud et fait un temps fou.
- Cette fois où t'as réussi à convaincre un chef borné que ta solution était la meilleure (spoiler alert : parce que c'était la meilleure).
- Et cette fois où tu as fanfaronné parce que tu avais raison (mais le mal est fait, et ce qui est parti en prod est une merde sans nom et son auteur a changé de boite au passage).
- Cette routine que tu peux réutiliser à chacun de tes projets et qui te fait gagner du temps.
- Et si c'est pas beau de comparer, cet ex-collègue qui a fait sacrément de la merde et qui est devenu team lead sur un sujet important... selon linkedin

C'est ça qui fait la différence. Moi aussi je doute beaucoup, surtout en ce moment avec la data qui vient du big bullshit big data, sachant que très honnêtement je pense que je me sortirai mieux sur un projet même en connaissant moins bien python qu'un jeune sorti de l'école d'ingé ou de la fac. Cependant, t'as des réflexes, des manières de gérer des gens.

C'est peut-être le moment de passer sur des métiers transverses, de l'urbanisme, du management (à petite échelle), etc.

[Mat.M]

Prends une feuille de papier et note :
- Le nombre de fois où t'as sauvé les fesses d'un projet.

hhmmm le yakafokon c'est très bien Mr Glutinus avec tout le respect que je vous dois..donc gérer un projet informatique c'est facile.
Yaka embrayer des méthodes agiles, des cycles en V, la cafetière Moulinex etc...
Mais y-a-t-il des gens sur ce forums dont vous capables de sauver des gros projets usine-à-gaz en faillite genre Louvois ou autres ?

[transgohan]

Mais y-a-t-il des gens sur ce forums dont vous capables de sauver des gros projets usine-à-gaz en faillite genre Louvois ou autres ?

N'importe quel chef de projet digne de ce nom te répondrait pour sûr que cela ne sert à rien de dépenser des milliards pour réparer cette usine à gaz.
Autant en dépenser des milliards pour repartir de zéro.

[Glutinus]

J'ai pas dit qu'il a fait les choses mal ! Il peut très bien avoir été dépassé sur les événements, sur trop de réunions ce jour-ci ou un autre dev s'est barré à 16h sans prévenir. C'est pas son rôle de savoir tout sur tout, mais il peut t'être redevable d'avoir sauvé la casse ce jour-là.

[Glutinus]

N'importe quel chef de projet digne de ce nom te répondrait pour sûr que cela ne sert à rien de dépenser des milliards pour réparer cette usine à gaz.
Autant en dépenser des milliards pour repartir de zéro.

Tu rigoles, et Choupa-Stevia de mettre 10 jeune diplomés pour un bon team leader, et de se mettre en sauveur de l'humanité (honnêtement, je me demande si la hausse de l'action cette dernière année n'est pas dû à ça)(et je dis ça avec gentillesse, j'ai été chez Choupa-Stevia et je me suis pas barré en claquant la porte).

[yento]

Mais y-a-t-il des gens sur ce forums dont vous capables de sauver des gros projets usine-à-gaz en faillite genre Louvois ou autres ?

Louvois c'etait pour la gestion des payes des militaire/fonctionnaires si je me souviens bien?

Facile:
* Il suffit que l'administation definisse les salaires/taxes d'une maniere comprehensible, histoire que ce soit implementable.
* Et d'avoir la liste des employes existants incluant leurs salaires/primes/avantages, histoire de pouvoir les inclure dans le nouveau systeme.

Sachant que le projet a certainement ni l'un ni l'autre. Le developpement est voue a l'echec.

Et vous me direz, mais alors on ne peut rien faire? Si, et c'est tres simple!
Ca va demander une armee de secretaires pour rentrer toutes les donnees des employees, avec une organization complete de support permettant aux employes de fournir leur contrats et precedentes fiches de paye comme reference (parce qu'on imagine bien qu'il n'y a peu de donnees informatique la dessus et meme certains militaires n'ont jamais eu de contrats), avec un processus de revue une personne qui entre et deux qui confirment.

C'est pas tres complique en fait, c'est juste pas un projet logiciel.

[Glutinus]

Louvois s'est officiellement terminé sur un bon atterrissage (reste à voir que perso, je suis pas sûr d'avoir envie d'être dans la maintenance de ce bidule). Oui c'est bien ça, calcul des soldes des militaires.

C'est bien ce que tu dis : yaka.

Ils avaient identifié le problème : il y a autant de calcul de solde qu'il y a de militaires car ça se ramifie dans tous les sens. Maintenant, la question c'est est-ce que c'est un problème technique avec toutes ces branches if/then/else, ou est-ce un problème de spécification qui n'ont pas pu définir tous les cas possibles et (in)imaginables ? ça je l'ignore.

[Mat.M]

bonsoir

Louvois c'etait pour la gestion des payes des militaire/fonctionnaires si je me souviens bien?

oui c'est exact

Maintenant, la question c'est est-ce que c'est un problème technique avec toutes ces branches if/then/else, ou est-ce un problème de spécification qui n'ont pas pu définir tous les cas possibles et (in)imaginables ? ça je l'ignore.

eeehh la paie des militaires c'est exact, il y en a autant à gérer qu'il y a de militaires.
Cependant c'est pas avec des basiques if the else que les problèmes seront résolus, je pense que ça tient plus des algorithmes complexes
Ce que je ne comprends pas c'est qu'en France on a des "tronches plates" comme Cédric Villani par exemple et des mathématiciens pointus qui font classes préparatoires qui ne sont pas foutus de résoudre ce genre de problème...

[fredoche]

Pas d'algorithmes complexes, la complexité est bien dans la multiplicité des salariés, des primes, des fonctions, des temps de travail, maladie, embauche, débauche, missions, mois de la paie, des échelons, des charges, contributions, taxes, etc.

Mon premier projet suisse, c'est de gérer la mise à jour du logiciel de paie du canton pour lequel je bosse. Je découvre le domaine.
Alors autant sur le papier, une fiche de salaire suisse c'est simple, 6 lignes avec les impôts source. Imaginez pour la France avec ses dizaines de lignes

Autant derrière cette simplicité se cache des milliers de cas particuliers à gérer que le logiciel est presque obligé de traiter dans sa totalité. La criticité est énorme du fait que vous gérez énormément d'argent, que des milliers de salariés en dépendent au jour de paie près, que la moindre erreur entraine des corrections en cascade sur plusieurs mois ou plusieurs années.

Les systèmes se basent beaucoup sur des accumulateurs pour élaborer la somme à payer à la fin du mois. Ces accumulateurs ont effectivement un aspect conditionnel.

C'est vraiment une affaire de spécialistes, à la fois de la paie dans ses aspects réglementaires et fonctionnels, et de spécialistes de l'ERP choisi pour faire le job. Visiblement ça s'apprend sur le tas et il faut du temps, beaucoup de temps


Les tronches plates ne servent à rien là-dedans. Il faut de la rigueur, de la méthode, de la persévérance, de l'astuce et du sens pratique. Des vrais informaticiens quoi
Et ça sert à rien de tout spécifier comme des malades non plus. Là encore faire le gratte-papier ne règle pas les problèmes

[Mat.M]

Les tronches plates ne servent à rien là-dedans. Il faut de la rigueur, de la méthode, de la persévérance, de l'astuce et du sens pratique. Des vrais informaticiens quoi

et pour apprendre les mathématiques donc selon votre raisonnement on fait cela en toute légèreté alors ?
Tel un Gérard Depardieu qui fait son numéro sur une scène ...
forcément expliquer ce qu'est une transformation de Fourier mais c'est bien sûr c'est trivial pour tout le monde...

Et ça sert à rien de tout spécifier comme des malades non plus. Là encore faire le gratte-papier ne règle pas les problèmes

donc si vous avez réponse à tout je suppose que vous êtes directeur de projet dans une grosse SSII genre Cap ou Atos si je ne m'abuse ?

[Invité]

et pour apprendre les mathématiques donc selon votre raisonnement on fait cela en toute légèreté alors ?
Tel un Gérard Depardieu qui fait son numéro sur une scène ...
forcément expliquer ce qu'est une transformation de Fourier mais c'est bien sûr c'est trivial pour tout le monde...

Ben là, appliquer des pourcentages suivant des critères, aussi complexes soient-ils, ça demande beaucoup de rigueur mais pas des connaissances mathématiques très avancées, il ne faut pas exagérer.
Mon Bac+5 en math ne fait pas de moi un comptable et même que je détesterai ça profondément

[Golgotha]

Hello,

Les recruteurs qui font passer ce genre de tests à leurs candidats n'ont rien compris au métier de développeur et devraient eux mêmes changer de métier.

Le développeur n'est pas là pour régurgiter des connaissances : Il est là pour s'adapter, créer, inventer des solutions.

signé : un développeur.

[fredoche]

et pour apprendre les mathématiques donc selon votre raisonnement on fait cela en toute légèreté alors ?

Non la seule chose que je dis c'est que pour faire de la paie, il n'y a pas besoin d’être un mathématicien de génie. Ce qui n'empêche pas qu'il faille une tête bien faite

donc si vous avez réponse à tout je suppose que vous êtes directeur de projet dans une grosse SSII genre Cap ou Atos si je ne m'abuse ?

Non du tout.
Si tu te mets à spécifier par écrit le moindre cas particulier pour ensuite en faire une règle, t'es pas sorti de l'auberge. Et donc plutôt que de noircir des documents word, il vaut surement mieux programmer directement tes règles de paie, programmation faite par des gars qui connaissent leur sujet et l'outil avec lequel ils bossent.

Et peut-être que la méthode de la spécification à foison tient plus de ces grands groupes à la con qui font leur fortune de vendre de la viande au prix de gros, et pas forcément des projets aboutis fonctionnant parfaitement et pour lesquels on ne facture plus parce que ça marche

[yento]

Maintenant, la question c'est est-ce que c'est un problème technique avec toutes ces branches if/then/else, ou est-ce un problème de spécification qui n'ont pas pu définir tous les cas possibles et (in)imaginables ? ça je l'ignore.

Les deux malheureusement parce que comptabilité Francaise et militaire ^^
C'est tres tres difficile de calculer les 20 lignes d'une fiche de paie, parce qu'elles dependent de centaines de facteurs et ne sont pas bien definies. En plus de cela les militaires ont pas mal d'extra qui rendent la tache encore plus difficile (primes diverses, frais de deplacement, mobilisation a l'etranger, regime de retraite speciaux, etc...).

La base d'un logiciel de paie c'est de gerer le salaire annuel avec les charges/impots/taxes, mais c'est mission impossible a réaliser parce qu'il n'y a pas de formules claires pour le faire.
[Pour comparison la paie en Angleterre a 3 lignes de contributions, c'est calculable par un lyceen de 15 ans si on prends 1 heure pour lui expliquer.]


Au final on revient assez rapidement sur rentrer tous les salaires et primes et avantages manuellement, avec un systeme de revue.
Ce qui est normal en fait. Vous imaginez bien que quand vous rejoignez une entreprise ou quand vous obtenez une augmentation, il y a quelqu'un aux ressources humaines qui rentre l'info et un autre qui valide.
Il faut bien comprendre qu'il y a un gros aspect humain, les chiffres sont rentres au cas par cas (souvent apres coup), ce n'est pas quelque chose qui est specifie ou specifiable (on ne sait pas qui on va embaucher a l'avenir a quel salaire, ni combien de frais de deplacement un tel va generer).
Le logiciel de paie est en fait majoritairement un logiciel d'entree de donnees (on imagine facilement que le projet puisse partir sur une mauvaise base avec l'idee de tout automatiser et de supprimer tout le personnel, auquel cas ça va droit dans le mur).

La difficulté ici c'est l'entree initiale. Les SSII sont tout a fait capables de gerer ca (les gros projets ont souvent un aspect support ou call center), mais ca fait pas mal de couts et c'est pas reluisant sur l'appel d'offre d'inclure 50 secrétaires pendant 6 mois. C'etait censé etre un projet technologique avec des développeurs!

[d_d_v]

Rebonjour,

Ok merci pour les réponses j'en tiens compte.

Que faut'il faire désormais face aux résultats ? Je l'ai passé, j'ai joué le jeu et quelque part, j'ai donné une mauvaise image de moi aux collègues qui ont eu un meilleur résultat.

Faut'il tout simplement abandonner dans l'optique où la période d'essai est fichue ?

Pour rappel, jusqu'à présent, j'arrive à faire le job. Ce genre de test est arrivé en plein milieu où j'essaie tout simplement de m'intégrer et faire mon job correctement. Je n'ai jamais été fort aux coding game, ce n'est pas la première fois. Ma nature faire que je suis plutôt une personne qui code et trouve une solution après coup, jamais dans l'immédiat. Cela a toujours été comme ça et je le savais déjà bien en amont.

Le moral est bas car indirectement, un score mauvais sème le doute.
Pour en revenir au titre initial du sujet, oui le coding game risque de me faire perdre mon emploi s'il est pris à son sens le plus strict.

Je me fais peut etre des images, maintenant quand ce genre de test arrive, je ne pense pas que ce soit pour s'amuser au sein de l'équipe.

Salut !
Tu devrais au contraire être fier de toi: tes collègues semblent avoir le profil "pisseur de code", alors que tu sembles avoir le profil ingénieur (réflechir d'abord). Félicitations
Je te rassures, après 20 ans d'expérience, ce genre de tests, je ne serai probablement pas capable de les réussir dans les temps, et puis ils ne correspondent pas à ce qu'on fait réellement dans le métier sur le terrain.

[codeur1989]

Je n'aime pas la plateforme Codingame non plus. Je préfère la plateforme edabit (https://edabit.com/)

Beaucoup d'agences balancent des algorithmes comme si ils étaient Google, alors que le profil lambda suffirait largement. Et vu la mentalité/business model de ces boîtes, c'est probablement de la merde.

Je suis étonné de voir la participation de SieKensou. Je me rappelle de tes posts sur le forum. Ne me dis pas que tu doutes ENCORE de toi ???

[olivier252]

Salut, salut,

Bon j'ai lu ce fil avec attention puisque je me soumets à un de ces fameux tests de coding game (angular pour moi). Par contre c'est vrai que les témoignages sur le sujet me font flipper. D'autant plus que je suis allé sur le site et j'ai rien compris avec la bataille intergalactique...La loose, je le sens moyen, mais je vais tenter. Du coup est-ce que vous avez des conseils pour préparer ce gentre de tests ?

Merci