Discussion :

[LSMetag]

Pour moi les interviews techniques ne sont pas un problème. Elles permettent de révéler ton système de pensée au recruteur et de pouvoir débattre avec lui. Je trouve ça intéressant.

Non, ce que je trouve aberrant, c'est les tests techniques où tu dois évaluer ou écrire du code sur papier ! Merci les gars, je ne suis pas un playmobil, je n'apprend pas un langage par coeur, juste les mécanismes. Mon crédo, c'est de réfléchir, faire des algos ou architectures en fonction des spécificités d'une technologie et d'un besoin. Le langage n'est qu'un outil et l'IDE et le compilateur sont la pour ça.

Pratique que je déteste encore plus : les tests psychotechniques (par exemple dans l'entreprise Sword).
Truc qui ne reflète pas du tout le niveau. Malheureusement pour moi j'avais tout fait (et j'avais la moyenne partout) sauf le dernier exercice par manque de temps (qui n'était pas plus gros que les autres mais contenait une bonne partie des points).
=> Total : 2/10 et on m'a même pas fait passer l'entretien RH qui suivait.

Etant une personne au système de pensée non conforme, avec une méthode de travail non conforme, les tests de QI ne fonctionnent pas avec moi. Ca ne m'a pas empêché de poutrer une bonne moitié des développeurs que j'ai cotoyé en milieu pro et sortant de prestigieuses écoles d'Ingénieur.

[Franck.H]

Pratique que je déteste encore plus : les tests psychotechniques (par exemple dans l'entreprise Sword).
Truc qui ne reflète pas du tout le niveau. Malheureusement pour moi j'avais tout fait (et j'avais la moyenne partout) sauf le dernier exercice par manque de temps (qui n'était pas plus gros que les autres mais contenait une bonne partie des points).
=> Total : 2/10 et on m'a même pas fait passer l'entretien RH qui suivait.

J'ai eu à plusieurs reprises le même problèmes.

Etant une personne au système de pensée non conforme, avec une méthode de travail non conforme, les tests de QI ne fonctionnent pas avec moi. Ca ne m'a pas empêché de poutrer une bonne moitié des développeurs que j'ai cotoyé en milieu pro

Je suis pareil, je suis non conforme, n'ayant déjà pas appris à l'école tout ce que je sais, je sort du cadre standard et cela porte souvent préjudice. C'est un peu comme les personnes et la mode, si tu n'es pas au style catalogue tu sort du lot et on te met de côté, bin c'est pareil dans ce cadre là, du moins souvent. J'ai eu la chance d'avoir réussi mon dernier entretien et test et obtenu tout de même mon poste de développeur et j'ai donc battu toutes les autres personnes qui pour la plupart d'entre-elles sont diplômées !

[LSMetag]

J'ai eu à plusieurs reprises le même problèmes.

Je suis pareil, je suis non conforme, n'ayant déjà pas appris à l'école tout ce que je sais, je sort du cadre standard et cela porte souvent préjudice. C'est un peu comme les personnes et la mode, si tu n'es pas au style catalogue tu sort du lot et on te met de côté, bin c'est pareil dans ce cadre là, du moins souvent. J'ai eu la chance d'avoir réussi mon dernier entretien et test et obtenu tout de même mon poste de développeur et j'ai donc battu toutes les autres personnes qui pour la plupart d'entre-elles sont diplômées !

Oui mais voila, ces pratiques m'énervent tellement, comme en SSII où t'as un client qui fait des mauvais choix (pour raison business) au mépris de ses utilisateurs, tu lui dis, il te demande quand même de faire de la merde, tu le fais, les utilisateurs gueulent et le client te dit que t'as fait de la merde...
Après dans le debrief de période d'essai, on te fait comprendre que tu n'es pas assez faux cul et pas fait pour bosser en entreprise.
Tu peux être mal vu aussi quand tu fais le choix de bosser à un rythme différent (truc important à finir, aller chercher déjeuner à 14h (en 10 minutes), fignoler jusqu'à 20h).

Résultat, je suis en train de monter ma propre boîte et je me sens bien mieux comme ça...

[Grom61736]

Je n'ai jusqu'à présent réussi QUE les entretiens où il y avait un test "technique" derrière. Histoire que les gens de l'IT contre-balance l'avis négatif des RH.

Pour tout les autres, RH est le premier RDV et te bloque si tu as un diplôme d'Ingénieur Logiciel plutôt que Software Engineer.


Mais de manière générale, je trouve stupide les tests de vraie technique. Un petit quizz algorithmique ou mise en situation est plus révélateur.

[Franck.H]

Mais de manière générale, je trouve stupide les tests de vraie technique. Un petit quizz algorithmique ou mise en situation est plus révélateur.

Je n'ai rien d'autre à ajouter, je suis entièrement d'accord

[LeSmurf]

Jugez-vous avoir été une fois injustement mis à l'écart avec le processus d'embauche traditionnel ?

Oui, il y a quelques années, à cause du stress. Au cours de l'entretien, le "technique" m'a demandé à quoi servait un grep. J'étais déjà stressé et cette question m'a étonné, je me suis demandé où était le piège, je ne connaissais plus mon propre nom. J'ai bredouillé un "Euh, ça sert à détecter des motifs...?", alors que j'avais déjà "grepé" à de très nombreuses reprises.

Après l'entretien, la commerciale qui m'accompagnait m'a dit que le client ne me retiendrait pas car il avait trouvé ma réponse sur le grep "curieuse".

Ironie du sort, je travaille actuellement dans un contexte où j'effectue régulièrement des traitements shell sur des fichiers très volumineux. J'écris donc des scripts avec des awk, des greps et bien d'autres choses.

avec le recul, j'en suis arrivé à la conclusion que l'entretien raté n'était finalement pas de mon fait mais celui du client : une question technique dont on trouve la réponse en 1 minute sur Google est le signe que le recruteur ne maîtrise son sujet et ne sait pas recruter.

[thierryler]

Les entretiens techniques, quand ils ne sont pas conduits par des commerciaux mais par des vrais techos, ça se transforme souvent en cassage de candidat. Et quand le candidat s'en sort trop bien, ça fait peur et on ne le prend pas car il est trop dans la qualité. Arf... (histoire vécue)

Je viens justement de passer plusieurs entretiens techniques. Des QCM bidons qui ne testent même pas le niveau débutant. Mais aussi des questions hypers complexes du style "expliquez MVC en une phrase. vous avez 30 secondes"...

Tiens, un conseil que j'applique régulièrement. Quand on commercial me donne un QCM (ou un test) technique, il me laisse en général tout seul dans une salle pendant une demi heure, voire une heure. Et ben je peux vous dire que mon iPhone est mis à contribution à chaque question pour laquelle j'aurais le moindre doute, surtout sur les questions qui ont l'air trop simple ou qui demande de la culture hyper spécifique (genre quelle est la différence entre EAP1 et EAP2)... Faut juste faire gaffe à ne pas avoir tout juste et ne pas être trop bon de manière générale car les entreprises ont peur des bons profils... Vous vous dites que c'est de la triche d'utiliser Google en entretien ? Moi non, au contraire, car une fois engagé, ça sera un de mes outils principaux, avant même Eclipse...

[Reward]

Ce que j'aimerais m'amuser à faire si j'avais du temps à perdre, ça serait un QCM/Test à poser au DRH/Testeur technique. Ca pourrait révéler des surprises.

[Franck.H]

Ce que j'aimerais m'amuser à faire si j'avais du temps à perdre, ça serait un QCM/Test à poser au DRH/Testeur technique. Ca pourrait révéler des surprises.

Oui tout à fait, surtout aux DRH Dans mon cas mon testeur technique n'est rien d'autre que mon nouveau chef et qui est développeur lui-même donc ce que côté je n'avais pas de mauvaises surprises.

[imikado]

Tiens, un conseil que j'applique régulièrement. Quand on commercial me donne un QCM (ou un test) technique, il me laisse en général tout seul dans une salle pendant une demi heure, voire une heure. Et ben je peux vous dire que mon iPhone est mis à contribution à chaque question pour laquelle j'aurais le moindre doute, surtout sur les questions qui ont l'air trop simple ou qui demande de la culture hyper spécifique (genre quelle est la différence entre EAP1 eth EAP2)... Faut juste faire gaffe à ne pas avoir tout juste et ne pas être trop bon de manière générale car les entreprises ont peur des bons profils... Vous vous dites que c'est de la triche d'utiliser Google en entretien ? Moi non, au contraire, car une fois engagé, ça sera un de mes outils principaux, avant même Eclipse...

Ce n est pas de la triche si vous indiquez avoir fait appel à google

Il n y a pas de honte à ne pas connaitre un terme.

[pcaboche]

Les entretiens techniques, quand ils ne sont pas conduits par des commerciaux mais par des vrais techos, ça se transforme souvent en cassage de candidat. Et quand le candidat s'en sort trop bien, ça fait peur et on ne le prend pas car il est trop dans la qualité. Arf... (histoire vécue)

+1

Je n'ai pas passé énormément d'entretiens, et pourtant j'ai déjà vu des perles dans ce domaine:

- l'entretien technique fait par un commercial

Je ne vois clairement pas l'intérêt. Si vous apportez une réponse intelligente, mais pas celle attendue par le technicien ayant écrit la question, comment le commercial peut-il évaluer la pertinence de votre réponse ? Il ne peut pas !

En gros, ce genre d'entretien, c'est du pur bachotage sans intérêt.


- le cassage de candidat

Il existe plusieurs techniques de cassage de candidat. Je vais commencer par exposer la première.

Première technique de cassage : on pose des questions sur un domaine particulier. Si le candidat s'en sort trop bien, on change complètement de domaine, en espérant que le candidat va se planter. Si malgré tout le candidat s'en sort, soit le recruteur va prendre peur (comme l'explique Thierry), soit le recruteur persiste, avec le risque que ça parte en coui**e.


- le cassage de candidat qui part en coui**e

Le problème de cette technique de cassage de candidat c'est que, à force de chercher la petite bête pour démonter le candidat, on en arrive au point où c'est le recruteur qui commence à raconter n'importe quoi.

Pour un poste de programmeur SQL, ça avait tellement dévié qu'on en était arrivé à discuter de l'implémentation de certaines collections en .Net... et attention ! pas les collections les plus récentes du namespace System.Collections.Generic. Noooooon... les antiques collections du framework 1.0 !

À la question "qu'est-ce qu'une ArrayList?" j'ai répondu que c'était "une collection avec une interface de liste (IList) mais que l'implémentation sous-jacente était en fait un tableau dynamique" (note: avec les problèmes associés quand on insère un élément en millieu de tableau ). Le recruteur me répond que je ne sais pas ce que je dis... c'est bête, la MSDN confirme ce que je dis.

Mais bon, c'était vraiment un cas extrême de cassage de candidat. En effet, initialement pour un poste "simple" de développeur SQL, ça a sérieusement dérivé:
- SQL
- administration de bases de données
- Linq
- programmation fonctionnelle (et autres paradigmes)
- programmation orientée-objet (en général)
- C# (en particulier)
- implémentations internes en .Net
- autres (je ne me souviens plus de tous les détails...)


J'avoue, j'ai pas été très fort sur la partie Linq (loin s'en faut) mais bon, à un moment il faut se mettre d'accord sur la manière de procéder : soit on recherche quelqu'un pour écrire des procédures stockées sur mesure, soit on fait tout dans le code et on laisse le framework générer les requêtes SQL (avec plus ou moins de succès ).

Et comme si ce n'était pas assez, l'entretien a duré plus de 2h et en Anglais. En soit ce n'est pas un problème... sauf que quand il s'agit de devoir supporter un fort accent Français à longueur de temps, je préfère que ça arrive une fois le contrat signé, quand on commence à toucher son salaire. Quand ça arrive pendant un long entretien avec des questions toutes plus débiles les unes que les autres, j'estime que cela va à l'encontre des Conventions de Genève, si vous voyez ce que je veux dire... (*)

Ce fut mon dernier entretien foireux en Europe. Juste après, je suis parti à Singapour...


- les questions ultra spécifiques

La deuxième technique de cassage de candidat (et aussi la plus évidente, donc pour que ça passe un peut plus inapperçu, on l'utilise de préférence en conjonction avec la première), c'est de poser des questions ultra spécifiques.

Exemple (réel) :

- il y a-t'il une limite au nombre de connections sur des "remote servers" que l'on peut faire simultanément en Sybase ?
- j'en sais rien, comme l'indique mon CV j'ai jamais fait de Sybase
- pour votre information, oui, il y en a une. On peut faire seulement 8 connection dans un même script...
- ah, je ne savais pas (et franchement, jusqu'ici, ça ne m'a pas vraiment empêché de vivre )
- on le sait parce qu'on a été confronté au problème récemment
- ... ...

En soi, la dernière phrase résume le fond du problème :
1) à moins d'avoir rencontré EXACTEMENT le problème en particulier, on ne peut pas répondre à la question
2) 8 connections simultanées dans un même script ? Et personnes ne se pose de questions par rapport à l'architecture ? ...

J'ai eu des entretients où justement je retournais les questions au potentiel employeur. Quand ils deviennent trop exigeants il faut leur demander ce qu'ils offrent en échange.

Entièrement d'accord avec cette phrase !

Quand on débute, on veut surtout montrer ce que l'on est capable le candidat idéal et on veut à tout prix "réussir son entretien" (et donc répondre correctement aux questions).

Seulement avec le temps, on devient plus pragmatique.

À force de pratiquer passer des entretiens où le recruteur cherche la petite bête, on devient de plus en plus direct (c'est pas comme si le recruteur ne pouvait pas se faire une idée des compétence du candidat au travers de ses précédentes réalisation).

Donc quand un recruteur commence à chercher la petite bête, parfois il est bon de s'arrêter et de demander direct : "bon, j'ai pas vraiment de temps à perdre; si je réponds correctement à cette question, vous me payez combien ?".

Oui, c'est sec. Cependant, ça remet les choses à leur place (on n'est pas là pour discuter du temps qu'il fait ou pour faire salon autour de différentes technologies, on est là pour parler pognon).

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 !


(*) "Les Conventions de Genève et leurs Protocoles additionnels sont des traités internationaux qui contiennent les règles essentielles fixant des limites à la barbarie de la guerre." (Source: Commité International de la Croix Rouge)

[pmithrandir]

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.

[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

[Grom61736]

L'entretien technique m'a permis (...) 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

Paradoxal ?

[martopioche]

Une première considération est que les entretiens "techniques" sont la plupart du temps du simple bachotage. Même si on parle de "vrai" entretien technique et non pas le QCM proposé par la RH. Le problème est que celui qui fait passer un entretien le fait passer sur ce qu'il connait lui, pas sur ce que connait le candidat. Non patate, je ne connais rien à votre framework que vous utilisez ici, moi je ne l'ai jamais utilisé, pas la peine de me demander quelle différence entre ces 2 méthodes de la classe contrôleur. De toutes manières il n'est pas documenté votre Framework ? Vos équipes ne font que réutiliser ce qu'elles connaissent ?

Ensuite

la solution pourrait consister à inverser le processus de recrutement, que le candidat choisisse lui même son futur patron ( cas d'un marché en pénurie ) ou idéalement se mettre en auto-entreprise / consultant informatique

Même en indépendant, on passe de l'entretien technique, car même en candidat d'une SSII, on les passent ces entretiens. Mais une chose intéressante que l'on oublie parfois dans ces cas, c'est que finalement cet entretien permet d'évaluer le niveau technique de l'environnement dans lequel on va être amené à intervenir.

[martopioche]

Comme un maçon peut faire visiter un chantier en cours, un développeur peut facilement partager du code sur des plateformes comme github sur des projets assez simple.
Les écoles ne poussent pas encore assez dans ce sens, je pense que ça va venir.

Des environnements comme linkedin permettent d'avoir une synthèse consolidé beaucoup plus complète et accessible des compétences qu'un CV classique.

Alors oui, aujourd'hui, je pense que nous sommes entre 2 eaux. Les pratiques des RH sont en train d'évoluer, enfin c'est mon impression.

C'est encore assez rare, mais certains commencent à exiger un lien vers un Github.

[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*****.

[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]

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 ?