Questions to ask the interviewer as a developer

Almost every interview ends the same way: "Do you have any questions for us?" The most common answer is "No, I think everything's clear." That's a missed chance. These are the only ten minutes when you can find out what you're actually signing up for, before you've signed anything.

Questions work the other way too. They show the interviewer what matters to you: just salary and remote work, or also the tasks, the processes, and the people.

Who to ask what

Each stage has its own person, and it's best to ask them about what they actually know:

• Recruiter: stages, timeline, work format, conditions, salary range.
• Future manager: what they expect from you, what your first tasks will be, how performance is evaluated.
• Engineers in technical rounds: how code review, releases, on-call, and tech debt work.

Asking an engineer about bonuses or a recruiter about architecture won't get you far. The honest answer will be "I don't know, I'll check."

How to push past vague answers

Many first answers sound the same: "we have good processes", "we work on tech debt", "on-call happens, but rarely". That's not necessarily an attempt to hide something. A general question is just easy to answer in general terms.

Three tricks that turn an answer like that into real information:

1. Ask about the last time: "How did it go the last time?" A real example is hard to sugarcoat.
2. Ask for a number: "Roughly how many?", "How often?" Even a rough estimate beats "sometimes".
3. Ask who decides: "Who decides what goes into the sprint?" The answer shows how decisions are made on the team.

Below are questions by topic, with follow-ups.

First tasks

What will I be working on in my first month? And after three months?

If the answer is "oh, various things, we'll see as we go", follow up:

What did the last person who joined the team work on in their first month?

A good answer is specific: "They spent a week getting to know the code, then took on a new payment screen, and a month in they were already on call." If nobody can remember, there's probably no onboarding, and you'll be figuring things out on your own. That's not always bad, but it's better to know in advance.

Code review and decisions

How does code review work here? How long does a pull request usually wait?

If you hear "we have a strong review culture", ask:

How many approvals do you need to merge? Was there a recent disagreement in a review, and how did it end?

A story about a disagreement tells you more than any process description: who makes decisions on the team and whether you can push back on the team lead.

On-call

Is there an on-call rotation? How often, and is it paid separately?

Follow up on "it happens, but rarely" like this:

When was the last time the on-call person got woken up at night, and why?

If it was last week and the reason was "that same integration went down again", you have a pretty good idea of what your on-call shifts will look like.

Tech debt

How much time goes to tech debt? Who decides what to fix first?

If you hear "everyone has tech debt, we deal with it", ask:

What was the last tech debt task you closed? How long did it wait?

If tasks like that get picked up regularly, you'll hear it in the answer right away. If people struggle to remember one, the debt is piling up, and there's a good chance you'll be the one cleaning it up.

Expectations

These are best asked to your future manager:

Six months from now, how will you know you hired the right person?

How does the probation period work? Are there regular one-on-ones and salary reviews?

If you hear "the main thing is that the person fits into the team", follow up:

What usually separates the people who fit in from those who don't?

The answer will show what they really expect from you: speed, independence, or not arguing.

How to ask without sounding like an interrogation

Three or four questions per stage is plenty. Pick the ones that matter to you and write them down in advance. Reading from your notes is fine, it shows you prepared.

Explain why you're asking, and the question immediately sounds softer:

Understanding on-call matters to me. At my last job I was on call every two weeks, and I'd like to know what to expect here.

Don't ask about things that are on the company website or in the job description. And don't turn your questions into a negotiation: money and conditions are for the recruiter, not for the engineer in a technical round.

Right after the call, write down the answers while you still remember the details. If you track your applications in the tracker, it's handy to save them in the notes on the job card: when an offer comes in, comparing companies will be easier.

For the rest of your prep, see How to prepare for an interview the night before.