Desarrollador n8n: 11 preguntas de entrevista y cómo puntuarlas

Once preguntas para entrevistar a un desarrollador n8n, cómo suena una respuesta buena y una mala, y una tabla de puntaje que te dice si contratar o descartar.

Por Carlos Familia, Experto en CRM y automatización con IA. Actualizado el 15 de octubre de 2026. 10 min.

Un equipo contó en r/n8n que heredó unos 50 flujos de un desarrollador anterior: sin documentación, sin reglas para nombrarlos y con la mitad fallando en silencio. Algunos eran críticos para el negocio. Otros quizá llevaban un año sin correr, y nadie sabía cuáles. Pasaron semanas averiguando qué hacía cada flujo antes de tocar nada, y después empezaron a migrar los importantes a scripts sencillos de Python, más fáciles de depurar y de entregar.

Nada en esa conversación dice que el primer desarrollador no supiera construir. Lo que falló fue todo lo que rodea la construcción: quién es el dueño, las alertas, los nombres y la entrega. Para contratar a un buen desarrollador n8n, hazle las once preguntas de abajo sobre propiedad, fallos, cambios y pruebas, puntúa las respuestas y paga una prueba pequeña antes del proyecto real.

n8n conecta aplicaciones y automatiza tareas con flujos (en inglés, workflows): cadenas de pasos que corren solas cuando pasa algo, como un mensaje nuevo o un formulario enviado.

Las guías de tarifas sirven para el presupuesto, no para esto. Flowlyn, una agencia que vende trabajo en n8n, publica tarifas de freelance de unos 35 a 110 dólares la hora para nivel junior a intermedio y de 120 a 250 para especialistas senior (guía del 25 de febrero de 2026). Las respuestas predicen el resultado mejor que la tarifa.

¿Dónde encuentras a quién preguntarle? n8n lista proveedores en experts.n8n.io, con etiquetas de nivel como Premium, Enterprise y Select, y la página no explica cómo los evalúa. La categoría de empleos de la comunidad de n8n reúne ofertas de trabajo y gente que ofrece sus servicios.

Si contratas en una plataforma de freelancers, las señales de alerta están en freelancer n8n en Upwork o Fiverr. Si te inclinas por un estudio, mira agencia de IA o freelancer. A todos hazles las mismas once preguntas, y pídele a cada uno que describa el último incidente de producción que resolvió.

Preguntas sobre propiedad y entrega

1. ¿En qué cuenta va a correr esto y quién es el dueño?

Una buena respuesta suena así: "En tu cuenta de n8n Cloud o en tu propio servidor, a tu nombre. Yo tengo un usuario. Tú recibes una exportación de cada flujo en la entrega."

Una mala respuesta suena así: "Lo aloja mi cuenta, no te preocupes por eso."

Construí cuatro flujos para un inversionista inmobiliario de Nuevo México en su propia cuenta de n8n Cloud. Recogen hojas de ejecuciones hipotecarias en Airtable, mantienen al día las subastas, completan los datos de contacto de los propietarios y pasan los registros a una aplicación de visitas en campo. Como la cuenta es suya, los flujos se quedan ahí, siga yo en el proyecto o no.

Si alguien te lo aloja en un servidor, ten en cuenta que la edición gratuita Community no incluye control de versiones con Git, proyectos ni compartir flujos y credenciales. Pregunta cómo se versionan y respaldan tus flujos, y quién vigila el servidor. A uno de mis propios servidores su proveedor de VPS le quitaba entre 87 y 90 por ciento del tiempo de CPU, y las revisiones de salud cada 5 segundos de una pila de base de datos eran buena parte de la carga.

2. ¿Dónde viven las claves y cómo quitas tu acceso?

Una buena respuesta suena así: "En el almacén de credenciales de n8n, en tu cuenta. Nada se pega en nodos de código ni en prompts. Te dejo una lista de lo que usé y el último día borras mi usuario."

Una mala respuesta suena así: "Mándame las claves de las API por mensaje y yo las pongo donde funcionen."

Las claves en el lugar equivocado son difíciles de encontrar y más difíciles de cambiar. Quien ya ha entregado proyectos tiene esa lista preparada. Si la respuesta es vaga, nadie se la había pedido.

3. ¿Qué recibo exactamente en la entrega?

