Technical screening questions that verify real skills

You do not need an engineering background to screen engineers credibly. You need questions where the shape of the answer reveals depth: whether the candidate names trade-offs unprompted, says when a tool buys you nothing, and reaches for specific incidents instead of textbook definitions. Those patterns are recognizable without understanding a line of code, and they are far harder to fake than trivia. This playbook shows how to build such questions, with worked examples for a Python and FastAPI role.

Why screen for the shape of the answer, not the content?

Because you cannot grade the content, and you do not have to. Whether an explanation of async is technically precise is the hiring manager’s call in the technical interview. What you can grade is structure, and structure is where experience hides. People who have run a tool in production talk in trade-offs, exceptions and incidents. People who have only read about it talk in definitions and benefits. The two are as distinguishable as a travel story from a brochure, and neither requires you to have visited the place.

This is the same role literacy that lets a recruiter tell a data engineer from a data scientist without having done either job: you learn the language map, not the territory.

It also explains why gotcha trivia fails. Asking what an acronym stands for tests recall, which weak candidates memorize from interview lists and strong engineers sometimes flub. And when the answer comes back, all you can do is mark it right or wrong, which adds nothing the CV did not already claim. A question about trade-offs returns an answer with texture you can actually read.

What does a deep answer sound like?

Across any technical topic, the same five markers separate lived experience from study notes:

Signal	Deep answer	Shallow answer
Opening move	Starts with “it depends” and names what it depends on	Jumps straight to a definition
Trade-offs	Names a cost or downside unprompted	Lists only benefits
Evidence	A specific incident, codebase or version	Textbook generalities
Boundaries	Says when the tool buys you nothing	Implies it always helps
Language	Plain words, unpacks jargon when it appears	Chains buzzwords without explaining them

None of these require technical knowledge to spot. A candidate can fake one marker; faking all five across three questions is close to impossible without the experience that makes faking unnecessary.

Worked example: what does async buy you?

Ask it like this: “This team runs FastAPI with async endpoints. In your own words, what does async buy them, and where does it buy them nothing?”

What good sounds like: the answer is about waiting. Async helps when the server spends most of its time waiting on slow things outside itself, like database queries or calls to other services. Instead of one request blocking everything while it waits, the server handles other requests in the meantime, so the same hardware serves more traffic. The depth marker is the second half of the question: an experienced candidate will say async buys you nothing for heavy computation, because then the processor is busy rather than waiting. Many will volunteer the classic failure on their own: one ordinary blocking call inside an async endpoint quietly stalls every other request sharing it. Phrases like “blocking the event loop” or “you need async database drivers all the way down” are good signs even if you cannot verify the details.

What shallow sounds like: “async makes the API faster,” with no waiting story and no case where it does not help. A speed claim without a mechanism is a memorized benefit.

Worked example: how do you use dependency injection?

Ask it like this: “FastAPI leans on dependency injection. What have you used it for, and what would your code look like without it?”

What good sounds like: concrete plumbing. Typical real answers mention getting the currently logged-in user, opening a database connection per request, or checking permissions, declared once and reused everywhere. The “without it” half is the depth test: they should describe the same setup copy-pasted into every endpoint, and the pain of testing it. The strongest tell is testing: someone who has genuinely tested a FastAPI app will mention swapping a dependency out, for example replacing the real database with a test one, because that is where the pattern pays off and they felt it personally.

What shallow sounds like: a recital that “Depends lets you declare what a function needs,” then silence on the counterfactual. A definition with no without-it story is documentation, not experience.

Worked example: what does Pydantic catch, and what does it miss?

Ask it like this: “What does Pydantic catch for you, and what does it not catch?”

What good sounds like: it guards the boundary. Data coming into the API is checked for shape and type, so an age is a number, an email looks like an email, required fields are present, and bad requests are rejected with clear errors before any real code runs. Many will add that the same models generate the interactive API documentation for free. The depth lives in the second half: Pydantic does not know your business. A request can be perfectly valid in shape and still wrong, like a start date after the end date or a discount code that expired; those rules you write yourself. Candidates who mention writing custom validators, or who distinguish between versions they have used, are speaking from contact with the tool.

What shallow sounds like: “it validates the data.” Validates what, against what, and where it stops are the entire question.

How do you run this in a 30-minute screen?

Three habits turn these questions into a repeatable screen:

• Source the questions at intake. Ask the hiring manager for one shape question per must-have skill, plus a sentence on what a good answer sounds like. Ten minutes of their time buys you a calibrated screen for the whole pipeline.
• One follow-up, always the same. “When did that bite you?” works on any answer and is the cheapest depth probe in existence. Brochure knowledge has no scars.
• Write down exact words. You grade shape; the hiring manager grades content, and they can only do that from verbatim quotes, not your paraphrase.

Know what the screen is for. It filters out confident shallowness; it does not rank deep candidates against each other, which is later-stage work. Your notes land next to what the system already measured from the CV, and how those scores are computed and what they cannot tell you is worth understanding before you weigh the two. The listening skill transfers, too: behavioral questions about pressure and conflict reward exactly the same ear for specifics over rehearsed generalities.

One note on where tooling fits. In Recruitifly, Fly parses CVs, scores candidates against the job and builds the shortlist, so your thirty minutes of shape questions go to people already worth them; your verbatim notes then travel with the candidate, and anything Fly proposes afterwards, a stage move or a follow-up draft, waits for your confirmation, because the judgment in that call was yours. We are in private beta; if screening for roles you have never coded in is part of your week, talk to us.