Most lists of structured interview questions by role are question banks: fifty questions, grouped by department, ready to paste into an interview guide. Then four interviewers paste the same five, the candidate tells the same story four times, and the debrief has one data point repeated with confidence. The structure comes from who asks what, and a longer bank won't fix that. This is for recruiters running interview loops for several functions at once, who need each panelist asking something different and comparable. You'll leave with four rules, a question card, and questions for six roles.
My bias, up front. Skillvee is a 60-minute "day at work" simulation that replaces the recruiter phone screen and the first interview round. The candidate solves a real challenge, talks to AI teammates to get the information they need, and defends their decisions on a call, while the screen is recorded. So I'd rather watch the work than hear about it, but most loops still run on interviews.
What makes interview questions structured
A structured interview question is one that every candidate for the role gets asked, by the same interviewer, scored against a strong answer someone wrote down before the first interview.
Banks give you the questions, and the better ones add a probe. None I've read says who asks which. The same interviewer matters because two people asking "tell me about a difficult customer" probe differently and hear different things. The written strong answer matters most. Without it, each interviewer scores against a private picture, and you've rebuilt an unstructured interview with a shared question list on top.
The question map: four rules
I call this the question map. It takes your interview scorecard and decides who asks what.
- One question per scorecard row. The rows are tasks from the first 90 days, the ones that survived the task test in your hiring manager intake meeting. If you've got a great question that doesn't fill any row, it doesn't go in the loop.
- Every question asks about a real past event with a turn in it. "Tell me about a time" plus something that went sideways, like a deal that slipped or a number that looked wrong. No hypotheticals. The turn is what you probe, because it's the part a candidate can't borrow from someone else's story.
- Each question ships with its probe and its 4. The probe is the follow-up you'll ask when the answer stays general. The 4 is one sentence, agreed at intake, describing what a strong answer contains.
- One owner per row, two on the rows that decide. Every row gets an owner: the manager takes the rows closest to the work, a peer takes the collaboration rows, and nobody asks a question that belongs to someone else. The one or two rows your advance rule leans on get a second owner who asks the same card, so the debrief has a spread to read where the decision actually sits.
Rule 4 is the one teams skip, and it's the cheapest. With four interviewers and four rows, double one row and you'll still cover every task, with two reads on the one that decides.
The question card
One card per row. The hiring manager and recruiter fill it in at intake, or in a 15-minute follow-up, and the interviewer brings it into the room.
QUESTION CARD
Role: [role] Scorecard row: [the task]
Owner: [interviewer] Round: [which interview]
QUESTION (a real past event with a turn in it):
"[Tell me about a time you ... What happened when ...?]"
PROBE (when the answer stays general):
"[Second example, from a different company? / What was the
name of ...? / What did the first version look like?]"
A 4 LOOKS LIKE (the same line as on the scorecard row):
[what a strong answer contains]
Time: [10-15 minutes including the probe]
Structured interview questions for six roles
Two rows per role, from what I see most on Series A to C req lists. They're different from the S3 questions in the recruiter phone screen template on purpose: the screen's S3 asks one role-specific past event, and the loop takes different tasks from the scorecard. Swap in your own rows.
| Role | Scorecard row (the task) | Question | A 4 looks like |
|---|---|---|---|
| Account executive | Builds a deal with more than one buyer | "Tell me about a deal where the person you were selling to wasn't the one who decided. When did you find out?" | Names when they found the real decider and what they changed in the deal after |
| Account executive | Forecasts honestly | "Tell me about a deal you had in commit that slipped. What did you tell your manager, and when?" | Flagged the slip before the quarter ended, with the reason |
| Customer success manager | Runs an expansion conversation | "Tell me about an upsell you didn't push, or one you pushed too early. What happened?" | Ties the timing to something the customer said or did |
| Customer success manager | Handles a customer escalation | "Tell me about the angriest customer email you've answered. What did you send back, and what happened next?" | Separates what they promised from what they fixed |
| Product manager | Says no to a stakeholder | "Tell me about a request from sales or a big customer that you turned down. What did you tell them, and what did they do next?" | Names the evidence and the person who disagreed |
| Product manager | Writes a spec others build from | "Tell me about a spec you wrote that the engineers pushed back on. What did you change in it?" | Names the objection and what changed in the document, beyond the date |
| Backend engineer | Reviews someone else's code | "Tell me about a code review where you pushed back on something. What was it, and how did it end?" | The specific risk, and how they handled being wrong if they were |
| Backend engineer | Hands a system to someone else | "Tell me about something you built that another engineer had to take over. What did you leave them, and what did they still have to ask you?" | Knows what the handover missed and what they now write down first |
| Data analyst | Questions the data before the answer | "Tell me about a number you were asked for that turned out to be the wrong question. How did you find out?" | Went back to the person who asked before building anything |
| Data analyst | Explains a result to a non-analyst | "Tell me about a finding that someone didn't want to hear. How did you present it?" | Describes the audience and what they changed for them |
| Program / ops manager | Runs work across teams | "Tell me about a cross-team project where one team stopped responding. What did you do in the first week?" | A specific escalation path, not "I followed up" |
| Program / ops manager | Builds a plan another team lives by | "Tell me about a plan or forecast you built that another team had to run on. Where was it wrong?" | Names the assumption that broke and who told them |
Behavioral interview questions by role, and why not hypotheticals
Most question banks mix past-event questions with situational ones: "What would you do if a customer threatened to churn?" I leave the situational ones out.
A hypothetical tests whether the candidate knows the right answer, which for common scenarios is easy to find. A past event tests what they did, with the people and the mess still attached. Probe a hypothetical and they just keep making it up. Probe a real event and you get more detail, including the version they'd rather not tell.
The fair objection is early-career candidates without that history. For them, don't fall back to "what would you do". Give them a small piece of the task and watch: a short work sample gets you closer to the row than a hypothetical answer ever will.
When the answer sounds read off a screen
Some candidates on video calls now have an assistant open. What usually gives it away is an answer that's complete and general, with no turn in it.
That's what the probe on each card is for. Ask for a second example from a different company, then go one level down: what was the tool called, who pushed back, what did the first draft say. In my experience a real story has another layer, and an answer built for the first question tends to run out of detail at the second. Score the second layer, and quote it.
Where this gets hard
Interviewers like their own questions, and a peer with a favorite won't give it up for a card. Let it stay as an unscored warm-up and hold the line on the scored row.
The rows run out before the panel does. Five interviewers and three rows means two of them double up, so put them on the rows that decide, or cut an interview. I'd rather cut one than invent a row for it.
And a good question still only gets you a story. The best structured interview gives you a well-told account of work you didn't see, which is a real ceiling. It's the reason Skillvee puts the candidate in an hour of actual work instead: the evidence for a row comes from what they did, and when two reviewers disagree they can watch the recording.
Put the cards in front of the debrief
After the loop, every interviewer submits their scorecard before reading anyone else's, with the quote from each question they owned. The interview debrief then starts at the spread, on the doubled rows where the two reads differ. With only two reads, the debrief template drops the threshold to one point. Single-owned rows have no spread, so read them against the advance rule. That's the trade in rule 4: coverage on most rows, and a real disagreement on the ones that decide.
After a few candidates, look for a question that gets the same answer from everyone. It isn't sorting anyone, so you'll want to rewrite it or swap in a short exercise. And if the row that keeps producing thin answers is about how someone finds what they need without being told, an hour of observed work will get you further than another question. The pricing page has the plans if you want to try that on one role.