Discussion :

[LSMetag]

Faire un bon recrutement, ca coute très cher... et ca épuise aussi beaucoup.

On voit pas mal de guignol, et pour ma part, l'entretien technique m'a permis dd'en virer certain qui n'aurait aps fait l'affaire plus tard, ou au contraire de rattraper d'autres qui en face d'un RH perdait tous leurs moyens.

Les recrutements que je fais sont tous sur le même format :
- pré tri par les RH
- envoie d'une feuille avec une liste de techno et une auto evaluation a faire(je ne connais, pas, je connais, j'en ai entendu parlé, je suis expert...)
- entretien d'une heure avec le candidat + un RH + le dev enior + moi(chef d'équipe) : on aborder des questions techniques, on cherche a discuter un peu avec la personne, a évaluer son niveau d'anglais(sait il s'exprimer, est ce qu'on se comprend, etc...). On pose aussi des questions techiques ou théoriques(design pattern) et pour ceux qui postulent en senior, on les fait passer au tableau.(parce que je veux savoir si ils sont capable d'expliquer un concept debout devant des gens pour l'aspect formation de l'équipe du senior)
- un entretien technique poussé qui dure entre 1h15 et 2h30 selon le niveau du participant. un questionnaire basé sur un schéma UML + quelques questions (que doit on faire si on veut ajouter telle fonction). il répond tous seul et on en discute après. (et on lui pique son smartphone). Un algo très simple(3-4 boucles et 2-3 if imbriqués pour voir si il a les bases). On le regarde pour voir sa démarche.(est ce qu'il commence de suite, est ce qu'il test ou qu'ils verifie sans executer son code, ...est il plutot experimenteur ou théoricien). Et enfin, si tout le reste est positif et qu'on cherche un dev non junior, un test plus complexe, voir impossible a réaliser entièrement. 45 minutes tout seul et on regarde comment il s'en sort, les idées qu'il nous rpopose pour avancer, etc... (il m a fallut 1h30 pour le finir, donc je n'attends pas qu'ils le fassent)

Au final, on fait un bilan sur le total pour voir si on a envie de travailler avec cette personne, si elle correspond aux besoin actuels(aussi bien humain que techniques) et on garde le cv si c'est bon, mais pas adapté tout de suite.

C'est ultra couteux en temps, mais ca permet de balayer pas mal de choses...
Pour l'instant, ca nous a permis de recruter une équipe assez homogène et variée.

Oui c'est ce genre de façon de faire que j'apprécie. Mais c'est assez rare...

[CHbox]

Mon pire souvenir restera un test de 20 pages à faire sur 1 heures, sur environ 10~12 technos différentes, je ne sais même plus en quoi consistait l'offre et je n'ai pas vu un seul tech, on m'a laissé dans une pièce tout seul... C'était un de mes 1ers entretiens, ça a contribué à me déprimer pendant mes quelques mois de chômage, heureusement que des entreprises sont plus réalistes et laissent leur chances à ceux qui prouvent qu'ils ont des capacités, j'avais déjà parlé de ça mais les recruteurs font parfois tout pour que les candidats se sentent comme des m*****.

[LSMetag]

De même, je n'ai rien contre les start-ups et je comprends parfaitement qu'une jeune société recherche des gens "passionnés" et "qui savent s'investir" mais n'a pas les moyens de payer des salaires mirobolants. Cependant j'ai 3 questions que me viennent à l'esprit :
1) j'ai le droit à combien de stock options par an ?
2) je touche quel pourcentage des ventes du produit en cas de succès ?
3) qu'est-ce qui est inclus dans mon "severance package" si jamais votre projet n'était pas viable ?

S'ensuit généralement un grand moment de silence où on entend les mouches voler... On nous prend vraiment pour des cons !

