Vibe coder or product engineer behavioural interview questions

As asked

Tell me about a time you shipped a feature or fix that caused a production incident. What broke, how did you find out, what did you do to restore the service, and what did you change afterward so it did not happen again?

Sample answer outline

A strong answer walks through the specific incident with concrete details: what changed, what failed, the timeline from detection to resolution, and who was affected. The candidate should show they took ownership, communicated proactively, and focused on restoring service before fixing blame. The retrospective section should include a systemic change like adding a test, changing a deploy process, or adding a monitor, not just 'I was more careful.'

Expect these follow-ups

• How long did it take to detect the issue? What would have made detection faster?

As asked

Walk me through a situation where you had to cut features or simplify a design to ship on time. How did you decide what to cut, how did you communicate that to stakeholders, and did you regret any of those cuts afterward?

Sample answer outline

The candidate should show they have a principled way to triage scope: cutting UI polish before core functionality, shipping a manual workaround before an automated one, or removing a feature entirely when it is not yet validated. Good answers show explicit communication with stakeholders about what is in versus out and why, and demonstrate that the cut did not compromise the core user value. Regret over a cut should be honest and lead to a learning about estimation or product scope.

Expect these follow-ups

• How do you handle a stakeholder who insists every feature must ship by the deadline, even if the quality will be poor?

As asked

Describe a situation where a project required you to use a technology or framework you had little to no experience with. How did you get up to speed, and what did you actually ship?

Sample answer outline

The candidate should describe a concrete learning strategy: docs, small experiments, finding reference implementations, leaning on colleagues. The key signal is how they separate learning from building, and whether they can identify what they actually needed to know versus what was a distraction. A strong answer also shows calibrated confidence: they shipped something that worked, they know the parts they understood well versus the parts they got working without fully understanding, and they followed up to close those gaps.

Expect these follow-ups

• Looking back, what would you have done differently about how you learned that technology?

As asked

Walk me through a product or feature you built entirely by yourself, from idea to users using it. What stack did you choose, what did you cut, what surprised you in production, and what would you do differently?

Sample answer outline

This is a showcase question. A strong answer gives a specific product with concrete choices about stack, scope, and tradeoffs. It shows the candidate can prioritise, handle the full stack from DB schema to UI, and learn from production. The 'what would you do differently' section is where candidates reveal taste and self-awareness. Watch for candidates who say everything went well: production always surprises you.

Expect these follow-ups

• How did you decide what not to build in the first version?
• How did you handle the first real bug a user hit in production?

As asked

You ship a new dashboard feature on Friday. By Monday morning you have a Slack message saying the dashboard is loading in 12 seconds. It was instant in local development. Walk me through what you do in the next 30 minutes.

Sample answer outline

First, confirm the issue is real and scoped: check error monitoring, confirm it is not just one user, and check if production data volume is orders of magnitude larger than dev data. Then instrument the slow path with query logging or APM to find where time is spent. The most common cause for a new dashboard feature is an N+1 query that does not manifest with small dev datasets. A strong answer shows systematic debugging instincts: instrument first, hypothesise second, fix third, and verify with a measurement not an eyeball.

Expect these follow-ups

• At what point would you roll back versus fix forward?

As asked

Your PM tells you a feature needs to ship in 3 days for a sales demo but your honest estimate is 2 weeks at the quality level they described. What do you do?

Sample answer outline

The right move is to present an honest scoped-down version of the feature that can ship in 3 days, explain what is in versus out, and get explicit alignment from the PM on that tradeoff. If they insist on the full scope in 3 days, escalate the risk explicitly: what corners will be cut, what technical debt will accrue, and what is the probability of it being buggy for the demo. The worst move is to silently agree and then deliver a half-finished feature. A strong answer also shows the candidate has built enough credibility with their PM through past accurate estimates that their estimate is trusted.

Expect these follow-ups

• How do you build a track record for your estimates so that PMs trust them?

As asked

Tell me about a specific product or technical decision you disagreed with. How did you raise your concern, what was the outcome, and how did you handle it if the decision did not go your way?

Sample answer outline

A strong answer shows the candidate raised their concern with specific reasoning and data rather than opinion, communicated once clearly and then committed to the decision once made. The outcome does not have to be that the candidate won. What matters is they did not silently comply or aggressively push past the point of productive disagreement. Ideally they mention what they learned about the other perspective.

