Je viens de tomber sut ton poste, et je voulais réagir. je vois que cela date de 2 mois ….. mieux vaut tard que jamais. et puis ça pourrais toujours servir à quelqu'un.
Ayant vécu une situation similaire , voici ce que je peux dire:
1er constat, je dirais que c'est une situation complètement "normale" (pour ma part, je boss en Algérie, mais je pense que les contextes restent similaires). dans la masse de développeurs , beaucoup sont très moyens, certain sont médiocre, et quelque un sont bon voir très bon. Mais la majorité se considèrent comme étant "un bon développeur" :)
Partant de ce constat, on peut être tenté de revoir ses critères de recrutement à la baisse (surtout, si comme pour mon cas, on subit une pression -compréhensive- de la part de la direction pour recruter au plus vite, histoire de se lancer "au plus vite" sur les projets,et de les finaliser -encore une fois- "au plus vite" :) GROSSIÈRE erreurs ** , **NE BAISSER JAMAIS VOS CRITÈRES, celui qui devra gérer les merde d'un mauvais développeur, c'est celui qui l'a recruté de toute façon :)
La raison est simple, n'étant pas un ouvrier,
un mauvais développeur, aura besoin de beaucoup plus de temps pour corriger sa façon de faire, si au départ , sa compréhension du développement (notamment de la POO) est erroné, PIRE encore, il pensera que ces solutions sont bonnes, et que les autres veulent juste se compliquer la vie à penser générique , réutilisable, maintenable …. c'est pas en 2 jours qu'on change complètement sa façon de penser le DEV.
ALORS que même un ouvrier stupide, peut rapidement corriger sa manière de mettre une pièce dans une machine!!!
cette subtilité échappent parfois à la direction et aux services RH.
Autre chose, en recrutant vite , on aura l'impression, qu'on a plus qu'a se lancer sur le projet, et qu'on a gagner du temps ……………. N'IMPORTE QUOI, les soucis qui seront engendré par un mauvais développeurs cause plus de tor au projet que le fait de ne pas en avoir:
1. Code bugué
2. Intégration difficile , vu la rigidité des solutions
3. Mise à jour et maintenabilité du code complexe, voir Impossible dans certain cas
4. Stresse permanent dû au fait de croire qu'on avance alors qu'on sait pertinemment, que ça sera revue et REFAIT
5. Pour bien Expliquer à un mauvais ce qu'il faut faire et comment le faire, il faut aller dans TOUT LES DéTAILS possible …… franchement , autant le faire soit même
6. Impact négatif pour l'esprit d'équipe. les BON développeurs Aiment bosser avec de BON développeurs…. ils sentirons qu'ils reculent s'il bossent avec des mauvais qui leur apportent rien
7……………………. franchement, je préfère m’arrêter la, car ça me rappel de mauvais souvenirs.
Bref pour résumer, je dis toujours la chose suivante:
"je préfère être sous staffé, que MAl staffé"
Concernant le test de recrutement, j'ai également testé cette façon de faire , qui consiste à donner une travail à faire en 3h (pour ma part aussi, c'était 3 heures) ……….. Mais je dois avouer que ça ne fonctionne pas très bien.
je pense que les raisons sont les suivantes:
- La stress de l'entretien est un facteur qu'on néglige, mais il est extrêmement important. il y a des gens qui gèrent mal le stresse, ça ne fait pas d'eux de mauvais développeurs pour autant.
- Il est difficile de résumer toutes les notions nécessaire au poste dans un seul exercice.
- Franchement, je ne coderais pas de la même façon pour un test sans suite de 3 heures, que dans le cadre d'un projet bien claire et bien structuré …..
ce que je recommande, (que j'ai testé, et qui jusqu’à aujourd’hui fonctionne plutôt bien), c'est de faire un entretien NORMAL (tu parles avec le gars, de ce qu'il veut faire, de sa vie etc….) et par la suite de passer au volet technique avec des petites questions-exercices bien précise (nécessitant au plus 5 minutes de réflexion) chacune relative à un sujet particulier, selon les besoins du poste (POO, SQL, HTML, Conception ….) histoire de faire le tour de la façon de réfléchir du candidat.
le tout, en offrant du papier brouillon et un stylo au candidats, pour les aider à réfléchir … voir à écrire du code.
Ajouter à cela des questions d’intelligence d'ordre général (pas des questions pieges) , nécessitant un cerveau bien huilé (généralement, avec des chiffres et des maths)
ce qui comptera par la suite, ce n'est pas tant, le fait que les réponses soient juste ou pas, Mais surtout la façon de réfléchir et la manière de considérer les problème.
Ah oui, autre chose de trés important,
ce n'est pas parce que tu n'aurais pas fait les chose comme lui l'a fait, que c'est forcement mauvais ;)
# mieux vaut tard que jamais
Posté par abdeslem_ . En réponse au journal Développeur, ou comment sur-évaluer ses compétences. Évalué à 2.
Bonjour,
Je viens de tomber sut ton poste, et je voulais réagir. je vois que cela date de 2 mois ….. mieux vaut tard que jamais. et puis ça pourrais toujours servir à quelqu'un.
Ayant vécu une situation similaire , voici ce que je peux dire:
1er constat, je dirais que c'est une situation complètement "normale" (pour ma part, je boss en Algérie, mais je pense que les contextes restent similaires). dans la masse de développeurs , beaucoup sont très moyens, certain sont médiocre, et quelque un sont bon voir très bon. Mais la majorité se considèrent comme étant "un bon développeur" :)
Partant de ce constat, on peut être tenté de revoir ses critères de recrutement à la baisse (surtout, si comme pour mon cas, on subit une pression -compréhensive- de la part de la direction pour recruter au plus vite, histoire de se lancer "au plus vite" sur les projets,et de les finaliser -encore une fois- "au plus vite" :)
GROSSIÈRE erreurs ** , **NE BAISSER JAMAIS VOS CRITÈRES, celui qui devra gérer les merde d'un mauvais développeur, c'est celui qui l'a recruté de toute façon :)
La raison est simple, n'étant pas un ouvrier,
un mauvais développeur, aura besoin de beaucoup plus de temps pour corriger sa façon de faire, si au départ , sa compréhension du développement (notamment de la POO) est erroné, PIRE encore, il pensera que ces solutions sont bonnes, et que les autres veulent juste se compliquer la vie à penser générique , réutilisable, maintenable …. c'est pas en 2 jours qu'on change complètement sa façon de penser le DEV.
ALORS que même un ouvrier stupide, peut rapidement corriger sa manière de mettre une pièce dans une machine!!!
cette subtilité échappent parfois à la direction et aux services RH.
Autre chose, en recrutant vite , on aura l'impression, qu'on a plus qu'a se lancer sur le projet, et qu'on a gagner du temps ……………. N'IMPORTE QUOI, les soucis qui seront engendré par un mauvais développeurs cause plus de tor au projet que le fait de ne pas en avoir:
1. Code bugué
2. Intégration difficile , vu la rigidité des solutions
3. Mise à jour et maintenabilité du code complexe, voir Impossible dans certain cas
4. Stresse permanent dû au fait de croire qu'on avance alors qu'on sait pertinemment, que ça sera revue et REFAIT
5. Pour bien Expliquer à un mauvais ce qu'il faut faire et comment le faire, il faut aller dans TOUT LES DéTAILS possible …… franchement , autant le faire soit même
6. Impact négatif pour l'esprit d'équipe. les BON développeurs Aiment bosser avec de BON développeurs…. ils sentirons qu'ils reculent s'il bossent avec des mauvais qui leur apportent rien
7……………………. franchement, je préfère m’arrêter la, car ça me rappel de mauvais souvenirs.
Bref pour résumer, je dis toujours la chose suivante:
"je préfère être sous staffé, que MAl staffé"
Concernant le test de recrutement, j'ai également testé cette façon de faire , qui consiste à donner une travail à faire en 3h (pour ma part aussi, c'était 3 heures) ……….. Mais je dois avouer que ça ne fonctionne pas très bien.
je pense que les raisons sont les suivantes:
- La stress de l'entretien est un facteur qu'on néglige, mais il est extrêmement important. il y a des gens qui gèrent mal le stresse, ça ne fait pas d'eux de mauvais développeurs pour autant.
- Il est difficile de résumer toutes les notions nécessaire au poste dans un seul exercice.
- Franchement, je ne coderais pas de la même façon pour un test sans suite de 3 heures, que dans le cadre d'un projet bien claire et bien structuré …..
ce que je recommande, (que j'ai testé, et qui jusqu’à aujourd’hui fonctionne plutôt bien), c'est de faire un entretien NORMAL (tu parles avec le gars, de ce qu'il veut faire, de sa vie etc….) et par la suite de passer au volet technique avec des petites questions-exercices bien précise (nécessitant au plus 5 minutes de réflexion) chacune relative à un sujet particulier, selon les besoins du poste (POO, SQL, HTML, Conception ….) histoire de faire le tour de la façon de réfléchir du candidat.
le tout, en offrant du papier brouillon et un stylo au candidats, pour les aider à réfléchir … voir à écrire du code.
Ajouter à cela des questions d’intelligence d'ordre général (pas des questions pieges) , nécessitant un cerveau bien huilé (généralement, avec des chiffres et des maths)
ce qui comptera par la suite, ce n'est pas tant, le fait que les réponses soient juste ou pas, Mais surtout la façon de réfléchir et la manière de considérer les problème.
Ah oui, autre chose de trés important,
ce n'est pas parce que tu n'aurais pas fait les chose comme lui l'a fait, que c'est forcement mauvais ;)
voila, bon courage et bonne continuation.