Ingeniero de software Preguntas de entrevista & Respuestas

Respuesta modelo

En mi anterior empresa el equipo quería adoptar una base de datos NoSQL para una funcionalidad con relaciones de datos bastante complejas. Yo pensaba que una base de datos relacional encajaba mejor con nuestros patrones de acceso reales. Preparé un documento técnico breve comparando ambas opciones sobre casos de uso concretos del producto y lo llevé a la siguiente revisión de diseño. Propusimos hacer una prueba de concepto de una semana con las dos alternativas sobre el mismo conjunto de consultas, y los resultados respaldaron mi propuesta: la opción relacional resolvía en milisegundos consultas que en NoSQL requerían agregaciones costosas en el cliente. El equipo cambió de rumbo sin que nadie se sintiera cuestionado personalmente. La clave fue llevar datos en lugar de opiniones, y plantear la comparación de forma que cambiar de idea no supusiera perder la cara ante el resto del equipo.

Respuesta modelo

Teníamos tres semanas para lanzar una funcionalidad en tiempo real que requería WebSockets, algo que nunca había usado en producción. Reservé las mañanas para aprendizaje enfocado: primero construí un prototipo desechable, después leí la especificación del protocolo y por último revisé cómo proyectos open source de mayor tamaño resolvían casos límite como la reconexión y el orden de los mensajes. También hice pair programming con un compañero que ya tenía experiencia con WebSockets antes de cada revisión de código. Lanzamos la funcionalidad en el plazo previsto y no tuvo ningún incidente en producción durante el primer trimestre. Aprendí que bajo presión se avanza más rápido construyendo algo pequeño y desechable antes de intentar entender toda la teoría.

Respuesta modelo

Nuestra API de cara al cliente tenía una latencia p95 de 800 milisegundos. Perfilé los endpoints más lentos y encontré tres patrones de consultas N+1 en la capa ORM. Reescribí esas consultas con joins explícitos y añadí una caché en Redis para una consulta de permisos de usuario que se ejecutaba en casi cada petición. La latencia p95 bajó a 120 milisegundos. El cambio técnico fue la parte fácil: lo difícil fue convencer al equipo de invertir el tiempo necesario. Construí un panel sencillo que relacionaba la latencia directamente con la tasa de conversión del checkout, y con esos números el caso de negocio se volvió evidente para el resto del equipo.

Respuesta modelo

Lanzamos una funcionalidad de recomendaciones en la que habíamos trabajado durante dos meses y tuvo una adopción casi nula. Habíamos optimizado para maximizar los clics, pero los usuarios encontraban las sugerencias poco relevantes para su búsqueda real. Hicimos un post-mortem y el problema de fondo quedó claro: nunca hablamos con usuarios antes de construir la funcionalidad. Escribí un resumen de una página con lo aprendido y propuse añadir una fase de descubrimiento al proceso de desarrollo de producto. Ese cambio de proceso sobrevivió a la propia funcionalidad: ahora tenemos una entrevista de usuarios como paso obligatorio antes de cualquier desarrollo grande.

Respuesta modelo

En esencia se necesitan dos operaciones: escritura (dada una URL larga, devolver un código corto) y lectura (dado un código corto, redirigir a la URL original). Para el código, usaría codificación Base62 sobre un identificador autoincremental: con 6 caracteres se obtienen unos 3.500 millones de combinaciones posibles. La ruta de escritura pasa por la base de datos y guarda el mapeo en caché. La ruta de lectura es caché primero, con la base de datos como respaldo si hay un fallo de caché. A escala, las lecturas superan ampliamente a las escrituras, así que la tasa de aciertos de caché es lo que de verdad determina el rendimiento. Añadiría límites de velocidad en la escritura para evitar abuso, y guardaría la fecha de creación, el usuario y las analíticas de clics en una tabla aparte para mantener la ruta de lectura lo más ligera posible.

Respuesta modelo

Un proceso es un programa independiente en ejecución con su propio espacio de memoria. Un hilo es una unidad de ejecución ligera dentro de un proceso que comparte memoria con otros hilos del mismo proceso. Uso hilos cuando las tareas necesitan comunicarse con frecuencia y compartir estado, porque son más baratos de crear y de cambiar entre ellos. Uso procesos cuando necesito aislamiento real: si uno falla, los demás siguen funcionando. En la práctica, recurro a hilos para paralelismo intensivo en CPU dentro de un mismo servicio, y a procesos cuando necesito aislar memoria o ejecutar servicios independientes. En Python, el GIL impide el paralelismo real de CPU entre hilos, así que para trabajo intensivo en cómputo suelo recurrir a multiprocessing en lugar de threading.