Una buena respuesta suena así: "Una exportación de cada flujo, una lista de credenciales por nombre, una nota de una página por flujo que diga qué lo dispara, qué escribe y cómo apagarlo, a dónde van las alertas y un manual corto."

Una mala respuesta suena así: "Todo está en el editor. Ábrelo y míralo."

El equipo de r/n8n del principio es lo que cuesta una entrega que no existe: semanas leyendo flujos antes de que alguien se atreva a cambiar uno. Pide ver el paquete de entrega de un proyecto anterior, sin datos del cliente. Si no puede mostrarlo, probablemente eres el primero que lo pide.

Preguntas sobre fallos

4. ¿Cómo me entero cuando algo falla?

Una buena respuesta suena así: "Cada flujo activo apunta a un flujo de errores que avisa a una persona. Una alerta por flujo, paso y error, con los repetidos silenciados un rato, más una revisión cada hora de los flujos que alguien apagó. Rompo una credencial a propósito y te enseño el mensaje."

Una mala respuesta suena así: "Puedes mirar la lista de ejecuciones cuando quieras."

En una empresa hipotecaria de Florida, los 33 flujos activos reportan a un solo capturador de errores. Un paso que falla manda una sola alerta, el mismo error se silencia media hora, y una revisión cada hora marca cualquier flujo apagado o programación que se saltó una corrida. La primera versión me enseñó algo: el capturador no hizo nada hasta que lo publiqué, porque un flujo de errores sin publicar nunca corre.

Pregunta también cómo prueban el canal de alerta. En esa empresa, un paso de alerta por WhatsApp registró "aceptado" durante días después de que la plataforma perdiera acceso a la cuenta de WhatsApp Business. Lo reemplacé por una alerta por SMS.

Dos trampas más. Una prueba mía programada cada pocos segundos llenó el historial tan rápido que toda la instancia conservaba solo unos dos días de corridas. Y las ejecuciones detenidas más de unos 65 segundos en un paso de espera no aparecían en la lista: una lista vacía no prueba que no haya nada pendiente.

5. ¿Qué pasa si el mismo webhook llega dos veces?

Una buena respuesta suena así: "Cada evento tiene un identificador. Lo reclamo en una base de datos antes de actuar, y la segunda copia se ignora."

Una mala respuesta suena así: "Eso no debería pasar."

En el bot de reservas por Instagram y Facebook de un spa médico en Nueva Jersey, las consultas programadas se superponían y el bot contestaba dos veces. n8n guarda los datos estáticos solo cuando termina una corrida, así que las dos tomaron el mismo mensaje como nuevo. La solución fue reclamar cada mensaje de forma atómica en una tabla de base de datos antes de responder.

6. ¿Qué informa la corrida cuando una API dice "más despacio"?

Una buena respuesta suena así: "Reintentos con espera creciente, concurrencia limitada y un conteo de elementos fallidos en el resultado, para que un fallo parcial se vea."

Una mala respuesta suena así: "O funciona o da error."

La primera corrida real de una cola diaria de llamadas que construí para la misma empresa terminó sin error. Aun así había perdido 28 lecturas de contactos y 16 escrituras de etiquetas por límites de velocidad (error 429), y nada en n8n lo decía. Agregué reintentos con espera creciente, limité la concurrencia a 4 y puse contadores de fallos en el resultado. Después del arreglo, una corrida leyó 118 de 118 contactos, escribió 43 de 43 etiquetas y tardó 29 segundos en vez de 152.

Los límites de tiempo fallan igual. El límite de 300 segundos de un nodo de código cubre el nodo completo, incluso en modo por elemento, y una noche de 32 contactos para un mayorista inmobiliario no escribió nada. Dividir el trabajo con SplitInBatches le dio a cada elemento su propio presupuesto de tiempo, y una noche de 32 contactos terminó después en 354 segundos, dentro del límite.

7. ¿Qué pasa cuando un nodo de código lanza un error?

Una buena respuesta suena así: "Falla en voz alta. El error llega al flujo de errores, y el webhook responde con un código de fallo, no con un 200."

Una mala respuesta suena así: "Envuelvo todo en try y catch para que nunca se rompa."

Un catch vacío esconde los problemas. Algunos entornos del nodo de código no tienen el objeto $helpers ni new URL(), y el fallo desaparece dentro del catch. Un error lanzado dentro de un nodo de código también puede dejar al webhook respondiendo un simple 200, y quien lo llamó cree que funcionó.

