Preguntas de entrevista para Ingeniero de Software

Respuesta modelo

Soy ingeniero de software con seis años de experiencia, centrado en backend distribuido con Java y Spring Boot. Empecé en una consultora, donde roté por tres clientes de banca y seguros, y hace tres años me incorporé a una empresa de producto de comercio electrónico con 2,3 millones de usuarios mensuales. Allí lideré la migración del monolito de reservas a doce microservicios: pasamos de un despliegue semanal nocturno a veinticinco despliegues diarios y redujimos las incidencias en producción un 37 %. En el último año he asumido el papel de referente técnico de un equipo de cinco personas, con responsabilidad sobre la arquitectura y las guardias. Ahora busco un puesto en el que pueda seguir tomando decisiones de arquitectura en un producto propio, que es exactamente lo que describe su oferta.

Respuesta modelo

Estoy a gusto y me voy en buenos términos; el motivo es de recorrido técnico. En mi puesto actual la arquitectura ya está estabilizada y mi trabajo se ha desplazado hacia el mantenimiento y la coordinación. Busco un entorno donde vuelva a haber decisiones de diseño abiertas, con volumen de datos y con un equipo del que pueda aprender. Su plataforma de pagos procesa un orden de magnitud más de transacciones que la nuestra y eso es justo el tipo de problema en el que quiero especializarme.

Respuesta modelo

La sincronización de stock entre 140 tiendas físicas y el canal online. Había un proceso batch nocturno de tres horas y los fines de semana el inventario se desajustaba, con cancelaciones de pedidos y quejas constantes. Propuse una arquitectura orientada a eventos con Apache Kafka: cada movimiento de almacén publica un evento y los consumidores son idempotentes, con claves de deduplicación y reintentos con retroceso exponencial. Lo más difícil no fue técnico, sino convencer a operaciones para desplegar tienda a tienda durante seis semanas en lugar de hacerlo de golpe. Eliminamos el batch, los desajustes de fin de semana desaparecieron y el equipo de atención al cliente dejó de gestionar unas 200 incidencias mensuales por ese motivo.

Respuesta modelo

Combino tres cosas. Leo con regularidad los blogs de ingeniería de empresas con problemas parecidos a los nuestros y un par de boletines semanales sobre la JVM y sistemas distribuidos. Cada trimestre me fijo un objetivo concreto y lo llevo a la práctica: el último fue sustituir nuestras pruebas de integración por Testcontainers, que después propuse al equipo y adoptamos. Y mantengo una pequeña biblioteca open source en Python, que me obliga a atender issues reales de gente que no conozco. Además asisto a la Commit Conf de Madrid y a los meetups de la comunidad Java local, más por las conversaciones de pasillo que por las charlas.

Respuesta modelo

Hace dos años introduje GraphQL en un servicio interno con tres consumidores conocidos y estables. La flexibilidad que aportaba no compensaba: añadió una capa de esquema que mantener, complicó el control de acceso por campo y las consultas anidadas generaron problemas de N+1 que tuvimos que resolver con un dataloader. La decisión fue mía y la tomé por interés técnico más que por necesidad del producto. A los ocho meses lo revertimos a REST con tres endpoints. Desde entonces exijo, y me exijo, escribir en el documento de diseño qué problema concreto resuelve cada tecnología nueva y qué señal nos haría dar marcha atrás.

Respuesta modelo

A corto plazo espero un periodo de aprendizaje del dominio, que en pagos es denso, y poder aportar desde el principio en las revisiones de código y en la observabilidad, que es donde tengo más recorrido. A tres años me veo como referente técnico de un área, participando en las decisiones de arquitectura y con responsabilidad sobre la incorporación y el crecimiento de perfiles junior. No busco un camino de gestión pura: me interesa la vía técnica, si en la empresa existe. De hecho, quería preguntarle cómo está definida aquí la progresión entre los niveles sénior y staff.

Lo justifica un problema real de acoplamiento organizativo o de escalado desigual: varios equipos bloqueándose en el mismo despliegue, o un módulo que necesita diez veces más recursos que el resto. No lo justifica que esté de moda ni que el código esté desordenado, porque un monolito mal modularizado se convierte en un sistema distribuido mal modularizado, con la latencia de red y la complejidad de datos añadidas. Mi orden preferido es: primero delimitar módulos con fronteras claras dentro del monolito, medir dónde duele de verdad y extraer solo ese contexto, empezando por el que menos comparta datos transaccionales. Y antes de dar el paso hay que tener listas tres cosas: despliegue automatizado, trazabilidad distribuida y una estrategia de consistencia eventual que el negocio acepte.

El B-tree es el índice por defecto y sirve para comparaciones de igualdad y rango sobre valores escalares ordenables, además de para ORDER BY: es el que quiero en una clave foránea, en una fecha o en un identificador. El GIN es un índice invertido para valores compuestos: arrays, jsonb y búsqueda de texto completo con tsvector. Si consulto con el operador de contención sobre una columna jsonb o busco palabras dentro de un documento, el B-tree no ayuda y el GIN sí. El precio del GIN es que ocupa más y encarece las escrituras, porque una fila genera muchas entradas; con inserciones intensivas conviene revisar el parámetro fastupdate y el mantenimiento. En cualquier caso, la decisión se toma leyendo el EXPLAIN ANALYZE de la consulta real, no de memoria.

