The Questions I Ask, By Round

Most advice about “questions to ask your interviewer” gives you a flat list. The list is not the problem. The round is.

I learned this the boring way: asking a peer engineer about promotion criteria and getting a shrug, then asking a director what time people actually leave and getting a confident answer that was wrong. Neither of them was lying. They just don't know each other's job.

So the rule I use now:

A question asked at the wrong round returns a useless answer even when the interviewer is completely honest. That single reframe made my questions land harder than any clever phrasing ever did.

Here is the full set, sorted by who is in the room.

Round 1 — peer engineers

Early technical rounds are run by people who write the code. They live the daily reality, they have almost no incentive to spin it, and they have usually not been media-trained about it. This is the only round where you get an unvarnished answer about how the days actually go.

It is also the wrong round for anything strategic. Do not ask a peer about the company's AI roadmap. They will guess, politely, and you will write down a guess.

What a day looks like

“What's a normal day like for you? Fixed hours, or genuinely flexible?”

“Is it sprints with a daily standup and a written report? Or looser than that?”

「日常大概什么样？打卡还是弹性？是 sprint + 每日站会 / 日报那种吗？」

The daily-written-report detail matters more than it looks. A team that files status upward every day is a team where trust flows downward slowly, and it tends to correlate with everything else you are trying to detect.

How work arrives — the important one

“Is work assigned to you, or do you pick up what you judge needs doing?”

“And when you disagree with an approach — what actually happens?”

「活是分配下来的，还是自己判断该做什么？如果你不认同一个技术方案，通常会怎么样？」

The second question cannot be performed. A team where disagreement changes outcomes has an example ready, unprompted, within about four seconds. A team where it does not will answer in principles — “we're very open”, “everyone's voice matters” — and no example will arrive. Listen for the example, not the sentiment.

Pressure, asked so it can be answered honestly

“When was the last crunch? What time were people leaving during it?”

「最近一次赶版本是什么时候？那段时间大概几点走？」

Never ask “do you work a lot of overtime”. Everyone says no, and they are not even being dishonest — nobody thinks their own hours are unusual. Past tense, plus a specific occasion, plus a clock time, is answerable and hard to soften.

Tooling depth

“What do you use day to day — Claude Code, Codex, Cursor, something internal? Is there a token budget per engineer?”

The budget number is the cleanest signal in the entire interview. A real per-engineer budget, however small, means someone owns that cost line, which means the practice is funded and measured. “Unlimited, nobody tracks it” is not generosity — it means it is not on anyone's P&L yet, which is a different risk, not the absence of one.

Then the depth question:

“Is the team going deep on one tool — hooks, skills, subagents, custom MCP servers — or trying several?”

A team that has written its own hooks and skills is doing engineering. A team that has evaluated seven assistants is doing procurement. I would rather join the first, and the difference never appears on a job description.

Two requests instead of questions

“Is there a shared repo of prompts, skills or agent configuration I could look at?”

“How many people on the team are remote right now, and in which timezones?”

If the config repo exists, that is the culture answered without anyone describing it. Shared configuration means knowledge compounds; everyone privately tuning their own setup means it evaporates every time someone leaves. And “we support flexible working” with zero currently-remote engineers means the policy exists on paper — the count is the answer.

Round 2 — the hiring manager

This is the round that decides things, and the one most people waste on questions about team structure they could have read on LinkedIn. The hiring manager is the first person who can narrate an approval path. Use them for exactly that.

★ The best question I have

“Say something I'm building needs a stale column restructured and data migrated — in prod. Walk me through what actually happens, from me proposing it to it being live.”

「假设我要做的东西需要重构一个废弃字段、还要在生产环境迁移数据。从我提出来到上线，这个流程实际是怎么走的？」

I have started opening with this one, and nothing else I ask comes close.

It works because it is a scenario, not a topic. “How do you handle technical debt?” gets a rehearsed paragraph. A stale column and a prod data migration can only be answered by narrating a real path — approval, review, migration tooling, prod access, rollback, who signs off, how long — or by revealing there isn't one.

It is also the smallest realistic request that touches all of those at once. And for anyone doing automation work it is the precondition:

A team that cannot move a column cannot host an agent fleet, whatever the job posting says about AI.

Follow-ups, in this order:

1. “Who signs off? And realistically, how long?”
2. “Has something like that gone through in the last six months?”
3. “Does that person still write code?”
4. “And when someone wants to introduce a new service into the existing workflow — same path, or different?”

The third is worth asking plainly. Someone hands-on understands immediately why a stale column blocks an automation. Someone who is not will hear “cleanup” and price it as optional forever.

Reading it: a narrated path with names, a review step and a realistic timeline means engineers change foundations here. “We'd have to discuss it”, or no example in six months, means you would be building on frozen ground.

The ratio

“Roughly what's the split between feature work and foundations — infra, repo health, tooling?”

「业务代码和技术债 / 基建大概什么比例？」

Nobody answers zero. They answer “we do it as we go”, which is zero. So always add the second half: “What did that buy last quarter, concretely?” The artifact is the answer; the percentage is the setup.

And if you have a target of your own, ask for theirs first. State yours first and you will get your own number handed back to you as a claim you cannot check.

