What can you ask a developer about their work without a technical background?

What can you ask a developer about their work without a technical background?

Everything around the code: who used the thing, what it replaced, what broke, what the review found, and what changed after it shipped. None of those topics require technical judgment to evaluate, because the answers are about events, people, and consequences rather than about code.

This works because of a division that runs through every technical claim. The technology half of a claim, whether the design was sound, whether the tool was the right one, belongs to the technical interview later in the process. The work half of the claim, what happened, to whom, and what it cost when it went wrong, belongs to anyone who was paying attention. A screen built on the work half produces answers that can be weighed on one scale: specificity. That scale needs no engineering background at all, and the rest of this lesson is about reading it. The wider frame around this lesson lives in the module guide, how to hold a technical conversation.

Why is the pipeline a good source of topics?

The release pipeline is a fixed sequence of events that every feature at every company passes through. Work gets saved as commits, gathered on a branch, opened as a pull request, examined in code review, merged, and deployed to production, where real users meet it. Each of those stages is something that actually happened to the candidate's work, which means each one is a place where a conversation can land.

Technology names offer no such footholds. A conversation that starts from a framework on the resume runs out of road in one exchange, because the follow-up territory is technical and the evaluator cannot go there. A conversation that starts from a pipeline stage stays in territory anyone can hold. Review is a human interaction with a memorable outcome. A deploy is an event with a date and an aftermath. Production is a place where things break in front of customers. The pipeline turns a technical career into a series of stories, and stories can be evaluated by anyone who has listened to people for a living.

The pipeline has one more useful property: it is universal. A developer at a bank and a developer at a five-person startup both commit, both get reviewed, both deploy, and both have watched something fail. Topics drawn from the pipeline work on every candidate for every req, which is more than can be said for topics drawn from any single technology.

Which topics need no technical judgment to evaluate?

Four families, and together they cover most of a career.

Users. Who actually used the thing, how many, and what they were doing before it existed. Every real piece of software displaced something: a spreadsheet, a manual process, an older system. A developer who built something real knows what it replaced and who complained when it changed.

Failures. What broke, when, and what it cost. Production software fails, and the field has built formal habits around failure: incidents, on-call rotations, postmortems, and rollbacks, all covered in why software is never done. A developer who carried responsibility for a live system has failure stories with dates on them, and tells them with a kind of rueful precision.

Review. What other engineers said about the work before it merged. Code review is the one stage of the pipeline where a developer's work gets judged by peers in writing, so memories of it are concrete: a reviewer who pushed back, a design that changed because of a comment, a standard the team held.

Consequences. What happened after the ship. Whether the thing is still running, what the team learned, what got built on top of it. Work that mattered has an afterlife, and the person who did it knows what that afterlife was.

Every answer in all four families gets weighed the same way: on how specific it is. That is the whole evaluation, and the next two sections describe each end of the scale.

What does a specific answer look like?

A specific answer names the system, the constraint, and the result. "The invoice service was timing out during the end-of-month batch run, so we moved the heavy queries to a nightly job, and the support tickets about it stopped." One sentence, and it contains a named system, a real constraint with a time attached, a decision, and a consequence measured in something a business cares about.

Specific answers share a texture. They contain nouns from the actual system rather than category words, numbers with context around them, and at least one moment where something went wrong or a tradeoff got made. They tend to include the word "I" at the decision points, because the person remembers which decisions were theirs. Smooth delivery is no part of the signal. Real memory is often halting, self-correcting, and full of "wait, that was the second version." Polish comes from rehearsal; texture comes from having been there.

None of this requires understanding the technology. Whether the nightly job was the right fix is a question for the technical interview. That the candidate can produce the constraint, the decision, and the result on demand is evidence available right now, and it is the same evidence regardless of what the technology was.

What does a vague answer look like?

A vague answer names the technology and stops. "We used Kafka for the event streaming layer, it was a pretty complex distributed system." Technology names, category words, and adjectives, with no named system underneath, no constraint, no number, and no moment where anything happened. The tell is what the sentence is built from: a specific answer is built from events, and a vague answer is built from labels.

A first vague answer is a normal opening position and carries little information on its own. People compress on a screen, nerves flatten detail, and a strong candidate often starts general out of politeness, unsure how much depth the listener wants. What carries information is the response to genuine interest. A person who did the work goes more specific each time the conversation leans in, because the detail is there to draw on. A person describing work they stood near stays at the same altitude no matter how much room they are given. The signal is the trajectory across the conversation rather than any single answer.

Vague-sounding answers have one more honest source: an impressive number delivered without its surroundings. "Cut load times by 80 percent" is neither specific nor vague until the baseline and the scale arrive, and numbers without denominators covers how to hear the difference.

Why do engineers open up about their own work?

Because building something is craftwork, and craftspeople like describing what they made to someone genuinely interested. Most of a developer's professional life passes without a non-engineer caring about the details of their work. A screen where the listener follows the story, holds the vocabulary, and wants to know what broke is a rare and pleasant event, and candidates respond to it.

This is where the earlier stations of this course pay off directly. A recruiter who has done the profile read arrives knowing what the candidate chose to pin and what their public work looks like, and interest anchored in something real reads as real. The concrete detail this lesson depends on does not have to be extracted. Offered a listener who can follow, the person who did the work supplies it on their own, which is what makes specificity such a reliable scale: it measures something the candidate is actively trying to give you.

The dynamic runs in both directions, which is worth knowing before the call. The candidate is reading the conversation too, and a screen that engages with their actual work tells them the company takes engineering seriously. What the candidate's own questions reveal has a lesson of its own.

What can be checked after the call?

Public work, first. Merged pull requests on open-source projects are permanent, attributed records that show the code, the review discussion, and the outcome. A published side project can be visited and used. A repository the candidate named on the call can be found and matched against how they described it. Talks and blog posts are timestamped and public. When a candidate mentions any of these, the claim has moved from testimony to evidence, and the check takes minutes.

Context claims, second. Company history, product launches, funding events, and public incident reports all live in the public record, so an answer that placed the candidate's work inside real events can be lined up against those events.

Absence of public work removes this check without replacing it with a negative one. Most professional code is private, and the empty GitHub lesson covers what a quiet profile does and does not mean. For those candidates, the call itself carries more weight, which is a reason to hold the specificity scale carefully rather than a mark against anyone. The candidates who do leave a public trail have handed over something valuable: a way to calibrate how their self-description maps to their actual work, and that calibration transfers to every claim they made that cannot be checked.