Bonjour,

je ne prétend pas être un as, un expert, ni autre chose du même genre...mais j'ai un coup de gueule à lancer. Voici mon histoire :

Je m'appel Julien, j'ai 22 ans et 7 mois ( Grand Garçon ), je développe depuis que j'ai 15 ans, et je suis détenteur d'un BTS IRIS.

Voilà un an et demi que je bosse dans ma boite, au départ l'équipe technique étaient composé de deux personnes : Un directeur technique, et moi même. Tout ce passé plutôt bien, malgré qu'il me cloisonné un peu trop par manque de confiance, ce qui est "normal", car c'était mon premier contrat CDI, et que pour lui le fait que je développais en PHP pour mes propres besoins & par passion depuis 7 ans, ça ne compte pas vraiment. Mais bon au fur et à mesure du temps, il m'a accordé sa confiance, et nous travaillâmes ( j'en suis pas sûr de cette conjugaison là ) de manière efficace, bien que j'ai eu beaucoup de mal à approuver ses méthodes de travail assez moyenâgeuse, avec des objets qui ne représentent pas grand chose, ou plutôt qui représentent un peu tout et n'importe quoi selon l'humeur du jour...

Depuis Janvier, ce dernier à quitter les bureaux de l'entreprise pour faire tourner la sienne à plein régime, et pour le remplacer, mes patrons on recrutés un développeur trouvé à la va vite. Ce fût l'occasion pour moi de tenter de repartir sur un développement plus "sain", et un peu plus respectueux du pattern MVC ( C'est pas le nirvana non plus, c'est juste histoire de séparer tout ce qui est accès à la base grave à des classes, pour la vue j'utilise smarty, et voila.. ).

Mais voilà, il s’avère que plus le temps passe, plus je me rend compte que le développeur recruté à des compétences ULTRA-SCOLAIRE, qu'il n'a aucune méthode & logique de développement web ( genre accès restreint à certaines page pour les personnes connectés...il ne test même pas si le membre est connecté, il se contente d'afficher la page et si le mec rempli le formulaire, bah je sais pas on update un mec inexistant ?! ) , et qui se contente d'aller sur des vieux projets et/ou sur le net faire des copier/coller de bout de code et de classes completes, ignorant TOTALEMENT le travail déjà réalisé sur le projet en question...Alors je veux bien que chaque développeur à ses méthodes, mais quand on bosse sur un projet en équipe, et d'autant plus quand on vient d'arriver, je pense qu'il est normal de se conformer à ce que les "aînés" se sont en(beter|merder) à construire... Et ça me rend fou de passer des heures à re-développer une partie ou tout ce qu'il à pût faire car il y a des failles ( pas de protection sur les requêtes ), car il ne répond pas du tout à la problématique, car il n'a pas fini son module et qu'il est passé à autre chose...

Pfiou, ça fait du bien, merci de m'avoir lu !

Sa voiture, elle est de quelle couleur ?

Couleur tramway + bus

D'où l'importance d'un petit test technique lors de l'entretien d'embauche.

Mais même là ce n'est pas évident parce que les tests qu'on rencontre ne sont pas souvent pertinents. Le but n'est pas tant de savoir si le candidat est un gourou du PHP comme son CV voudrait nous le laisser croire mais s'il a de la méthodologie, des connaissances pratiques de base essentielles et éventuellement est ouvert à l'apprentissage.

On te dira aussi que le but étant surtout que le produit soit livré, l'important n'est pas tant que le candidat connaisse tout que de savoir s'il est capable d'aller trouver les solutions manquantes, où il les cherche et comment il les exploite pour les intégrer dans le développement global. Mais en tout état de cause, un simple entretien sans aucun test technique est insuffisant. Les cabinets de recrutement ne sont en général pas en mesure de faire faire ces tests faute des compétences techniques en interne pour les créer et les corriger ensuite, mais l'entreprise qui recrute pour son compte, même par le biais d'un cabinet de recrutement, a le devoir de faire attention à ça.

On ne peut malheureusement pas y faire grand chose si le responsable de l'embauche n'en tient pas compte : bienvenue dans le monde joyeux de l'entreprise et de sa culture de plus en plus généralisée de la médiocrité

Je vais dire quelque chose de violent, mais c'est soit le moment de changer de boite, soit de mettre un ultimatum.

Plus sérieusement, il faut que tu te demande si tu es prêt à continuer à bosser dans ces conditions, et si c'est vraiment trop loin de ton idéal, il ne faut pas que tu t'enlises dans une société où tu ne te sens pas bien.

Ladies,

Vous avez des exemples de test techniques ? Je n'en ai jamais passé ...

Maintenant, les patrons veulent un stagiaire, mais pas un débutant ( autrement dit, un stagiaire au moins aussi productif qu'un employé ). Et en tant que second, et avant dernier mec de la technique, c'est moi qui doit faire passer les entretiens ( pas mal hein pour un mec qui a un an et demi d'exp en entreprise ... )

Mais je bloque assez vite, peut on exiger d'un stagiaire d'être un développeur fin prêt... à priori non. ça me gêne d'envoyer ch*er un mec motivé car il est débutant, alors que le but d'un stagiaire c'est d'apprendre, et de prendre à la place un mec sans attrait particulier pour le domaine mais qui a des compétences ( J'aime souvent dire qu'il y a des mecs fait pour être développeur, et d'autre qu'ils le sont sans attraction particulière pour la matière, juste pour le plaisir de faire du PC comme on dirait à l'école ! ).

Pour ce qui est de quitter l'entreprise...je ne peut l'envisager pour le moment. C'est une startup, j'y suis dépuis presque la création, mes perspectives d'évolutions sont prometteuses ( Salaire + 400€ net en un an et demi, je n'ai pas à me plaindre clairement ), je suis déjà passé de développeur débutant à quasiment chef de projet, je me charge du recrutement, j'aide à la planifications des projets.... Mon réel problème, c'est que le seul autre mec que compose l’équipe technique ( comme vous l'avez lu, nous ne sommes que deux ) ne fait pas d'effort pour fournir un boulot clean, et développe sous l'emprise de l'adage : "Ça marche et ça ressemble à ce que l'on m'a demandé....job done".

oui il faut du productif, pour faire de l'argent vite, quite à faire de l'argent mal et à se manger tous les soucis de l'univers derrière, c'est classique, moi mon conseil c'est que ton binôme tu le bash un bon coup tu lui explique ce que c'est du code correct, et s'il est pas content, soit il se taille soit tu te tailles, zeus a tout à fait raison, faut pas s'enliser dans une boite qui ne te donne pas les moyens de faire du bon boulot.

Tu pourrais le concevoir toi-même en posant les limites et restrictions :

• Le test ne doit pas prendre plus d'une heure au candidat;
• Quels sont les techniques qu'on lui demande de connaitre un minimum, quels langages ?

À partir de là, tu peux élaborer la construction d'une simple page, voire deux pages, mais dans lesquelles on devra retrouver les différents éléments à mesurer :

• Propreté du code;
• Méthodologie;
• Architecture et répartition des fichiers;

Même s'il n'a pas eu le temps de terminer dans le délai imparti, tu auras au moins une idée générale de ses capacités techniques, de sa manière de raisonner pour résoudre un problème.

Apparemment il y a deux problèmes, le premier concernant la cohérence du code (contrôles/protections non effectués etc.) et le second le manque d'adaptation aux techniques employées par l'équipe en place.

Etant donné qu'il est difficile de demander tout à la fois, j'irais plutôt par étape. Selon moi la première est celle de fournir un code cohérent/maitrisé. C'est le minimum requis pour être développeur, que se soit en solo ou en équipe. Ensuite, ou parallèlement mais en seconde instance, s'adapter aux techniques déjà mises en place.

Bon la première étape peut être dépendante de la seconde mais il est selon moi utile de bien faire la distinction et/ou la complémentarité entre les deux afin de mieux éclairer et motiver ton collègue. Il faut favoriser au maximum le facteur "motivation" pour accélérer les progrès, et donc bien expliquer plutôt que souligner, l'intérêt de faire ceci plutôt que cela. Evidemment cela demande plus de temps que de poser des règles et s'y tenir, donc plus d'investissement "formation" au départ mais les résultats sont autrement plus productifs à terme.

Après cela dépend de ce que ton entreprise souhaite faire avec le stagiaire mais si c'est un emploi durable tu pourrais peut-être négocier avec ton entreprise un temps de formation nécessaire à la bonne intégration du stagiaire, soit en heures sup soit déductible de ton temps de développement. Si les choses sont clairement définies tout sera plus simple et moins stressant.