Engineering hiring: ask the technical questions in writing first

The CV read well. The intro call was fine. Ten minutes into the technical round everyone in the room already knows how this ends, and there are fifty minutes left on the invite.

Nobody says it out loud. The interviewer keeps asking questions, the candidate keeps answering, and two senior engineers spend the rest of the hour being polite. Multiply that by the number of times it happens in a single search and you have the real cost of engineering hiring, which is not the job board fee and not the recruiter's time. It is the hours of the people you least want sitting in a room where the answer is already known.

This page is about one specific move: asking the technical questions in writing, before anyone opens a calendar. What it changes, what the arithmetic actually looks like, and the cases where it does not help.

Where the hours actually go

Recruiting costs are usually discussed as money per hire. Inside an engineering team the binding constraint is different and much less fungible: a senior engineer's afternoon. That hour does not come out of a budget line. It comes out of the same week as a code review, an incident, and the design doc that has been in draft for a fortnight.

An interview hour is also not one hour. There is the invite and the coordination. There is the fifteen minutes of reading the CV that nobody read until that morning. There is the interview itself, usually with two people in the room. There is the debrief, and the second debrief when the two people disagree. And there is the context switch on either side, which is the part that never appears in anybody's spreadsheet and which every engineer will tell you is the most expensive part of the whole thing.

So the question worth asking about a hiring process is not "how fast is it" but "how many senior hours does it burn per hire, and how many of those hours went to people who were never going to get an offer".

The recoverable part is the interviews that ended early in everyone's head. Not the ones where the decision was hard, and not the ones you lost. The ones where the first ten minutes decided it.

What changed in the last two years

Two things happened at once, and together they broke the filter that used to sit in front of the technical round.

The first is volume. Applying became close to free. In ZipRecruiter's 2026 AI Employer Report, just under half of surveyed employers said AI had increased application volume per role, which matches what anyone with an open engineering req has been looking at in their inbox.

The second is that the artifact you used to filter on stopped carrying information. A CV is now a document that a model can tailor to a job description in seconds, and candidates would be foolish not to do it. The same ZipRecruiter research found that a quarter of employers say they can almost always tell when AI was used in an application, with most of the rest saying they can sometimes tell. Read that the other way around: recruiters are spending attention on detecting a tool rather than on evaluating a person, and most of them are only sometimes right.

None of this means candidates are cheating. Developers use these tools at work every day. Stack Overflow's 2025 Developer Survey found that 84% of respondents use or plan to use AI tools, while 46% say they distrust the accuracy of the output, which is a fairly precise description of professional practice: use the thing, verify the thing. A candidate who uses a model to polish an application is doing what they will do at work.

The problem is not the tool. The problem is that the polished artifact no longer separates people, so the separation moved further down the funnel, into the technical interview, where it costs senior hours instead of recruiter minutes.

Moving the separation back up the funnel

If the CV no longer distinguishes, something else has to, and it has to be cheap for you and fair to the candidate.

The move is to ask a small number of real technical questions before the interview and read the answers. Not a quiz, not a timed test, not a recorded video. Four to six questions of the kind a senior engineer would actually ask, answered in writing, in the candidate's own time.

This is closer to established practice than it sounds. The most useful thing research has to say about hiring is not about any particular format but about structure: asking everyone the same questions and evaluating the answers against criteria decided in advance. In the reanalysis by Sackett and colleagues published in the Journal of Applied Psychology in 2022, structured interviews came out with the highest mean validity among the commonly used selection procedures, ahead of general cognitive ability tests, after correcting a statistical error that had inflated estimates for decades.

Two cautions before that becomes a claim it is not. The study is about structured interviews, not about written questionnaires, and validity coefficients in that literature describe averages across many studies, not a guarantee about your next hire. What carries over is the mechanism rather than the number: the same questions for everyone, criteria fixed before the answers arrive, and a written record of what was asked and what came back.

Written pre-screening inherits that mechanism almost for free. Everyone gets the same questions. The criteria exist before the first answer. The record is the answer itself, in the candidate's own words, still readable six weeks later when someone asks why this person and not that one.

What a good written question looks like

The format only pays off if the questions are good, and most screening questions are not. "Tell us about your experience with Kubernetes" measures how long someone is willing to write. It cannot be answered wrongly, which means it cannot be answered rightly either.

A good screening question has a wrong answer. Some shapes that work for engineering roles:

• A decision with a tradeoff. "You need to add full text search to an existing Postgres application. What would you consider before reaching for a separate search service, and what would make you reach for one anyway?" The wrong answer is a feature list. The right answer names constraints.
• A debugging narrative. "Describe a production issue you diagnosed where the first hypothesis was wrong. What made you abandon it?" Almost nobody can fake the texture of this. People who have done it write about the thing that did not fit.
• A decision they regret. "What is a technical decision you made that you would make differently now, and what changed your mind?" This one separates people who have owned consequences from people who have only had opinions.
• A reading of someone else's work. "Here is a short function. What would you raise in review, and what would you leave alone?" The second half of the question is the interesting half.
• A scoping question. "A stakeholder asks for a dashboard by Friday. What do you ask them before saying yes?" For anyone senior, how they narrow the problem is the job.

What all of these have in common: they are answerable in a few paragraphs by someone who has done the work, and they are painful to answer convincingly by someone who has not, even with help.

