Preguntas de entrevista de Stripe para software engineers

Stripe corre el proceso de entrevista de ingeniería más distintivo de tech. Sin LeetCode. Sin puzles de pizarra. Escribe código de calidad de producción en su propio IDE, integra contra una API casi real, caza bugs en código desconocido y defiende sus decisiones de diseño ante ingenieros que de verdad construyeron el stack de pagos. El proceso está diseñado para sacar a la luz candidatos que pueden entregar, no candidatos que pueden actuar. Esta guía desglosa el formato y los patrones de preguntas a partir de reportes públicos de Glassdoor y de las propias entradas del blog de ingeniería publicadas por Stripe.

El proceso de entrevista de Stripe

El proceso es más corto que el de los FAANG, pero cada ronda es más profunda. Screen del recruiter (30 minutos). Phone screen técnico (60-75 minutos, uno o dos problemas de coding estilo integración en coderpad o en su IDE). Onsite virtual (un solo día, 4-5 rondas). El onsite suele incluir una ronda de integración (construye una pequeña feature contra una API mock), una ronda de bug squash (diagnostica y arregla problemas en una base de código existente), una ronda de diseño de sistemas, una ronda conductual y una charla con el hiring manager. La cronología desde el screen hasta la oferta es de aproximadamente 4-6 semanas.

Stripe le dice explícitamente a los candidatos que usen su propio entorno de desarrollo. Configure su editor, debugger, linter y test runner con antelación. Practique en el mismo setup exacto que usará el día — cambiar de keybindings o de IDE a mitad de la entrevista es una desventaja autoinfligida. Si normalmente programa en VSCode con copilot, decida con antelación si lo desactiva; a Stripe le parece bien cualquiera de las dos opciones, pero encenderlo y apagarlo a mitad de ronda señala poca familiaridad con sus propias herramientas.

Top 10 de preguntas técnicas para preparar

Las preguntas de Stripe premian el pensamiento de producción. Estos son los patrones recurrentes de los reportes públicos.

1. Cliente HTTP con retry y backoff — implemente un cliente pequeño que llama a una API, maneja 429s y 5xx, con backoff exponencial y jitter. Pista: escriba tests para el comportamiento de retry, no solo el camino feliz.
2. Manejador de idempotency key — envuelva un endpoint para que las peticiones duplicadas devuelvan resultados cacheados. Pista: piense en el TTL, las peticiones en vuelo y qué pasa cuando la operación cacheada realmente falló.
3. Verificación de firma de webhook — verifique el HMAC, maneje ataques de replay. Pista: este es un primitivo real de Stripe — quieren verle razonar sobre ataques de timing y tolerancia de timestamp.
4. Rate limiter — token bucket o sliding window, en memoria o distribuido. Pista: aclare el scope antes de implementar; "para un proceso" y "para un cluster" son problemas distintos.
5. Conversión de divisas con casos límite — maneje precisión, redondeo y tipos de cambio faltantes. Pista: nunca use floats para dinero; enteros y unidades menores explícitas.
6. Importación de CSV con reporte de errores — parsee un archivo, valide filas, emita un reporte de errores estructurado. Pista: piense en streaming para archivos grandes y en semántica de éxito parcial.
7. Consumidor de cola con semántica at-least-once — procese mensajes, maneje fallos, retries, dead letters. Pista: escriba código que haga la idempotencia explícita a nivel del consumidor.
8. Máquina de estados para un ciclo de vida de pago — modele transiciones (created → processing → succeeded / failed / refunded). Pista: enumere las transiciones válidas y rechace las inválidas en el código, no en comentarios.
9. Bug squash: bug de zona horaria en un job de facturación — encuentre por qué las facturas de fin de mes se desvían un día para algunos usuarios. Pista: lea primero los tests, luego reproduzca en local, luego haga bisect.
10. Ejercicio de diseño de API — diseñe la API para una nueva feature (p. ej., subscriptions, refunds). Pista: piense en extensibilidad, respuestas de error, versionado e idempotencia desde el principio.

Top 5 de temas de diseño de sistemas

1. Pipeline de procesamiento de pagos — autorización, captura, settlement, señales de fraude, retries, chargebacks.
2. Motor de facturación de subscriptions — proration, dunning, cambios de plan a mitad de ciclo, manejo de divisas.
3. Sistema de transacciones idempotente — semántica exactly-once bajo fallos de red, escrituras concurrentes, consenso distribuido.
4. Sistema de entrega de webhooks — entrega at-least-once, backoff exponencial, dead letters, estado de retry visible para el cliente.
5. Ledger / contabilidad de doble entrada — journal inmutable, balances derivados, reconciliación, audit trail.

A los entrevistadores de Stripe les importa profundamente la corrección bajo fallo. Para cada diseño, saque a la luz qué pasa cuando un servicio downstream da timeout, cuando dos peticiones compiten y cuando un deploy interrumpe una operación en vuelo. "Hacemos retry" sin especificar la semántica de retry (¿idempotente? ¿backoff? ¿máximo de intentos? ¿dead letter?) rinde por debajo.

Top 5 de preguntas conductuales

1. Cuénteme una vez en que tuvo que entregar algo con información incompleta. Stripe es una empresa de alto contexto y movimiento rápido; la comodidad con la ambigüedad es central.
2. Describa un sistema que construyó y que sigue en funcionamiento. La longevidad y el ownership operativo importan más que la novedad.
3. Explíqueme cómo maneja un incidente de producción. Un incidente específico, su rol, los patrones de comunicación, el seguimiento.
4. Cuénteme una vez en que discrepó de una decisión de producto. Stripe valora a los ingenieros que dan forma a la dirección del producto, no solo la ejecutan.
5. ¿Cómo decide qué testear y qué entregar? Pragmatismo sobre dogma; ganan los ejemplos específicos.

Consejos específicos de la cultura de Stripe

Los ingenieros de Stripe escriben muchos documentos internos. "Los memos ganan las discusiones" forma parte de la cultura. En la ronda conductual, mencione la escritura como herramienta: design docs, postmortems, RFCs. Los títulos o tipos de documento específicos ganan a las afirmaciones genéricas de "me comunico bien".

Trate la ronda de integración como trabajo real. Lea la spec de la API con cuidado antes de programar. Haga preguntas aclaratorias sobre el comportamiento en los bordes (¿qué pasa si la API devuelve un 503? ¿qué pasa si la petición está malformada?). Escriba un test para al menos un caso de error. Saltarse los tests es el modo de fallo más común — Stripe es una empresa de pagos; el código sin tests es la señal equivocada.

Para la ronda de bug squash, el flujo que puntúa más alto: reproduzca el bug en local con un test que falla, haga bisect con prints o un debugger, arregle, verifique el arreglo con el test y luego explique la causa raíz y qué otro código podría tener el mismo bug. Los candidatos que puntúan más bajo saltan a un arreglo en los primeros 5 minutos sin reproducir.

Preguntas frecuentes