Respuesta modelo

La consistencia eventual significa que un sistema distribuido acabará devolviendo el mismo valor para una clave dada en todos sus nodos, pero no de forma inmediata. Las escrituras se propagan de manera asíncrona, así que las lecturas que ocurren justo después de una escritura pueden devolver datos desactualizados durante un breve periodo. La aceptaría para contadores de "me gusta" en redes sociales, sincronización de preferencias de usuario entre dispositivos o actualizaciones de inventario en un catálogo, casos donde un desfase de uno o dos segundos no causa ningún daño real. La descartaría para transacciones financieras, tokens de autenticación o cualquier caso donde un dato desactualizado pueda provocar un resultado de negocio incorrecto o un problema de seguridad.

Respuesta modelo

En Java, la JVM usa un recolector de basura generacional. El heap se divide en generación joven y generación vieja según el tiempo de vida de los objetos. La mayoría de los objetos mueren jóvenes, así que el recolector ejecuta recolecciones menores frecuentes y baratas sobre la generación joven. Los objetos que sobreviven varias recolecciones se promueven a la generación vieja, que se recolecta con menos frecuencia pero de forma más costosa. Recolectores como G1 o ZGC reducen las pausas stop-the-world haciendo la mayor parte del trabajo de forma concurrente. El compromiso es la sobrecarga de memoria y una latencia de pausa poco predecible: la recolección de basura cambia rendimiento bruto por gestión automática de memoria. En sistemas sensibles a la latencia he ajustado tamaños de heap y parámetros del recolector, y en casos extremos he movido asignaciones del camino crítico fuera del heap para evitar por completo la presión sobre el recolector.

Respuesta modelo

Primero evalúo la gravedad y la explotabilidad real: ¿se está explotando activamente y nuestro patrón de uso nos expone? Si la respuesta es sí, escalo de inmediato al responsable técnico y al contacto de seguridad, y lo tratamos como un incidente y no como una tarea más del sprint. Buscaría primero una versión parcheada de la librería. Si no existe, revisaría si podemos mitigar el problema en nuestro propio código mientras esperamos el parche, o si conviene sustituir la librería por otra. Comunicaría el estado con claridad: quién está afectado, cuál es el riesgo real, qué estamos haciendo y en qué plazo. El alcance del sprint cambia como consecuencia: las correcciones de seguridad pasan a ser lo primero que se entrega.

Respuesta modelo

No toco nada sin entenderlo primero. Dedicaría el primer día a mapear los puntos de entrada del código, el flujo de datos y las dependencias clave, ejecutándolo en local y siguiendo peticiones reales a través del sistema. Antes de escribir código de la nueva funcionalidad, añadiría pruebas de caracterización sobre las zonas que voy a modificar: pruebas que capturan el comportamiento actual, no el comportamiento ideal. Esas pruebas son mi red de seguridad. A partir de ahí, haría los cambios mínimos necesarios para añadir la funcionalidad, con pruebas unitarias propias para el código nuevo. Resistiría la tentación de refactorizar todo lo que no me gusta del código existente: esa es una conversación aparte con el equipo, con su propio calendario y su propia evaluación de riesgo.

Respuesta modelo

Antes de objetar nada, me aseguro de entender bien su propuesta: a veces la complejidad existe por razones que todavía no veo. Hago preguntas para entender qué restricciones está optimizando. Si sigo pensando que mi enfoque es mejor, escribo una comparación breve: las ventajas y desventajas de cada opción, qué ganamos y qué sacrificamos con cada una, y mi recomendación razonada. Lo presento como "esto es lo que veo, ¿me estoy perdiendo algo?" en lugar de "tengo razón". Si tras la discusión el ingeniero senior sigue prefiriendo su enfoque, lo asumo y lo ejecuto lo mejor posible: un desacuerdo de arquitectura merece un buen debate, no una disputa continua a lo largo del proyecto.

Respuesta modelo

No doy un número único para un alcance poco claro, porque ese número será incorrecto y luego se me exigirá cumplirlo igualmente. En su lugar, hago preguntas para entender el requisito central e identificar las incógnitas de mayor riesgo. Después doy un rango: "con lo que sé hoy, esto son de 3 a 5 días, pero estas tres preguntas abiertas podrían llevarlo a 2 semanas". Explico qué necesito para reducir el rango: una decisión sobre un caso límite, acceso a un sistema concreto o un día para explorar la parte que no conozco. Una buena estimación es una conversación, no una fecha sacada de la manga.