On entend souvent parler de ce genre de tests: on vous expose un problème et vous devez proposer une solution (ou plusieurs, la solution évoluant pendant l’interview) pour résoudre ce problème.
Ces tests ont été popularisés par les grandes entreprises tech américaines et ce sont des tests que l’on retrouve aujourd’hui un peu partout, et notamment dans les grosses boîtes tech.

Je ne vois personnellement pas vraiment l’intérêt de ce genre de test. Pouvoir réussir ces tests d’algorithmie demande en effet qu’une seule chose: de la préparation et du bachotage. Ils ne jugent donc que d’une chose: avez-vous passé vos 6 derniers mois à faire tous les exercices décrits dans le livre "Cracking the coding interview" ? Cela montre une motivation certaine mais ne nout dit pas grand chose sur les capacités de la personne.

De nombreuses personnes échouent à ce test, et c’est normal. Vous pouvez d’ailleurs généralement retenter votre chance après une certaine durée (6 mois par exemple) chez les GAFAM après échec, donc à force d’insister cela peut finir par passer.
Je trouve ça personnellement étrange, vous n’êtes pas pris mais 6 mois après vous êtes soudainement au niveau parce que ce coup ci l’intervieweur vous a posé un problème qui, coup de chance, est semblable à un que vous avez résolu durant votre entraînement la veille.

J’ai toujours aimé l’algorithmie. J’avais quand j’étais étudiant pris toutes les options d’algo disponibles durant mon Master, j’ai donc quelques bases correctes. Avec le temps j’ai bien sûr oublié pas mal de choses mais les bases restent et je sais reconnaître certains problèmes et où chercher pour les résoudre.

je pense néanmoins que ces tests ne sont pas pertinents et donc je préfère éviter les entreprises avec ce genre de tests à l’entrée. Vous avez passé des années sur des problématiques de code et d’infrastructure complexes, mais vous avez raté votre inversion de binary tree à l’interview donc vous n’êtes pas pris.

EDIT: je ne dis pas que l’algorithmie et les structures de données ne sont pas des sujets importants, mais qu’utiliser cela comme premier test pour filtrer des candidats en masse en les exposant à des problèmes fantaisistes n’est pas ma tasse de thé.
Une personne très compétente peut très bien bloquer sur un problème, comme une autre tomber sur un problème comme je disais rencontré la veille.
Et est ce que ces tests sont vraiment représentatifs de notre métier ? Ne pouvons-nous pas tester autrement ce type de connaissance ?

J’avais reçu après un premier entretien dans une startup un test technique à faire à la maison surprenant.

Je devais écrire une application Python type CRUD (je ne fais pas de Python mais passons) stockant ses données dans PostgreSQL, et gérer ensuite son packaging et son déploiement.

Le déploiement devait se faire sur le cloud de Google (GCP) où je devais déployer l’application sur Kubernetes, puis PostgreSQL en statefulset sur Kubernetes également en mode master/replicas (sans tricher: pas d’operators ou de trucs tout faits). L’application devait parler à un proxy PostgreSQL qui devait se charger de faire la bascule sur le réplica en cas de panne du master. Tout cela devait bien sûr être automatisé avec des outils d’infrastructure as code.

On m’annonçait 12 heures pour la durée de ce test, je l’estime personnellement à plus surtout que je connais mal Python et pas du tout GCP.

j’aurai très bien pu faire ce test (techniquement ça ne n’impressionnait pas plus que ça, c’est juste pénible) mais là aussi je ne vois aucun intérêt à faire un test aussi long, donc j’ai préféré décliner.
Les entreprises doivent comprendre que le temps libre des candidats est aussi limité et qu’on ne peut pas passer des jours à réaliser des tests.

Le test technique que j’ai le plus apprécié était un test théorique. Je devais répondre en quelques heures chez moi (on m’avait indiqué 3 heures maximum, j’ai fait un petit peu plus) à quelques questions et mises en situation autour d’aspects SRE, d’architecture et de performance.

C’était volontairement des questions très ouvertes mais c’est au final la force du test: voir le raisonnement du candidat et les questions et hypothèses qu’il va poser. j’ai vraiment eu le sentiment de pouvoir expliquer ma façon de réfléchir pendant ce test qui était purement écrit, bien plus que lorsqu’on me demande de pondre un rôle Ansible ou un module Terraform.
Je m’en fiche personnellement de savoir si quelqu’un maîtrise Ansible, au pire il ou elle apprendra. Cet exercice écrit permettait de discuter de concepts et pas seulement de technologies, et c’est cela que je recherche dans un test technique.

Une fois le test réalisé un entretien de débriefing était organisé pour discuter du résultat et creuser certains points.

Et vous, que pensez-vous des tests techniques en entretien ?