Questions to Ask Developers
Questions for a conversation with a working software developer, suited to networking, a mentoring call, or research into the career. Covers what the week actually contains, debugging, testing, on-call, and where the job has changed.
20 questions, each with the reason to ask it · includes a conversation guide
The questions
Open any question to see why it works.
- 1
What are you working on at the moment?
A better opener than asking about languages, because it gets a real answer instead of a resume line. It also tells you immediately whether they build features, maintain systems, or fight infrastructure, which are different jobs.
- 2
How did you get into it, and would you take that route now?
Self-taught, bootcamp, and degree routes each had different odds at different times, and developers are candid about which doors have since closed. Ask what they would substitute today.
- 3
How much of your week is actually writing code?
The number surprises most people outside the field, and it drops sharply with seniority. Ask what fills the rest, since reviews, meetings, and investigating other people's problems tend to make up more of it than expected.
- 4
What is the oldest code you regularly touch, and who wrote it?
Nearly all professional programming is editing something that already exists. Whether they can name the author, or whether that person left years ago, tells you how much of their work is archaeology.
- 5
What broke most recently, and how did you find out about it?
The detection route is the interesting part. Learning about an outage from a customer email is a different engineering culture from learning about it from an alert, and developers will say which they have.
- 6
How do you debug something you have never seen before?
Look for a method rather than intuition: reproduce it, narrow it, read the actual error, check what changed most recently. Someone who describes staring at code until it makes sense has not worked on a system too big to hold in their head.
- 7
What does your test setup look like, and do you trust it?
The second half is where the honesty lives. Teams with tests they do not trust behave exactly like teams with no tests, and most developers will admit which category they are in if you ask it this way.
- 8
How long does it take from writing a line of code to it being live?
This one number, minutes, days, or a quarterly release, predicts more about daily working life than the tech stack does. Ask what makes it that long and what has been tried.
- 9
What is the worst thing you have shipped?
Most developers have a story with a number attached: rows deleted, hours down, money moved. Listen for what changed afterwards in the process, since blaming themselves alone usually means nothing structural was fixed.
- 10
What do you do when you are stuck for more than an hour?
The answer is a habit, and habits transfer. Some have a rule about asking for help, some go for a walk, some write out the problem as if for someone else. All of it is more practical than general advice about persistence.
- 11
How do code reviews work on your team, and are they worth the time?
Reviews are either the main way a team teaches each other or a rubber stamp with a queue. Ask how long a review normally waits, which is the detail that reveals which one it is.
- 12
Which technical decision at your company do you disagree with?
This gets past the recruiting version of the team. Notice whether they can articulate the case for the decision they dislike, which is the difference between judgement and complaint.
- 13
What have you deliberately decided not to automate?
Restraint is a senior trait and it rarely comes up. Answers usually involve something rare enough, or risky enough, that a human check is cheaper than the automation plus its maintenance.
- 14
How do you decide between rewriting something and patching it?
Ask for a specific instance and how it turned out. Rewrites that were the right call and rewrites that consumed a year look identical at the start, and the people who have lived through both have real criteria.
- 15
Is there a language or tool you like that you cannot use at work?
Light to ask and it surfaces both what they enjoy and what constrains them, whether hiring, existing systems, or an architecture decision made before they arrived.
- 16
How do you keep up, and how much of it turns out to matter?
The second half stops this being a question about newsletters. Experienced developers usually name a small number of durable ideas and admit how much of what they read they never used.
- 17
What do people early in their careers overestimate?
Common answers involve language choice, algorithm puzzles, and code elegance, against underrated things like reading existing code, writing clearly, and asking about requirements. Their version tells you what they see going wrong around them.
- 18
Are you on call, and what is it actually like?
Ask how many nights they were woken in the last rotation and whether anything changed as a result. On-call quality is one of the biggest differences between two jobs with identical titles and salaries.
- 19
What has changed about this job in the last few years?
Better than asking for predictions, because it draws on what they have watched happen: tooling, hiring conditions, expectations about speed, how much of the work is reviewing rather than writing.
- 20
If I wanted to be useful on your team in six months, what would I need to learn?
This turns general advice into a specific list, and it is usually less about languages than about a domain, a deployment system, or reading unfamiliar code quickly. Ask what they would have you build first.
Talking with a developer about the work
Practical guidance for the conversation itself.
Set the conversation up
Set the conversation up
Ask about their work, not the industry
Broad questions about the state of software get broad answers anybody could give. Questions about what they touched this week get you the specifics you cannot read anywhere.
Do not pretend to know more than you do
Saying plainly that you do not know what a term means gets a better explanation and costs you nothing. Nodding along leads to an answer pitched at a level you cannot use.
Bring something concrete if you want feedback
A repository, a half-finished project, or a specific problem you are stuck on turns generic career advice into a useful review. Send it in advance if you are asking for time.
Follow-ups that get past the surface
Follow-ups that get past the surface
- What did you try before that worked?
- How long did that actually take, start to finish?
- Who else had to agree, and what did they want instead?
- What would you do differently if you started it today?
- Is that particular to your company, or common?
- What is the part of that you would not put on a slide?
Common mistakes
Common mistakes
Asking which language to learn
It produces a debate rather than an answer, and the honest reply is that it barely matters at the start. Ask what they would have you build instead, which gets you something actionable.
Treating one developer's setup as the industry
Practices differ enormously between a startup, a bank, and a consultancy. If you are weighing the career, talk to people in at least two of those settings before drawing conclusions.
Asking for a job in the middle
If you want a referral, ask for it directly at the end. Steering the conversation there gradually is transparent and it costs you the honest answers you were getting.
Skipping the boring questions
Deployment time, on-call load, and how long reviews wait sound dull and describe most of the daily experience. They are the questions that distinguish two otherwise identical jobs.