Cómo aprobé la entrevista de ingeniero de software en Adobe

TL;DR

• Aprobé el proceso de ingeniero de software de Adobe después de casi suspender la ronda en la que te piden que expliques algo que has construido tú.
• Mi proceso fue una llamada con recruiting, una prueba técnica de una hora y cuatro rondas de onsite: código práctico, revisión a fondo de un proyecto propio, una ronda de diseño con forma de producto y una conversación con el hiring manager.
• El listón de código estaba mucho más cerca del trabajo real que del LeetCode difícil, y la profundidad con la que defendí mis propios compromisos técnicos pesó más que mi velocidad resolviendo algoritmos.
• Si repitiera la preparación, dedicaría la primera semana a escribir la bitácora de decisiones de tres proyectos y solo la segunda a picar código.

Introducción

Mandé la candidatura a Adobe en marzo desde el móvil, en la cola del súper, con el mismo currículum que había enviado a otras once empresas. Llevaba algo más de cinco años como full-stack en una empresa mediana de Madrid, casi siempre en la parte de editor de un producto de documentos colaborativos, y tres meses metido en un plan de preparación muy disciplinado y muy equivocado: 40 minutos de algoritmos antes de trabajar, 90 después, y una hoja de cálculo con una columna en rojo, ámbar y verde por patrón.

Acabé con una oferta para un puesto de ingeniería de producto de nivel intermedio, y estuve a una ronda de quedarme fuera por algo que no tenía nada que ver con la hoja de cálculo.

Cómo llegué a la entrevista

La candidatura del súper no hizo nada durante seis semanas. Lo que la movió fue aburrido: localicé a una ingeniera del equipo a través de una excompañera y le escribí un mensaje corto nombrando la superficie de producto que quería tocar, una cosa que yo había construido cerca de eso y la pregunta de si tenía sentido una referencia interna. Nueve días después tenía correo de recruiting.

Un detalle del mercado español que aprendí tarde: que una vacante aparezca publicada para España no significa que el equipo esté en España. En mi caso estaba repartido por Europa, el idioma de trabajo era el inglés y la oficina de Madrid no era el centro de gravedad de nada de lo que yo iba a tocar. Pregunta dónde vive el equipo en la primera llamada, no en la última.

La llamada con recruiting, 30 minutos, principios de abril

Estándar, pero no un trámite. Me preguntó qué trabajo quería hacer a continuación y luego me lanzó dos preguntas que no esperaba de recruiting:

• «¿Qué producto usas a diario sobre el que tengas una opinión concreta acerca de una decisión de diseño?»
• «Cuéntame algo que hayas construido donde hoy tomarías otra decisión.»

La primera la respondí bien, porque tenía una opinión sobre la pila de deshacer de un editor de texto. La segunda la respondí fatal: algo sobre «ojalá hubiéramos escrito más tests», el equivalente a decir que tu mayor defecto es que te implicas demasiado. Vi que apuntaba algo.

También me dio el nombre de las rondas: prueba técnica, y después código, revisión a fondo de un proyecto propio, diseño y hiring manager. Entre cuatro y seis semanas hasta la decisión; el mío tardó cinco.

La prueba técnica, una hora, mediados de abril

Un editor compartido con un ingeniero de un equipo vecino, y la primera señal de que mi preparación apuntaba al sitio equivocado. Había hecho sesiones cronometradas en PhantomCodeAI antes de la llamada, todas de algoritmos, que era el ensayo equivocado para lo que me encontré.

El arquetipo: parsear un formato de entrada estructurado pequeño, normalizarlo en una representación en memoria y responder un par de consultas contra ella. Después extenderlo. Después tratar entradas mal formadas que yo no había contemplado. Nada de aquello era difícil en el sentido de LeetCode. Medía si sabía escribir código que otra persona pudiera mantener, con nombres razonables, una estructura de datos elegida por las consultas y no por lucirse, y errores que fallaran de forma ruidosa en lugar de devolver una lista vacía en silencio.

Pasé, pero con dos observaciones. Los primeros cuatro minutos los pasé tecleando callado, porque ese era el músculo que había entrenado. Y al pedirme extender el código, mi diseño inicial se me puso en contra, porque había optimizado para el primer requisito en vez de para la forma del problema. Lo escuché en la pregunta siguiente: «si hubieras sabido que esto venía después, ¿qué habrías hecho distinto al principio?». Esa pregunta, disfrazada de mil maneras, resultó ser el proceso entero.

El onsite: cuatro rondas en dos bloques

Mi onsite se partió en dos por un problema de agenda suyo: dos rondas un jueves y las dos últimas el martes siguiente. Esos cinco días de margen son la única razón por la que tengo una oferta.

