Question 1

Tell me about yourself — what is your experience with n8n?

Accepted Answer

This opens almost every interview, and a scattered answer weakens the whole conversation. Use a 60-90 second structure: 1. Who you are — one sentence: background and current role 2. How you came to n8n — which problem brought you here 3. What you have built — one or two concrete examples with outcomes 4. Where you are heading — the link to this role Example: "My background is in business process work; I have worked with APIs but I am not a developer. What brought me to n8n was concrete — our team assembled a report by hand every morning. I automated it, then came lead routing and AI classification of support tickets. What I learned most was reliability: duplicates, error handling, data loss. Now I want to apply that at a larger scale." Note: do not recite a list of technologies. One concrete outcome beats ten tool names.

Question 2

What was the hardest part of learning n8n?

Accepted Answer

This tests honesty and self-assessment. "Nothing was hard" signals either inexperience or arrogance. A strong answer picks a concrete technical difficulty and describes how you resolved it: "The hardest part was the item model. I assumed a node processed all the data together. Then, in testing with one item, everything looked right; with real data 40 items arrived and 40 emails went out. After that I learned the rule: one item = one run. Once that clicked, a lot fell into place — why loops are rarely needed, what the Aggregate node is for, what Execute Once does. My habit now is to check every node's output and its item count as I add it, and to always keep more than one item in my test data." Note: whatever difficulty you pick, name the lesson — that is what the question is actually looking for.

Question 3

What mistakes do you see most often in n8n?

Accepted Answer

This tests both knowledge and your ability to assess others' work. Give a list with a cause and a fix for each. "1. Not understanding the item model. Tested with one item, production delivers 50, and the node runs 50 times. Fix: always keep more than one item in test data. 2. No error workflow. The workflow breaks, nobody knows, and two weeks later someone notices stale data. The most expensive mistake, because it is silent. 3. Ignoring idempotency. A second run creates duplicates — even though retries and re-runs are normal, so writes should be upserts. 4. Keeping a key in a node parameter. It leaks through exports and sharing. Using a credential is a minute's work. 5. Reaching for an agent for everything. A chain is enough for classification or summarisation — an agent is both costlier and less consistent. 6. Leaving node names at their defaults. In a twenty-node workflow HTTP Request3 says nothing, and six months later nobody dares touch that workflow."

Question 4

What questions would you ask at the end of an interview?

Accepted Answer

Your questions reveal your level — generic questions leave a generic impression. Pick technical and process ones. Technical: "Do you run n8n Cloud or self-hosted? How was that decided?" "How many active workflows are there and who maintains them?" "Do the workflows have an error workflow assigned? How do you learn about failures?" "Are dev and production separated?" Process: "How does a new automation request arrive, and how is it prioritised?" "Are the AI components in use, and for which scenarios?" "What is expected in the first three months in this role?" These do two things: they present you as someone who thinks about operations, and they let you assess that team's maturity. If the answer is "what is an error workflow?", that is information for you too.

Question	What the interviewer is really asking	What the answer must contain
"How is data passed in n8n?"	Do you understand the item model	The array plus `json`/`binary`, and the one item = one run rule
"Webhook or Schedule?"	Can you make an architectural decision	Push vs polling; keeping a cursor when polling
"What happens if a workflow fails?"	Do you have production experience	The error workflow, retry only for transient failures, partial failure
"Agent or chain?"	Do you reach for AI without thinking	A chain is cheap and predictable; an agent is for when decisions are needed
"Your most complex workflow?"	Real experience, and how you handle difficulty	Problem → solution → difficulty → a measurable outcome
"Cloud or self-hosted?"	Will you stop at "it depends"	What it depends on: data residency, maintenance capacity, custom requirements

Common questions and how to structure answers

📚 Sources and documentation