Question 1

How do you choose between writing a Code node and using a ready-made node to transform data?

Accepted Answer

This tests your thinking about code quality — the word "readability" belongs in the answer. "My order is: expressions first, then a transformation node, and the Code node last. The reason is not speed but readability. n8n's core advantage is that someone looking at a workflow sees what happens from the canvas. Sort, Summarize and Split Out are instantly clear; 20 lines of JavaScript doing the same thing have to be opened and read. After a while I am that reader too. When do I switch to the Code node? When the logic is genuinely complex — reconciling data from several sources by a non-standard rule — or when a chain of five or six nodes collapses into one function. There is a flip side: people sometimes insist on nodes for everything and end up with an unreadable 15-node chain. A single Code node is clearer there. My yardstick is which version is easier to explain to someone else."

Question 2

How would you combine data coming from two different sources?

Accepted Answer

Knowing the modes apart is the main signal here. "With the Merge node — but the choice depends on the mode, and I settle that up front: Append — simply stacking two lists. Fields are not combined; only the item count adds up. Join on a key — combining both sources' fields into one item on, say, email. Here you must decide explicitly what happens to non-matching rows, or they vanish silently. For harder cases I use Compare Datasets: it compares two streams and gives four outputs — only in the first, only in the second, different, and identical. That is invaluable for sync problems: you see directly which record is new, which was updated and which was removed. The mistake I see most: someone picks a key-based join, the output item count drops and they do not notice. So I always check the item count after a merge."

Question 3

The item count in a workflow differs from what you expected. How do you trace it?

Accepted Answer

This checks whether you debug systematically. "In n8n every node header shows its input and output item counts. So tracing is simple: walk left to right and find where the count changes. Then I look at what that node is supposed to do. The set of nodes that change the count is small: Increasing — Split Out, and Merge in append mode Decreasing — Filter, Limit, Remove Duplicates, and a key-based Merge Collapsing to one — Aggregate Reducing to group count — Summarize The two cases I hit most: Filter drops more items than expected, which means a type mistake in the condition; or a key-based Merge silently omits non-matching rows. To catch it even earlier you can put a small IF at critical points that checks the item count is in the expected range and alerts when it is not. That is the cheapest protection against silent data loss."

Node	What it does	Effect on item count
Edit Fields (Set)	Adds fields, renames them, drops the ones you do not need	Unchanged
Split Out	Turns a list inside an item into separate items	Increases
Aggregate	Collects separate items into a list inside one item	Decreases (usually to 1)
Summarize	Groups and aggregates like an Excel pivot table (sum, count, avg)	Becomes the number of groups
Sort	Orders items, or randomises them	Unchanged
Limit	Caps the number of items	Decreases
Remove Duplicates	Eliminates identical items	Decreases
Merge	Combines two streams: appending, or joining on a key	Depends on the mode
Compare Datasets	Compares two streams and produces up to four outputs	Splits

Transformation nodes: reshaping data without code

📚 Sources and documentation