Preguntas sobre cambios y pruebas

8. ¿Cómo publicas un cambio en algo que ya está corriendo?

Una buena respuesta suena así: "Aplico el cambio sobre la versión publicada, comparo lo que corrió con lo guardado y vuelvo a procesar lo que se perdió durante el cambio. Puedo revertirlo."

Una mala respuesta suena así: "Lo edito en vivo y ya."

Una vez corregí el enrutador de un bot de chat partiendo de la copia en borrador. Eso publicó código viejo y dejó el enrutador caído 15 minutos. Trampas parecidas: una actualización parcial de un flujo activo puede dejar su webhook sin registrar hasta que lo desactivas y lo activas, y en la construcción de Nuevo México, activar mediante la API pública de n8n Cloud no registró los disparadores. Pregunta cómo demuestran que un disparador está vivo.

9. ¿Cómo pruebas sin tocar a mis clientes?

Una buena respuesta suena así: "Solo contactos de prueba, una lista blanca y un indicador de prueba que revisa cada escritura. Si no puede leerse el indicador, la corrida se detiene."

Una mala respuesta suena así: "Lo pruebo primero con unos cuantos clientes potenciales reales."

Un indicador de prueba que se lee una sola vez, al final de la corrida, es un informe, no una protección. El bot del spa médico también tiene una lista blanca de probadores. En el bot de un contratista de techos en Kentucky, un texto interno del modo de prueba le llegó a un cliente potencial real, así que pide una demostración y no una descripción.

10. Si esto incluye un agente de IA, ¿cómo evitas que diga que hizo algo que no hizo?

Una buena respuesta suena así: "Las herramientas devuelven los hechos, y un cambio cuenta como real solo cuando la herramienta tiene éxito. Los límites que deben cumplirse viven en el código, no en el prompt. Después de cualquier edición con script corro una conversación que obliga a llamar una herramienta."

Una mala respuesta suena así: "Escribí un prompt buenísimo."

He visto tres versiones de este fallo. Un enrutador construido con llamadas REST directas recibía cada resultado de herramienta como una cadena vacía, y por eso inventaba horarios, precios y reservas. Un script que reconstruyó las conexiones borró 23 conexiones de modelo, memoria y herramientas, y las ejecuciones seguían mostrando éxito. Una regla en el prompt no evitó que un bot pidiera una hora en cada respuesta, mientras que un contador en el código sí.

La lista completa está en los errores de agentes de IA en n8n que viví en producción (en inglés).

11. ¿Qué construirías primero como tarea de prueba pagada?

Una buena respuesta suena así: "Un flujo real pequeño en tu instancia. Datos de prueba, un fallo provocado que dispare una alerta, la misma entrada enviada dos veces que produzca un solo resultado y una nota de una página sobre cómo apagarlo."

Una mala respuesta suena así: "Déjame hacer todo el proyecto y lo juzgas al final."

Paga la prueba. Muestra cómo trabaja y cuesta menos que descubrirlo en el proyecto completo. Lean juntos el registro de ejecución al terminar.

Casi todas mis construcciones conectan n8n con GoHighLevel; explico dónde está esa línea en GoHighLevel con n8n (en inglés). Si el presupuesto es la duda abierta, lee cuánto cuesta un desarrollador n8n. Y si ya tienes flujos que nadie ha revisado, empieza con un consultor de n8n (en inglés).

¿Cómo puntúo las respuestas?

Da 0 a una respuesta mala, 1 a una vaga y 2 a una buena respaldada por una historia de un proyecto real. El máximo es 22. Puntúa a cada candidato por separado y anota los números antes de que termine la llamada.

Dos ceros entre las preguntas 4, 5 y 6 son motivo para descartarlo, sea cual sea el total, porque esas tres deciden si te vas a enterar de los problemas. Puedes agendar una llamada y respondo las mismas once sobre mi propio trabajo, en español o en inglés.

Sobre el autor

Carlos Familia, Experto en CRM y automatización con IA. GoHighLevel, n8n, agentes de IA, servidores. Desarrollador full stack.

Construyo sistemas de CRM en GoHighLevel, automatizaciones de n8n en mis propios servidores y agentes de IA de voz y chat para negocios de servicios. Desarrollador full stack: escribo el workflow, la integración con la API, la base de datos y el servidor donde corre, y pruebo cada sistema con recorridos reales antes de entregarlo.