Desarrollador·a Backend

Método estructurado: reproducción u observación directa, formulación de hipótesis, validación con logs, métricas o experimentación dirigida. Honestidad sobre la duración y las falsas pistas. Bonus: la persona candidata cita la causa raíz (no solo el hotfix) y la medida preventiva aplicada después (post-mortem, alerta añadida, test de regresión). Las respuestas tipo reinicié el servicio y todo volvió a la normalidad sin diagnóstico revelan debilidad en investigación.

Capacidad de estructurar una decisión bajo incertidumbre: clarificación de restricciones, alternativas evaluadas, arbitrajes explícitos entre simplicidad y flexibilidad futura, consulta a las partes implicadas, validación posterior. Bonus: la persona candidata menciona una decisión sobre la que cambiaría hoy o un ADR escrito para el equipo. Quienes describen una decisión obvia con perspectiva nunca llegaron a arbitrar de verdad.

Humildad frente a las hipótesis iniciales: la persona candidata reconoce el límite, mide antes de actuar (profiling, métricas, carga real frente a sintética), arbitra entre optimización local y rediseño. Bonus: identifica en retrospectiva la señal que podría haber leído antes. Quienes afirman no haber tenido nunca un problema de carga mienten o no han servido tráfico real.

Capacidad de señalar una debilidad sin bloquear: comentario factual en la PR (aquí está el riesgo concreto, esta es una propuesta de solución), corrección propuesta, escalado al·a la tech lead o al equipo de seguridad si la PR se mergea pese al comentario. Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico, crítico en un puesto de backend.

Clarificación de la necesidad real antes de negociar el plazo: qué volumen de datos, qué latencia aceptable, qué funcionalidades realmente imprescindibles (filtros, scoring, resaltado). Propuesta de opciones explícitas: MVP vía ILIKE de Postgres en 1 semana más indexación real en V2, o recorte de alcance. Las respuestas del tipo lo hago en 1 semana si trabajo el fin de semana son una bandera roja.

Diagnóstico primero, no la revolución total: priorización por riesgo operativo. Típicamente: (1) observabilidad mínima para ver antes de actuar (métricas básicas, logs estructurados, dashboard de incidentes), (2) asegurar el pipeline de despliegue (rollback rápido, un entorno de staging fiable), (3) reverdecer los tests críticos en las zonas de negocio sensibles, (4) plan más largo para el resto. Validación explícita con el equipo y la persona tech lead antes de avanzar.

Aclaraciones antes de proponer: volumen esperado, criticidad, restricciones de latencia, SLA prometido a los clientes. Arquitectura coherente: cola de mensajes persistente, reintentos exponenciales acotados, dead-letter queue, idempotencia en el receptor, firma HMAC, aislamiento de clientes lentos (rate-limit o worker dedicado). Observabilidad: tasa de éxito por cliente, latencia p99, tamaño de la cola. Bonus: reconoce zonas de incertidumbre (prototiparía Kafka frente a RabbitMQ frente a SQS según el volumen real antes de comprometerme). Quienes se meten en el código sin clarificar revelan debilidad de diseño.

Método estructurado: (1) elevar temporalmente el nivel de log y activar el tracing en los endpoints afectados, (2) correlacionar con métricas (latencia p99, tamaño de payload, conexiones de base de datos, memoria, GC), (3) buscar un patrón (hora, tipo de petición, usuario·a concreto·a, ratio sobre un pod determinado), (4) hipótesis ordenadas: pool de base de datos saturado, timeout aguas arriba, race condition, OOM, panic no recuperada. Quienes se precipitan con seguro es la base de datos sin investigar revelan sesgo.

Medir antes de optimizar: EXPLAIN ANALYZE sobre la consulta, profiling en aplicación, comprobación del pool de conexiones. Identificar el cuello de botella real: índice ausente, N+1, payload enorme, serialización costosa, lock de tabla. Jerarquizar por esfuerzo por impacto. Las respuestas tipo añado Redis delante sin diagnóstico revelan reflejo de optimización prematura. Bonus: la persona candidata nota que una brecha p50 frente a p95 tan fuerte sugiere un comportamiento por caso (usuario·a con dataset grande, lock ocasional) más que una lentitud uniforme.

Transacción de base de datos: atomicidad e isolation gestionadas por la base, acotadas a una sola DB; isolation fuerte al precio de conflictos visibles (serialization failures a reintentar en el lado aplicativo). Lock aplicativo: coordinación entre procesos o instancias cuando la coordinación supera una sola base (microservicios, deduplicación de jobs, leader election). Riesgos distintos: deadlock frente a lock perdido si cae quien lo retiene (de ahí los TTL y el fencing token). Quienes no distinguen los dos mecanismos crean race conditions en producción.

Comprensión clara: la persona cliente envía una clave de idempotencia (cabecera HTTP), el servidor la persiste junto con la petición y la respuesta, y toda petición posterior con la misma clave devuelve la respuesta almacenada sin volver a ejecutar el efecto. Detalles esperados: restricción UNIQUE sobre la clave en la base, manejo del conflicto (devolver la respuesta cacheada, no un 409), TTL razonable (24-48 horas típico), interacción limpia con la transacción de negocio (idealmente la misma transacción o compensación). Quienes responden compruebo si ya existe antes de insertar crean una race condition clásica.

Comprensión de la pirámide: muchos unitarios sobre la lógica de negocio, menos integraciones acotadas a las fronteras (base de datos, colas, APIs externas), pocos end-to-end. Distinción entre cobertura y utilidad: 90 por ciento sobre código trivial vale menos que 60 por ciento sobre la lógica de negocio crítica. Bonus: la persona candidata cita una vez en que un test evitó una regresión real, o un tipo de bug que los tests no atrapan (race conditions, problemas de configuración en producción). Quienes responden testeo al 100 por ciento sin matizar muestran un juicio débil.

Apertura: capacidad de separar el código del ego personal. Bonus: la persona candidata cita una vez en que cambió de opinión gracias a una review y explica qué le hizo cambiar. Quienes describen sobre todo haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para un puesto donde la calidad del código es compartida.

Postura de mentoría activa: pair programming, reviews pedagógicas (no solo ok merge), documentación de las decisiones importantes (ADR), compartir en reuniones de equipo o en lunch and learn. En pyme con equipo backend pequeño (3-8 personas), la capacidad de transmisión es esencial para la pervivencia del código. Quienes responden ayudo cuando me piden sin más precisión muestran una postura pasiva.

Postura de partenariado: cuestionamiento constructivo basado en la viabilidad, la complejidad o el coste operativo a largo plazo (la persona backend vive con los esquemas y los contratos de API que expone). Propuesta de alternativas. Bonus: la persona candidata cita un caso en el que aceptó el brief inicial tras conversarlo. Quienes describen a las personas PM o frontend como gente que no entiende la complejidad técnica revelan debilidad en juego de equipo.