Preguntas de entrevista Ingeniero de software

Mi primer paso es reproducir el problema de forma fiable. Un bug intermitente que no puedo reproducir es mucho más difícil de corregir que uno que puedo activar de forma consistente. Una vez que puedo reproducirlo, formo una hipótesis sobre la causa raíz basándome en los síntomas, luego añado logs específicos o uso un depurador para probar esa hipótesis. Trabajo de fuera hacia dentro, comenzando por el punto más cercano al fallo observable y rastreando hacia atrás por la pila de llamadas. Evito cambiar múltiples variables a la vez, porque eso hace imposible saber qué fue lo que realmente corrigió el problema. Si estoy bloqueado después de 30 minutos, pido ayuda a un compañero: una perspectiva fresca es casi siempre más rápida que el esfuerzo en solitario prolongado.

Escribo tests como parte del desarrollo, no como reflexión posterior. Para cualquier función no trivial escribo tests unitarios que cubran el camino feliz, los casos límite y los modos de fallo. Uso la revisión de código como puerta de calidad e intento dar contexto a los revisores manteniendo los pull requests pequeños con descripciones claras. También invierto tiempo en legibilidad: una función fácil de entender es más fácil de testear y mantener. Además, me apoyo en herramientas de análisis estático y linters en el CI para detectar problemas antes de la revisión. Cuando encuentro un bug en producción, mi primera acción tras corregirlo es escribir un test de regresión para que el mismo bug no vuelva silenciosamente.

Al principio de mi carrera construí un pipeline de datos que leía la configuración desde variables de entorno sin capa de validación. Funcionaba bien en local y en staging, pero en producción una variable faltante causó un fallo silencioso que tardó horas en diagnosticarse. Ahora siempre validaría y fallaría rápido en el arranque: si un valor de configuración requerido falta o está malformado, el servicio debería negarse a arrancar y registrar un error claro. De forma más amplia, he aprendido a invertir en observabilidad desde el principio. Los logs y métricas añadidos después siempre son menos útiles que los diseñados desde el inicio. Es un coste inicial relativamente pequeño que se amortiza muchas veces durante los incidentes.

Uso Cursor como editor principal y me apoyo mucho en él para el código boilerplate, la generación de tests unitarios y las refactorizaciones sencillas. Para esa categoría de trabajo ha reducido mi tiempo considerablemente, y me permite centrarme en las partes de un problema donde realmente aporto valor. Para la revisión de código, encuentro la IA útil para detectar problemas obvios y sugerir casos límite que podría haber pasado por alto, aunque siempre hago un repaso manual antes de que nada vaya a revisión. Soy más cauteloso al usarla para decisiones arquitectónicas complejas: la ventana de contexto no captura suficientemente el sistema como para fiarse ahí, y las sugerencias tienden a ser genéricas. Mi valoración honesta es que la IA me ha hecho más rápido en problemas bien entendidos y ha sido menos útil en los genuinamente nuevos. También reviso cuidadosamente todo lo que produce porque el código generado por IA puede ser sutilmente incorrecto de maneras que no hacen fallar los tests obvios.

Me uní a un equipo a mitad de proyecto en un monolito legacy con documentación mínima. En lugar de lanzarme directamente a la funcionalidad que me habían asignado, pasé la primera semana leyendo el código alrededor del área que iba a tocar, ejecutando la suite de tests y mapeando manualmente el flujo de datos. También encontré a la persona que había gestionado esa área durante más tiempo e hice una sesión de pair programming con ella para llenar el contexto que no podía obtener solo del código. Cuando empecé a hacer cambios los mantuve pequeños y aislados para que cada pull request fuera fácil de revisar y revertir. La funcionalidad se entregó a tiempo.

Mi equipo decidió usar un mecanismo de polling para sincronizar el estado entre dos servicios. Pensé que un enfoque basado en eventos sería más escalable y reduciría la carga innecesaria. Lo planteé en la revisión de diseño con una breve comparación escrita de ambos enfoques, cubriendo los compromisos en complejidad, latencia y overhead operativo. El equipo decidió seguir con el polling citando el plazo de entrega más rápido y la familiaridad existente. No estaba de acuerdo pero me comprometí totalmente una vez tomada la decisión. Seis meses después sí migramos a eventos cuando el problema de carga se materializó. No lo traté como una vindicación: la decisión original tenía sentido dadas las restricciones del momento.

Nuestro entorno de desarrollo local requería una configuración manual de 12 pasos, sin documentar e inconsistente entre máquinas. Los nuevos ingenieros perdían regularmente medio día configurándolo. Pasé una tarde del viernes escribiendo un único script de shell y un README que automatizaban todo el proceso de configuración, lo probé en una máquina limpia y abrí un pull request. Tardé cuatro horas en total. A partir de entonces, los nuevos empleados estaban operativos en menos de diez minutos. Luego lo añadí al checklist de incorporación para que se mantuviera actualizado.

Un proceso es un programa independiente con su propio espacio de memoria, descriptores de archivo y recursos del SO. Los hilos son unidades de ejecución que viven dentro de un proceso y comparten su espacio de memoria. La diferencia práctica clave es el aislamiento: un crash en un proceso no derriba automáticamente a otro, mientras que un crash en un hilo puede afectar a todo el proceso. Uso múltiples procesos cuando necesito un aislamiento fuerte, por ejemplo al ejecutar código no confiable. Uso hilos cuando necesito concurrencia con estado compartido y el overhead de la comunicación entre procesos sería demasiado alto. En la práctica, para trabajo I/O-bound suelo recurrir primero a patrones async/await.

Comenzaría aclarando los requisitos: volumen de escritura esperado, ratio lectura/escritura, vida útil de las URLs y si se necesitan analytics. Para el servicio principal, generaría una clave corta codificando un ID único (la codificación base62 de un entero auto-incremental es simple y sin colisiones). Almacenaría el mapeo en una base de datos con la clave corta como clave primaria. Para las lecturas, que superan ampliamente a las escrituras, pondría una caché (Redis) delante de la base de datos para servir la redirección con latencia inferior al milisegundo. La redirección es un HTTP 301 (permanente) o 302 (temporal) según si queremos caché del navegador. El camino de lectura es sin estado y fácilmente escalable horizontalmente.

Las bases de datos SQL almacenan datos en tablas con un esquema fijo y usan transacciones ACID para garantizar la consistencia. Son excelentes cuando los datos tienen relaciones claras y la consistencia es crítica. Las bases NoSQL intercambian algunas de esas garantías por flexibilidad y escalabilidad horizontal. Las bases documentales como MongoDB funcionan bien cuando los datos son jerárquicos. Las bases clave-valor como Redis destacan en lookups simples de alto rendimiento. Las bases columnares como Cassandra están diseñadas para cargas de trabajo de series temporales o con muchas escrituras. Mi punto de partida predeterminado es una base de datos relacional. Paso a NoSQL cuando tengo un patrón de acceso específico que el modelo relacional gestiona mal.