Keep the set small. Four to six questions, and say in the invitation roughly how long it should take. A questionnaire that takes an hour is not a questionnaire, it is unpaid homework, and the people most likely to abandon it are the currently employed seniors you wanted most.

The obvious objection

Somebody is reading this and thinking: they will just paste the questions into a chatbot.

Some will. Here is why the format survives it anyway.

A generated answer is a general answer. Ask about a tradeoff in the abstract and a model will produce four confident paragraphs. Ask what the candidate did, on what system, and what broke, and generated text starts to hedge, because the specifics were never in the prompt. The gap is visible to anyone who has done the work, and it is visible in a way that a polished CV is not.

A real answer gives you something to check. A name of a company, a product, a project, and details that only make sense there: a version, a number, an incident. Eneya reads the whole set for exactly that and reports it next to the score as High or Medium, with the fragments that gave the reading. It does not try to guess whether a model was involved, because a candidate writing with an assistant from their own notes produces true answers that no tool can tell from typed ones.

And that reading is a reason to ask, not a reason to reject. Medium means nothing named could be verified, not that the answers are false. Treating it as a verdict costs you good candidates and teaches you nothing. Treating it as an input to the interview costs you one follow-up question, and the follow-up is easy: ask them to walk through the specific thing they described. Anyone who lived it can. Anyone who did not will change the subject.

The deeper point is that written pre-screening does not have to be uncheatable. It has to be more informative than the CV it replaces, and it has to give the interviewer somewhere concrete to start. Both are low bars that the current process is failing.

What it does not replace

It does not replace the technical interview. It narrows who gets one.

It does not replace a work sample or a paid trial for roles where those are appropriate. If you can afford a real work sample and candidates will do it, that is a stronger signal than any conversation.

It does not tell you whether someone is good to work with, and it is not supposed to. That is what the interview is for, and now the interview has an extra fifteen minutes for it, because the technical ground was covered in writing and everyone can start from what the person actually wrote.

And it does not make the decision. In Eneya the score is arithmetic: the model assesses each answer against the competencies you defined, and the final number is computed from those assessments by fixed code, not by the model, so every report shows where the number came from. The verdict is advisory. The hiring decision is a field a human fills in, and the two are stored separately on purpose, so that a disagreement between them stays visible instead of being averaged away.

How this runs in practice

The shape of the week, concretely.

Build the questionnaire once per role, not per candidate. Write the four to six questions, and map each one to the competencies the role actually needs. Ten minutes of work that gets reused for everyone who applies to that opening, and reused again the next time you open it.

Send a private link. Each candidate gets their own. No account to create, nothing to install, answers written on any device in their own time. For someone employed full time, that alone is a better experience than finding a quiet room with decent lighting during working hours.

Read the report. A score, a note on each competency with the evidence it was based on, a reading on how the answers were produced, and a short list of follow-up questions worth asking this specific person. That last block is the part interviewers end up using most, because it turns a cold hour into a continuation of something already started.

Decide, then look. If you take one habit from this page, take this one: form your own view of the answers before you look at the score. Once you have seen a number, your judgement is no longer independent of it, and you will find evidence in the text for whatever the number said. This is not a criticism of scoring, it is how anchoring works on all of us. Eneya stores your decision separately from the model's verdict for exactly this reason.

The interview then starts from a shared artifact. Instead of "so, tell me about yourself", it is "you wrote that you dropped the queue and moved to Postgres advisory locks, walk me through what forced that". That is a different hour, and it is a better one for both sides.

Where this breaks down

Any honest description of a method includes the cases where it does not work. Here are the ones worth knowing before you try it.

Very small funnels. If three people applied, do not build a questionnaire. Talk to all three. Screening is a tool for reducing a pile, and below a certain size there is no pile.

Roles where the work is not explaining. For a role that is overwhelmingly hands on a keyboard with little communication, written answers measure something adjacent to the job rather than the job. It is still useful, but the weight you put on it should be smaller.

Candidates early in their careers. Scoring rewards demonstrated experience, and a junior with a strong portfolio and no employment history will score lower than their potential. If you are hiring juniors, read the answers rather than the number, and treat the number as a rough sort.

Questions that do not match the competencies. If the questions ask about one thing and the competency list describes another, no scoring can rescue that. Eneya will tell you the coverage was too thin to produce a number rather than inventing one, which is the correct behaviour and also a signal that the questionnaire needs work.

Teams that will not read. If the plan is to look only at the top-line number and never open an answer, this will fail, and it will fail in the direction of hiring people who write confidently. The score is a sort order. The evidence is the text.

Starting this week

If you want to try it on a live opening without reorganising anything:

1. Pick one role you are actively hiring for, with more applications than you have interview slots.
2. Write four questions of the kinds above, and map each one to a competency. Half an hour, once.
3. Send the link to everyone who is not an obvious no, including the ones you would normally have discarded on CV formatting. This is the cheap part, and it is where the surprises come from.
4. Read the answers and write down your own call before looking at any score.
5. After the technical interviews, look back at the cases where you and the score disagreed. Those are the only cases that teach you anything, and after five of them you will know how much weight the number deserves in your process.

A free account is enough to run one role end to end, and there is no annual contract to sign to find out whether this works for you. See how it works, or read the longer argument about written answers versus one-way video if the format itself is the question.