“We shipped the feature” is a perfectly normal way to describe working in a team. It leaves you with something to ask: “What did you contribute specifically?”
You’re trying to understand this person’s work. Give them room to explain the team’s achievement, then explore the decisions and responsibilities that were theirs.
Most of the questions below work well after an assessment. You can also adapt them to a previous project. Pick a few that match what the role actually needs, rather than trying to get through the whole list.
Get specific without putting words in their mouth.
“How do you use TypeScript?” invites a general explanation. “Tell me about the last time you used TypeScript in a production application” gives you a particular project to discuss.
From there, ask what they were responsible for, which difficulty they encountered and what they did about it. If they keep saying “we”, return to their contribution. If they describe a principle, ask where it affected a decision.
Keep the main topics and evaluation criteria consistent across candidates. Follow-ups can clarify different answers without giving one person the solution you hoped to hear. Structured interviews give you a basis for comparison while leaving room to understand each person’s evidence.
Specificity helps you examine a claim; it doesn’t make a story impossible to invent. Allow time to think, respect confidential details and check explanations against the assessment where possible.
Which decision didn’t pay off?
“Was there a decision you undid, or an approach you tried differently? What made you change direction?”
Explore the first approach, what they learned and why the next attempt seemed more promising. A useful follow-up is: “What did you notice that told you it wasn’t working?”
You’re looking for evidence that they can recognise a problem and adapt. Being willing to discuss a mistake is useful, but one polished story won’t establish honesty or humility. Pay attention to how they investigated and what changed.
Which AI suggestion did you reject?
“Did the AI offer different solutions? Talk me through one you chose not to use.”
Ask what made it unsuitable for this application. Was it too complicated, based on a wrong assumption or missing a requirement? How did they check the alternative they accepted?
This lets you explore whether they used their own experience and judgment. Don’t reward rejecting AI for its own sake. An accepted suggestion can be a good decision too, provided they can explain why it fit and what they verified.
What haven’t we discussed that you’d like to show?
“Is there a part of the assessment you’re proud of, or something you think we’ve overlooked?”
Give them a little space to lead. They might show a small interaction, a useful test, a simplification or a decision to leave something out.
Ask why it matters and what they contributed. You may learn something about their standards that your prepared questions missed. It also gives them a fair chance to explain work that wasn’t immediately visible to you.
What would you change before launching this?
“Suppose real customers were going to use this next month. What would you need to change first?”
Depending on the brief, they might discuss access controls, analytics, deployment, support, data recovery or a limit in the architecture. Ask them to choose the most consequential gap and explain who it affects.
“What could wait until we had more users?” is a useful follow-up. You’re exploring whether they can turn a prototype into a useful product, rather than name every production concern they know. If login already exists, inventing a new login system is hardly a priority.
What else would you ask the customer?
“If this were a real project, what would you want to know from the client or customer before taking it further?”
An assessment will leave some things unspecified. Ask which assumptions they made to keep moving, and which answer could cause them to reconsider their solution.
For example, knowing that customers share devices might change an access decision. A strict delivery deadline might change the scope. Follow the connection between the missing information and the work; a long list of generic discovery questions tells you less.
Which change had the highest impact?
“Of the changes you made, which mattered most? Why did you put your time there?”
Let them define impact in the context of the brief. Then ask: “What difference did it make, and what evidence do you have?”
They might point to a working user flow, a removed failure or a simpler way to deliver the same outcome. If there are no real users or measurements, a reasoned expectation is fine when they identify it as such. Explore how they prioritised, what they understand about the code and what they would measure next.
What would you do differently next time?
“If you started again with what you know now, what would you change about your approach?”
“I’d write more tests” may be true, but it needs a follow-up: “Which check would you add first, and what did you discover that makes it useful?”
Look for learning they can connect to the work. They might change how they briefed an agent, investigate an assumption earlier or spend less time on a feature. They don’t need to disown a sensible decision simply because hindsight offers another option.
How would you approach the whole backlog?
“As a thought experiment, if you had to complete all these tasks in four to six hours, how would you try?”
Make clear that this doesn’t change the assessment rules. If the brief said that unfinished work was expected, completing everything must not suddenly become the standard.
Explore what they would do in parallel, which tools they would choose and where the dependencies are. Ask: “What happens when two agents change the same interface?” and “How would you check the combined result before merging?”
A thoughtful answer might involve smaller independent tasks, agreed interfaces, separate branches and checks after integration. It might also explain that the premise is unrealistic. Reward reasoning about quality, cost and time; the number of agents they can launch isn’t a measure of skill.
Write down evidence before your overall impression.
Record the decision, their contribution, the reason they gave and anything you still need to check. Compare that with the abilities you agreed to assess before meeting them. “Explained why retries needed an idempotency key and showed the duplicate-request test” is more useful than “seemed senior”.
Choose a few questions and give the answers room. Our interview guide provides a structure for the conversation, while the assessment question library goes further into scoping, architecture and verification.
You don’t have to be a perfect interviewer. Notice where a question produced a vague answer, try a better follow-up next time and keep learning alongside the candidates you meet.
Research and further reading
These are practical questions from Tim’s proposed interview approach. They are not a validated scoring instrument or a way to diagnose personality.
- OPM: structured interviews. Supports consistent, job-related questions and common criteria for evaluating answers.
- OPM: creating structured interview questions. Covers questions about previous behaviour and hypothetical job situations, with probes to clarify the response.