Questions to Ask a Programmer
Questions for a working programmer, in an interview or on a team you are about to join, about how they debug unfamiliar code, what they test, how they ship risky changes, and how they treat the people who read their code next.
The questions
Open any question for the note
When you inherit code you have never seen, what do you do in the first hour?
Why ask it
Watch whether they run the thing first or read it top to bottom. Getting it running and tracing one real behavior is what separates people who orient in a morning from people who read for a day and still guess.
How do you decide between fixing something properly and shipping a workaround?
Why ask it
Good answers name the factors out loud: who is affected right now, how reversible the shortcut is, whether anyone will realistically come back to it. Anyone who says they always do it properly has not shipped against a real deadline.
Which tests would have to pass before you were comfortable deploying on a Friday afternoon?
Why ask it
This separates what they trust from what they write for coverage numbers. Naming a small set, usually a few end-to-end paths plus a verified rollback, is a stronger signal than any coverage percentage.
Tell me about an outage you were part of. What changed afterwards?
Why ask it
The change is the signal: an alert that would have caught it, a test, a removed footgun, a safer default. If the answer is that everyone was more careful afterwards, the same outage is still sitting there waiting.
How do you decide what a function should be called and where it should end?
Why ask it
A small question that sorts people quickly. Listen for whether they name things after what the code does for the caller or after how it works inside, because the second kind goes stale the moment the implementation changes.
How do you roll out a change that could break something?
Why ask it
Flags, a percentage rollout, a dark launch, running old and new side by side. The revealing follow-up is who removed the flag afterwards, since forgotten flags quietly become a category of bug on their own.
When do you add a dependency, and when do you write it yourself?
Why ask it
Look for costs beyond the install: transitive updates, security advisories, the day the maintainer walks away. Both extremes, a library for everything and hand-rolling everything, hand the team a bill later.
After you deploy, which numbers do you actually look at?
Why ask it
Strong answers include a latency percentile rather than an average, an error rate, and one business number that would notice a silent failure. CPU and memory alone usually means they have never owned something in production.
What keeps security and privacy from becoming something you deal with later?
Why ask it
Practical answers are about defaults: parameterised queries, no secrets in the repository, least privilege, keeping personal data out of logs. If the whole answer is the name of a security team, it is someone else's job in their mind.
What makes a code review useful to you, on both sides of it?
Why ask it
Ask what they do with a comment they disagree with. Conceding everything and escalating everything both cost the team; the workable answer involves a short conversation away from the thread and the decision written down.
When have you argued for deleting code?
Why ask it
Deleting takes more nerve than adding, and the good version is specific: a feature nobody used, a config branch no one could explain. People who cannot remember removing anything tend to work in systems that only grow.
What is a design decision you regret, and what would you do instead now?
Why ask it
The replacement is the point. Regret with no alternative attached is just self-criticism, while regret with a concrete different design means they went back and thought it through.
How do you work out why something is slow?
Why ask it
The right instinct is to measure before touching anything: a profile, a trace, timings either side of the suspect call. Anyone who opens by naming the likely culprit is guessing, and guesses about performance are wrong more often than not.
How is your local setup put together, and what part of it still annoys you?
Why ask it
This measures the friction between having an idea and seeing it run. The useful detail is what they automated versus what they still do by hand every morning, which is a fair proxy for how they treat repeated work generally.
What documentation do you wish existed on the teams you have worked on?
Why ask it
Answers are usually specific and unglamorous: runbooks, why a decision was made, how to get a working environment. Follow up on whether they wrote any of it, which distinguishes a complaint from a habit.
How do you handle accessibility, or users in other languages, while you build rather than afterwards?
Why ask it
Concrete markers exist: keyboard navigation, labeled inputs, no text baked into images, no sentences assembled by string concatenation. If it only ever arrives as an audit, it gets retrofitted at several times the cost.
How do you make a breaking change to something other teams depend on?
Why ask it
The sequence is the answer: announce it, run both versions, measure who is still calling the old one, then remove it. Skipping the measurement step is how migrations end up half done for years.
How do you keep work coherent when it is split across several weeks and several people?
Why ask it
Listen for merging often, an agreed interface early, and a written plan someone else could pick up. A long-lived branch merged at the end is the pattern behind most of the worst weeks people can describe.
What have you learned recently, and what made you go and learn it?
Why ask it
The trigger matters more than the topic. Learning driven by a problem they actually hit tends to show up in their work; learning driven by novelty usually stops at a tutorial.
What is a small tool you have written just for yourself?
Why ask it
These reveal what they find repetitive and whether they fix it or put up with it. It is also the least guarded question in a technical conversation, which is why it often produces the most candid few minutes.
Running the conversation
Practical guidance for the conversation itself
A workable hour
- Five minutes: what they are working on now, in their own words, with no interruptions.
- Fifteen minutes: one system they know well. Ask for a diagram on the whiteboard and interrupt with "what happens if this part goes down?"
- Fifteen minutes: an incident or a bug they chased. Follow the debugging steps in order rather than accepting the summary.
- Fifteen minutes: a tradeoff with no clean answer, drawn from your codebase. You are listening for the questions they ask before answering.
- Ten minutes: their questions for you. What they ask about reveals what they have been burned by before.
What the strong answers have in common
- They involve a specific system, a date, and a consequence, not a general philosophy.
- They mention measurement before action: a profile, a log line, a metric that moved.
- They give credit and blame accurately, including their own part in a mess.
- They name a downside of their own preferred approach without being prompted.
- They say "I do not know" and then describe how they would find out.
Mistakes interviewers make here
- Grading on familiarity with your stack. Someone who has debugged hard problems in another language will learn your syntax in two weeks.
- Mistaking fluency for skill. Confident, well-rehearsed answers about best practice can sit on top of very little delivery.
- Rewarding the person who fights fires over the person whose systems do not catch fire. Ask what they changed so the problem could not recur.
- Letting a single puzzle decide the outcome. One bad half hour on an unfamiliar problem predicts less than a coherent story about work they finished.
- Filling silence. The pause after a hard question is usually where the honest answer comes from.
If you are not a programmer yourself
You can judge most of this without following the technical detail. Ask them to explain one decision as though to a new teammate, and notice whether they simplify without becoming vague. Ask what it would cost to change later, and whether anyone disagreed with them at the time. Ask who else was involved and what those people did. Answers that never mention another human being, a cost, or a user are worth a second opinion from someone technical, and so is any answer that leaves you unable to repeat the gist of it afterwards.