Test technique intégrateur web

Je ne sais pas comment ça peut se passer, je ne suis pas intégrateur web. Mais je vais faire deux remarques par rapport à mon expérience (en tant que recruté et en tant que recruteur) sur les tests techniques qui ont pour but d'évaluer ton niveau :

• Il ne faut pas pipoter. Si tu ne sais pas, tu le dis et c'est tout. Si dans un tel cas tu aurai été consulté la doc par ce que tu ne connais pas le truc par coeur, tu le dis. Quelqu'un qui essai de se sauver en inventant en espérant que ça passera inaperçu, ça se voit 99% du temps et ça renvoie une très mauvaise image. Vu ton domaine ça sera probablement des questions HTML css de toute façon, peut être certaines sur ta méthodologie (ex : je te fournit une maquette, quels sont les étapes que tu va suivre pour l'intégrer?). Il m'est arrivé en entretien de ne pas savoir, voir de ne pas être d'accord avec le recruteur. On est passé à autre chose. Après l'entretien j'ai vérifié et renvoyé un mail (pour préciser sur nos points de désaccord qui avait raison ou et pourquoi). Et j'ai eu le poste.
• lié au point précédent, il est NORMAL en entretien de ne pas pouvoir répondre à tout. Si tu trouve l'entretien trop facile ou que tu as pût répondre à tout c'est soit que tu t'es planté sur les questions de bases, soit que le recruteur technique à mal fait son taf (exceptionnellement ça peut être que tu as plus que dépassé son niveau mais la encore c'est une erreur côté recruteur, ils auraient dut mettre un meilleur type en face de toi). Pourquoi ? Parce que l'objectif du test technique est d'évaluer ton niveau. Évaluer ton niveau c'est te pousser dans tes retranchement. Typiquement un recruteur va poser des questions de plus en plus techniques jusqu'à ce que tu bloque. La complexité des questions qu'il pose permet de connaître ton niveau. Si tu ne bloque pas c'est qu'ils n'ont pas atteint ton plafond de connaissance et aurait dut continuer. Il est donc normal de ne plus savoir répondre, cela correspondra en gros à ton niveau et lui pourra décider si ce niveau est suffisant ou pas.

Donc bilan de tout ça, être honnête et ne pas stresser si on ne sait pas répondre aux questions. Être humble et honnête c'est très important. Embaucher quelqu'un prend énormément de temps. Si ils te font passer l'entretien c'est qu'ils pensent que tu pourra convenir, ils ne te font pas passer les tests pour s'amuser. Donc la personne en face de toi n'est pas ton ennemie.

Très difficile de te répondre.

Pour avoir passé des tas d'entretiens soit disant techniques par téléphone ou physiquement, ça varie énormément.

Ça peut prendre les formes suivantes :

1. entretien technique formel avec un responsable technique (la forme que je trouve préférable, mais c'est mon avis)

Dans ce cas, l'objectif est d'évaluer rapidement tes connaissances par le biais de questions pêle-mêle, voire en proposant un problème technique concret. Dans ton cas, par exemple : "Nous disposons d'une base de code CSS existant et on a du mal à s'en sortir, on voudrait remplacer cela par un framework 'connu', comment vous y prendriez-vous ? Par quoi vous commenceriez ?". Autre exemple : la plupart de nos interfaces ne sont pas responsives, et pourtant les chiffres montrent que la plupart de nos clients sont sur mobile. Il faut que nous migrions la chose, petit bout par petit bout. Avez-vous déjà mené à bien ce genre de projet ? Sans trop changer la structure (figée) des pages, comment procéderiez-vous ?"

A toi de faire part de ton expérience, de ce que tu connais, ce que tu as fait. Ce que tu sais bien faire vs. ce dont tu as entendu parler mais n'a jamais fait. Le responsable attend certainement des mots-clefs. Si tu lui parles de media-query alors qu'il t'a demandé comment soumettre un formulaire en AJAX (je schématise évidemment), c'est clairement pas la réponse qu'il attend.

1. Le test technique bête et méchant

Certaines boîtes utilisent des banques de test automatiques. D'autres des questionnaires "à l'oral".

Dans le cas numéro 1, tu peux trouver sur le net des tests tout fait qui pourront t'y entraîner. Ça va des trucs complètement bidons, à des questionnaires très poussés mais généralement hors-d'âge qui parlent de points de langage dépréciés depuis des années (c'est du vécu).

Parfois ce sont de "simples" questions écrites du genre :

"A quoi sert tel text-align ?"

Ou des fois la question est du style : "Que fait ce code ?"

1
2
3

table > td:first-child {
  color: red;
}

Y'a parfois des questions pièges mais souvent très "bateau" également. Par exemple en Java le petit test sur equals / == et le cache des types primitifs revient extrêmement souvent.

1
2
3
4
5
6

Integer i = 1;
int j = 1;
System.out.println(i.equals(j)); // ?
Integer k = 257;
int l = 257;
System.out.println(k.equals(l)); // ?

J'imagine qu'il y a la même chose en CSS avec des petites bricoles du style tu mets un div en absolute, son parent est ou n'est pas en relative, etc. Mais je suis très très loin d'être un expert.

Un bon entraînement pour ce genre de trucs si vraiment tu as du temps et l'envie de t'y préparer :

• lis, lis lis et relis les questions posées sur Stackoverflow ou sur les forums (alsacréations, …) tu y trouveras absolument tous les pièges potentiels pour peu que tu y passes du temps
• lis des guides de bonnes pratiques. Souvent ce genre d'articles recensent des problèmes qui pourraient t'être posées

1. Le test technique concret

On te donne un truc à faire, tu le fais, et la personne corrige avec toi.

Ça c'est généralement le plus difficile, il faut justifier tes choix face à quelqu'un qui (souvent) est là pour te mettre en difficulté. Même en ayant des années et des années d'expérience, il y a toujours des concepts que tu ne connais pas, maîtrise mal, des termes de vocabulaire que tu emploies à mauvais escient etc.

La préparation pour ce genre de trucs c'est :

• lire des bouquins techniques "de référence" (pour de la programmation ça serait un truc sur les design patterns + bouquins ciblés "Effective Java" dans mon cas). Pour l'intégration je ne sais pas trop ce qui fait référence
• faire des exercices style Javaquarium (sur ce site), prologin, etc. Je ne sais si Alsacréations propose ce genre d'exercices mais ça serait intéressant. Et surtout, surtout : montrer ton code et écouter les critiques. En tant que débutant, tu vas forcément écrire des trucs sales, ou mal adaptés, écoute ce qu'on te dit, essaie de comprendre pourquoi ça serait mieux de la façon dont M. X t'a dit de faire

Dans ton cas c'est assez peu probable que ce soit la solution 3. cela dit.

PS : plus tout ce qu'a dit Kje qui est très vrai également.