◆ Sparround

The practical task: designing a workflow live

The heaviest part of a middle-level n8n interview is the practical task: "How would you build this process in n8n?" The interviewer does not expect a working workflow — they want to see how you think.

The most common mistake is launching straight into node names. A strong candidate asks questions first, because that is what real work looks like.

A five-step approach:

1. Ask clarifying questions — volume, frequency, sources, edge cases 2. Describe the flow at a high level — trigger, processing, result 3. Turn it into nodes — with concrete node names 4. Add the edge cases — duplicates, failures, empty results 5. State the boundaries — when this design stops working, and what you would do then

QuestionWhy it matters
How often does this event happen?It determines the trigger choice and whether rate limits matter
Does the source support webhooks, or is polling needed?Building polling when push is available is pointless
What should happen if the same record arrives twice?Idempotency is foundational and hard to bolt on later
Is the outcome reversible?If not, a human approval step is needed
If one source is unavailable, should the process stop or continue?Continuing with a partial result is often better
Who sees the result, and who learns if it is wrong?Notification and error handling are part of the design
Is there sensitive data?Credential permissions and execution data retention follow from this

Do not avoid asking questions. Some candidates hold back for fear of looking uninformed. The opposite is true: asking clarifying questions is a sign of experience — in a real project, building before the requirement is clear is the most expensive mistake. Interviewers know this and often leave the task deliberately incomplete.

What to say out loud. The interviewer only sees your thinking through what you say. So state each choice with its reason:

  • "I pick a Webhook here because the system can announce the event itself — polling would just make empty requests."
  • "I make the write an upsert, because a webhook resending is normal."
  • "I set continue-on-error on this node, because one bad record should not stop the other 99."

That shows the "why", not just the "what" — and that is where the assessment comes from.

Name the boundaries yourself. At the end of the design: "This holds up well to about a thousand records a day. At a hundred thousand you would need batching and sub-workflows, and probably queue mode on self-hosted." Knowing the limits of your own solution is one of the strongest signals there is.

📚 Sources and documentation