Where AI output actually goes

“What's the path from an AI-written change to production? Who owns the gate?”

“How much of it gets line-by-line human review today — and where do you want that number to be?”

“How do you measure the quality of AI output — is there an eval framework, or does review catch it?”

The second is the real one. Line-by-line human review of every AI diff is a perfectly reasonable starting point. It is a bad destination, and what you are testing is whether they know the difference.

Who decides

“For a piece of work on this team, who decides the approach — the engineer, the lead, or is it specified coming in?”

Ask this in round 1 and round 2, then compare the two replies. When they disagree, believe the engineer.

Final round — director, CTO, founder

By the last round the leverage has shifted: they have spent hours on you and want to close. Questions that would read as presumptuous at stage one read as diligence at stage eight. It is also the only round where the expensive questions are answerable, and your last cheap chance to ask them — after an offer, every question becomes a negotiation.

★ Promotion, framed so it cannot be dodged

“How does promotion work — what's the cadence, twice a year? And what separates a strong candidate from a borderline one at this level?”

「晋升怎么走？一年两次？什么样算强候选人，什么样算勉强？」

The “strong versus borderline” framing is the whole trick. It forces a description of the actual bar instead of a value. “We reward impact” is not an answer. “A strong case shows X, a borderline one shows Y” is.

A company that cannot draw that line does not have a standard. It has discretion.

Follow-ups:

1. “Is it written down? Could I see the criteria for the level above this one?”
2. “Who was promoted recently, and for what?”
3. “Does platform and tooling work count, or does it read as overhead against feature delivery?”

Asking to see the next level's criteria is the sharpest form — an entirely normal question from someone planning to stay, and a company with a real framework answers it in one sentence. The third follow-up decides whether your kind of work is even visible: if tooling does not appear in the review, it will not appear in your manager's decisions either.

Reading it: a cadence, written criteria, cross-team calibration and a recent named example means a standard exists. “We're too small for levels” is fair at twenty people and a warning at three hundred. “Talk to your manager” means there is no standard. At Chinese big tech, expect a real 职级体系 — there the question shifts to whether your team gets promotion headcount at all.

Whether the mandate is real

“In the last year, which internal-tooling or developer-productivity project actually got funded with headcount — and who approved it?”

“If a platform investment doesn't show results within a quarter, what usually happens to it?”

A name plus a project means the decision-maker's view reaches that far. Warm generalities about valuing tooling mean it has never been tested.

The second question is the one I care most about, and the hardest to ask without sounding cynical — so keep it neutral and let the answer do the work. What you are listening for is whether they distinguish not working from not working yet. Those are completely different sentences and most people only have one of them.

Whether leadership feels it

“Do you still write code? What's the last thing you built with an AI tool?”

Asked in good faith this is one of the most informative questions available, and with a technical founder it is a pleasure rather than a challenge. What I am actually trying to learn: does leadership feel the current coding paradigm, or only fund it? Those produce very different decisions about what is worth building, and you cannot tell them apart from outside. A personal website does not count — something real, touched recently.

Strategy, both directions

“If the AI bet works, what does this company look like in two years? And if it underdelivers for two quarters, what changes?”

Everyone can answer the first half. The second half is where the actual thinking is, and it tells you how durable the thing you are being hired for really is.

And always, at the end

“Is there anything about my background that gives you pause? I'd rather answer it now than leave it unanswered.”

“Next steps, timeline, and who else is in the decision?”

The first is the most underused question in interviewing. It surfaces the objection while you can still address it. You almost certainly know what yours are — have one calm sentence ready for each, and do not get defensive when it lands.

The three I would keep if I could only ask three

• The prod migration walkthrough (hiring manager). Unfakeable, and the precondition for automation work. If they cannot move a column, nothing else you were told about AI matters.
• “Is work assigned, or do you pick it up — and what happens when you disagree?” (peer round). Two things at once: whether technical judgment sits with you, and whether self-directed work is even possible. Async, self-directed teams are the only ones where agent-driven work is feasible at all; a presence-and-daily-report culture cannot host it regardless of policy.
• “What separates a strong promotion candidate from a borderline one?” (final round). Exposes whether a standard exists, or whether it is discretion wearing a process costume.

How to read any of it

One rule covers all of them: the answer is the artifact, not the sentiment. A name. A number. A document. A date. A person who was promoted and what for. A project that got funded and who approved it. A repo you can open.

If a question comes back with warmth and no artifact, that is your answer — usually not a lie, but genuine goodwill about something that has never been tested.

What I don't ask

• Comp for the first time in a late round. It belongs in call one. If it is still unknown by the final round, that is a process failure to fix next time.
• Anything answered on their website. At a late stage it reads as not having prepared.
• “Does leadership actually understand AI?” Right instinct, unsurvivable phrasing. 「技术方案的决策通常在哪一层？」 does the same work and gets answered.
• Anything about a former employer. An interview is not the place, the story never lands the way you intend, and every question above works fine without it. Keep it forward-looking: what you are looking for, not what you are leaving.
• From a page. Pick four or five, hold the rest. Three asked well beats twelve recited.