Guía de entrevista para Software Engineers

Enfoque — Guardar el complemento en una tabla hash

Recorrería el array una vez. Para cada x comprobaría si target − x ya está en una tabla hash. Si está, devolvería su índice y el actual; si no, guardaría x con su índice. Cada elemento se procesa una vez: O(n) de tiempo y O(n) de espacio. Antes aclararía si existe exactamente una solución y si puede reutilizarse un índice.

Enfoque — Sliding window con último índice visto

Mantendría una ventana [left, right] sin duplicados y el último índice de cada carácter. Si aparece de nuevo dentro de la ventana, movería left a lastSeen + 1. Después actualizaría el índice y el máximo. Left nunca debe retroceder. El tiempo es O(n) y el espacio O(k), donde k es el alfabeto.

Enfoque — Crear una clave canónica por palabra

Crearía para cada palabra una clave canónica y agruparía claves iguales en una tabla hash. La clave puede ser la cadena ordenada o, con alfabeto fijo, un vector de frecuencias. Ordenando, el tiempo es O(n · m log m); con frecuencias, O(n · m), donde m es la longitud.

Enfoque — Tres punteros: anterior, actual y siguiente

Inicializaría prev en null y current en la cabeza. En cada iteración guardaría current.next, apuntaría current.next a prev y avanzaría ambos punteros. Al final prev es la nueva cabeza. La invariante es que prev siempre apunta a la parte ya invertida. Tiempo O(n), espacio O(1).

Enfoque — Propagar límites inferior y superior válidos

Comparar solo con los hijos no basta. Recorrería recursivamente pasando el rango permitido: a la izquierda, el valor actual se convierte en límite superior; a la derecha, en inferior. Si un nodo viola el rango, el árbol no es válido. Aclararía la regla para duplicados. Tiempo O(n), espacio O(h) por la recursión.

Enfoque — BFS por niveles de distancia

Trataría cada celda transitable como nodo y ejecutaría BFS desde el inicio. Marcaría una celda al encolarla para no duplicarla. El primer acceso al destino es mínimo por el orden en niveles. Para devolver el camino, guardaría predecesores. Tiempo y espacio O(filas · columnas).

Enfoque — Mapear cada nodo original a su clon

Usaría DFS o BFS y una tabla que asigna cada original a su clon. Crearía y guardaría el clon en la primera visita y luego clonaría vecinos. Guardarlo antes evita bucles en ciclos y preserva vecinos compartidos. Tiempo y espacio O(V + E).

Enfoque — DP bottom-up para todas las cantidades

Definiría dp[a] como el mínimo de monedas para la cantidad a. Establecería dp[0] = 0 y el resto en infinito. Para cada cantidad y moneda c ≤ a, actualizaría dp[a] = min(dp[a], dp[a − c] + 1). Si el objetivo sigue en infinito, no puede formarse. Tiempo O(cantidad · monedas), espacio O(cantidad).

Enfoque — DP por posición final y optimización con búsqueda binaria

La solución básica define dp[i] como la longitud máxima que termina en i. Para todo j < i con nums[j] < nums[i], actualiza dp[i], con O(n²). La solución optimizada guarda el menor final posible para cada longitud y lo sustituye mediante búsqueda binaria, logrando O(n log n).

Enfoque — Generar solo prefijos válidos

Construiría la cadena paso a paso. Puede añadirse apertura mientras open < n y cierre solo si close < open. Cuando la longitud llega a 2n, la combinación es válida. Como nunca se crean prefijos inválidos, se poda pronto el espacio de búsqueda.

Enfoque — Requisitos → API → generación de ID → almacenamiento → redirección → escala

El usuario envía una URL larga y recibe un código; la redirección debe ser rápida. Las API principales son createShortUrl y redirect. El registro contiene código, destino, usuario, creación, caducidad y estado. Los códigos pueden derivarse de ID secuenciales en Base62 o generarse aleatoriamente con detección de colisiones. La lectura usa caché delante de la base, valida estado y caducidad y responde 301 o 302. La analítica se procesa de forma asíncrona mediante cola. A escala añadiría edge cache, sharding por código, rate limits y control de abuso.

Enfoque — Usuarios → publicaciones → fanout → ranking → lectura → consistencia

