Question 1

Tell me about the most complex workflow you have built.

Accepted Answer

This is the most-asked question, and without structure the answer falls apart. Use problem → solution → difficulty → outcome. "Problem. The sales team replied to website leads after four hours on average, because everyone checked their inbox by hand. Solution. A webhook receives the lead, enriches it with company data from an external API, routes it by company size with a Switch, writes it to the CRM, then DMs the right rep on Slack. Difficulty. Two main problems. First, the enrichment API failed intermittently and stopped the whole process — I solved that with the 'Never Error' option so the lead reached the CRM even without enrichment. Second, some users submitted the form twice; I solved that with an idempotency check in a Data Table. Outcome. Average response time went from four hours to two minutes, and duplicate leads went to practically zero." Keep the difficulty section — that is where the interviewer sees what you learned.

Question 2

A workflow broke at 3 a.m. What do you do when you arrive in the morning?

Accepted Answer

This tests operational reflexes. Give a sequence. "1. Measure the impact. First I check the execution history for how many runs failed and what time range they cover. That tells me how much data went unprocessed — I need that before fixing anything. 2. Find the cause. I open a failed execution, see which node it stopped at and look at that node's input data. Most causes are either an unexpected data shape or the external service. 3. Transient or permanent? A 429 or 5xx may already have cleared — a re-run may be all that is needed. A 401 or 400 means a credential or request change and needs a fix. 4. Recover the lost data. This is the most-forgotten step. Events that arrived during the outage do not come back on their own — a cursor catches them up, and without one I reprocess that window by hand. 5. Prevent a repeat. The same cause should not fire twice: retries, alerting, validation of incoming data. And if I only found out about it in the morning, that is a separate problem: no error workflow was set up, and that is the first thing to fix."

Question 3

Starting an automation project from scratch, what would you do in the first week?

Accepted Answer

This is a senior-level question: they expect a process answer, not a technical one. "Days 1-2 — discovery. I write no code. I talk to teams and write down which work is done by hand, how long it takes and how often it repeats. People usually say "let's automate this"; what I need is "this takes N hours a week". Day 3 — prioritisation. I score each process on two axes: impact (time saved or latency removed) and complexity (how many systems, how many edge cases). The first project comes from the high-impact, low-complexity quadrant. Day 4 — the infrastructure decision. Cloud or self-hosted? The criteria: where the data may go, who will maintain it, whether custom nodes are needed. Days 5-7 — the first workflow. Something small, visible and reversible — the daily report, typically. If it breaks, nothing is damaged, but everyone sees the result each morning. Beyond that I always set up two things in week one: an error workflow and a naming and folder convention. Adding either later costs far more than building it in from the start."

Scenario	Trigger	The main difficulty
Lead routing	Webhook (website form)	Duplicates, and the enrichment source being unavailable
Daily business report	Schedule	Not losing the whole report when one source fails
Document processing (invoices)	Gmail Trigger	Validating what the AI extracted
Service monitoring	Schedule (every 5 minutes)	Preventing repeated alerts
Employee onboarding	A form or the HR system	Knowing the state of the rest when one step fails

End-to-end real scenarios

📚 Sources and documentation