Questions d'entretien Stripe pour software engineers

Stripe mène la boucle d'entretien d'ingénierie la plus singulière de la tech. Pas de LeetCode. Pas de puzzles au tableau. Vous écrivez du code de qualité production dans votre propre IDE, vous intégrez face à une API quasi réelle, vous traquez des bugs dans du code inconnu et vous défendez vos choix de design devant des ingénieurs qui ont réellement bâti la stack de paiement. La boucle est conçue pour faire ressortir les candidats capables de livrer, pas ceux capables de performer. Ce guide décompose le format et les patterns de questions à partir des rapports publics Glassdoor et des articles d'ingénierie publiés par Stripe.

Le processus d'entretien Stripe

La boucle est plus courte que chez les FAANG, mais chaque tour est plus profond. Screen recruteur (30 minutes). Phone screen technique (60-75 minutes, un ou deux problèmes de coding de style intégration sur coderpad ou votre IDE). Onsite virtuel (une seule journée, 4-5 tours). L'onsite inclut généralement un tour d'intégration (vous construisez une petite fonctionnalité face à une API mock), un tour bug squash (vous diagnostiquez et corrigez des problèmes dans une base de code existante), un tour de system design, un tour comportemental et un échange avec le hiring manager. Le délai du screen à l'offre est d'environ 4-6 semaines.

Stripe demande explicitement aux candidats d'utiliser leur propre environnement de dev. Configurez à l'avance votre éditeur, votre debugger, votre linter et votre test runner. Entraînez-vous dans la configuration exacte que vous utiliserez le jour J — changer de raccourcis clavier ou d'IDE en plein entretien est un handicap auto-infligé. Si vous codez habituellement dans VSCode avec copilot, décidez à l'avance de le désactiver ou non ; Stripe accepte les deux choix, mais l'activer et le désactiver en plein tour signale une méconnaissance de vos propres outils.

Top 10 des questions techniques à préparer

Les questions Stripe récompensent la réflexion orientée production. Voici les patterns récurrents issus des rapports publics.

1. Client HTTP avec retry et backoff — implémentez un petit client qui appelle une API, gère les 429 et 5xx, avec backoff exponentiel et jitter. Conseil : écrivez des tests pour le comportement de retry, pas seulement le happy path.
2. Gestionnaire de clé d'idempotence — encapsulez un endpoint pour que les requêtes dupliquées renvoient des résultats en cache. Conseil : pensez au TTL, aux requêtes en cours et à ce qui se passe quand l'opération en cache a réellement échoué.
3. Vérification de signature de webhook — vérifiez le HMAC, gérez les attaques par rejeu. Conseil : c'est une vraie primitive Stripe — ils veulent vous voir raisonner sur les timing attacks et la tolérance d'horodatage.
4. Rate limiter — token bucket ou sliding window, en mémoire ou distribué. Conseil : clarifiez le périmètre avant d'implémenter ; « pour un seul process » et « pour un cluster » sont deux problèmes différents.
5. Conversion de devises avec cas limites — gérez la précision, l'arrondi et les taux manquants. Conseil : n'utilisez jamais de floats pour de l'argent ; des entiers et des unités mineures explicites.
6. Import CSV avec rapport d'erreurs — parsez un fichier, validez les lignes, émettez un rapport d'erreurs structuré. Conseil : pensez streaming pour les gros fichiers et sémantique de succès partiel.
7. Consommateur de queue avec sémantique at-least-once — traitez les messages, gérez les échecs, retries, dead letters. Conseil : écrivez du code qui rend l'idempotence explicite au niveau du consommateur.
8. Machine à états pour un cycle de vie de paiement — modélisez les transitions (created → processing → succeeded / failed / refunded). Conseil : énumérez les transitions valides et rejetez les invalides dans le code, pas dans les commentaires.
9. Bug squash : bug de fuseau horaire dans un job de facturation — trouvez pourquoi les factures de fin de mois sont décalées d'un jour pour certains utilisateurs. Conseil : lisez d'abord les tests, puis reproduisez en local, puis faites un bisect.
10. Exercice de design d'API — concevez l'API d'une nouvelle fonctionnalité (par ex. abonnements, remboursements). Conseil : pensez extensibilité, réponses d'erreur, versioning et idempotence dès le départ.

Top 5 des sujets de system design

1. Pipeline de traitement des paiements — autorisation, capture, settlement, signaux de fraude, retries, chargebacks.
2. Moteur de facturation d'abonnements — proratisation, dunning, changements de plan en milieu de cycle, gestion des devises.
3. Système de transactions idempotent — sémantique exactly-once en cas de pannes réseau, écritures concurrentes, consensus distribué.
4. Système de livraison de webhooks — livraison at-least-once, backoff exponentiel, dead letters, statut de retry visible par le client.
5. Ledger / comptabilité en partie double — journal immuable, soldes dérivés, réconciliation, piste d'audit.

Les interviewers Stripe accordent une grande importance à la correction en cas de panne. Pour chaque design, faites émerger ce qui se passe quand un service downstream timeout, quand deux requêtes entrent en compétition et quand un déploiement interrompt une opération en cours. « On fait un retry » sans préciser la sémantique de retry (idempotent ? backoff ? nombre max de tentatives ? dead letter ?) sous-performe.

Top 5 des questions comportementales

1. Racontez-moi une fois où vous avez dû livrer quelque chose avec des informations incomplètes. Stripe est une entreprise à fort contexte et qui avance vite ; l'aisance avec l'ambiguïté est centrale.
2. Décrivez un système que vous avez construit et qui tourne encore. La longévité et l'ownership opérationnel comptent plus que la nouveauté.
3. Expliquez-moi comment vous gérez un incident en production. Un incident précis, votre rôle, les patterns de communication, le suivi.
4. Racontez-moi une fois où vous avez contesté une décision produit. Stripe valorise les ingénieurs qui façonnent l'orientation produit, pas seulement ceux qui exécutent.
5. Comment décidez-vous quoi tester et quoi livrer ? Le pragmatisme prime sur le dogme ; les exemples précis gagnent.

Conseils propres à la culture de Stripe

Les ingénieurs Stripe rédigent énormément de documents internes. « Memos win arguments » fait partie de la culture. Dans le tour comportemental, mentionnez l'écriture comme outil : design docs, postmortems, RFCs. Des titres ou types de documents précis battent les affirmations génériques « je communique bien ».

Traitez le tour d'intégration comme du vrai travail. Lisez attentivement la spec de l'API avant de coder. Posez des questions de clarification sur le comportement aux limites (que se passe-t-il si l'API renvoie un 503 ? si la requête est malformée ?). Écrivez un test pour au moins un cas d'erreur. Sauter les tests est le mode d'échec le plus courant — Stripe est une entreprise de paiement ; du code non testé est le mauvais signal.

Pour le tour bug squash, le workflow qui obtient les meilleurs scores : reproduire le bug en local avec un test qui échoue, faire un bisect via des prints ou un debugger, corriger, vérifier la correction avec le test, puis expliquer la cause racine et quel autre code pourrait avoir le même bug. Les candidats qui obtiennent les plus mauvais scores sautent à une correction dans les 5 premières minutes sans reproduire.

Questions fréquentes