Chaque candidat reçoit un environnement cloud isolé avec un vrai système dedans : un service qui ne démarre pas, un cluster grand ouvert, un déploiement qui n'a jamais été écrit. Ce qui revient, c'est ce qu'il a réellement fait.
$ docker compose up -d
3 services démarrés
$ systemctl status api
active (running)
$ curl -s localhost:8080/health
{"status":"ok"}
Environnement actif
En cours2 h 12 restantes dans le créneau
Sans Scalyz
Avec Scalyz
Ce qui est en jeu
Personne ne découvre qu'un recrutement DevOps était raté en relecture de code. On le découvre pendant un incident.
Où ça se voit
Le premier incident
L'écart entre décrire un rollback et l'exécuter est invisible en entretien et évident à 3h du matin.
Qui le paie
L'astreinte
Un recrutement qui ne tient pas l'astreinte dégrade le tour de garde de tous ceux qui la tiennent.
Ce qu'un entretien ne peut pas demander
Montrez-moi
L'accès à un vrai système est la seule chose qu'un entretien ne peut pas donner. C'est la seule chose que ceci remplace.
Trois étapes, de l'annonce à une shortlist que vous pouvez défendre, sans un seul appel de présélection.
Recrutement backend, juillet
OuverteClôture vendredi, 18:00
Vous choisissez le lab et la date limite, puis envoyez toute la liste de candidatures en une fois, par email, par import CSV ou via un lien partageable.
Environnement actif
En cours2 h 12 restantes dans le créneau
Chaque candidat reçoit sa propre machine, une vraie, avec une vraie mission déjà en place.
Camille Durand
Évaluation DevOps
Aucune alerte d'intégrité
La notation s'exécute automatiquement par rapport à la mission, donc le classement se construit au fil des sessions terminées.
$ docker compose up -d
3 services démarrés
$ systemctl status api
active (running)
$ curl -s localhost:8080/health
{"status":"ok"}
Mission
Créneau de 3 hLe déployer derrière un load balancer
2 sur 4 terminés
Ce sont de vrais systèmes, pas des exercices : un service Go qui doit redémarrer tout seul sous systemd, une stack Node et Postgres qui ne se parle plus, un déploiement Kubernetes à durcir, un serveur web à construire avec Ansible.
Les missions publiées pour ce poste
Des réponses directes sur le fonctionnement réel des tests, de la notation et des crédits.
Une vraie machine virtuelle avec une vraie mission, pas un QCM. Le candidat travaille avec les mêmes outils qu'au quotidien, et toute la session est enregistrée pour que vous puissiez en revoir les preuves ensuite.
Automatiquement. Les vérifications s'exécutent sur ce que le candidat a livré, et vous obtenez un rapport détaillé compétence par compétence, donc personne dans votre équipe n'a rien à corriger à la main.
Un chatbot peut suggérer des commandes, mais il ne peut pas piloter un système en marche à la place du candidat. La mission doit être accomplie sur la machine elle-même, et chaque signal de triche du rapport arrive avec son contexte pour que vous jugiez vous-même.
En crédits, un par candidat. Un crédit est réservé quand vous envoyez une invitation et libéré si elle expire sans être utilisée. Vous payez par candidat testé, jamais par utilisateur.
Oui. Importez vos fichiers au format .zip, renommez la mission pour correspondre à votre poste, et passez-la vous-même pour un crédit d'abord. Ce que vous avez testé est exactement ce que les candidats recevront.
À leur rythme. Ils démarrent le test au moment qui leur convient, travaillent avec de vrais outils sur une vraie machine, et terminent en une seule fois. Le tout en anglais et en français.
Réservez une démo : on fait tourner une de ces missions sur votre poste ouvert.
1 crédit par candidat, réservé à l'envoi, libéré à l'expiration