Ronda 1: código práctico, 55 minutos

Un problema práctico con envoltorio de producto. El arquetipo: dado un flujo de acciones de usuario, mantener una vista derivada que responda barato a una pregunta concreta y permitir deshacer las últimas N acciones.

La parte de deshacer fue lo interesante. Mi primer diseño recalculaba la vista desde cero, correcto y lento. El entrevistador me dejó terminar y preguntó qué pasa cuando N es grande y el registro es largo. Comparé una operación inversa por tipo de acción frente a instantáneas cada K acciones, elegí instantáneas más reproducción porque la inversa de uno de los tipos era ambigua, y dije en voz alta que eso cambia memoria por simplicidad. Le vi más contento con el razonamiento que con el código, que creo hoy que es el objetivo de la ronda.

Ronda 2: la revisión a fondo de un proyecto propio, 50 minutos — la ronda que casi me deja fuera

Aquí me deshice. El enunciado era simple: «elige algo que hayas construido en los últimos dos años y cuéntamelo». Elegí el autoguardado e historial de versiones de nuestro editor. Buen proyecto, ejecución pésima.

Lo que entregué fue un recorrido turístico. Aquí está el cliente, aquí la cola, aquí la capa de almacenamiento, así funcionaba la resolución de conflictos, y aguantaba unos cuantos miles de documentos concurrentes. Cronológico. Con forma de diagrama de arquitectura. Una charla de conferencia.

Él me sacaba del recorrido con preguntas que no supe responder bien:

• «¿Por qué hacer debounce por temporizador y no por fronteras semánticas del documento?»
• «¿Qué perdisteis al escribir el documento entero en lugar de un delta?»
• «¿Quién se quejó primero cuando salió a producción, y de qué se quejó?»
• «¿Qué medisteis antes de decidir que ese compromiso era el correcto?»

Tenía respuesta para dos de las cuatro, y reconstruidas a posteriori. La verdad incómoda: algunas de esas decisiones las tomó un tech lead en una reunión a la que asistí sin rechistar, y nunca me había molestado en reconstruir el razonamiento. Así que hice lo peor posible: tapé los huecos y dije «decidimos» muchas veces.

En el minuto cuarenta dejó de repreguntar y empezó a contarme cómo resuelve su equipo un problema parecido, cosa que interpreté, correctamente, como que ya había terminado de evaluarme. Colgué y lo supe.

Aquí hay una trampa muy española: en muchos procesos locales, cuando te dicen «háblame de un proyecto» les vale con el recorrido. Cuentas la arquitectura, quedas bien y pasas. Yo llevaba años entrenando ese formato, y aquí no vale nada.

Los cinco días de margen

Tenía un fin de semana y tres tardes. No abrí un solo algoritmo. Hice dos cosas.

La primera, escribir lo que ahora llamo la bitácora de decisiones de tres proyectos. Una página por proyecto, con un formato rígido a propósito: la decisión, las dos alternativas que no tomamos, el motivo concreto, el coste que pagamos, lo que medimos y lo que cambiaría hoy. Entre tres y cinco decisiones por proyecto. Cuando no podía rellenar una casilla con honestidad, iba a buscarla a un documento de diseño viejo, a un hilo de Slack de hace catorce meses o al panel de métricas, para tener números en vez de adjetivos. El de autoguardado me costó cuatro horas.

La segunda, cuatro simulacros en PhantomCodeAI centrados solo en ese tipo de ronda. Las transcripciones dejaron el patrón vergonzosamente claro: al empezar cada respuesta yo narraba cronología («primero construimos X, luego vimos que Y») en vez de abrir con la decisión y su coste. Más de dos minutos de media antes de decir nada evaluable. En la cuarta pasada ya abría con «la decisión interesante aquí era A frente a B, elegimos A y nos costó C».

Un detalle que en España importa y nadie cuenta: todo esto lo hacía en inglés, y la cronología era además mi refugio lingüístico, porque contar una secuencia en otro idioma es mucho más fácil que defender un compromiso técnico. Ensayar las primeras frases directamente en inglés me quitó segundos de latencia por respuesta.

Cambio pequeño. Valió el proceso entero.

Ronda 3: diseño y arquitectura, 60 minutos

Con forma de producto, no de infraestructura. No «diseña un acortador de URLs», sino: diseña el comportamiento sin conexión y el modelo de sincronización de una herramienta de edición donde el usuario espera que su trabajo sobreviva a cerrar la tapa del portátil a mitad de frase. Dos cosas se separaban del system design estilo FAANG que llevaba meses machacando.