Expect these follow-ups

• Was there a case where you were overruled, the decision turned out to be wrong, and you had to navigate that?

As asked

Walk me through a situation where you had already built something and then user research or feedback made you significantly change it. How did you process the feedback, what did you change, and how did you decide not to just ignore it?

Sample answer outline

The best answers show genuine curiosity about users rather than defensiveness about existing work. The candidate should describe how they collected the feedback, how they distinguished signal from noise, and the specific change they made as a result. Strong answers also show the discipline to throw away or significantly rework code that did not serve users, even when it represented significant effort.

Expect these follow-ups

• How do you decide when user feedback reflects a real need versus a preference that conflicts with your product vision?

As asked

Tell me about a specific time a code suggestion from an AI tool like Copilot, Cursor, or Claude was wrong in a way that cost you time. How did you catch it, and how did you adjust how you use AI tools as a result?

Sample answer outline

The question tests whether the candidate uses AI tools thoughtfully rather than blindly. A strong answer names the specific failure mode: hallucinated API, confidently wrong security pattern, outdated dependency usage. It shows the candidate has a review habit and does not paste AI output into production without understanding it. The adjustment should be concrete: they now verify any AI-suggested library exists, or they run tests before accepting changes, not a vague 'I am more careful now.'

Expect these follow-ups

• In what situations do you trust AI tool output more versus less?

As asked

Walk me through a situation where you identified technical debt that was slowing down the team. How did you make the case to spend time on it rather than new features, and how did that go?

Sample answer outline

A strong answer ties the tech debt to a concrete business impact: deploy times doubled, two incidents in a month traced to the same root cause, onboarding new engineers takes twice as long. The case to stakeholders is made in those terms, not in technical terms. The resolution can be partial: a two-day refactor extracted from a feature sprint rather than a dedicated debt sprint. Watch for candidates who either always push back on features for cleanliness, or who never push back at all.

Expect these follow-ups

• How do you prevent tech debt from accumulating in the first place when your team is under constant feature pressure?

As asked

Describe a situation where the product requirements were ambiguous or incomplete and you had to make judgment calls to move forward. How did you handle the ambiguity, and looking back, how did your choices turn out?

Sample answer outline

This tests autonomy and judgment. A strong answer shows the candidate identified specific ambiguities, made reasonable assumptions, documented them, and flagged them to the PM or designer rather than silently choosing. They shipped something useful without being paralysed, and they owned the outcome of their assumptions. A good answer also shows they learned to ask better clarifying questions upfront on future work.

Expect these follow-ups

• How do you decide when an ambiguity is small enough to just decide versus when it needs stakeholder input?

As asked

Walk me through a code review where you and another engineer disagreed about the right approach. How did you handle it, and what was the outcome?

Sample answer outline

The question probes for collaborative instinct. A strong answer shows the candidate engaged with the reviewer's reasoning rather than defending their approach from the start, was able to distinguish preference from correctness, and knew when to escalate a deadlock to a third opinion. They should also show they can hold a strong technical opinion while still being open to being wrong.

Expect these follow-ups

• Have you ever changed your code review opinion after initially disagreeing and then re-reading the feedback the next day?

As asked

Tell me about a feature or project where AI tools like Cursor, Claude, or Copilot did a significant portion of the code generation. What was your role, how did you ensure quality, and what could the AI not do that you had to handle yourself?

Sample answer outline

This question tests whether the candidate is a thoughtful director of AI tools rather than a passive consumer. Strong answers show they provided clear context and constraints to the AI, reviewed output critically for correctness and edge cases, owned the architecture decisions, and added tests for the generated code. The parts the AI could not handle are revealing: complex business logic with subtle invariants, security-sensitive code that required careful review, or integration glue that required understanding of the broader system.

Expect these follow-ups

• How do you estimate your own contribution to a feature when AI generated significant portions of it?

As asked

While building a new feature, you discover that your existing API has no authorisation check on an endpoint that returns user data. Any authenticated user can read any other user's data. What are your next steps?

Sample answer outline