Je ne suis pas d'accord sur cette partie là. Une StartUp, c'est une entreprise qui vient de naître, sans expérience, non cotée en bourse, plus orientée projet que business.
Stock Options => tu rêves
Tu trouves beaucoup de sociétés qui te donnent un pourcentage sur les ventes à une nouvelle recrue ?
Le "Sévérence Pack", c'est pareil. Une StartUp a déja du mal à trouver des financements au début. Ils te payent ton salaire, puis éventuellement une indemnité à la fin si le projet bat de l'aile, mais c'est loin d'être une obligation. Mais y a toujours des arrangements dans ce cas.

[erwanlb]

Faire un bon recrutement, ca coute très cher... et ca épuise aussi beaucoup.

On voit pas mal de guignol, et pour ma part, l'entretien technique m'a permis dd'en virer certain qui n'aurait aps fait l'affaire plus tard, ou au contraire de rattraper d'autres qui en face d'un RH perdait tous leurs moyens.

Les recrutements que je fais sont tous sur le même format :
- pré tri par les RH
- envoie d'une feuille avec une liste de techno et une auto evaluation a faire(je ne connais, pas, je connais, j'en ai entendu parlé, je suis expert...)
- entretien d'une heure avec le candidat + un RH + le dev enior + moi(chef d'équipe) : on aborder des questions techniques, on cherche a discuter un peu avec la personne, a évaluer son niveau d'anglais(sait il s'exprimer, est ce qu'on se comprend, etc...). On pose aussi des questions techiques ou théoriques(design pattern) et pour ceux qui postulent en senior, on les fait passer au tableau.(parce que je veux savoir si ils sont capable d'expliquer un concept debout devant des gens pour l'aspect formation de l'équipe du senior)
- un entretien technique poussé qui dure entre 1h15 et 2h30 selon le niveau du participant. un questionnaire basé sur un schéma UML + quelques questions (que doit on faire si on veut ajouter telle fonction). il répond tous seul et on en discute après. (et on lui pique son smartphone). Un algo très simple(3-4 boucles et 2-3 if imbriqués pour voir si il a les bases). On le regarde pour voir sa démarche.(est ce qu'il commence de suite, est ce qu'il test ou qu'ils verifie sans executer son code, ...est il plutot experimenteur ou théoricien). Et enfin, si tout le reste est positif et qu'on cherche un dev non junior, un test plus complexe, voir impossible a réaliser entièrement. 45 minutes tout seul et on regarde comment il s'en sort, les idées qu'il nous rpopose pour avancer, etc... (il m a fallut 1h30 pour le finir, donc je n'attends pas qu'ils le fassent)

Au final, on fait un bilan sur le total pour voir si on a envie de travailler avec cette personne, si elle correspond aux besoin actuels(aussi bien humain que techniques) et on garde le cv si c'est bon, mais pas adapté tout de suite.

C'est ultra couteux en temps, mais ca permet de balayer pas mal de choses...
Pour l'instant, ca nous a permis de recruter une équipe assez homogène et variée.

Et en dehors du temps passé à recruter....vous développez aussi un peu ?

[stailer]

C'est hallucinant de voir les réponses de certains à ce post... Avec des propositions de tests techniques sur 1 journée etc.

Sans parler du fait, qu'en étant développeur, il faut sans cesse s'intéresser aux nouvelles technos et savoir gérer un projet (parfois même un client).

Entre le recrutement et le type de compétences demandées on croirait parler d'un poste de chirurgien... A la différence que nous ne parlons certainement pas du même salaire

[azias]

Je n'ai jamais eu de tests techniques pour une embauche et heureusement sinon je pense que je n'aurai jamais travaillé, je perd complètement mes moyens lors des entretiens. En plus je n'arrive pas à travailler avec quelqu'un qui regarde par dessus mon épaule pour voir ce que je fais. Pour autant, après quelques semaines dans une entreprise on m'a toujours félicité pour mes compétences et ma réactivé.

J'ai parfois l'impression que certains recruteurs sont plus intéressés par l'aptitude du candidat à passer un entretien d'embauche plutôt que par ses compétences. Il suffit de voir comment certains cherchent volontairement à déstabiliser le candidat: c'est quoi l'objectif? Evaluer les compétences techniques ou juste montrer qu'il y a une ambiance de merde dans l'entreprise?

Je ne crois pas que des compétences techniques puissent être évaluées aussi simplement. Analyser, concevoir ou développer sont des activités intellectuelles, elles ne peuvent pas se réaliser correctement dans des conditions défavorables.

Si j'ai bien compris, Jon Evans propose de remplacer des questions et des exercices par un projet technique? C'est quoi la différence? C'est tout aussi stupide!

[erwanlb]

Je ne crois pas que des compétences techniques puissent être évaluées aussi simplement. Analyser, concevoir ou développer sont des activités intellectuelles, elles ne peuvent pas se réaliser correctement dans des conditions défavorables.

Ca sert surtout à donner du boulot au RH, s'autosatisfaire des tests qu'ils ont conçus, etc...

[yimson]

Bonjour à tous,

Je me souviens en 2010, lorsque je passais mon tout premier entretien d'embauche en tant que développeur PHP. J'avais subi le même stress, je n'avais jamais développé réellement en PHP sauf de petits programme de connexion à une base de données, de petits sites de présentation d'images. En fait la chance que j'avais eu est que j'avais été briefé par un ami qui travaillait dans cette entreprise sur le type de questions.

Sans être trop sceptique, je n'ai vraiment pas trop apprécié cette suite de question technique sur le PHP et à la fin l'interviewer me demande d’écrire un code PHP pour se connecter à une base de données sur un tableau a marqueur.

Moi à cette époque j'étais très attiré par le JAVA, j'étais plus attirée par le JAVA et heureusement deux semaines après j'ai été appelé et malheureusement pour eux, j'avais déjà trouvé un job en JAVA.

Cool, c'était juste pour partager mon expérience. Je partage l'avis de Jon Evans. Allez bonne journée...........

[robian]

J'ai pour ma part eu les 2 cas :

• en SSII ou chez un client, il m'est arrivé de répondre à des questionnaires techniques, ça peut être intéressant tout de même pour le recruteur pour se faire une idée des compétences du candidat, en tout cas ça permet de détecter des gens dont le CV est super mais qui sont un peu "bidon"
• Avant d'entrer dans ma boîte actuelle j'ai eu droit à un questionnaire technique + un petit projet à implémenter en 30-45 min, rien d'utilisable pour la boîte je précise il s'agit juste de voir comment le candidat se sert de l'IDE et architecture un mini-projet (par exemple s'il met tout le code dans une seule classe, c'est embêtant ..)

Personellement que ce soit un questionnaire technique ou un mini-projet, je ne trouve pas ça insupportable à condition que ce ne soit pas trop long, mais ça doit être un complément à l'entretien plus axé sur les expériences et les souhaits du candidat...

[Eric80]

Dans le dernier projet que j ai fait (proj .NET), l entretien avec le chef de projet et l architecte du soft surquel je devais bosser s'est terminé par un mini test technique: j'avais 3 min pour écrire le bout de code nécessaire pour lire une ligne dans un fichier texte (genre un using (StreamReader...). Cela m a surpris sur le moment mais aussi semblé tellement trivial que je me suis demandé "à quoi bon?".
Plus tard (une fois engagé sur le projet), les 2 collègues m ont raconté que plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique...

[thierryler]

Plus tard (une fois engagé sur le projet), les 2 collègues m ont raconté que plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique...

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

[imikado]

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

1. un développeur expérimenté de doit jamais parser des fichiers plats ?
2. selon vous quel test technique serait acceptable ? (vous êtes contre mon idée de CRUD, contre celle de lire un fichier...)

Je vous rappelle que ceux-ci sont la pour éviter d'embaucher un profil qui sera remercié 1 semaine après (et aura fait perdre du temps au deux parties)
Quel test technique feriez-vous passer à un futur collègue ?

[pmithrandir]

2. selon vous quel test technique serait acceptable ? (vous êtes contre mon idée de CRUD, contre celle de lire un fichier...)

Je testerais plus algorithmie et la connaissance / compréhension des outils normé(UML par exemple) ainsi que des concepts utilisés dans un langages
- Design patern
- thread
- ...

Si les connaissance théoriques sont là et qu'il sait faire un algo avec plus de 3 niveaux de complexité(boucle / récursivité) on a trouvé quelqu'un d’intéressant je pense.

Le CRUD, je t'avoue qu'il me faudra ou 25 secondes avec symfony pour le faire(génération auto) ou plusieurs journées... pour faire un formulaire propre sécurisé et tout... c'est pas si simple que ca je trouve.

[imikado]

Je testerais plus algorithmie et la connaissance / compréhension des outils normé(UML par exemple) ainsi que des concepts utilisés dans un langages
- Design patern
- thread
- ...

Si les connaissance théoriques sont là et qu'il sait faire un algo avec plus de 3 niveaux de complexité(boucle / récursivité) on a trouvé quelqu'un d’intéressant je pense.

Le CRUD, je t'avoue qu'il me faudra ou 25 secondes avec symfony pour le faire(génération auto) ou plusieurs journées... pour faire un formulaire propre sécurisé et tout... c'est pas si simple que ca je trouve.

Pour le CRUD, cela s'entend sans framework/générateur (sinon on met mon framework et il le fait en 4 clics

Créer un CRUD n'est pas compliqué en soit, estimer le temps nécessaire à l'écriture d'un CRUD en 45 minutes c'est deja se poser et poser les bonnes questions.
Mais il faut une fois le CRUD terminé indiquer ce que l'on modifierai/améliorerai si on avait plus de temps (XSS,XSRF...)

[Luckyluke34]

j'avais 3 min pour écrire le bout de code nécessaire pour lire une ligne dans un fichier texte (genre un using (StreamReader...).

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

+1. A la limite si on s'en souvient pas ça se retrouve en 20 sec sur le net.

Avait-on accès à Google et/ou msdn pour ce test ? Si ce n'était pas le cas :

- Se servir de ce genre de test pour donner un + aux développeurs ayant une bonne mémoire et/ou étant habitués à manipuler des fichiers, OK.

- Se servir de ce genre de test de façon éliminatoire... c'est juste se couper d'énormément de gens qui ne connaissent peut-être pas la syntaxe par coeur.

plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique

C'est quoi "tombés" ? Ne connaissaient pas les méthodes à utiliser par coeur ? Ont rendu feuille blanche ? N'ont pas fini dans les temps ? Ont fini mais rendu un résultat buggé ? ...

Sinon je pense que el_slapper a la bonne solution : tester les compétences d'une personne à un instant T c'est bien, mesurer sa capacité à évoluer et apprendre, c'est mieux.

[jabbounet]

+1. A la limite si on s'en souvient pas ça se retrouve en 20 sec sur le net.

Avait-on accès à Google et/ou msdn pour ce test ? Si ce n'était pas le cas :

- Se servir de ce genre de test pour donner un + aux développeurs ayant une bonne mémoire et/ou étant habitués à manipuler des fichiers, OK

Tu ne regarde pas uniquement la syntaxe quand tu fais ce genre d'exercice, tu regarde surtout la façon dont le candidat réfléchi, et les questions qu'il se pose et qu'il pose au recruteur quand il ne connait pas quelque chose. il est important de parler.

- Se servir de ce genre de test de façon éliminatoire... c'est juste se couper d'énormément de gens qui ne connaissent peut-être pas la syntaxe par coeur.

Ne pas connaitre la syntaxe d'un langage et mettre expert+++ niveau +32 sur un cv me parait risqué.
Si tu pratique une langage de façon quotidienne pendant plusieurs années en développement tu connais au minimum la syntaxe du langage.

C'est quoi "tombés" ? Ne connaissaient pas les méthodes à utiliser par coeur ? Ont rendu feuille blanche ? N'ont pas fini dans les temps ? Ont fini mais rendu un résultat buggé ? ...

J'ai eu le cas d'une personne ayant fait une thèse et qui a enseigné l'algorithmie, qu n'as pas réussi faire une exercice d'algorithmie simple (dedans il y'a une boucle et 1 condition)

Sinon je pense que el_slapper a la bonne solution : tester les compétences d'une personne à un instant T c'est bien, mesurer sa capacité à évoluer et apprendre, c'est mieux.

c'est pour cela que le candidat doit être capable de se servir de ses expérience pour réussir l'exercice en restituant ce qu'il a pu apprendre.


En général sur ce genre de question tu t'arrange pour n'avoir que des éléments de base du langage qui sont censée être maîtrisé par le candidat. en caricaturant un peu si le candidat me dit que pour faire une boucle "for" ou "while" il doit aller sur le net, je suis inquiet quand a ses capacité d'acquisition du savoir.

Est-ce que pour écrire en français on fait une recherche sur le net avant, personnellement je m'attend à ce que quelqu'un d'expérimenté dans une techno en dev et qui dit la pratiquer 8h/jour au cours des 5 dernières année connaisse les bases du langage.

[Luckyluke34]

J'ai eu le cas d'une personne ayant fait une thèse et qui a enseigné l'algorithmie, qu n'as pas réussi faire une exercice d'algorithmie simple (dedans il y'a une boucle et 1 condition)

