40 Take-Home Tests Graded in 14 Min: The n8n Rubric Node

By Lazar Milicevic · Published July 23, 2026 · 8 min read

Forty GitHub links land in your inbox on a Monday. Somebody — usually the founder or a senior engineer — is about to lose a Saturday cloning repos, running tests, and writing feedback. At nine minutes per submission that's six hours, and by submission thirty the reviewer is tired and rounding everyone down. That's not hiring. That's fatigue-based rejection, and it's the reason most small teams either drop take-homes entirely or hire the wrong person.

Here's the workflow I built to fix it: five n8n nodes, 14 minutes total runtime for 40 submissions, about $0.60 in API cost. The whole thing hinges on one prompt change nobody talks about.

Why every "AI code reviewer" demo fails

Most automation tutorials skip take-homes because everyone asks the model the wrong question. They paste code into GPT and ask "is this good?" The model answers confidently, plausibly, and unreliably. It praises garbage. It rejects solid work. Ask it the same question twice and you get two different scores. So the industry decided take-homes can't be automated and moved on to booking calendar invites.

The fix is a reframing, not a bigger model. Language models are terrible at subjective judgment ("is this idiomatic Python?") and genuinely good at yes-no checks against fixed criteria ("does this repo contain a README file that describes setup steps?"). Take-home grading looks subjective, but 80% of it is actually the second kind of question. You just have to write the rubric that way.

• Bad prompt: "Rate this code from 1–10."
• Good prompt: "Does README.md contain a section describing how to install dependencies? Quote the exact lines. If no such section exists, score 0."

The second prompt is auditable. You can re-run it on the same repo six months later and get the same answer. That's the property you need for hiring decisions.

The 5-node n8n workflow

The pipeline is deliberately boring. Every node does one thing and hands off structured data. Nothing clever, nothing hard to debug.

• Node 1 — Airtable Trigger. Candidate submits their GitHub URL through your application form (Tally, Typeform, whatever). A row lands in Airtable. Trigger fires.
• Node 2 — GitHub API / Clone. Pulls the repo into a temp directory on the n8n host. Also fetches commit metadata via the REST API — you'll need commit timestamps and hashes for the rubric later.
• Node 3 — Docker Execute. Spins up a clean, network-isolated container, installs dependencies, runs your pre-defined test suite. Captures pass/fail per test, runtime, stderr.
• Node 4 — Rubric Scorer. LLM call (Claude Sonnet or GPT-4o-mini both work) with the structured rubric prompt. Returns JSON.
• Node 5 — Airtable Write. Score, per-criterion breakdown, evidence citations, and a flag column written back to the candidate's row.

Here's the Docker execute node body — the actual command that runs each submission:

docker run --rm \
  --network=none \
  --memory=512m \
  --cpus=1 \
  --read-only \
  --tmpfs /tmp:rw,size=128m \
  -v "$REPO_PATH:/app:ro" \
  -w /app \
  node:20-alpine \
  sh -c "npm ci --silent && npm test -- --json > /tmp/results.json; cat /tmp/results.json"