Immediate steps: assess exploitability and whether it is already being exploited by checking logs, do not disclose publicly yet. Then fix the vulnerability, deploy the fix, and verify it is closed. Assess if data was accessed: query logs for suspicious access patterns. Notify the security lead or CTO immediately regardless of severity. Determine if there is a regulatory or contractual disclosure obligation. Post-fix: add an automated test that would have caught this, and audit other endpoints for the same class of bug. A strong answer shows the candidate escalates quickly rather than trying to quietly fix and move on, because undisclosed breaches become larger liabilities.

Expect these follow-ups

• How do you prevent this class of bug from being introduced in the first place on future endpoints?

As asked

You are using an AI coding assistant and it suggests storing a user's raw password in the database for a password reset flow. You know this is wrong. How do you handle this moment and what does it tell you about using AI tools on your team?

Sample answer outline

Reject the suggestion, implement the correct pattern of hashed temporary tokens with short expiry, and note that this is a foundational security error that the AI got wrong confidently. The team implication is that AI tools require the developer to have enough domain knowledge to catch these errors, and that security-sensitive code paths deserve extra scrutiny on AI-generated output. A strong answer does not throw AI tools under the bus but articulates a review principle: never blindly accept AI suggestions in security, auth, or data-handling code without understanding and verifying them.

Expect these follow-ups

• How would you write a team guideline for when AI-generated code requires mandatory human security review?

As asked

You are asked to add a payment method to a checkout flow that was written 3 years ago by someone who left the company. There are no tests and limited comments. What is your process before writing a single line of new code?

Sample answer outline

Read the code top to bottom at least once before touching anything, trace the execution path for a happy path checkout to understand data flow, and check git log to understand the history and intent behind odd decisions. Write characterisation tests that capture the current behaviour before making changes, so you have a safety net. Identify the minimal surface area that needs to change to add the new payment method without refactoring everything. A strong answer also mentions not refactoring legacy code while adding a feature unless the refactor is necessary for the feature, because the blast radius of simultaneous changes is hard to debug.

Expect these follow-ups

• How do you write tests for code that was not designed to be testable?

As asked

Your product needs email sending, in-app notifications, and a rich text editor. You could build each from scratch or use a SaaS for each. Walk me through your build-versus-buy framework for a product-focused engineering team.

Sample answer outline

Buy when the capability is not a core differentiator, when the switching cost is low, and when the best-in-class third party is dramatically better than what you would build in the time available. Email sending is a clear buy: deliverability alone requires years of infrastructure work. A rich text editor is a closer call: ProseMirror or Tiptap are open source and give you full control, while a SaaS editor has vendor lock-in. Build when you need to own the data, when the SaaS pricing model becomes punitive at scale, or when the capability is the product itself. A strong answer also mentions the hidden cost of third-party integrations: you own the integration layer, the debugging when their API goes down, and the migration if they shut down.

Expect these follow-ups

• Has a build-versus-buy decision ever come back to bite you? What happened?

As asked

Your product lead says the team is moving too slowly and suggests skipping unit tests to ship twice as fast. How do you respond and what evidence do you use to make your case?

Sample answer outline

The right answer is nuanced. Some tests do slow you down with minimal return: testing implementation details that change every refactor, or 100% coverage of trivial getters. But tests for business logic, auth flows, and payment processing pay for themselves quickly in prevented bugs. The candidate should agree to reduce low-value test coverage rather than eliminate tests entirely, and tie the argument to specific past incidents where a test would have caught a production bug. A strong answer also notes that the team's current test coverage baseline matters: a team with no tests that adds targeted integration tests for critical paths will ship faster than one with no tests because they spend less time debugging prod.

Expect these follow-ups

• What kinds of tests give the highest return for a fast-moving product team?

As asked

Your growth lead asks you to implement a confirm-shaming cancel flow where the cancel button says 'No, I want to be less productive' and is styled to be nearly invisible. How do you respond?

Sample answer outline

The candidate should push back by naming the tactic as a dark pattern, explain the reputational and trust risk to the product, and offer an alternative: clear cancellation with an exit survey to understand why users leave. If the growth lead insists, escalate to the product lead or CTO with the same reasoning. A strong answer shows the candidate has a line they will not cross for short-term metrics and can articulate the business case for user trust rather than just citing personal ethics.

Expect these follow-ups

• Where is your personal line between aggressive growth tactics and dark patterns?