Contact
Detail A4Internal
In use

Hiring pipeline

A system that reads every application. We built it for ourselves: it does the reading, and people make the decisions.

Applications4,500+1Read by the pipeline
Hiring forms17One system for every role
PeriodSep 2025 – Oct 2026And still running
Hires5+Made through it
Speed144 → 11Ranked in about 11 minutes

Note 1Counts are at least these. Earlier hiring rounds ran on another machine and in another repository, and are not included. ↩

A–A
The problem

One job post in India brings hundreds of applications within a day.

142 of 144applications on day onefor one Flutter role
Volume
Hundreds per post, within a day
Signal
Most applicants skip the post
Goal
Read everyone, fast; people decide
B–B
How it works

Six stages. The machines read; people meet the candidates and decide.

From application to interview
S1

Custom form

Written answers instead of checkboxes, and a hidden reading keyword

Automated
S2

Pre-filters

Salary band, experience, thin answers, missing links

Automated
S3

Resume scan

Text extracted from every resume; students detected

Automated
S4

GitHub analysis

Each repo classed real, suspicious, dump or thin

Automated
S5

AI scoring

6–12 dimensions per role: shortlist, maybe or reject

Automated
S6

Interview and practical

People meet the shortlist and set a real task

Human
Fig. 2 — The pipeline. A new role is a new config file, not a new system.
C–C
The work, in detail

Five things the pipeline does, and what changed.

Detail C1Screening
In use
C1

Reading every application

~11 minto a shortlist

144 Flutter applicants ranked into a shortlist of 11. The top-ranked candidate was hired.

How we did it
Problem
Reading hundreds of applications by hand took days, so the later ones got less attention than the first.
What we did
The pipeline reads every answer and every resume, scores each applicant against the role, and ranks them. For writing roles it reads the samples too.
Outcome
144 Flutter applicants ranked into an 11-person shortlist in about 11 minutes. The top-ranked candidate was hired. 91 writers screened, 79 of them read in full with their samples, in about 20 minutes.
Two rounds · timed
Content writers · about 20 minutes
Screened91
Read in full79
Top-rankedHired
Detail C2Verification
In use
C2

Claims checked against code

19claimed skills not in their code

Every applicant’s GitHub is checked and classed real, suspicious, dump or thin.

How we did it
Problem
A form lets anyone tick a skill. A resume lets anyone claim years of experience.
What we did
The pipeline opens each applicant’s public code and checks it against what they claimed. It classes every repository by how it was built, and reads resumes for graduation dates.
Outcome
In one round, 19 applicants claimed a skill their code did not show, and 19 had “dump” repositories, with 80% or more of the commits made in 3 days. Students posing as experienced developers were caught by the resume scan.
Repository classes
Realsteady history Suspiciousdoesn’t add up Dump80%+ in 3 days Thintoo little to judge
Skill claimed, not in code19
Dump repositories19
Students posing as experiencedCaught
Detail C3AI use
In use
C3

AI use, seen honestly

37%said no AI, or left it blank

AI traces still showed up. Using AI is fine. We ask candidates whether they did, and we look for an honest answer.

How we did it
Problem
Applicants use AI to write their answers. Many say they don’t.
What we did
The form asks directly how the applicant uses AI. The pipeline then looks for the traces AI leaves: leftover prompt instructions, citation artifacts and the same templated answer from many people.
Outcome
In one round, 37% left the question blank or said they used no AI, and AI traces still showed up. Using AI is fine. We ask candidates whether they did, and we look for an honest answer.
The AI question · one round
Blank or “no AI” · 37%Answered · 63%
Traces foundLeftover promptsCitation artifactsTemplated answers
Detail C4Evaluation
Changed
C4

The filter we retired

1filter retired

The reading keyword is now a signal, not a gate, and a practical round is part of every hire.

How we did it
Problem
Our first filter was a hidden keyword in the job post. Anyone who didn’t include it was rejected. We checked who it was rejecting.
What we did
It tested obedience, not ability: some of our best candidates had failed it. We turned it from a gate into one signal among many.
Outcome
The keyword is now a signal, not a gate. We also found that a polished form did not predict good work, so a practical round is now part of every hire.
Process · revised
Hidden keywordGate→Signal
Practical roundOptional→Every hire
Detail C5Reuse
In use
C5

A new role is a new config

17hiring forms

All on one system. A new role is a new config file and a review script.

How we did it
Problem
Every role asks different questions and needs different checks. Building a screening system per role does not scale.
What we did
The stages are shared. A role is described in one config file: its form, its pre-filters and its scoring dimensions, plus a short review script.
Outcome
17 hiring forms run on one system.
New role
ConfigFormPre-filtersScoring dimensions
PlusReview script
SharedEvery other stage
17 forms · one system
D–D
All work Next caseShopping Event VIP