Four things matter here: --network=none after install (candidate code cannot phone home), memory + CPU caps (an infinite loop won't take down your n8n box), read-only mount (the container cannot modify the repo you cloned), and a JSON test output so node 4 gets structured data instead of parsing terminal noise.

The rubric prompt (the whole game)

Everything above is plumbing. This is the part that actually decides whether the workflow works or produces nonsense. Four fixed criteria, 25 points each, 100 total.

You are grading a take-home coding submission against a fixed rubric.
You may ONLY score based on evidence you can quote directly from the
repo contents provided below. If you cannot cite a specific file path,
line number, or commit hash as evidence, the score for that criterion
is 0. Do not infer, do not assume, do not give benefit of the doubt.

CRITERION 1 (0-25): Does the code run end-to-end without errors?
  Evidence source: test_runner_output below.
  25 = all tests executed, exit code 0.
  0-24 = partial or failed execution. Quote the error.

CRITERION 2 (0-25): Does it pass the 3 functional tests in the spec?
  Evidence source: test_runner_output.
  Award 8 points per test passed, +1 if all three pass.
  Quote the test name and pass/fail status for each.

CRITERION 3 (0-25): Is there a README explaining setup and design?
  Evidence source: readme_contents below.
  25 = setup steps + design rationale present. Quote both sections.
  12 = one but not both. 0 = missing or under 100 words.

CRITERION 4 (0-25): Does the commit history show incremental work?
  Evidence source: commit_log below.
  25 = 5+ commits spread over 2+ days, each with a message describing
       a specific change. Quote 3 commit hashes + messages as evidence.
  0 = single commit, or all commits within a 60-minute window.

Return JSON:
{
  "criterion_1": {"score": N, "evidence": "..."},
  "criterion_2": {"score": N, "evidence": "..."},
  "criterion_3": {"score": N, "evidence": "..."},
  "criterion_4": {"score": N, "evidence": "..."},
  "total": N,
  "notes": "one sentence, factual only"
}

The line that kills hallucination: "If you cannot cite a specific file path, line number, or commit hash as evidence, the score for that criterion is 0." Without it, the model invents praise. With it, the model has to point at a line, which means it has to actually look at the repo. In 40 submissions I've had zero fabricated citations since adding that constraint. Before it, roughly 1 in 6 submissions got scored on things that didn't exist in the code.

The ≥90 guardrail: catching AI-written submissions

Any submission scoring above 90 gets automatically flagged for human review. Not because the workflow is broken — because near-perfect scores are the exact suspicious signal you want.

Two scenarios produce a 95+:

1. The candidate is genuinely strong.
2. The candidate pasted your spec into Claude or GPT and shipped the output.

Both look identical to the rubric. Neither is a problem the LLM scorer can solve, because a well-prompted model can produce code that clears functional tests, includes a README, and even runs git commit in a loop with plausible messages. What it can't fake convincingly is the shape of real development work over time. Thirty seconds looking at the commit log tells you which bucket the candidate is in.

Signals I check on flagged submissions:

• Commit timing. 12 commits across 3 days with variable gaps = human. 8 commits inside 20 minutes at 2 a.m. = LLM dump run through a bash script.
• Commit message style. "fix off-by-one in date parser" = human. "Implement feature", "Update code", "Fix bug" repeated = LLM default.
• File-level churn. Real devs edit the same file 3–5 times as they iterate. LLM dumps write each file once and never touch it again.
• README voice. LLMs love bulleted feature lists and the phrase "This project demonstrates". Humans write shorter, more specific setup notes.

This guardrail catches maybe 3–5 of every 40 submissions. Of those, 1–2 are legit strong candidates and the rest are LLM output. Thirty seconds of human eyeballs per flagged repo is a cost I'll take.

What 40 submissions actually looks like

Real numbers from the last hiring round I ran this on (senior full-stack role, Node/React take-home, 40 submissions):

The workflow didn't change who got hired. It changed how many hours got burned to find them, and it stopped candidate #35 from getting a worse read than candidate #3.

Things that will trip you up

Four failure modes I've watched people hit trying to build this themselves:

• Running candidate code on your main box. Someone will submit a repo with rm -rf / in a postinstall script. Docker with --network=none and --read-only isn't optional. Do not skip it.
• Writing tests after you've seen submissions. Define the three functional tests before the job posts. If you write tests after submissions arrive, you will unconsciously write tests that pass the candidates you already like. That's not grading — that's confirmation bias with extra steps.
• Tweaking the rubric mid-round. If you change the prompt between candidate 10 and candidate 20, you've broken the consistency guarantee that made the workflow worth building. Version the prompt in git. Freeze it when the job posts.
• Treating the score as a hiring decision. The rubric picks who deserves 30 minutes of real human attention. It doesn't pick who to hire. That's still a person's job.

Where this sits in a full recruiter stack

The rubric grader is one node in a larger pipeline. For a small team hiring engineers, the full flow I usually build looks like: intake form captures the applicant, an enrichment step pulls public GitHub and LinkedIn data, a resume screener does a first-pass fit check against the job spec, this rubric grader handles the take-home, and a scheduling agent books calls with candidates who cleared every gate. Each node is boring on its own. Chained together, they collapse a two-week hiring cycle into about three days of actual work.

How this looks when we build it for a client

Most of the hiring pipelines we ship at bizflowai.io start with exactly this take-home grader, because it's the step where founders feel the pain most acutely. We set up the Airtable base, the sandboxed Docker runner, the rubric prompt tuned to the specific role (a React take-home rubric and a data-engineering take-home rubric are not the same document), and the ≥90 human-review flag routing into whatever your team uses — Slack, email, a Trello column. Then we hand it over. It runs on your n8n instance, your API keys, your data. Nothing about the workflow is proprietary — everything in this post is what actually runs in production.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.