Asumiría un feed de cuentas seguidas. Los objetos centrales son usuario, follow, publicación, contenido, entrada de feed e interacción. Servicios de publicación, grafo, feed y ranking trabajan con caché, object storage y colas. Fanout al escribir permite lecturas rápidas, pero es caro para cuentas enormes. Fanout al leer reduce escrituras y aumenta latencia. Un enfoque híbrido distribuye cuentas normales al escribir y trata las grandes al leer. También consideraría frescura, privacidad, fallos de cola, invalidación de caché y spam.

Enfoque — Conexiones → flujo de mensajes → almacenamiento → entrega → fiabilidad

Los clientes mantienen WebSocket con gateways. Al enviar, el gateway autentica, usa una clave de idempotencia, guarda el mensaje, publica un evento y entrega a receptores conectados. Los usuarios offline reciben push y sincronizan desde el último punto visto. El modelo incluye conversación, participante, mensaje, entrega, lectura y dispositivo. Las claves evitan duplicados, las secuencias por conversación ordenan y los acknowledgements y reintentos aseguran entrega. Los adjuntos van a object storage. Vigilaría latencia, tasa de entrega, conexiones, reconexiones, cola y fallos de escritura.

Enfoque — Validar señal → acotar alcance → revisar cambios → descomponer dependencias → mitigar

Confirmaría la señal en varios monitores y revisaría p50, p95, p99 y endpoints. Segmentar por región, zona, versión, host, cliente, tipo y dependencia ayuda a acotar. Revisaría despliegues, configuración, migraciones, tráfico, feature flags, caché y caídas downstream. Los traces descomponen latencia; también comprobaría base de datos, hit rate, cola, CPU, memoria, GC y pools. Si hay impacto, mitigaría antes de demostrar la causa perfecta mediante rollback, desactivar flag, escalar o evitar una dependencia lenta.

Enfoque — Casos normales → límites → entradas inválidas → invariantes

Aclararía tipos, combinaciones, caducidad, mínimo, elegibilidad, redondeo, impuestos y envío. Los unit tests cubrirían sin descuento, porcentaje, cantidad fija, mínimo exacto y por debajo, caducado, usuario no elegible y acumulación. Las invariantes: el precio nunca es negativo, el descuento no supera el importe elegible, una promoción caducada no aplica y la misma entrada produce el mismo resultado. Si afecta a pagos, añadiría integración y registraría la razón de cada decisión.

Enfoque — Corrección → mantenibilidad → riesgo → claridad

Revisaría en orden: ¿resuelve correctamente el problema? ¿Es mantenible y tiene límites claros? ¿Qué riesgos introduce en migración, concurrencia, seguridad, rendimiento, compatibilidad u observabilidad? ¿Las pruebas cubren el cambio? Separaría bloqueos de sugerencias. Corrección, seguridad o migración pueden bloquear; el gusto no. Una review debe mejorar código y velocidad del equipo, no demostrar superioridad.

Enfoque — Contexto → opciones → compensaciones → decisión → resultado

Elegiría una decisión con alternativas reales: construir o comprar, SQL o NoSQL, parche rápido o rediseño, consistencia o disponibilidad. Explicaría contexto, restricciones y opciones. Nombraría la compensación y qué evidencia decidió: tráfico, fecha de cliente, incidentes, capacidad o roadmap. Terminaría con resultado y aprendizaje. Una respuesta madura puede admitir qué haría distinto hoy.

Enfoque — Incidente → impacto → respuesta → causa → prevención

Comenzaría por el impacto: qué falló, quién sufrió y gravedad. Después describiría mi contribución a detección, triaje, rollback, mitigación, comunicación o causa. Durante el incidente, restaurar importa más que probar una teoría. Explicaría cómo utilicé logs, métricas, traces, flags, rollbacks o dependencias. Tras mitigar, detallaría causa y prevención: mejores pruebas, rollout seguro, monitorización o runbooks, sin buscar culpables personales.

Enfoque — Objetivo común → restricciones → opciones → compensaciones → decisión

Primero alinearía el objetivo de usuario y negocio. Muchos conflictos nacen de supuestos distintos. Explicaría con precisión la restricción técnica: complejidad, fiabilidad, plazo, mantenimiento, seguridad o rendimiento. En lugar de decir solo no, ofrecería opciones: MVP menor, proceso manual temporal, feature flag, trabajo escalonado o diseño más simple. Ante riesgos importantes, documentaría alternativas, consecuencias y recomendación. El objetivo no es que Ingeniería gane, sino una decisión consciente del equipo.