Un problème d'amnésie peut-être ?

Sinon je pense que el_slapper a la bonne solution : tester les compétences d'une personne à un instant T c'est bien, mesurer sa capacité à évoluer et apprendre, c'est mieux.

c'est pour cela que le candidat doit être capable de se servir de ses expérience pour réussir l'exercice en restituant ce qu'il a pu apprendre.

Oui, mais ça ne suffit pas. Ca ne montre pas à quelle vitesse il a appris, s'il a assimilé à force de répétition ou du premier coup. Ca ne montre pas non plus s'il va avoir du mal à remettre en cause ces bases pour basculer sur un paradigme de programmation ou une méthodologie différents.

Est-ce que pour écrire en français on fait une recherche sur le net avant, personnellement je m'attend à ce que quelqu'un d'expérimenté dans une techno en dev et qui dit la pratiquer 8h/jour au cours des 5 dernières année connaisse les bases du langage.

On est d'accord, je parlais bien sûr de la connaissance et de la manipulation des méthodes adéquates pour lire un fichier (c'est l'exemple d'exercice donné par Eric80), pas de la syntaxe de base du langage. Pour moi savoir qu'il faut utiliser un StreamReader et la méthode ReadToEnd() ou je ne sais quoi d'autre ne relève pas des "bases d'un langage", à la rigueur juste des bases d'un sous-ensemble d'un framework/plateforme...

