Questions to Ask About a Role and Team

Almost every interview round ends with “Do you have any questions for me?” Candidates often treat it as a formality, ask something generic and wrap up. That’s a missed opportunity in two ways. It’s the only part of the process designed for you to learn whether you want the job, and the questions you ask tell the interviewer how you think about work.

What your questions do

Harvard’s career office describes two purposes for candidate questions: getting the information you need to make an informed decision, and reinforcing your interest in the role. It also suggests making sure you know the next step before you leave.

There’s a third effect worth knowing about. Interviewers notice what you ask about. A candidate who asks how incidents are reviewed, or how technical disagreements get settled, signals that they care about those things. A candidate who asks only about perks signals something else.

Start from what would change your decision

Before the interview, write down what actually matters to you in your next role. For many engineers, it’s some mix of: how much on-call there is and how bad it gets, how decisions are made, what growth looks like, whether the team is stable, how much remote flexibility there is and what the first six months involve.

Then write questions whose answers could change your mind. If any answer would leave your opinion where it started, the question is filler. “What’s your tech stack?” is usually filler, since it’s in the job ad. “What would you change about the stack if you had six months?” isn’t.

Questions that get real answers

General questions get general answers. Ask “What’s the culture like?” and almost everyone says “collaborative” and “supportive.” The fix is the same idea behind behavioral interviews: ask for a specific recent example instead of an opinion.

• Instead of “How’s the work-life balance?” try “What did the last busy period look like, and how did the team handle it?”
• Instead of “Do you have good engineering practices?” try “Tell me about the last incident. What happened afterwards?”
• Instead of “Is there room to grow?” try “Who on the team has been promoted recently, and what did they do to get there?”
• Instead of “How do you make decisions?” try “When did the team last disagree on a technical decision, and how was it settled?”

A question about success early on is also worth asking almost every time: “What would make someone in this role successful in their first three months?” The answer tells you what’s expected and whether anyone has thought about it.

Matching questions to the interviewer

Different people can answer different questions well. Asking a recruiter about code review practices wastes both your time.

Asking a couple of the same questions to different interviewers can be useful too: if the manager says on-call is light and a peer says it’s exhausting, you’ve learned something important.

Worked example: following up instead of reading a list

Here’s an illustrative exchange with a hiring manager. It shows the difference between ticking off questions and actually finding out.

Candidate: How does on-call work on this team?

Manager: We have a weekly rotation across six engineers. It’s pretty manageable.

A weak response moves to the next prepared question: “Great. And what do you enjoy most about working here?” The candidate has learned almost nothing; “pretty manageable” could mean anything.

A stronger response follows up on the vague part:

Candidate: What did the last few rotations look like in terms of pages? And when something keeps paging out of hours, what happens next?

Manager: Honestly, last quarter was rough. About fifteen pages a week, mostly from one flaky queue consumer. We’ve got a project this quarter to replace it.

Candidate: Is that project something the person in this role would work on?

In two follow-ups, the candidate has learned the real on-call load, that the team recognizes the problem and is investing in fixing it, and possibly what their first project would be. They’ve also shown the manager that they care about operational health and ask good questions under uncertainty, which is useful evidence for a senior role.

Questions to avoid, and when to ask them

• Anything on the website or in the job ad. It suggests you didn’t prepare.
• Salary and benefits in a technical round. They’re fair questions, but the recruiter is the right person.
• “Did I get the job?” Ask about next steps instead: “What’s the timeline from here?”
• Yes-or-no questions. “Do you do code review?” gets “yes.” “What does a good code review look like here?” gets an answer.
• Loaded questions. “Is the work-life balance as bad as people say online?” puts the interviewer on the defensive. “How does the team handle crunch periods?” gets the same information.

Questions for senior candidates

For senior and staff roles, your questions are also part of the evaluation. Interviewers expect you to think about how the team works, not just what you’d work on. Questions that fit that level:

• “Who makes technical decisions that span teams, and how?”
• “What would you want a senior engineer to have changed after six months?”
• “What’s been tried before to fix this problem, and why didn’t it stick?”
• “How does the team decide between new features and reliability work?”

They show that you expect to influence decisions and want to understand the context first.

Mistakes that waste the time

• “No, I think you covered everything.” It reads as low interest, even when you’re just tired.
• Reading from a list without listening. The best questions often come from something the interviewer said earlier.
• Too many questions. Respect the time; two or three good ones beat six rushed ones.
• Using the time to keep selling yourself. A short connection to your experience is fine; a second pitch isn’t.

Interview practice: five minutes with a peer engineer

You have five minutes left with an engineer who’d be your teammate. Your biggest worry about this company is that deadlines regularly win over code quality. Write two questions and the follow-up you’d ask to each.

Answer and reasoning

Good questions ask for recent, specific examples rather than opinions, because “Do deadlines beat quality here?” invites a defensive “no.”

First question: “Can you tell me about the last time the team was under real deadline pressure? What gave?” Follow-up, depending on the answer: “Did the things that were cut get picked up afterwards?” That checks whether shortcuts are deliberate and repaid, or just accumulate.

Second question: “What’s something in the codebase you’d fix tomorrow if you had a free week?” Follow-up: “Why hasn’t it been fixed yet?” The first part shows what the engineer is unhappy with; the second shows whether the team can get improvement work prioritized, or whether it’s always pushed back.

Both questions are neutral, so the engineer can answer honestly without feeling disloyal, and both follow-ups test the part of the answer that matters for your decision. Compare what you hear with the hiring manager’s version of the same topic. If they match, you can trust it more.

Before your next interview

• Behavioral and HR interview questions
• Behavioral and HR multiple-choice questions
• Behavioral: Negotiating Compensation, for the questions that belong with the recruiter
• Interview Introductions With Relevant Evidence
• Harvard Mignone Center for Career Success: Interviewing, including questions to ask employers