Resumen ejecutivo

• Los interviewers no contratan “saber Make”: buscan evidencia de debugging, APIs, ownership y criterio bajo presión.

• Traducí cada flujo (n8n, Make, Zapier, agentes) a problema → diseño → fallas → métrica de impacto, con lenguaje de ingeniería.

• Usá el método STAR (Situation, Task, Action, Result) para respuestas de 2–3 minutos, con ~60% del tiempo en Actions, como recomienda MIT CAPD.

• Practicá historias de reintentos, idempotencia, webhooks duplicados y costos de LLM: son las preguntas que separan “probé herramientas” de “operé sistemas”.

Si tu portfolio está lleno de automatizaciones y agentes, pero la entrevista habla de “experiencia técnica”, el riesgo no es que te falten skills: es que las cuentes mal. Esta guía te muestra cómo traducir proyectos de n8n, Make o agentes a evidencia que un interviewer de producto, plataforma o data sí valora. ¿Por qué ahora? Porque la demanda de perfiles que orquestan LLMs y workflows crece más rápido que los guiones de entrevista, y CoderLibrary ya tiene piezas de preparación con IA, pero faltaba el puente concreto desde automatización. Complementá con cómo usar IA para preparar una entrevista técnica y con cómo demostrar habilidades tech sin experiencia formal.

Qué miran los interviewers (aunque vengas de no-code)

En una ronda técnica o de hiring manager, casi siempre evalúan cuatro señales:

• Ownership: ¿podés nombrar un sistema que vos operaste de punta a punta?

• Debugging: ¿cómo aislás una falla cuando el flujo “a veces” rompe?

• Integraciones: ¿entendés APIs, auth, rate limits, schemas y errores?

• Trade-offs: ¿elegís herramientas y diseños con costo, latencia y riesgo en mente?

Make o n8n son el medio. La evidencia es el criterio. Si solo decís “monté un bot que resume tickets”, el interviewer no sabe si copiaste un template o si diseñaste reintentos, alertas y un runbook.

Traducir automatizaciones a skills técnicas (mapa práctico)

Usá esta conversión cuando armes historias y cuando reescribas el CV:

• Escenario Make/n8n con HTTP Request → “integré APIs REST, manejé OAuth/API keys, parseé JSON y paginé resultados”.

• Error Trigger + reintentos → “diseñé manejo de fallas, backoff y alertas; medí tasa de éxito por ejecución”.

• Webhook + deduplicación → “defendí el sistema de entregas duplicadas con IDs de evento y checks antes de side effects”.

• Agente con tools → “definí tool contracts, límites de acción, logs y evaluación de calidad de respuestas”.

• Dashboard de costos / tiempo ahorrado → “medí impacto: horas/mes, tickets evitados, error rate, costo por run”.

El blog de n8n sobre idempotencia en APIs es una buena fuente para explicar por qué los reintentos sin claves de idempotencia pueden duplicar pagos, altas o mensajes. Si podés contar un caso real (o un lab documentado) donde evitaste eso, pasás de “usuario de la herramienta” a “alguien que piensa en producción”.

Método STAR aplicado a proyectos de agentes y workflows

Según Career Advising & Professional Development de MIT, STAR estructura la respuesta en Situation (~20%), Task (~10%), Action (~60%) y Result (~10%), con foco en lo que vos hiciste (preferí “yo” sobre “nosotros”) y resultados cuantificables. Prepará 3–5 historias adaptables, no un guion memorizado.

Ejemplo STAR 1 — Debugging de un webhook que “a veces” fallaba

• Situation: Un flujo de onboarding recibía webhooks de un CRM; ~8% de leads se duplicaban o se perdían en horarios pico.

• Task: Me pidieron estabilizar el flujo sin reescribir el CRM.

• Action: Revisé logs de ejecución, reproduje con payloads reales, detecté timeouts en un POST y entregas duplicadas. Agregué deduplicación por event ID, reintentos con límite, y una alerta a Slack si fallaba 3 veces.

• Result: Bajamos duplicados a <1% en dos semanas y documenté el runbook para soporte.

Ejemplo STAR 2 — Ownership de un agente con tools

• Situation: El equipo de CS pedía un agente que clasifique tickets y sugiera respuesta.

• Task: Diseñar el agente con guardrails y métricas, no solo el prompt.

• Action: Definí tools (leer ticket, buscar KB, crear draft), límites (no enviar sin humano), logging de prompts/respuestas, y un set de 30 casos de evaluación. Iteré el prompt cuando el agente inventaba políticas.

• Result: Tiempo medio de primera respuesta bajó X%; el agente solo auto-enviaba en categorías de bajo riesgo.

Si no tenés X real, usá proxies honestos: % de casos correctos en tu eval set, horas ahorradas estimadas, o reducción de pasos manuales. Inventar métricas se nota.

Qué practicar la semana antes (checklist)

1. Elegí 3 proyectos: uno de integración API, uno de falla/incidente, uno de impacto de negocio.

2. Escribí cada uno en STAR en una hoja (bullets, no párrafo eterno).

3. Grabate 2 minutos y cortá Situation si te pasás de 30–40 segundos.

4. Preparate para live debugging: “¿cómo testearías este HTTP 429?” / “¿qué pasa si el webhook llega dos veces?”.

5. Armá un one-pager de arquitectura de tu mejor flujo (trigger → transform → side effect → alerta).

Si querés contexto de productividad con agentes para hablar con más soltura del stack, mirá también Claude Cowork y agentes de IA.

Curso recomendado de Coderhouse

Para pasar de “automatizo tareas” a “diseño sistemas con agentes y evaluaciones”, el Curso de AI Agents te da el marco de tools, orquestación y producción. Si tu gap es más de workflows e integraciones, el Curso de AI Automation refuerza n8n/Make con LLMs en flujos reales.

CTA: hoy mismo reescribí un proyecto de tu CV con el mapa de traducción de arriba y ensayá el STAR de debugging en voz alta. Mañana, mandá ese one-pager a un peer para feedback duro.

Preguntas frecuentes

¿Puedo entrar a roles tech solo con Make/n8n? Sí, si demostrás APIs, fallas, métricas y ownership. Sin eso, te van a ver como power user, no como perfil técnico.

¿Me van a pedir live coding? Depende del rol. En muchos puestos de automation/ops piden debugging de flujos, SQL liviano o scripts; en roles más de ingeniería, sí pueden pedir coding. Preguntá el formato del loop.

¿Cuántas historias STAR necesito? MIT sugiere preparar unas pocas historias bien trabajadas (orientativamente 3–5) y adaptarlas, no memorizar docenas.

¿Qué hago si no tengo métricas de negocio? Medí lo que sí controlás: tasa de éxito de ejecuciones, tiempo de ciclo, tickets evitados, costo por run. Sé transparente con estimaciones.