[pcaboche]

Est-ce que pour écrire en français on fait une recherche sur le net avant, ...

Euh... ouais !

Bien que le Français soit ma langue naturelle, il m'arrive très souvent de faire des recherches sur internet, le plus souvent afin de vérifier l'orthographe et la conjuguaison (et quand je vois le niveau de certaines interventions sur internet, je me dis que certains feraient bien d'en faire de même ).

Pourquoi ? Parce que bien que maîtrisant les principes de base, il y a des toujours des détails du langages qui restent abscons ou peu intuitifs...

De même en informatique, même pour les langages que j'utilise tous les jours, il y a certains détails que je suis obligé de chercher régulièrement, soit parce que je suis soudainement pris d'un doute, soit parce que je trouve certains points de la syntaxe absolument pas naturels.

Et en informatique comme en Français, soit tu te débrouilles avec les limites de la grammaire du langage, soit tu choisis une autre tournure de phrase pour exprimer la même idée (parfois de manière plus simple).

[Olivier P.]

Je suis chef de projet en SSII et je réalise des entretiens techniques lors de nos recrutements. Dans ce cadre, je fais passer un test technique.
Aussi je vous apporte mon témoignage.

Tout d'abord, il n'est pas toujours évident pour un candidat de montrer ses réalisations. En effet, un développeur ne fait pas forcément du pur web visible.
Beaucoup travaillent sur des intranets, du code privatif, ou dans la "tuyauterie" d'une application. Ensuite, ce n'est pas parce que vous avez participé à l'élaboration d'un site web, que vous l'avez réalisé de A à Z.

Ensuite, pour rebondir sur l'exemple du plombier à qui on ne fait pas passer d'entretien technique avant de le faire venir à la maison, c'est vrai et pas vrai...
C'est pas toujours le cas, mais d'une manière générale, on appelle un plombier (ou autre) car il nous est recommandé par quelqu'un.
Or en SSII, pour ceux qui y travaillent, nous savons très bien que la recommandation ne se pratique pas.
Qui irait appeler un manager concurrent pour lui demander des informations sur un prestataire ?

Donc, un test technique est un excellent outil pour juger la personne.

Cela dit, il y a test technique et test technique....
Le notre n'est pas adhérent à une technologie ou à un langage. Il n'est pas non plus sous forme de QCM. Il est orienté autour de la culture informatique et la conception "grosse maille" d'une application.

Alors certes, il ne permet pas forcément de repérer les très bons, stress ou autre oblige, mais pas contre, il permet à coup sur d'écarter les mauvais.

[el_slapper]

(.../....)
Tout d'abord, il n'est pas toujours évident pour un candidat de montrer ses réalisations. En effet, un développeur ne fait pas forcément du pur web visible.
Beaucoup travaillent sur des intranets, du code privatif, ou dans la "tuyauterie" d'une application. Ensuite, ce n'est pas parce que vous avez participé à l'élaboration d'un site web, que vous l'avez réalisé de A à Z.

+1. Perso, je bosse pour des applis internes à des grands comptes(banques, assurances). Par définition, 100% de mon travail est protégé par le secret professionel.

Ensuite, pour rebondir sur l'exemple du plombier à qui on ne fait pas passer d'entretien technique avant de le faire venir à la maison, c'est vrai et pas vrai...
C'est pas toujours le cas, mais d'une manière générale, on appelle un plombier (ou autre) car il nous est recommandé par quelqu'un.
Or en SSII, pour ceux qui y travaillent, nous savons très bien que la recommandation ne se pratique pas.
Qui irait appeler un manager concurrent pour lui demander des informations sur un prestataire ?

Il est arrivé qu'on me demande de recommander des gens, mais c'est en effet rarrissime, et c'était le client qui demandait. +1, donc

Donc, un test technique est un excellent outil pour juger la personne.

Cela dit, il y a test technique et test technique....
Le notre n'est pas adhérent à une technologie ou à un langage. Il n'est pas non plus sous forme de QCM. Il est orienté autour de la culture informatique et la conception "grosse maille" d'une application.

J'ai eu ça une fois. Une spec vague, il fallait faire un dessin de chaine, et un plan de test succint. C'est très révélateur. Mais c'est plus un test de pensée qu'un test technique.

Celà dit, si un jour j'ai à recruter, j'essayerais peut-être le test Jeff Atwood : j'emmène le candidat et toute l'équipe à la machine à café, et je demande au candidat de parler de ses projets.

Alors certes, il ne permet pas forcément de repérer les très bons, stress ou autre oblige, mais pas contre, il permet à coup sur d'écarter les mauvais.

En même temps, un cador qui ne tient pas le stress, c'est souvent rédhibitoire.