Questions to Ask Developers
Questions to ask a software developer, whether you are networking, weighing the career, sitting across an interview table, or relying on one to build something for you. The first three groups cover the job itself, how they work and the team around them. Career holds the questions to ask a software engineer about their career: the first year, the step to senior, management or staying hands-on. Junior Developers is for someone at the start, at a first-role interview or in an early one-to-one, and the last group is for anyone whose own project is in a developer's hands.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The Job
What are you working on at the moment?
Why ask it
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.
How did you get into development, and would you take that route now?
Why ask it
A degree, a bootcamp or teaching yourself each worked differently depending on the year and the local job market, so their own route is a record of one moment. Ask what they would do in its place if they were starting this year, and whether that holds where you live.
How much of your week is actually writing code?
Why ask it
It is often less than people outside the field expect, and it tends to shrink as a developer becomes more senior. Ask what fills the rest: reviews, meetings and looking into other people's problems are the usual answers.
Which languages and tools do you use most, and who chose them?
Why ask it
Every developer has the list ready, so the second half is where the conversation is. A stack they picked shows their taste, and one they inherited comes with a story about the company and what it would cost to change.
What is a project you are proud of, and which part of it was yours?
Why ask it
Pride tends to attach to something that was hard, so you get the difficult problem without asking for one. Pin down their own part, because 'we built it' can mean the whole design or a single screen.
What does a normal day look like, from the first thing you open?
Why ask it
Starting with the first thing they open keeps the answer concrete: a ticket board, a chat backlog, a build that failed overnight. If they say no two days match, have them walk through yesterday.
What is the oldest code you regularly touch, and who wrote it?
Why ask it
Much of professional programming is changing 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.
Which part of the job do you enjoy most, and which part would you hand off tomorrow?
Why ask it
Some developers are in it for the puzzle and some for seeing a thing get used, and the two are happy in different roles. The part they would give away, whether support tickets, estimates or release paperwork, is the part the job title hides.
Who decides what you build next, and how much say do you have?
Why ask it
On one team the work arrives as finished tickets, and on another it arrives as a problem to solve. Where this person sits between the two shapes the whole job, and a job advert rarely says.
Who uses what you build, and do you ever hear from them?
Why ask it
A developer who has watched a real person struggle with their screen builds differently from one who only reads tickets. If the users are other developers inside the company, find out whether that makes them easier or harder to please.
Craft
How do you debug something you have never seen before?
Why ask it
Look for a method rather than intuition: reproduce it, narrow it, read the actual error, check what changed most recently. 'I stare at it until it makes sense' works on a small program and stops working on a system too big to hold in one head.
What is the hardest bug you have ever tracked down?
Why ask it
Most developers have one ready, and it tends to end with days of searching and a one-line fix. The useful part is where the time went: reproducing it, a wrong first theory, or a log that pointed somewhere else. In an interview, ask what they check first now because of it.
What do you do when you are stuck for more than an hour?
Why ask it
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.
Before you write any code on a new piece of work, what happens first?
Why ask it
Reading what is already there, questioning the requirement, sketching the data, writing a short design note: the order they give is their real process. Follow up with a time the requirement turned out to be wrong, and when they found out.
What does your test setup look like, and do you trust it?
Why ask it
A test suite that fails at random gets ignored, and after that it protects nothing. Ask what happens when a test goes red late on a Friday: does somebody investigate, or does somebody run it again until it passes?
How long does it take from writing a line of code to it being live?
Why ask it
Minutes, days or a quarterly release: this one number often says more about daily working life than the tech stack does. If it is long, find out what makes it long and what the team has already tried.
How do you decide when something is good enough to ship?
Why ask it
Everyone draws this line somewhere between polishing forever and hoping for the best, and the right place depends on what a mistake costs. A payments system and a marketing page deserve different answers, so check which kind of work they have in mind.
What is the worst mistake you have shipped, and what changed afterwards?
Why ask it
These stories tend to come with a number attached: rows deleted, hours down, money moved. The change to the process afterwards is the thing to hear. If the only lesson is 'I was careless', nothing structural was fixed.
How do you estimate how long something will take, and how often are you right?
Why ask it
Estimating is the part of the job that people outside it assume is easy. Listen for work broken down until the unknown pieces show, and for a range instead of a single date. The story of the last estimate that was badly off is usually worth hearing.
How do you decide between rewriting something and patching it?
Why ask 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.
What counts as technical debt on your project, and who decides when it gets paid down?
Why ask it
Every codebase has shortcuts somebody meant to come back to. What varies is whether there is an agreed way to spend time on them or whether they only get fixed after they cause an outage. A written list with an owner is a healthy sign.
What makes code easy for the next person to read?
Why ask it
Expect naming, small pieces, and comments that say why instead of what. Then ask about a codebase written by someone else that they enjoyed working in, which is rarer than a principle and tells you more.
How do you use AI coding tools, and where do you not trust them?
Why ask it
Practice differs from team to team and is still shifting, so ask what they actually do with them this month. The places they will not rely on one, such as security-sensitive code or anything they could not review themselves, show how they think about being responsible for what ships.
Team
How do code reviews work on your team, and are they worth the time?
Why ask it
At their best, reviews are how a team teaches itself. At their worst they are a rubber stamp with a queue. How long a change normally waits for a reviewer is the detail that shows which kind this team has.
What do you do when a reviewer wants changes you think are wrong?
Why ask it
How someone takes criticism of their code is a standard interview topic, and this version asks for behaviour instead of a virtue. Good answers separate matters of taste, where they give way, from matters of correctness, where they bring evidence such as a failing test. Find out who breaks the tie if neither side moves.
How do you explain a technical problem to someone who does not write code?
Why ask it
A staple of developer interviews, and worth asking in conversation because you may be that someone. Have them do it on the spot with whatever they are working on this week. Reaching for a comparison and then checking you followed is the whole skill.
How do you work with designers and product managers, and where does it usually go wrong?
Why ask it
Most of the friction is at the handover: a design the data cannot support, or a requirement that moves once the work is half built. Notice whether they get involved early or wait for a finished spec, which is a personal habit as much as a company one.
Does your team work in sprints, and does the process help or get in the way?
Why ask it
Agile, Scrum and Kanban are practised differently from one company to the next, so ask what a week looks like: how work is planned, how long the daily meeting runs, what happens to whatever is unfinished on the last day. Whether they defend the process or roll their eyes shows who it was designed for.
Which technical decision at your company do you disagree with?
Why ask it
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.
When a deadline and doing the work properly pull apart, which one gives?
Why ask it
There is no clean answer, and that is the reason to ask. The considered ones cut scope before quality, say early that the date is at risk, and write down what was skipped. 'We just work late' describes the employer as much as the developer.
What broke most recently, and how did you find out about it?
Why ask 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.
Are you on call, and what is it actually like?
Why ask it
Not every developer carries a pager, and whether it is paid or given back as time off differs by employer and country. If they do, ask how many nights they were woken in the last rotation and whether anything got fixed as a result.
How does a new person get up to speed on your team?
Why ask it
Find out how long it takes a new hire to ship a first change and who they are allowed to interrupt. A written setup guide and a named buddy make a different first month from being told to read the code.
Do you work remotely, in an office, or a mix, and what does that change about the work?
Why ask it
The policy matters less than what moved because of it: whether design discussions happen in writing, how a junior gets unstuck with no desk to walk over to. Arrangements differ by employer and change often, so treat one person's setup as one data point.
Who is the best developer you have worked with, and what did they do differently?
Why ask it
It is rarely about typing speed. People describe someone who asked the question that made the task smaller, or wrote things down, or left the rest of the team better than they found it. The traits they pick are often the ones they are working on themselves.
Career
What do you wish you had known in your first year?
Why ask it
You get one specific regret instead of a list of tips: not asking for help sooner, staying too long on one team, hiding what they did not understand. Find out what finally taught them, since that is the bit you can borrow.
What do people early in their careers overestimate?
Why ask it
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 is a report on what they see going wrong around them.
What would you want to see from someone applying for a junior role on your team?
Why ask it
Developers who have sat on the hiring side remember what made them say yes: a small finished project, a clear account of a bug, honesty about gaps. Hiring loops differ from company to company, so ask what theirs involves.
What separates a senior developer from a junior one, apart from years?
Why ask it
The strong answers are about scope and judgement: being trusted with a vague problem, knowing what not to build, getting other people unstuck. If you hear only speed or a count of languages, ask how promotion is actually decided where they work.
Do you want to manage people one day or stay hands-on, and what does each path look like where you work?
Why ask it
Plenty of companies describe a technical track that runs alongside management, and it is real in some and nominal in others. Whether anyone senior there still writes code answers it better than the official career ladder.
How do you keep up, and how much of it turns out to matter?
Why ask it
Without the last part this is a question about newsletters. Experienced developers tend to name a handful of ideas that lasted and admit that much of what they read never got used, which is a relief if you are trying to learn everything at once.
Is there a language or tool you like that you cannot use at work?
Why ask it
Light enough for a first conversation. You hear what they enjoy, and then what stops them using it at work: nobody to hire who knows it, the systems already in place, or a decision taken before they arrived.
Do you write code outside work, and do you think it matters?
Why ask it
Side projects are sometimes read as proof of commitment, and plenty of good developers close the laptop at the end of the day. Their view tells you what the people around them expect, which matters if you have other things to fit a career around.
Has this job ever worn you out, and what did you change?
Why ask it
Save it for when the conversation is easy, and accept a short answer. When people do talk about a bad stretch, the cause is usually something specific, such as constant on-call or a project with no end, and so is what they changed.
What has changed about this job in the last few years?
Why ask it
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.
If I wanted to be useful on your team in six months, what would I need to learn?
Why ask it
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.
Junior Developers
What is the first thing you built that somebody else actually used?
Why ask it
A tutorial followed to the end and a tool a friend relied on are different experiences, and only the second teaches what happens when a real person does something unexpected. Small counts here: a script for a parent's shop is a fine answer.
Can you walk me through something you wrote and why it is built the way it is?
Why ask it
With a short work history, their own code is the fairest ground to meet on. Listen for reasons, even modest ones like 'this was the first way that worked', and for what they would change if they wrote it again this week.
How do you find your way around a codebase you did not write?
Why ask it
Much of a first job is reading, and courses mostly teach writing. Running the thing, following one request from the screen down to the database, or starting with the tests are all real methods. 'I have not had to yet' is an honest answer from a beginner and tells you what to teach in week one.
How do you check your own work before you ask someone else to look at it?
Why ask it
Running it, reading the change top to bottom as if a stranger wrote it, trying the input nobody expects: any of these is a habit worth having early. Sending work for review the moment it compiles spends a senior colleague's time, and it is easy to coach once it has been said aloud.
When did you last ask for help, and how long had you waited first?
Why ask it
New developers often wait too long because asking feels like admitting something. A lead learns how often to check in, and an interviewer learns whether the person can tell being slow from being stuck.
What kind of help works for you: a pointer, a worked example, or someone sitting beside you?
Why ask it
People new to the job often do not know they are allowed a preference. Asked early, it saves a mentor weeks of explaining in a way that does not land. The answer shifts as they get faster, so ask again after a few months.
What feedback on your code has stung, and was it right?
Why ask it
A first serious review can feel personal, so leave room for that part of the story. The second half is what matters: whether they went back, tested the point, and either changed their mind or kept their view with a reason.
Which part of the work is hardest for you at the moment?
Why ask it
Better in a one-to-one than in an interview, where it only draws a rehearsed weakness. Git, estimating, speaking up in a meeting and reading a stack trace each need a different kind of help, so ask about the last time it came up.
What did your degree, bootcamp or self-teaching leave out that you have had to pick up since?
Why ask it
Version control with other people, reading logs and working from a vague request are typical gaps, and which ones they have depends on the route they took. Their list is a map of what to pair on first.
What would you like to be trusted with a year from now that you are not trusted with today?
Why ask it
It gives a manager something to plan toward and shows an interviewer whether the candidate has thought past getting hired. Owning a small feature from request to release is a realistic answer. Note what they say and come back to it at the next review.
Your Project
What am I asking for that is harder than it looks?
Why ask it
Some features that sound small touch everything: search, permissions, anything that syncs or has to work offline. Asked before the estimate, this saves an argument after it, and the answer often comes with a cheaper version that gets you most of the way.
What is a realistic date for this, and what would move it?
Why ask it
Ask for the date they would bet on, not the one that holds only if nothing surprises anybody. The list of things that would move it is worth more than the date: a late decision from you, a third party's approval, a feature added in week three. Several of those are yours to prevent.
Which part of this are you least sure about?
Why ask it
More useful than asking whether the date is safe, since almost nobody answers no. The uncertain part is where a schedule slips, so follow with what they could try this week to find out, and whether the estimate already allows for it.
If we had to launch with half of this, which half would you keep?
Why ask it
Developers can see which features carry the product and which are costly decoration, and they are seldom asked. You do not have to agree. If their half is very different from yours, though, one of you has misunderstood what the thing is for.
What decision are we about to make that will be expensive to change later?
Why ask it
Most choices in software can be revisited and a few cannot, at least not cheaply: where the data lives, which platform, how accounts work. Hear which is which before you sign anything off.
Can you show me what you have so far, even if it is rough?
Why ask it
A working screen tells you more than a status report, and early is when changing your mind costs least. Say plainly that you know it is unfinished, or you will be shown nothing until it is polished.
How will you keep me updated, and how often?
Why ask it
Settle it before the first silence. A short written note each week, a standing call, or access to the board they work from will all do, as long as it is agreed. Say how quickly you will answer their questions too, because a developer waiting three days for a yes is three days added to the schedule.
What do you need from me that you are not getting?
Why ask it
For anyone a developer is waiting on, which covers most clients and managers at some point. Expect decisions, content, access to an account, or one person who is allowed to say yes. Whatever they name, put a date on it.
How would you like me to report a problem so you can fix it quickly?
Why ask it
'It is broken' costs a developer an hour of questions back. Most will want what you did, what you expected, what happened instead, and a screenshot or the exact error text. Agree the format once and every later bug gets cheaper.
What will this need from us once it is live?
Why ask it
Launch is not the end of the cost. There are updates, bills for hosting and outside services, and things that break when something they depend on changes. Ask who will be watching it and what a quiet month costs, since both depend on the project and the contract.
When this is finished, who holds the code, the logins and the domain?
Why ask it
Ask for access in your own name to the code repository, the hosting, the domain and any app store or payment accounts, so the project can carry on if the two of you part ways. Who legally owns the code depends on your contract and on the law where you are, so ask how your agreement handles it and get the answer in writing.
Talking with a developer about the work
Practical guidance for the conversation itself
Set the conversation up
Choose the group that fits why you are asking
The Job, Craft, Team and Career are for learning about the work from someone who does it, and most of those questions hold up across an interview table too. Junior Developers is for someone in a first role or applying for one. Your Project is for a developer who is building something for you. Five or six questions fill half an hour, so choose before you start.
Questions to ask a developer in an interview
When you are the one hiring, favour the questions that ask for something that happened: the hardest bug, the worst mistake shipped, the reviewer who wanted changes. A principle can be rehearsed, and the details of a real week mostly cannot. Put the same handful to every candidate so that you are comparing answers and not conversations.
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
- What did you try first, before the thing 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?
When the developer is building something for you
Ask at the start, and again halfway
What is hard, what is uncertain and what will be costly to undo are cheapest to hear before the work begins. Ask the same things again at the midpoint, because by then the developer knows far more about your project than either of you did on day one.
Trade 'is it done?' for 'what is left?'
A yes or no question about progress gets a yes. Asking what is left, and which piece is least certain, gets you a list you can plan around and a developer who does not feel chased.
Do not bargain an estimate down
An estimate you argued lower is still the same amount of work with a smaller number on it. If the figure is too high, change what is being built, which is what the question about launching with half is for.
Sort out access while everyone is on good terms
Ask early whose name the hosting, the domain and the code repository are in. It is a five-minute conversation at the start and a hard one after a falling-out. What a contract says about ownership differs from one agreement and one country to the next, so read yours.
Common mistakes
Asking which language to learn
It produces a debate rather than an answer, and many developers will tell you the choice matters less at the start than finishing something. Ask what they would have you build instead, which gets you something you can act on.
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 junior developers about things they have not met
Someone in a first role has rarely had the chance to run a live system or carry a pager, so questions about outages measure their luck more than their ability. The Junior Developers group sticks to what a beginner has had the chance to do: finish something, get stuck, read code they did not write, take a review.
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.