Desarrollador·a Full-stack

Capacidad de estructurar una decisión bajo incertidumbre: identificación de restricciones, compromisos explícitos, consulta a las partes implicadas, validación posterior con datos. Bonus: la persona candidata menciona haber cambiado de opinión durante el proceso o haber documentado la decisión para el futuro equipo. Quienes describen una decisión obvia con perspectiva revelan que nunca llegaron a deliberar realmente.

Método de depuración estructurado: reproducción, logs, instrumentación, hipótesis validadas con experimentos. Honestidad sobre la duración (un bug real de producción rara vez se cierra en menos de 30 minutos). Bonus: la persona candidata cita la causa raíz y el correctivo sistémico, no solo el hotfix. Las respuestas tipo reinicié el servicio sin diagnóstico revelan debilidad en investigación.

Humildad técnica y capacidad de aprender. Bonus: la persona candidata identifica lo que habría hecho diferente desde el principio. Quienes afirman no haber tenido nunca que refactorizar su propio código mienten o no han mantenido código en producción durante el tiempo suficiente.

Capacidad de señalar una debilidad técnica sin bloquear: comentario factual en la PR (aquí está el riesgo, esta es mi propuesta de solución), propuesta de solución, escalado al tech lead si la PR se mergea pese al comentario. Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico.

Clarificación de la necesidad antes de negociar el plazo (quizá la feature pueda entregarse en dos fases o simplificarse). Propuesta de opciones: MVP en 1 semana más V2 en 2 semanas, recorte explícito de alcance, refuerzo de personal. Las respuestas del tipo lo hago en 1 semana si trabajo el fin de semana son una bandera roja (señal de mala gestión personal).

Diagnóstico primero: no intentar arreglarlo todo a la vez. Priorización por riesgo e impacto (típicamente: monitoring primero para ver, luego tests en zonas críticas, después automatización del despliegue). Validación con el equipo y con la persona tech lead antes de avanzar. Quienes se lanzan directamente a la reescritura completa muestran falta de pragmatismo.

Aclaraciones antes de proponer (volumen esperado, latencia objetivo, dispositivos soportados, persistencia de las notificaciones no leídas). Arquitectura coherente: push (WebSocket o Server-Sent Events) frente a pull (polling), persistencia (base de datos de notificaciones), idempotencia de los envíos, fallback por correo. Bonus: reconoce zonas de incertidumbre (haría un POC antes de comprometerme con WebSocket o SSE). Quienes se meten en el código sin aclarar restricciones revelan una debilidad de diseño.

Método estructurado: (1) elevar temporalmente el nivel de log en los endpoints afectados, (2) correlacionar con métricas (latencia, tamaño de payload, origen), (3) identificar un patrón (hora del día, tipo de petición, usuario·a concreto·a), (4) ordenar hipótesis (timeout de base de datos, race condition, memoria). Quienes se lanzan a decir seguro es la base de datos sin investigar revelan un sesgo.

Medir antes de optimizar: DevTools, Lighthouse, profiler de servidor. Identificar el cuello de botella (rendering, consultas a base de datos, payload, CDN). Priorizar por esfuerzo por impacto. Las respuestas tipo añado caché sin diagnóstico revelan optimización prematura. Bonus: la persona candidata menciona que una página en 8 segundos en producción suele indicar un problema sistémico (N+1, payload enorme) y no una optimización local.

Comprensión de la pirámide de tests (muchos unitarios, menos de integración, pocos end-to-end). Distinción entre cobertura y utilidad (90 por ciento de cobertura 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. Quienes responden testeo al 100 por ciento sin matizar muestran un juicio débil.

Transacción de base de datos: atomicidad e isolation gestionadas por la base (ACID), acotadas a la duración de la transacción. Lock aplicativo: coordinación entre procesos o instancias vía Redis, ZooKeeper o similares; útil cuando la coordinación supera una única base de datos (microservicios, cola de tareas). Riesgo de deadlock en ambos casos. Quienes no saben distinguir los dos mecanismos crean race conditions en producción.

Enfoque progresivo: (1) mapear componentes críticos y patrones recurrentes, (2) extraer hooks y lógica de negocio primero (impacto alto, riesgo bajo), (3) trocear componentes grandes por frontera de negocio (no por capricho técnico), (4) introducir un state manager solo donde el props drilling duela de verdad (Context o Zustand en pyme, Redux a partir de cierto volumen). Quienes quieren reescribirlo todo a React Server Components desde el día 1 carecen de pragmatismo.

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. Quienes describen haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para el trabajo en equipo en pyme.

Postura activa de mentoría: pair programming, reviews pedagógicas (no solo aprobar y mergear), documentación de decisiones, transmisión de buenas prácticas. Quienes responden ayudo cuando me piden sin más concreción muestran una postura pasiva. En pyme con equipo técnico reducido, la capacidad de transmisión es clave para la sostenibilidad del equipo.

Postura de partenariado: cuestionamiento constructivo basado en viabilidad o complejidad, propuesta de alternativas. Bonus: la persona candidata cita un caso en el que aceptó el brief inicial tras conversarlo (no está en oposición sistemática). Quienes describen a las personas PM o diseñadoras como gente que no entiende la técnica revelan debilidad de juego en equipo.