Designing a technical screening pipeline that respects candidates

A technical screen is a sequence of decisions. The candidate decides whether to apply. The recruiter decides who to talk to. The hiring manager decides who to interview. The company decides who to hire.

Most screening software optimises one of those decisions and makes the others worse. A fast filter can produce a worse candidate experience. A thorough process can take three weeks before anyone hears back.

A good pipeline is not the longest one. It is the one where every step earns its place.

Start with the decision you are making

Before adding a round, write down what decision it informs. A resume review answers: is there enough relevant evidence to spend a conversation on this person? A coding round answers: can they write working code under a realistic constraint? A system design round answers: can they reason about trade-offs out loud?

If a round does not change a decision, it is probably a tax on the candidate.

This is also why a pipeline should be linear in its first version. Branching pipelines are powerful, but they make it hard to explain why two candidates had different experiences. Start with an ordered list, keep it short, and add complexity only when the hiring data asks for it.

Use modules, not a single mega-interview

A module is a self-contained round with its own config, candidate experience, runner and grader. That structure has practical benefits:

• A resume round can ship before a coding round exists.
• Each module can have its own deadline and required flag.
• A new module plugs into the same pipeline instead of changing the engine.
• Candidates see one round at a time instead of a wall of tasks.

It also keeps grading honest. Deterministic parts stay deterministic: multiple-choice keys and SQL results are checked by code, not by a model. When the coding module ships, test cases will be checked the same way. Free-text answers go to structured LLM grading with evidence and confidence.

Make the next step obvious

Candidates should never have to decode internal stage names. Tell them what the next step is, when it is due, and what happens after they submit.

Three details matter more than they look:

1. Autosave. A dropped connection should not erase twenty minutes of work.
2. A visible deadline. Time limits should be clear before the round starts, not discovered halfway through.
3. Plain-language status. "Waiting for review" is better than "stage_3_pending".

The recruiter view can stay dense. The candidate view should be calm.

Consent is part of the flow, not a footer link

If a system evaluates a candidate with AI, the candidate should consent to that evaluation before it happens. If a round records audio, screen or webcam, consent should be separate per capture type. Webcam should be optional and off by default.

Consent is not a legal afterthought. It changes the product design. It means the consent gate is a real step in the pipeline, not a checkbox buried in an application form.

The same logic applies to retention. A recording should have a retention date when it is created. A deletion request should have a path through the system, not a support ticket that disappears.

Do not auto-reject

It is tempting to let the score do the work: below 60, reject; above 80, advance. Resist it.

A score is a compressed judgement. Compression loses context. A candidate with a weak resume might have the strongest coding signal in the pool. A candidate with a strong resume might freeze in a live round. A model might be uncertain and hide that uncertainty in a single number.

Keep outcomes as scores and flags. Let a human make the call. If a step is required, say so. But do not dress up an automatic rejection as a pipeline rule.

A starter pipeline

For a backend role, a reasonable first pipeline looks like this:

1. Resume review against the job description, with verbatim evidence.
2. A short questionnaire to check role fit and communication.
3. An assessment with a few multiple-choice and SQL questions.
4. A coding round with a realistic problem and test cases.
5. A system design conversation for senior roles.

That is five steps, which is already a lot. Cut what does not change the decision. For a junior role, the assessment and coding round may be enough. For a staff role, the design round matters more than another quiz.

Measure the screen, not just the hire

A pipeline is a product. It should be reviewed like one. Are candidates dropping out at a particular step? Are scores clustering at the top? Are overrides piling up on one dimension? Is the same group of candidates consistently scored lower?

Some of those reports are on our roadmap, not shipped today. But the design should make them possible: versioned pipelines, stored provenance, audit trails, and evidence that can be re-read later.

The goal is not a perfect score. It is a process you can explain, defend and improve.