n8n Developer Skills Test: A Practical Hiring Assessment

A useful n8n developer skills test should require a candidate to build and explain a small production-style workflow, not answer trivia about nodes. Test webhook validation, API authentication, data transformation, pagination, duplicate prevention, failure recovery and documentation. Give every candidate the same synthetic data and restricted sandbox, then assess the exported workflow and a technical walkthrough. This exercise suits UK and European employers hiring someone to own live automations; simplify it for a junior role.

What the assessment needs to prove

A successful execution proves only that the happy path worked. Employers need evidence that the candidate understands the business process, controls changes to external systems and leaves a maintainable workflow. Start with the work they will own: synchronising CRM records needs different judgement from administering the infrastructure that runs n8n.

How Borderless Recruit helps: Borderless Recruit supplies a dedicated, full-time AI Automation Specialist from £990 / €1,150 per month ($1,300) as a flat monthly client staffing fee. It handles sourcing, vetting, local employment contracts, payroll and HR; vetting includes a live English interview, a personality/reliability assessment and a practical workflow build with error handling. You interview the finalists. The specialist works only for you, during your UK or European business hours, on an overlapping shift in the Philippines. The Philippines does not observe daylight saving, so agree how the shift follows your seasonal clock changes.

Copy-ready candidate brief and sample data

Give every candidate the same brief, mock API documentation, sandbox and expected effort. State whether AI assistance is permitted and which tools are available. Pay for a substantial trial or commercially useful work, and agree the fee and ownership terms before it begins. Do not turn an assessment into an unpaid client project.

Employer setup: provide a working mock customer API, a mock CRM that records attempted writes, disposable credentials and reset instructions. Define the pagination format, permitted status values, required fields and simulated failures. Let candidates focus on the workflow rather than building their own test infrastructure. Ask a technical reviewer to confirm that the supplied environment can run the exercise before inviting applicants.

• Build an n8n workflow that receives a synthetic customer event by webhook. Authenticate the request, validate required fields and reject malformed input with a clear response.
• Look up the customer through the mock authenticated API. Follow pagination and distinguish an absent customer from an API failure.
• Normalise the record and write an upsert to the mock CRM. Prevent replayed events from repeating completed business actions, while allowing a genuinely new event for the same customer.
• Handle validation rejections explicitly. Route unexpected execution failures and exhausted retries to an operator-visible recovery path; explain how each path is triggered and tested.
• Keep tokens in credential storage. Separate configuration from workflow logic and remove secrets, sensitive execution data and private endpoints from the submission.
• Write a short runbook covering setup, assumptions, monitoring, credential changes, common failures, replay and deployment.

Illustrative fixture and expected results

Use this synthetic starting payload: {"event_id":"evt-alpha","customer_id":"cust-alpha","email":"alex@example.invalid","status":"active"}. For this exercise, require every field, allow active or inactive status, and use event_id to identify a delivery replay. Treat customer_id as the CRM identity. Provide an authenticated request separately from the payload.

Required submission

• An importable workflow export with secrets removed, plus any supporting components needed to run it.
• A README with setup instructions, assumptions and known limitations.
• Execution evidence for the supplied scenarios, including the mock CRM's write history.
• A runbook for alerts, safe replay, credential changes and maintenance.
• A walkthrough in which the candidate explains decisions and makes a small live change.

A transparent marking rubric

Share the rubric before the test. Treat security and reliability as gates: an attractive canvas should not pass if it exposes credentials, duplicates business actions or hides failures. Record the execution or explanation that supports each judgement so interviewers can compare evidence rather than presentation style.

For an independent hire, resolve any safety failure before approving the candidate. Offer a bounded correction where the issue is repairable, then rerun the affected scenarios. A junior may need support with architecture, but the reviewer should still see safe credential handling and an honest account of limitations. Agree who would provide that supervision before making an offer.

Check replay safety beyond the happy path

During the walkthrough, use the ambiguous-write scenario: the CRM accepted the change, but the workflow did not receive confirmation. Ask the candidate to recover without blindly repeating it. Look for evidence from the target system, a durable record of event state and a clear explanation of what remains uncertain. Merely adding an idempotency field to the payload is insufficient evidence of duplicate prevention.

Then discuss overlapping deliveries of the same event. Ask how the design would prevent competing executions from both acting, and what happens if processing stops after an event is marked as started. For a senior role, require a demonstration in the supplied environment; for a junior, assess their recognition of the problem and proposed escalation. Keep these expectations visible in the brief.

Technical interview questions after the test

• Where is event state stored, when can it be deleted, and how do you distinguish an unfinished attempt from a completed event?
• Which failures should be retried, which should stop immediately, and how does an operator know what to do next?
• How would you move this workflow between environments and reconnect its credentials?
• What belongs in logs, and which customer or credential details should be excluded?
• When would you use a Code node, a reusable sub-workflow or an external service?
• If the API changed its schema, where would this workflow fail and how would the operator notice?

Do not try to detect AI-assisted work from writing style alone. Ask the candidate to trace an execution, explain an expression and diagnose an injected failure. Assess whether they can verify and safely modify the submitted work. Apply the declared AI-tool policy consistently, and do not equate confident presentation with technical ownership.

Run a secure and fair remote assessment

Use synthetic records, disposable credentials, a mock API and an isolated n8n instance. Overseas access can engage UK GDPR international-transfer rules: assess which legal entity receives the data and the actual access arrangement using the ICO's international-transfer guidance. Keeping a server in the UK does not by itself settle the question. For EU personal data, review the European Commission's guidance on transfers outside the EU.

• Give candidates the same brief, environment, deadline, permitted tools and evaluation criteria.
• Offer an accessible alternative where the interface or live presentation format creates a disability-related barrier.
• Avoid production records, live API keys and unrestricted CRM accounts.
• Explain any recording or monitoring, who can access the assessment and how long it will be retained.
• Revoke temporary credentials and remove assessment environments when they are no longer needed.

Adjust the test to the role

If the job centres on n8n workflows and integrations, assess an automation specialist against that scope. If it requires substantial application development around n8n, compare the responsibilities with a Full-Stack Developer. Include hosting and infrastructure tasks only when the employee will own them. A non-technical hiring manager should appoint a technical reviewer to inspect the export and recovery behaviour.

Turn the assessment into an ownership plan

Use the assessment findings to agree onboarding priorities. Assign ownership of credentials, repositories, workflow exports, incident decisions and vendor accounts. Require an inventory, change notes, alert routing and recovery instructions. Ask the successful candidate to document an existing low-risk workflow before taking responsibility for consequential automations, and agree who approves changes.

Keep the hiring decision specific: record demonstrated strengths, unresolved gaps and the support the role needs. For broader decisions about scope and ongoing ownership, use the n8n developer hiring guide. The assessment should leave you able to explain why this candidate can handle your workflows and where review is still required.