Les trois formats d'entretien technique
L'entretien technique prend généralement trois formes distinctes, parfois combinées dans un même processus de recrutement. Chacune évalue des compétences différentes et nécessite une préparation spécifique.
- L'entretien algorithmique : résolution de problèmes de coding en temps limité, souvent sur une plateforme en ligne (CoderPad, HackerRank) ou sur un tableau blanc
- Le system design : conception d'une architecture technique complète pour répondre à un besoin métier
- Le live coding : écriture de code fonctionnel en pair programming avec l'intervieweur
Questions de coding algorithmique
Les classiques qui reviennent constamment
Manipulation de tableaux et chaînes : inverser une chaîne sans méthode native, trouver les doublons dans un tableau, fusionner deux tableaux triés. Ces questions testent votre maîtrise des structures de base et votre réflexe d'optimisation.
Structures de données : implémenter une stack avec getMin() en O(1), détecter un cycle dans une liste chaînée, valider un arbre binaire de recherche. Le recruteur vérifie que vous connaissez les structures au-delà de leur interface.
Algorithmes de recherche et tri : recherche binaire sur un tableau rotatif, tri d'un tableau de 0, 1 et 2 sans tri classique, k-ième plus grand élément. La complexité temporelle est toujours discutée.
La méthode pour aborder chaque problème
1. Clarifiez les contraintes : taille des entrées, types de données, cas limites. Posez au moins deux questions avant de coder
2. Proposez une approche brute-force d'abord : montrez que vous comprenez le problème avant d'optimiser
3. Annoncez la complexité : dites "cette approche est en O(n2), je pense qu'on peut faire O(n log n)" avant de coder
4. Codez proprement : noms de variables explicites, fonctions courtes, commentaires sur les parties non évidentes
5. Testez avec des exemples : parcourez votre code à la main avec un cas simple puis un cas limite
Erreurs fatales en coding
- Coder en silence pendant 20 minutes sans expliquer votre raisonnement
- Ignorer les cas limites (tableau vide, un seul élément, valeurs négatives)
- Refuser d'écrire une solution brute-force par peur de paraître "pas assez bon"
- Ne pas tester votre code une fois écrit
Questions de system design
Exemples de sujets courants
- "Concevez un raccourcisseur d'URL type Bitly" : teste votre compréhension du hashing, du stockage clé-valeur et du dimensionnement
- "Concevez le fil d'actualité de Twitter" : teste la gestion du fan-out, du cache et des architectures événementielles
- "Concevez un système de chat en temps réel" : teste votre connaissance des WebSockets, de la persistance et de la scalabilité horizontale
- "Concevez un système de réservation comme Booking" : teste la gestion de la concurrence, des transactions et de la cohérence
La structure à suivre systématiquement
Minute 0-5 : Cadrage. Définissez le périmètre. Combien d'utilisateurs ? Quelle latence acceptable ? Quelles fonctionnalités prioritaires ? Un bon candidat réduit le problème à un périmètre réaliste pour 45 minutes.
Minute 5-15 : API et modèle de données. Décrivez les endpoints principaux et le schéma de base de données. Justifiez vos choix (SQL vs NoSQL, normalisation vs dénormalisation).
Minute 15-30 : Architecture haut niveau. Dessinez les composants : load balancer, serveurs applicatifs, base de données, cache, file de messages. Expliquez le flux d'une requête de bout en bout.
Minute 30-40 : Approfondissement. Le recruteur vous demandera de zoomer sur un aspect : "Comment gérer 10 millions d'écritures par seconde ?" ou "Que se passe-t-il si ce composant tombe ?". C'est ici que la profondeur technique fait la différence.
Minute 40-45 : Compromis. Résumez les trade-offs de votre architecture. Mentionnez ce que vous amélioreriez avec plus de temps.
Ce qui différencie les bons candidats
Les recruteurs en system design ne cherchent pas la solution parfaite. Ils évaluent votre capacité à raisonner sur les compromis. Dire "j'utilise Redis comme cache parce qu'il est rapide" est faible. Dire "j'utilise Redis comme cache-aside avec un TTL de 5 minutes, ce qui accepte une incohérence de 5 minutes en échange d'une réduction de 80% de la charge sur la base" montre une vraie compréhension.
Le live coding en pair programming
Format typique
Vous partagez votre écran (ou travaillez sur un IDE partagé) et implémentez une fonctionnalité réelle pendant 60 à 90 minutes. L'intervieweur joue le rôle d'un collègue.
Les do's
- Verbalisez votre raisonnement en continu : "Je commence par le modèle de données, ensuite je ferai le endpoint, puis les tests"
- Posez des questions sur les exigences comme vous le feriez avec un vrai collègue
- Écrivez des tests : même un ou deux tests unitaires montrent votre rigueur
- Faites des commits logiques si vous travaillez avec Git
- Demandez du feedback : "Est-ce que cette approche vous semble raisonnable avant que j'avance ?"
Les don'ts
- Ne copiez-collez pas depuis Stack Overflow sans comprendre le code : l'intervieweur vous posera des questions dessus
- Ne passez pas 30 minutes sur la configuration : préparez votre environnement de développement la veille
- N'ignorez pas les erreurs : si votre code ne compile pas, déboguez méthodiquement au lieu de changer de stratégie
- Ne surengineez pas : un code simple qui fonctionne vaut mieux qu'une architecture complexe inachevée
Le whiteboard : conseils spécifiques
Écrire sur un tableau blanc est physiquement différent d'écrire dans un IDE. Quelques conseils pratiques :
- Utilisez des abréviations cohérentes : ne perdez pas de temps à écrire des noms de variables de 20 caractères
- Structurez l'espace : réservez un tiers du tableau pour les exemples et les cas limites
- Utilisez des couleurs différentes si des marqueurs sont disponibles : une couleur pour le code, une pour les annotations
- Entraînez-vous physiquement : pratiquez chez vous sur un grand papier ou un tableau Velléda avant l'entretien
Ressources et préparation
La préparation technique efficace prend entre 4 et 8 semaines à raison de 1 à 2 heures par jour. Concentrez-vous sur les patterns plutôt que sur la mémorisation de solutions individuelles. Les patterns les plus rentables : sliding window, two pointers, BFS/DFS, dynamic programming bottom-up, et merge intervals.
Pour le system design, lisez des articles techniques de blogs d'ingénierie (engineering blogs de Stripe, Uber, Airbnb) et entraînez-vous à dessiner des architectures pour des systèmes que vous utilisez au quotidien.
CandidIA prépare vos entretiens techniques avec un coaching adapté au poste visé. Le coach IA analyse la fiche de poste, identifie les compétences techniques attendues et vous entraîne sur les questions les plus probables avec un feedback détaillé sur votre approche et votre communication.