The questions you ask are part of the assessment
Almost every interview ends with some version of "do you have any questions for us," and how you answer it carries real weight. Good questions show that you have thought about the role, that you can reason about a business, and that you are evaluating the fit rather than just hoping to be chosen. Weak questions, or none at all, leave a flat final impression even after a strong conversation.
There are two jobs your questions do at once. They signal judgement to the interviewer, and they get you the information you need to decide whether to take the role if it is offered. The best questions do both. This guide gives you patterns rather than a script to memorise, because a question read off a list sounds exactly like a question read off a list.
It helps to understand why this moment matters to the interviewer. By the time you reach the questions, they have a rough verdict forming, but it is rarely settled. A sharp question can move a borderline candidate into a clear yes, because it shows curiosity and ownership that do not appear on a CV. A flat "no, I think you covered everything" can quietly confirm a doubt they were already nursing. You are never neutral in this moment, so treat it as the last few minutes of the interview, not the wind-down after it.
The questions you ask reveal what you think the job actually is. An interviewer can learn more about your seniority from one well-aimed question than from ten polished answers.
What good questions look like, and what weak ones look like
Before the patterns, it helps to have a clear picture of the difference. The gap between a strong and a weak question is rarely about cleverness. It is about specificity, about who you aim it at, and about whether the answer could change your decision.
| Weak question | Why it falls flat | Stronger version |
|---|---|---|
| What is the tech stack? | Answerable from the job ad, signals no preparation | I saw you run a mix of Go services and a Rails monolith. Which side does new product work tend to land on? |
| What is the culture like? | Too broad to answer honestly, invites a slogan | When two engineers disagree on an approach and neither will budge, how does that usually get resolved? |
| Is there room to grow? | Vague, puts the interviewer on the spot | What did the last person promoted on this team do in the six months before that promotion? |
| Do you have good work-life balance? | Yes-or-no, easy to deflect | When was the last time the team had to work evenings or weekends, and what caused it? |
The pattern is consistent. Strong questions are concrete, they are tied to something real, and the honest answer carries information you could act on. Weak questions ask for a brochure, and a brochure is what you will get.
Match the question to the person
A common mistake is asking everyone the same questions. Different interviewers can answer different things well, and tailoring shows you understand who you are talking to. Find out in advance who you will meet, recruiters will usually tell you, and aim a couple of questions at each person's actual vantage point. If you are not told the panel in advance, it is entirely reasonable to email the recruiter and ask who you will be speaking with and in what capacity.
The recruiter
Recruiters are best on process, logistics, and the shape of the role rather than deep technical detail. They also have a wider view than anyone else of how this role compares to others they are filling, so they are the right person for calibration questions. Use them for:
- What the rest of the process looks like and the rough timeline.
- How the team is structured and where this role sits in it.
- What they think makes someone successful in this role.
- Why the position is open, whether it is a backfill or a new headcount.
- What the salary band is for the level, so you can decide early whether the range works.
Recruiters are also the safe place for the practical questions you should not raise with the panel. Compensation, start dates, remote and hybrid policy, visa support, and equity basics all belong here. Asking them early saves everyone time and signals that you are treating the process seriously rather than naively. See understanding total compensation before this conversation so you can interpret the band they give you.
The hiring manager
This is the person you would likely report to, and the most important conversation for understanding your day-to-day. Their answers tell you more about your future quality of life than anyone else's. Worthwhile directions:
- What the first ninety days would look like for whoever takes this role.
- How they would describe their management style and how they give feedback.
- What success at six months and a year would actually look like, in concrete terms.
- What the biggest challenge facing the team is right now.
- How they protect the team from interruptions and shifting priorities.
A particularly useful question here is to ask the manager to describe their best current report and what makes that person effective. The answer tells you what this manager actually values, which may differ from the official job description, and it lets you judge whether those are traits you have or want to build.
Peers and future teammates
Peer interviewers can tell you what the work really feels like, away from the official line. They are usually the most candid people on the panel because they are not selling, and they remember what it was like to join. Ask about:
- What a normal week looks like, and what tends to eat the time.
- What they enjoy about the team and what they find frustrating.
- How decisions get made and how disagreements are resolved.
- What they wish they had known before they joined.
- What the on-call rotation or release process feels like in practice.
The "what do you wish you had known" question is one of the most reliable in the whole interview. It gives a teammate a graceful way to mention a real downside without sounding disloyal, and the hesitation before the answer is itself informative.
Senior leaders
If you meet a founder or a senior leader, they are best on direction and strategy. They are usually short on time and they have heard every generic question, so aim higher and be specific:
- Where they see the biggest opportunity and the biggest risk over the next year.
- How this team's work connects to the company's priorities.
- How they think the company will change as it grows.
- What they would want a new senior hire to push back on.
Avoid asking a leader something an engineer could answer just as well. The implicit question they are evaluating is whether you can think at the altitude they operate at, so a question about strategy or trade-offs lands far better than one about the build pipeline.
Make your research visible
The strongest questions grow directly out of homework you have done. If you used the product, read an engineering blog post, or noticed something in the news, turn it into a specific question. This is the kind of thing no generic candidate can produce, and it proves you did the work.
For example, rather than "what is the tech stack," which you could ask anyone, try something rooted in what you found:
I read your post about moving to a monorepo last year. How has that played out, and would you make the same call again?
Or, from using the product:
I tried the onboarding and the import step was smooth, but I noticed there is no undo on a bulk action. How does the team think about destructive operations like that?
Questions like these turn the end of an interview into a real conversation between future colleagues rather than a formality. They also do something subtle in your favour. By referencing a specific decision the company made, you invite the interviewer to reflect openly, and people remember conversations where they got to think out loud far more warmly than ones where they recited facts.
A reliable way to build these is to spend twenty minutes before the interview collecting raw material. Read the recent posts on the engineering blog, skim the changelog, look at product reviews, and check recent announcements. For every interesting thing you find, write a single question that starts from it. You will rarely use more than two, but having six in your pocket means you can always reach for the one that fits. The companion guide on how to research a company before the interview covers where to look in depth.
Questions that help you decide
Remember that you are also gathering information to make your own choice. Some of the most valuable questions are the ones that surface how the company actually operates, asked plainly and without an edge.
Useful areas to probe:
- How performance is measured and how growth and promotion work in practice.
- What the on-call or support expectations are, if relevant to the role.
- How the team handles work-life balance during crunch periods.
- Why the last person in this role left, or why a new role was created.
- What the company is genuinely working to improve right now.
- How decisions get reversed when they turn out to be wrong.
Asking what a company is trying to improve is quietly revealing. A healthy organisation can name a real weakness and what it is doing about it. An answer that there are no problems at all tells you something too. The same goes for asking how a bad decision gets unwound. Teams that handle this well describe a calm process. Teams that handle it badly tend to go quiet or describe blame.
If you want to dig deeper into the signals that should give you pause, the guide on interview red flags worth noticing covers the warning signs that often hide behind polished answers.
A worked example: turning a flat question into a sharp one
It helps to see the full arc of a real exchange. Imagine you are interviewing for a backend role and you have twenty minutes left with the hiring manager. Here is the weak version of the closing exchange:
You: Do you have any questions for us? Candidate: Yeah, what is the team like to work with? Manager: Oh, they are great, really collaborative, smart people. You would enjoy it. Candidate: Cool, sounds good. I think that is all I had.
Nothing wrong happened, but nothing happened at all. The candidate learned nothing they could act on and left no impression. Now the same minutes, used well:
Candidate: You mentioned earlier that the team is splitting the monolith into services. What forced that decision, and what has been the hardest part so far? Manager: Honestly, deploys. We were at the point where one bad change could block everyone for a day. The hard part has been data ownership, deciding which service owns which tables. Candidate: That makes sense. When you draw a boundary and later realise it was in the wrong place, how does the team handle walking it back? Manager: Good question. We have done it twice. We try to treat it as expected rather than a failure, so we write a short note on what we learned and move on. Candidate: That is reassuring, the fact that it is treated as normal. Last one. If I joined, what would make you glad in six months that you hired me rather than the next candidate?
In the second version the candidate learned the team's real pain point, confirmed that the culture handles mistakes maturely, and ended on a question that quietly invites the manager to picture them in the role. The questions built on each other and on what was already said. That is the texture you cannot get from a memorised list.
A simple framework for building your questions
When you are short on time, a structure beats inspiration. Use a four-part frame and fill one slot from each.
- One from your research. Something specific you found that no other candidate would ask. This proves preparation.
- One about the work. A question about the day-to-day, the codebase, the process, or how the team actually spends its time. This proves you care about doing the job, not just getting it.
- One that helps you decide. A plain question about growth, expectations, or how the team handles pressure. This is for you, and asking it openly signals confidence.
- One raised live. A follow-up on something said during the interview. This proves you were listening and can think on your feet.
Carry two options for each slot so you are never stranded if the conversation already covered one. Across a full loop of four or five interviewers you will reuse the structure but rotate the specifics, aiming the research and work questions at the people best placed to answer them.
How seniority and role change the questions
The four-part frame holds at every level, but the centre of gravity shifts. Calibrate to the seniority you are interviewing for, because a question that sounds curious from a junior can sound naive from a principal.
| Level | Where to aim | Example |
|---|---|---|
| Early career | Learning, mentorship, ramp-up | How does the team help new engineers get productive, and who would I learn the most from? |
| Mid level | Ownership, scope, how work is chosen | How is work assigned versus chosen, and how much say would I have over what I pick up? |
| Senior | Influence, technical direction, trade-offs | Where does the team have the most technical debt, and how much freedom would I have to address it? |
| Staff and above | Strategy, organisational health, leverage | What is the most important problem you would want me focused on, and what is in the way of solving it? |
Role changes the emphasis too. For a product engineer position, lean towards how engineering and product decide what to build and how close engineers sit to users. For a backend or platform role, the work questions can go deeper into systems, reliability, and on-call. As an engineering manager, the most revealing questions are about how the team is performing and how much latitude you would have over hiring and process.
How to ask well
Delivery matters as much as content. A few habits keep your questions landing as curiosity rather than interrogation.
- Ask open questions that invite a real answer, not yes-or-no questions.
- Listen to the reply and follow up on it, rather than racing to your next prepared item.
- Keep two or three ready per interviewer and adapt to what the conversation has already covered.
- Read the time. If a session is running short, pick your best one or two questions rather than forcing all of them.
- Keep each question to one clear ask. Stacking three questions into one sentence forces the interviewer to pick which to answer, and they usually pick the easiest.
It is also fine, and often good, to ask a question that arose during the interview itself. "Earlier you mentioned the team is rebuilding the billing system. What is driving that?" shows you were paying attention. The best closing questions in any loop are usually the ones you could not have written down beforehand, because they prove you were genuinely in the conversation.
One more habit worth building. When an interviewer gives an answer that surprises you, say so and ask a gentle follow-up rather than nodding along. "That is interesting, I would have expected the opposite, what drove that?" turns a one-way answer into a real exchange and shows that you process information rather than just collect it.
What to avoid
A few patterns reliably weaken the impression. Asking only about salary, holidays, and perks before you have shown any interest in the work reads as transactional. Asking questions whose answers are plainly on the company website signals you did no preparation. And asking nothing at all suggests either disinterest or that you did not engage with the conversation. Save the detailed compensation and benefits discussion for the recruiter or the offer stage, where it belongs, and use your interview questions to understand the role and the team.
Two subtler mistakes are worth naming. The first is the disguised statement, where the candidate uses the question slot to show off rather than to learn. "Do you use event sourcing, because in my experience it scales much better than a traditional CRUD model" is not really a question, and interviewers notice. The second is the overlong wind-up, where the context before the question runs so long that the interviewer loses the thread. Give just enough setup to make the question land, then stop and let them answer.
Frequently asked questions
How many questions should I prepare? Prepare six to eight across the whole loop, but plan to ask only two or three per interviewer. You want a deep enough bench that you always have a relevant one ready, not a checklist you feel obliged to complete.
What if the interview already answered all my questions? Say so, briefly, and then ask a follow-up on something specific they said. "You covered most of what I was going to ask, which I appreciate. The one thing I am still curious about is how the team decided to prioritise the migration over new features." Never claim to have no questions just because your prepared ones were addressed.
Is it acceptable to bring notes? Yes. Glancing at a short list of prompts reads as organised, not unprepared. What looks weak is reading a paragraph verbatim or losing eye contact to study a page. Keep the notes to keywords, not full sentences.
Should I ask about salary in the interview? Raise compensation with the recruiter, early, and keep it out of the technical and team interviews. The exception is if an interviewer opens the topic, in which case engage briefly and steer back. For the money conversation itself, see how to negotiate a job offer.
A small kit to carry in
For the recruiter: process, timeline, why the role is open, salary band
For the manager: first 90 days, success at 6-12 months, biggest challenge
For peers: a normal week, what they wish they had known
For leaders: biggest opportunity and risk in the next year
One question from your own research
One question raised live during the interview
A backup for each slot in case the conversation got there firstWalk in with a kit like this, adapt it to the room, and the closing question becomes one of your strongest moments rather than an afterthought.
Continue your prep
Build the research that makes great questions possible: