Do the questions I ask actually affect the decision?

Yes. Interviewers commonly report that a candidate 'asked good questions' as evidence of seniority, and 'had no questions' as a mild negative. The questions reveal what you think matters, which is a signal about how you would work.

How many questions should I prepare?

Six to eight, expecting to ask three or four. Some get answered during the interview, and asking one that was already covered reads as not listening. Prepare more than you need so you can drop the ones that became redundant.

Is it acceptable to ask about salary in a technical round?

Ask the recruiter, not the engineers. Engineers usually cannot answer and it uses time you could spend on questions only they can answer. The recruiter screen is the right place, and asking early saves everyone a wasted loop.

What should I do if the answers are evasive?

Note it and probe once more with a specific version of the question. Vagueness about on-call, testing or why the last person left is data — it is usually the answer, delivered indirectly.

The Questions You Ask | SkillByExample

The last five minutes are part of the assessment, and they are also the only part where you are the one gathering evidence. Both matter.

Why they are scored

An interviewer’s notes after this section typically read like one of these:

"Asked about how the team handles incidents and what changed after the last one.
 Clearly thinks about operations, not just shipping."         → senior signal

"Asked what the tech stack is."                                → neutral; it is on the job ad

"No questions."                                                → mild negative; reads as
                                                                  uninterested or unprepared

The pattern: a question that could be answered by the job advert wastes the slot. A question that only someone on the team can answer is the one worth asking.

Questions that work

About the actual work

"What does a typical week look like for someone in this role?"
"What is the thing the team is most frustrated by right now?"
"What was the last significant technical decision the team made, and how did it
 get made?"
"If I joined and did an excellent job for six months, what would I have shipped?"

The third is the strongest of these. It tells you whether decisions are made by consensus, by the loudest voice, by a staff engineer, or by someone who left. Almost nobody asks it.

About engineering practice

"How long does it take from a merged commit to running in production?"
"What is your test strategy — where do you invest, and where do you deliberately
 not?"
"How often does the team pay down technical debt, and how does that get
 prioritised against features?"
"What happens when something breaks at 2am?"

Deployment frequency is the highest-information single question about engineering maturity. The difference between “a few times a day” and “we batch a release every six weeks” tells you about testing, CI, rollback confidence and probably team autonomy — all from one answer.

About the team

"How is the team structured, and who would I work with most closely?"
"How do you handle disagreement about a technical approach?"
"What is the review culture like — how much back-and-forth is normal on a PR?"
"Why is this role open?"

“Why is this role open?” is worth asking every time. Growth, backfill and “the last two people left” are very different situations, and the hesitation before the answer is often more informative than the answer.

About your interviewer

"What made you join, and has it turned out how you expected?"
"What is the best thing about working here, and what would you change?"

These get honest answers more often than process questions, because they are personal. Watch for the pause on the second half.

Questions to skip

Question	Why it lands badly
”What does the company do?“	you should know; it reads as no preparation
”What is the tech stack?“	it is on the job ad
”How much holiday do I get?“	recruiter question, not an engineer one
”Is there remote work?“	should be settled before a technical round
”How did I do?“	puts the interviewer in an awkward position
”What is the salary?“	ask the recruiter — engineers usually cannot say

None of these are offensive. They just spend a scarce slot on something answerable elsewhere.

Reading the answers

You are evaluating them too. What the answers mean:

QUESTION: "How long from merged commit to production?"

"A few times a day, automated."      → strong CI, tests they trust, likely autonomy
"Weekly, with a release manager."    → fine; heavier process, slower feedback
"Every six weeks, and it's painful." → the honesty is good; expect release stress
"...it depends."                     → probe once: "when did you last deploy?"

QUESTION: "What happens when something breaks at 2am?"

"Rota, runbooks, and we do blameless postmortems."   → mature operations
"It usually goes to whoever wrote it."               → no rota; expect ad-hoc pages
"We don't really have that problem."                 → either genuinely batch-only,
                                                        or nobody is watching
"[long pause]"                                       → the pause is the answer

QUESTION: "What is the team most frustrated by?"

A specific, concrete answer            → healthy; problems are discussed openly
"Nothing really, it's great here."     → either very good, or not safe to say
A complaint about another team         → note it; it may be your future

The one to weigh most heavily is a long pause on an operational question. Teams with good practices answer those instantly, because they are proud of them.

Tailor by interviewer

Ask the person in front of you what only they can answer:

ENGINEER          day-to-day, code review, testing, the last hard bug
ENGINEERING MGR   team structure, growth, how performance is assessed, priorities
SKIP-LEVEL / DIR  strategy, where the team fits, what changes in a year
RECRUITER         process, timeline, compensation band, level
CROSS-FUNCTIONAL  how engineering and product actually negotiate scope

Asking a director about code review style, or an engineer about the three-year roadmap, wastes the one person who could have told you something useful.

When you genuinely have none left

If everything was covered — which happens in a long, good conversation — say so rather than inventing one:

"You've covered most of what I had — particularly the deployment process, which
 was my main one. The only thing I'd add: is there anything about my background
 that gives you pause, that I could address now?"

That last question is worth keeping in reserve. It occasionally surfaces a concern you can correct on the spot, and it never reads badly.

A working set

Prepare eight, expect to ask four:

1. What is the team most frustrated by right now?
2. How long from merged commit to production?
3. What was the last significant technical decision, and how was it made?
4. What happens when something breaks out of hours?
5. Why is this role open?
6. What would a successful first six months look like?
7. What made you join, and has it matched expectations?
8. Is there anything about my background that gives you pause?

Keep them on the desk. Reading from a list is fine and reads as prepared, not scripted.

Practice

1. Ask about deployment frequency in your next interview.

"a few times a day, automated"      → strong CI, likely autonomy
"every six weeks, and it's painful" → honest; expect release stress

One question, and you have learned about testing, CI, rollback confidence and probably team autonomy. It is the highest-information question in the set.

2. Ask why the role is open, and watch the pause.

"We're growing the team."          → straightforward
"...the previous person moved on." → probe gently: "how long were they in the role?"

Growth, backfill and churn are very different situations. The hesitation is usually more informative than the words.

3. Ask the same question of two interviewers.

engineer: "review is slow, PRs sit for days"
manager:  "review is quick, we're pretty responsive"

Divergent answers are the most valuable data you get in a loop. Believe the engineer.

4. Prepare eight and mark off the ones answered during the interview.

prepared 8 → 5 answered during the conversation → 3 left to ask

This is why eight rather than three. Asking something already covered reads as not listening, which is a worse outcome than asking nothing.

Next: take-homes and live coding — two formats with different rules.