Parto de que la entrega es al menos una vez, así que el consumidor debe tolerar duplicados. Uso una clave de negocio estable en el mensaje, por ejemplo el identificador del pedido más el tipo de evento, y la registro en una tabla de mensajes procesados con restricción de unicidad, dentro de la misma transacción que escribe el resultado. Si el mensaje ya está, se descarta y se confirma el offset. Cuando el productor también debe ser fiable, aplico el patrón outbox: la operación de negocio y el evento se escriben en la misma transacción de base de datos y un proceso aparte publica en Kafka. Además confirmo los offsets después de procesar, nunca antes, y configuro una cola de mensajes fallidos para los que agotan los reintentos.

Para una API pública consumida por clientes que no son navegadores propios elijo tokens, normalmente OAuth 2.0 con JWT de vida corta y refresh token, porque no exige estado compartido entre instancias y encaja con clientes móviles y de terceros. Asumo el inconveniente principal: un JWT no se puede revocar de verdad hasta que caduca, así que uso caducidades de cinco a quince minutos, una lista de revocación para casos críticos y rotación de claves de firma. Si el consumidor fuera solo mi propio frontend web, una sesión en servidor con cookie HttpOnly, SameSite y protección CSRF es más simple y más segura, y la revocación es inmediata. La decisión depende de quién consume, no de qué tecnología es más moderna.

Primero confirmo el patrón con las métricas: si el uso del heap tras cada recolección completa crece de forma sostenida, es una fuga; si solo crece la memoria del proceso y no el heap, sospecho de memoria nativa, hilos o buffers directos. Después capturo un histograma con jcmd y, si hace falta, un volcado de heap para analizarlo con Eclipse MAT buscando los objetos que dominan la retención y la cadena de referencias que los mantiene vivos. Las causas más frecuentes que he encontrado son cachés sin límite ni política de expiración, ThreadLocal sin limpiar en pools de hilos y listeners o conexiones que no se cierran. Reproduzco en preproducción con carga sintética, corrijo y verifico con una prueba de resistencia de varias horas antes de volver a producción.

Empiezo por acotar los requisitos: proporción de lecturas y escrituras (aquí es muy asimétrica, quizá 500 a 1), si los códigos deben ser impredecibles, si hacen falta métricas de clics y cuál es la latencia objetivo. El modelo es sencillo: código corto como clave y URL original como valor. Genero el código con un contador distribuido codificado en base 62, que evita colisiones, o con un hash truncado más comprobación si se exige impredecibilidad. Para la lectura, una caché en Redis delante del almacén persistente absorbe casi todo el tráfico, porque el acceso sigue una distribución muy sesgada; con un CDN por delante y redirecciones 301 cacheables se reduce todavía más. La escritura va a una base de datos particionada por el código. Y cerraría hablando de lo que suele olvidarse: caducidad de enlaces, protección contra abuso y bloqueo de destinos maliciosos.

Lo primero es contener, no entender: si existe despliegue reciente, revierto a la versión anterior o desactivo la funcionalidad con el feature flag, porque restablecer el servicio siempre va antes que encontrar la causa. En paralelo abro un canal de incidencia, aviso al responsable de guardia y a atención al cliente con un mensaje claro sobre el alcance, y reviso las trazas y los paneles para acotar qué transacciones se han visto afectadas. Con el servicio estabilizado, evalúo si los pagos fallidos requieren reproceso o devolución y lo acuerdo con negocio. La causa raíz y el arreglo definitivo pueden esperar al lunes; el post mortem sin culpables, no más de una semana después, con acciones concretas y responsables asignados.

Distingo entre lo que bloquea y lo que no. Si el cambio toca una ruta crítica sin pruebas, lo marco como bloqueante y lo explico por escrito con el riesgo concreto, no como una cuestión de estilo. Después ofrezco una salida realista: escribir juntos las dos o tres pruebas que cubren el camino principal, que suele costar media hora, o desplegar detrás de un flag apagado y completar las pruebas antes de activarlo. Si la presión de la fecha es real, la conversación deja de ser entre dos ingenieros y sube al responsable de producto, con el coste técnico explicitado. Lo que no hago es aprobar en silencio y comentarlo después: eso convierte un problema técnico en un problema de confianza.

No discuto la fecha, discuto el alcance. Descompongo la funcionalidad y muestro qué parte aporta ya valor en dos semanas y qué parte no: en el último caso similar, entregamos el flujo principal sin el panel de administración ni la exportación, que llegaron cinco semanas después. Explico también qué se puede acelerar con más manos y qué no, porque hay tareas secuenciales. Si nada de eso es aceptable, expongo las opciones con su coste: entregar con deuda técnica asumida y planificada, reducir el alcance o mover la fecha; la decisión es de producto, pero con la información encima de la mesa. Lo importante es dejarlo por escrito para que dentro de tres meses nadie recuerde una versión distinta de lo acordado.

Antes de tocar nada, consigo poder ejecutarlo en local y observarlo: logs, métricas y un entorno donde reproducir el flujo. Después escribo pruebas de caracterización sobre el comportamiento actual, aunque ese comportamiento sea raro, porque son mi red de seguridad y a la vez la documentación que no existe. Con eso, aíslo la zona que debo modificar creando una costura o interfaz, añado la funcionalidad nueva con sus propias pruebas y evito la tentación de reescribirlo todo de paso. Voy anotando en un documento lo que descubro y las decisiones sorprendentes, con los nombres de quienes puedan conocer el contexto histórico; una conversación de veinte minutos con quien lo mantuvo hace tres años ahorra días de arqueología.