Product sense interviews for engineers

More engineering loops now include a product round, especially for senior, staff, full-stack, founding, and product-engineer roles. If you've never had one, it can be disorienting: no code, no architecture diagram, just a prompt like "how would you improve this feature?" and an interviewer waiting to hear how you think about users.

Most advice about product sense interviews is written for product managers. This guide is for engineers: what the round is checking when the candidate is an engineer, how it differs from a PM interview, a structure for your answer, and how to prepare.

What a product sense interview is

A product sense interview asks you to reason about a product: who it's for, what problem it solves, what to build, and how you'd know it worked. Typical prompts:

• "How would you improve our onboarding?"
• "Design a feature that helps users who abandon their cart."
• "Engagement went up last month but retention went down. What might be happening?"
• "You have two engineers and six weeks. What would you build first?"

It's usually 30 to 45 minutes, often one open prompt explored in depth, with the interviewer adding constraints as you go.

Do software engineers have product sense interviews?

Some loops include one, and the job description often hints at it. Look for words like "ownership", "customer impact", "product thinking", "work closely with product and design", or "product engineer". Startups often fold product questions into a founder conversation. Roles where engineers decide what to build, not just how, are the most likely to have a dedicated round.

When the round is there, it's checking whether you can connect technical work to users and outcomes. Interviewers generally look at:

• User focus. Do you start from who the product serves and what they need?
• Prioritisation. Can you choose a first version and cut scope deliberately?
• Measurement. Do you know how you'd tell whether it worked, including side effects?
• Engineering judgement. Do you weigh impact against effort, risk, and maintenance?

How it differs from a PM interview

The structure is similar, but the emphasis shifts:

Your advantage as an engineer is technical realism. You can say which solution is a week of work and which is a quarter, which one has risky dependencies, and how a smaller first version could test the idea before committing to the expensive one. Use it.

A structure for your answer

Say your structure up front so the interviewer can follow, then move through it. A common path:

1. Goal. What is the product or company trying to achieve with this? Ask if it's not clear.
2. Users. Who are the users, and which segment will you focus on? Say why that one.
3. Problems. What are that segment's main problems or unmet needs, related to the goal?
4. Solutions. Two or three ideas that address the most important problem.
5. Prioritisation. Choose one, and explain why, including what it costs to build.
6. Metrics. How you'd measure success, and what could go wrong.

Spend most of your time on steps 5 and 6. That's where engineers can stand out and where weaker answers stay vague.

Choosing a user segment

Don't try to solve for everyone. "New users in their first week", "small businesses with one admin", or "users on slow mobile connections" are focused enough to reason about. Say why you picked the segment: it's the largest, the most underserved, or the most tied to the goal.

Prioritising

Make one clear call and defend it. A simple way to reason out loud is impact against effort: how much would this move the goal, and what would it take to build and maintain? Then say what you'd build second, and why not first. If the interviewer adds a constraint ("you only have two engineers"), revisit the call openly rather than defending the original plan.

Metrics

Propose:

• One primary metric tied to the goal, such as the share of new users who complete setup in their first week.
• A couple of supporting metrics that explain movement in the primary one.
• At least one guardrail that would catch harm elsewhere: support tickets, churn, page load time, or complaints.

Explain why each metric reflects the behaviour you want, not just that it's easy to count. Then add the engineering view: how you'd instrument it, and how you'd roll out the change (behind a flag, to a small percentage first) so you can see the effect before committing.

An example, briefly

Prompt: "How would you improve onboarding for our project-management tool?"

An illustrative outline of a strong answer:

• Goal: more new teams reaching the point where the tool becomes part of their week. Confirm that with the interviewer.
• Users: focus on small teams where one person signs up and invites the others, because their success depends on the rest of the team joining.
• Problems: the person who signs up sees an empty workspace; invited teammates arrive with no context; nobody knows what to do first.
• Solutions: starter templates for common workflows; an invite flow that shows teammates what they're joining; importing tasks from a spreadsheet.
• Prioritisation: templates first. They're cheap to build (data, not new infrastructure), they help the first user immediately, and they give invitees something to look at. The import is valuable but has many edge cases; leave it for later.
• Metrics: primary, the share of new workspaces with three or more active members after two weeks; supporting, template usage and invite acceptance; guardrail, support tickets about setup. Roll out to a share of new signups and compare.

Metric questions: "this number changed, why?"

Some product rounds start from a metric rather than a feature: "Daily active users dropped last week. What would you look at?" or the engagement-up, retention-down prompt above. These are close cousins of debugging questions, and engineers are often good at them once they recognise the shape.

A structure that works:

1. Clarify the metric. How is it defined? Over what period? How big is the change, and is it outside normal variation?
2. Rule out measurement problems. Did tracking change? A release that broke an analytics event looks exactly like a drop in usage. This is where an engineer's instinct helps most, so say it early.
3. Segment. Is it all users or some? One platform, one region, one app version, new users or existing ones? Narrowing the segment usually narrows the cause.
4. Check what changed. Releases, experiments, pricing, marketing campaigns, seasonality, outages, or something outside the company such as a competitor launch or a holiday.
5. Form a hypothesis and say how you'd test it. "If the new onboarding flow is the cause, I'd expect the drop to be concentrated in users who signed up after the release."

For the engagement-up, retention-down case, a good answer considers that both can be true at once: a change might make existing users more active while making the product harder for new users to get into, or a notification push might raise short-term activity while annoying people into leaving. Saying how you'd tell those apart is the strong part of the answer.

Common traps

• Jumping to solutions before saying who the user is and what problem you're solving.
• Listing ideas without choosing. Five ideas and no decision is a brainstorm, not product sense.
• Metrics without reasons, or without a guardrail.
• Forgetting you're an engineer. Ignoring build cost and risk wastes your strongest card.
• Not adapting. When the interviewer adds a constraint, they want to see you adjust.
• Treating it as a test of the company. Pointing out what's wrong with their product can be useful, but frame it around users and opportunities, not criticism. The interviewer may have built the feature you're discussing.
• Running out of time before metrics. Watch the clock. If you're twenty minutes in and still listing problems, move to a decision.

How to prepare

• Use the company's product before the interview, and note two or three things you'd improve and for whom.
• Read the job description for the domain and the product signals. Our guide to preparing from the job description covers how.
• Practise the structure out loud on everyday products you use: a ticketing app, a banking app, your team's internal tools. Ten minutes each is enough.
• Practise metrics separately. For any feature, name a primary metric, a supporting one, and a guardrail, in under a minute.
• Bring real examples. If you've shipped something where you influenced what got built, have that story ready; the STAR method works well for it.

The product round sits alongside the others in the interview loop, and it often shares an interviewer's mindset with the behavioural round: both are asking whether you think beyond the ticket in front of you.

Hardmode's product sense round grounds the conversation in the product and domain from the job description, then pushes on your prioritisation and metrics the way an interviewer would, in 30–45 minutes.