Interview Questions

Here is my list of interview questions to ask candidates during your hiring process. This isn't my full process, nor the only thing I ask. More on that another time.
I have added commentary to help you understand my thoughts on them, what they are trying to achieve, and how well they work. While the wording of questions is often deliberate, I don't always strictly adhere to it.
I have given my indication of how much I like a question with stars (★) from 0–3. I don't list bad questions here (unless they are untested and I'm not sure yet), so even 0 stars is good.
Very few of these questions are intended to be asked in isolation. They start a conversation and should be followed up. A follow-up is generally a gentle "why?" e.g. "That's interesting, did you try x?" "How did you solve for z?" "I have found that with stand-ups too, but as a remote team, how did you stay connected?"
You will notice a lack of specific technical questions. I don't really ask them; exam questions are for those without experience where there aren't better alternatives. I test experience, values, and culture. I care less about whether they know X and more about whether they could learn it quickly and effectively.
If you found this useful, consider subscribing to Brilliant People, Exceptional Teams for updates about content here and more content about leading data teams.
Introduction/Phone Screen Questions
Based on your own research and previous conversations, can you tell me what you think [Company] does? ★
Have they researched the company at all? Have they even spent five minutes on the website? I want people who care about the role. They don't have to be the company's main evangelist, but they should have spent some time looking into the job they will spend the majority of their waking hours at.
People who have clearly not even been on the website very rarely do well in the rest of the process.
What was interesting about [Company] and the role? ★
A better variation on "Why do you want this job?". Generally, I want enthusiasm for the role; it should match what they are looking for and how they want to progress. The values and ways of working we demonstrated in the job ad should be attractive. Enthusiasm for the company mission is always good, but it's role and company-dependent how much that matters.
You want someone who will be happy and engaged in the role, who will grow and excel in it.
Why are you looking to leave your current role?
Standard question. You are looking for red flags and that their goals align with what you can offer. For example, if they were applying for a manager role but looking for an opportunity to be a C-level within 1-2 years (and this is very unlikely to be available at your company), then you should know that, and you should let them know (this has happened!).
Can you give me a five-minute summary of your work experience to date?
Whilst their CV should have most of this, having them explain it leads to a much more natural conversation. Five minutes is a good amount of time. You should cut them off if they go too much over.
Write down things to follow up later (e.g. technologies, projects and skills you want to learn more about).
Testing Competence
Questions in this section are multi-part, as follow-ups are essential. Competence is about deep understanding. Bad questions will allow candidates to sail through with surface knowledge, giving you a false sense of security.
This is not the only way I test competence; there will be an article on this soon (subscribe for updates).
What project have you worked on that you're most proud of, and why? ★★
The goal is to unearth the nuanced decisions that only a hands-on contributor would know and understand how they make decisions. If someone struggles to explain a project they claim to be proud of, that’s a significant red flag.
It is very important to dig into the details and not ask this in isolation. It's probably 15–20 minutes and a key part of my hiring manager interview (after the phone screen). I say "proud of" as they should have had deep involvement and still remember the details. It makes the project their choice and gives them little room to not be able to talk about it.
Inquire about their data and decision-making process: Why MongoDB? Why a random forest? What features did you choose, and why? Did you consider alternatives? Which features were most impactful, and how do you know? What would you do next to enhance the results?
There’s no set script here; it’s about exploring something they should know intimately. If candidates can’t answer these questions, it suggests they either mindlessly followed a process or are taking credit for work they weren’t very involved in.
Not every decision requires exhaustive analysis (most don't), but thoughtful responses like, “I chose a random forest because it performs well on our data with minimal tuning” or “Doing that would add complexity but only affect 4% of users, which wasn’t worth the effort” indicate genuine engagement and thought.
Why did you use X method?
Commonly asked to data scientists talking about a machine learning project, e.g., Why a random forest?
What are the advantages of X method over Y method?
E.g., Why did you use a document store over a relational database?
How does X method work?
I don't expect mathematical derivations, but they should have an idea of how a fundamental technology to the project works. I sometimes describe this like a racing car driver and the engineers who build the car. I expect them to be the driver, with a deep understanding of how it behaves and how to use it, but not be able to build the engine themselves.
What lessons did you learn from this project? Is there anything you would do differently in the future?
I prefer this phrasing as it's more forward-looking. I dislike phrasing like "What would you do differently if you started again?" as it focuses more on decisions you would make differently with more complete knowledge rather than lessons you will take with you to future projects.
Asking about technology they have used (either mentioned in the interview or CV) ★★
Treat candidates as experts in the technologies and frameworks they list on their CV.
If you met them at a conference, what questions would you ask them to learn from their experience?
For example:
- You've used MongoDB a lot? When have you found it to be a better choice over SQL? Some of our older infrastructure is on Mongo, and we've had to recreate a lot of relational logic in the application code.
- Have you faced query optimisation issues with GraphQL? We love the flexibility but have heard users can end up running suboptimal queries that can be really tough to fix.
- You say you have deployed LLM-based features? How did you handle ensuring safety and avoiding hallucinations? How did you evaluate how it was performing?
These questions work best when they're genuine — when the candidate should be better versed on the subject than you, but you know enough to ask good questions. You can quickly gauge someone's real-world experience by how well they can teach you the nuances of using it. They might not always know the solution to your specific problem, but if they have real experience, it should lead to an insightful conversation.
It’s a red flag when a candidate has only surface knowledge about the things they have highlighted in their CV.
As an aside for candidates: Don't put things on your CV that you don't want to talk about in an interview!
Case study
The case study is an essential part of my process for testing competence in the role. It is, however, much more than a question and will be covered on its own page at a later date.
Cultural Fit
What ceremonies and processes does your team do, which do you value or not? ★
The reasons are what you're looking for. E.g., I really value retrospectives, and I've had good candidates say they didn't. When I asked why, they explained how their current company runs them and the issues — they have terrible retrospectives! They showed cultural fit in their reasoning by showing what they valued. If I didn't follow up, I would have falsely assumed they didn't value feedback and continuous improvement.
How would you interview [the role you are applying for]? What would be important for you? ★★
Good for managers and senior ICs and above. Okay for mid-levels, not very useful for juniors. It's a great way of drawing out their values, but also how they think about things.
Speed of work vs. quality: On a spectrum, where do you like to be? ★
Either extreme is generally bad, but I'm looking for whether, rather than a rigid view, their view is flexible and dependent on circumstances. You surface a lot of their values here.
What size team do you like working in?
Generally, I have worked in start-ups with small teams. So, if someone likes big teams with lots of support, then they probably aren't a match. It's mostly trying to figure them out and draw out their experience.
What is your preferred working style? How do you prefer to be managed?
I am generally looking for self-starters who can work independently, so it is testing a specific value. However, this also offers an opportunity for candidates to volunteer some red flags or show value alignment.