How do you hold a technical conversation with an engineer?

How do you hold a technical conversation with an engineer?

You hold a technical conversation by getting the engineer talking concretely about something they built, then evaluating what you hear on its shape rather than its correctness. The shape of an answer is checkable without a technical background: whether it is specific, whether it contains decisions, and whether the person describes their own work or stands near someone else's. Correctness would require an engineer to judge. Shape requires attention, and attention is a transferable skill.

By this point in the path the hard part is behind you. Reading the profile gave you the vocabulary of the work itself, and the intake gave you the role's real requirements. The call is where both get used live, with no time to look anything up. That is why this station comes ninth. A conversation held on borrowed keywords collapses at the first follow-up, and a conversation held on a real model of how software reaches customers keeps going, because every step of that pipeline is something the candidate lived through and can describe.

This guide is the map of the module. The lessons under it each take one piece: where topics come from, how to pressure-test the three big resume verbs, what a number needs before it means anything, what the candidate's own questions reveal, which statements are real fit data, and how the same method handles the AI claims that now appear on every resume.

What can you evaluate without technical judgment?

Specificity. It is the single most useful measurement available on a call, and it needs no opinion about the technology to apply. A person who did the work names the system, the constraint, and the result. A person who worked near it names the technology and stops.

The difference is audible. "We used Postgres" is a fact about a tech stack. "The orders table was the bottleneck, so I moved the reporting queries to a read replica, and the checkout timeouts stopped" is a story with a system in it, a constraint, an action, and a consequence. You can hear the second one without knowing what a read replica is. The nouns are concrete, there is a number of steps, and something happened at the end that a user or a business would notice.

The full topic list comes from the release pipeline, and the first lesson in this module walks through it: who used the thing, what it replaced, what broke, what the code review caught, and what happened after it reached production. Every one of those produces answers you can evaluate on specificity. Engineers also tend to enjoy this ground. Describing something they built to a person paying genuine attention is one of the more pleasant parts of a screen for them, and the concrete detail comes out on its own.

Some of what you hear can be verified afterward. Public work leaves a record: merged pull requests, published projects, talks, and posts. The live call and the public record check each other.

How do you test architected, owned, and led?

Each of the three big resume verbs has definite content, and each one can be tested by the shape of what comes back. The probing lesson covers the method in full; this is the summary.

To architect a system means making its structural decisions: what the parts are, how they talk to each other, where the data lives, and what got traded away. So a real architecture claim arrives carrying decisions, and above all it carries rejected alternatives. A decision with no alternatives behind it was never a decision. Someone who chose an approach can say what they turned down and which constraint settled it. Someone who can describe the system fluently while naming zero choices is describing a system they worked inside, which is honest experience of a different scope.

The pronouns carry information of their own. A person recounting their own decisions naturally says "I chose" and "I decided", and gives the reason. Consistent "we" through an entire account, with no personal decision anywhere in it, usually marks proximity. Neither pattern needs interrupting. It shows up on its own when the account gets specific.

"Owned it end to end" has the most concrete content of the three, because ownership across the pipeline includes designing the thing, getting it reviewed, releasing it, watching it in production, and answering for it when it broke. Each of those is a distinct memory when the claim is true. "Led the project" is the loosest of the three: it can mean leading the technical direction, managing the people, or being present while someone else did both. The three are different claims, separated by which decisions the person made, and what senior means at this company decides which one the role needs.

What is missing from an impressive number?

Three things: a baseline, a scale, and a consequence. "Reduced latency by 40%" contains none of them, and without them the percentage describes nothing. The numbers lesson turns this into a reusable test; the outline fits in a paragraph.

The baseline is the starting measurement. A 40% improvement from four seconds and a 40% improvement from forty milliseconds are different pieces of work. The scale is the traffic the number applied to, which is what separates an improvement from an impact: the same fix on a page nobody visits and on a checkout path carrying millions of requests are different achievements. The consequence is who noticed. Customers, the cloud bill, and an internal dashboard are three different audiences, in descending order of weight.

The useful property of the test is who can pass it. A person who did the work has these numbers, because they measured before and after and watched who felt it. A person repeating a line from their own performance review does not. This means the test requires no idea of what good latency looks like, and it works unchanged on cost savings, uptime improvements, and every other metric that will ever appear on a resume. It pairs with the resume-side version you already know from shipped, owned, and migrated: the same verbs, now with a person attached who can be measured on specificity.

What do a candidate's questions tell you?

They are health checks on the pipeline the candidate would live in, and they carry as much information as anything the candidate says about their past. The questions lesson decodes the common ones.

A question about how often the team deploys is a question about engineering health. Teams that ship many times a day usually have strong automated testing and small, low-risk changes. Teams that ship quarterly usually have large, tense releases. A question about code review is a question about the quality bar and whether people help each other. A question about on-call is a question about nights and weekends, and about whether the team gets time to fix the causes of alerts or only to silence them. "Engineering culture", when a candidate uses the phrase, usually bundles three things: autonomy, the quality bar, and whether failure gets treated as a system problem.

A candidate raising these has usually lived somewhere the answers were bad, which makes the questions experience speaking. The pattern connects back to why developers leave jobs: the conditions these questions probe are the same conditions that drive the leaving. When the client's honest answers are weak, that is information worth having early, because the candidate will discover the truth within a month of starting.

Which candidate statements are worth attention?

The ones that state what the person needs from a role. Statements about previous employers mostly carry less than they seem to, and the flags lesson sorts the common ones into each pile.

The statements that predict are the fit statements. "I am a builder, more than a maintainer" matches greenfield work and mismatches a role whose whole job is a long-lived system, and it is better to learn that on the first call. A stated preference for boring, proven technology usually reflects having been responsible when something novel broke at a bad time, which makes it one of the more reliable seniority signals available. "I do not want CRUD work" describes what the person needs: problems with unsolved parts in them.

Background shapes the reading too. A large company and a startup build different engineers, with different scars, and each background raises one specific concern the other answers. The big tech versus startup lesson covers both directions, and in both cases the resolving evidence lives in the work record rather than in the company names.

How do you test an AI claim?

With the same method, pointed at the claim every resume now carries. The first move is a sort you already have from builds versus uses: building AI systems and using AI tools are different kinds of work, held by different pools of people, and an "AI experience" line belongs to one side or the other before anything else about it matters.

After the sort, specificity does the rest. Real work on the using side comes with which model, what it was built for, what it got wrong, and how the team measured whether it improved. A candidate who mentions evals has worked past the demo stage, because evals are what a team builds once the output has to be reliable rather than impressive. Prompt engineering is a real line when a shipped system and measurements stand behind it. Public evidence exists here too, in the same way it does for everything else in this module: Hugging Face hosts models and datasets in the open, so activity there is checkable the way a GitHub profile is. The AI claims lesson runs the whole method end to end.

That closes the loop on the call itself. Shape over correctness, decisions over descriptions, anchored numbers over impressive ones, and the candidate's questions read as carefully as their answers. The last station on the path takes what the call produced and turns it into the decision: two strong candidates, one seat, and a ranking you can defend upward.