Las restricciones eran de experiencia de usuario, no de throughput. Las repreguntas: «qué ve el usuario mientras esto se reconcilia», «qué pasa si dos dispositivos no coinciden y uno es el móvil», «qué modos de fallo son aceptables para producción». Cuando saqué números de capacidad, me dejó hablar noventa segundos y me devolvió a la semántica de conflictos.

El alcance se evaluó de forma explícita. Sobre el minuto 40: «tienes un ingeniero y seis semanas, ¿qué entra en la v1?». Recorté la edición sin conexión completa, mantuve la recuperación tras caída desde un búfer local y dejé la v1 con última escritura gana y un aviso visible de conflicto, porque una fusión silenciosa incorrecta es peor que una fea pero honesta. Ella insistió en si el aviso no era una salida por la tangente; le dije que sí, que era la correcta para seis semanas, y que querría telemetría de cuántas veces se dispara antes de decidir sobre la v2.

Ahí giró el proceso: dejó de ser una evaluación y pasó a ser dos personas discutiendo una decisión de producto, y elegí seguir defendiendo mi postura en vez de darle la razón.

Ronda 4: el hiring manager, 50 minutos

Apenas técnica, y contó mucho.

Me preguntó qué quería estar haciendo en dos años, qué tipo de feedback encajo mal y qué haría si un diseñador y yo no nos ponemos de acuerdo en si algo está listo. Después me dio una situación real de su equipo, una funcionalidad que iba a salir con una arista conocida, y me preguntó qué recortaría, qué mantendría y qué retrasaría.

Usé el hábito de la bitácora sin darme cuenta. En lugar de una filosofía general, nombré qué cosa recortaría, por qué ese recorte era barato y qué mediría después de publicar para saber si me había equivocado. Discutió una de mis elecciones. Mantuve dos puntos, cedí en el tercero y expliqué por qué.

Casi al final: «¿qué estamos haciendo sobre lo que tú nos discutirías?». Merece la pena prepararla. Nombré un comportamiento concreto del producto que uso, expliqué por qué me parecía el valor por defecto equivocado y dije qué necesitaría saber antes de fiarme de esa opinión. Al despedirnos me preguntó qué dudas tenía y yo llevaba seis apuntadas, que no es un rasgo de personalidad sino la señal más barata que puedes comprar.

La espera y la llamada

Once días de nada. El octavo mandé a recruiting una nota corta y nada ansiosa preguntando si necesitaba algo más de mí, que es la cantidad máxima aceptable de insistencia. La llamada llegó un viernes por la tarde: oferta para el puesto de nivel intermedio, en el equipo con el que había hablado. El detalle del comité que me sigue rondando es que la ronda del proyecto propio entró como la señal más débil de mi proceso, y las de diseño y hiring manager la compensaron.

La negociación, y lo que cambia en España

No voy a publicar números: un dato de una sola persona es peor que ningún dato. La forma de lo que pedí sí transfiere, y en España hay comprobaciones que no aparecen en las guías escritas en Estados Unidos.

1. La banda y mi posición dentro de ella. No «¿puedes mejorarlo?», sino «cuál es el rango para este nivel y esta ubicación, en qué punto está esta oferta y qué la movería».
2. Doce pagas o catorce. Es la fuente número uno de comparaciones mal hechas aquí: si vienes de catorce pagas y comparas el bruto anual sin normalizar, o te crees rico o te crees estafado. Pregúntalo por escrito, junto con la parte variable.
3. Si hay acciones, el calendario. Fuera de las grandes tecnológicas es un componente poco habitual aquí y mucha gente lo valora fatal. Pregunta el periodo de consolidación, la retención inicial y si existe política de refresco anual.
4. Fecha de incorporación y primer proyecto. Pedí tres semanas más para cuadrar el preaviso de mi contrato y me las dieron al momento. Y pedí por escrito cuál sería mi primer proyecto: no es contractual, es claridad.

Un componente se movió, los demás no. Resultado normal, y tardé unos días en dejar de sentir que debería haber apretado más.

El plan de dos semanas que repetiría

Con catorce días, así los gastaría. Fíjate en el poco código que hay dentro.

Días 1-3: bitácoras de decisiones. Tres proyectos, una página cada uno, el formato de arriba. Si una casilla queda vacía, busca la respuesta en documentos de diseño viejos, tickets y paneles. Al menos un número real por proyecto. Es lo que más rinde y casi nadie lo hace.

Día 4: ensayar las aperturas. Para cada decisión de esas bitácoras, di la primera frase en voz alta hasta que abra con el compromiso y no con la cronología. Si el proceso va a ser en inglés, ensáyala en inglés. Grábate. Hazlo igual.

Días 5-7: código práctico en un editor de verdad, nada de puzles. Elige problemas a los que puedas añadir un segundo y un tercer requisito después de darlos por terminados, y escribe los tests. Si toda tu preparación vive en una plataforma que te corrige contra casos ocultos, estás entrenando el reflejo equivocado; el banco de preguntas de código sirve para el patrón de extender tu propio código.

Días 8-10: diseño con forma de producto. Diseña una subfuncionalidad difícil de tres herramientas que uses: deshacer a través de la red, edición sin conexión, versionado, permisos sobre recursos compartidos. Responde a «qué entra en la v1 con un ingeniero y seis semanas» y a «qué ve el usuario cuando falla». Sáltate la capacidad.

Día 11: la ronda del manager. Escribe por qué ese equipo, qué quieres en dos años, un desacuerdo que perdiste y una cosa del producto que discutirías. Las preguntas de competencias sirven de guion de partida. Después escribe tus seis preguntas.

Días 12-13: dos simulacros completos, uno detrás de otro. Los míos los hice en PhantomCodeAI porque necesitaba la transcripción más que una opinión amable, y comprobaba si seguía derivando hacia la cronología bajo presión. Haz al menos uno cansado, que es como llegarás a la cuarta ronda.

Día 14: nada. Relee las bitácoras y duerme.

Lo que le diría al de marzo

Los tres meses de algoritmos no fueron tiempo tirado: hicieron que las rondas de código me resultaran tranquilas. Pero estaban mal proporcionados. Mi proceso premiaba la profundidad sobre un sistema que yo había construido de verdad y la capacidad de defender una decisión de producto ante un desacuerdo suave, y yo no había dedicado tiempo a ninguna de las dos cosas.

Si llevas meses entrenando el patrón FAANG y vas a entrevistarte donde se vive del oficio de producto, el ajuste no es preparar más. Es preparar otra cosa, apuntando a la parte de tu experiencia que nunca has tenido que explicarle a un desconocido con permiso para seguir preguntando por qué. Ve a escribir la bitácora primero: me costó casi perder una oferta aprenderlo.

Preguntas frecuentes

¿Cuántas rondas tiene el proceso de Adobe?

El mío tuvo una llamada de 30 minutos con recruiting, una prueba técnica de una hora en un editor compartido y cuatro rondas de onsite repartidas en dos bloques. La forma del proceso cambia según el equipo y la vacante, así que tómalo como la experiencia de una persona y pide el calendario exacto a tu recruiter. Cuando yo lo pedí, me mandó los nombres de las rondas y el foco aproximado de cada una sin poner ninguna pega.

¿El nivel de código es más difícil que LeetCode?

No es más difícil, es distinto. Los problemas de mi proceso se parecían más a una tarea pequeña y realista con requisitos que se van añadiendo que a un puzle con un truco elegante. Me pidieron nombrar bien las cosas, tratar entradas mal formadas y extender dos veces mi propio código, y eso castiga el hábito de la solución memorizada que había construido en tres meses de grind.

¿Cuál fue la ronda que casi me deja fuera?

La revisión a fondo de un proyecto propio. Hice un recorrido cronológico de la arquitectura en lugar de defender las tres o cuatro decisiones que había dentro, y no supe explicar por qué habíamos descartado las alternativas. En este proceso esa ronda es señal de verdad, no un calentamiento, y estuve a punto de perder la oferta ahí.

¿Se puede hacer el proceso desde España?

Yo lo hice íntegramente en remoto desde Madrid y todas las rondas fueron en inglés. Lo que sí conviene aclarar en la primera llamada es dónde reside el equipo, porque una vacante que aparece publicada para España no siempre significa que el equipo esté aquí, y eso condiciona horario, viajes y expectativa de presencialidad. Yo lo pregunté tarde y tuve suerte.

¿Cuánto pesa la conversación con el hiring manager?

En mi proceso pesó de verdad. No fue un trámite final, fueron 50 minutos discutiendo compromisos de producto en los que tuve que decir qué recortaría de una funcionalidad y por qué. Mi recruiter me contó después que esa ronda y la del proyecto propio fueron las dos que más se debatieron en el comité.

¿Qué se negocia en una oferta así en España?

No publico cifras porque el paquete de una persona concreta es un pésimo indicador para otra con otro nivel y otra vacante. Sí transfiere la forma de lo que pregunté: la banda del nivel, en qué punto de la banda estaba mi oferta y qué la movería, la fecha de incorporación y cuál sería mi primer proyecto por escrito. En España añade además dos comprobaciones propias: si el bruto viene en doce o en catorce pagas, porque comparar sin normalizar lleva a errores de bulto, y qué política de consolidación y refresco tiene la parte en acciones si la hay.