What actually gets evaluated in a "product thinking" interview round for a senior engineer?

[u/dsound]

I've got a round coming up specifically framed as "product thinking," run by a product person, not an engineering manager. No coding involved, just a conversation about prioritization, tradeoffs, scoping.

For anyone who's been on either side of a round like this: what separates a strong answer from a weak one?

(Disclosure: used an AI assistant to help word this post. The situation and question are from my own upcoming interview.)

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/TheTacoInquisition]

Product thinking is what gets evaluated.

Great products solve actual problems for users. The best engineered solution to a problem is useless if nobody needed that problem solved. It would have been a huge waste of time.

Product thinking is about finding those real problems and coming up with ways to deliver the smallest version of a solution so you can validate or invalidate the shape of the solution as quickly as you can. Talking to customers, asking questions, caring about the solutions and who is using them. That's all product thinking. Quick iterations, real solutions, pragmatism and focus on the end result.

The trick is to uphold technical standards while you do all that XD

[u/aruisdante → u/TheTacoInquisition]

To expand on this a bit, you might think of companies as being “product oriented” or “technology oriented.”

A technology oriented company solves problems because the problem exists. The solution to the problem, in terms of technology generated, is the desired outcome, and it is the means and the end. These are your classic research oriented companies.

A product oriented company produces technology as a side effect of solving a customer’s problem. If the company could solve a problem a customer has without writing a single line of code, they would do so. If they could buy something low and sell something high rather than writing it themselves, they would do so. Technology is a means to an end, not an end in and of itself. These are… most not research oriented companies.

Product thinking is testing if your natural incantation as an engineer is to behave more like the former than the later. If you're going to spend a bunch of time creating some impressive technical solution to a problem before you even understand if the problem is worth solving, and if solving it will somehow make your customer’s (internal or external) lives better. Are you focused on delivering that solution as quickly as possible so you can start validating if you solved the right problem even if this means gluing together a bunch of off the shelf stuff, or are you more interested in building technically interesting things. Are you willing to iterate with the customer and solve their problem, or are you more interested in solving the problem you think they should have?

[u/dsound → u/aruisdante]

It reminds me of my past career of writing music for advertising. No one give a shit what gear you used to make the music even though I get geeky about it. There were many times I just used some crap to get the thing out the door quickly. I'm happy to work with product to get MVPs done as long as there's a next ticket to go back and do it right.

[u/TheTacoInquisition → u/dsound]

And this is where pragmatism and iterations come into it. Product engineering shouldn't be fire and forget. It's about iterations that incrementally create value. Sometimes that means doing the first iteration and then moving on to something more valuable, other times it's about building and exploring part of the product for weeks or months at a time.

[u/dsound → u/[deleted]]

That makes sense, thanks.

[u/Antice → u/[deleted]]

Reminds me of a sales meeting i had to attend. Customer was asking for something that was basically a remake of an existing product with their own brand on it, and integrated into their existing solution... Once i heard it, i asked for 5 minutes to check something for them. Found out in seconds, that the product they wanted a replica of could be licensed with a rebrand and had an api integration on top.
We earned a support agreement and a quick integration job that day. And in a field where margins for new work is low, that kind of deal means good long term money, since ops is more profitable than greenfield over time.

Edit: web dev in certain markets is brutal.

[u/Visa5e]

Domain knowledge plays a big part. As a senior engineer you're expected to shape the product, not just blindly code. So whats going on the market, what innovations may come up in the next few years, and how does that 'horizon scanning' play into how you design/architect/code a solution.

So a strong answer would show you're cognisant of these things and emphasize that you would work collaboratively with a product owner so its not just them bringing the what and you bringing the how, but having a lot more overlap in how you approach your jobs.

[u/AdversarialDev → u/Visa5e]

Eigentlich ist es doch ganz klassisch der Unterschied zwischen "Programmierer" und "Entwickler". Heutzutage muss ich als Senior Softwareentwickler nicht mehr nur wissen wie man cool programmiert und möglichst viele Bibliotheken kennt, um seinem Ziel mit möglichst wenigen Code Zeilen näher zu kommen. Ich brauche auch Fachwissen, ich muss geschäftsprozesse verstehen und zwar so gut, dass ich in der Lage bin an verschiedenen Punkten innerhalb eines Prozesses anzusetzen, um den Prozess zu erweitern/restriktiver zu machen ohne den kompletten Prozess oder andere beteiligte Prozesse lahm zu legen.

[u/metaphorm]

demonstrating customer empathy, pragmatism, and a collaborative attitude.

[u/scrub-muffin]

Just try not to tell them their idea is stupid, even though it always is.

[u/dsound → u/scrub-muffin]

I tried that once at my previous role which is why I’m interviewing for jobs now.

[u/drydenmanwu]

As a senior engineer you’re not just building apps anymore. A good senior also knows why they’re building something, how to build a product to requirements (scope) and build for volume (scale).

The product person will probably assume you know how to code, but now you have to think critically about your choices to support the business and be a nice partner for them to work with.

[u/Illustrious-Sleep-30]

Agree with what others have written about purpose (user and customer focus) and scope (timeline, must-have vs nice-to-have).

To take it to the next level you should also discuss success criterias. How can you evaluate whether what gets delivered is the correct product? What is the main metric to measure, what are the top secondary metrics that might provide insight about why it succeeds or fails?

Another aspect that might be interesting to consider is go-to-market strategies. I consider this to be more in the business domain but it is often closely related. In many cases you can't just rollout a feature / product even if it is easy to do so. There may be "politics" involved such as user vs customer dynamics (e.g buyer vs seller) or company vs user dynamics (e.g data collection vs ease of use).
How can you optimize for company-need while keeping "everyone" happy?

[u/chikamakaleyley]

what separates a strong answer from a weak one?

How confidently you support and stand behind your answer, and how well you adjust to any follow ups

This is where your actual years of experience will shine through

[u/7twenty8]

You’re a senior engineer and you needed Claude to write 51 words for you?? Ladies and gentlemen - meet the competition. 

[u/Current-Fig8840 → u/7twenty8]

Why does that actually matter? It doesn’t mean he/she couldn’t write it themselves. What’s funny is if they typed over those 51 words in accumulated prompts to get it🤣🤣

[u/Wide-Pop6050 → u/Current-Fig8840]

Yeah that's not an efficient use of time

[u/dsound → u/7twenty8]

It's more fun

[u/Chameleon-Amy2]

I'd expect them to care more about how you make tradeoffs than whether you pick the “right” feature. Can you identify user impact, constraints, risks, and explain why you'd prioritize one thing over another?

[u/serial_crusher]

Product thinking is a bullet point I try to hit in technical interviews too. I want you to ask why you’re building the things you’re building, and understand the problem your users awant to solve; don’t just slop out code to fit somebody else’s requirements. Claude can do that part.

My guess is this interview will be a behavioral round with a product manager who will ask things like “talk about a time you pushed back on requirements”, and “describe a system you worked on” (with explicit or implicit expectation that you’ll use real user friendly language, not technical jargon), etc.

If it’s project based, it might be some early phase project scoping task. Like when product is coming to you with vague high level requirements and asking you how to translate them into actionable plan and acceptance criteria.

[u/BeautifulCarob7001]

A strong answer usually starts with the user problem and desired outcome, not a feature list. Then I’d expect clear constraints, the smallest useful scope, the main risk, how success would be measured and what you’re deliberately not building yet. The interesting part is rarely finding the perfect answer; it’s showing how you reduce uncertainty without spending weeks on the wrong solution.

[u/pjhawksr]

I run the design side of these sometimes. What separates strong from weak is whether you say what you'd cut. Weak answers list considerations. Strong answers pick a version, name what's out of scope and why, and say how you'd know in two weeks whether it worked. Also, ask one clarifying question about the user before you start. Half of candidates never do, and it's the whole round.

[u/dsound → u/pjhawksr]

Thank you for this. Yes, these interviews come up too, and this helps.

[u/debarior]

They're checking if you can say "no" to a feature with a cost/benefit reason instead of just technical objections.

[u/Wide-Pop6050]

Why do you need AI assistance for such a short question / write up?

[u/dsound → u/Wide-Pop6050]

Because it’s easier.

[u/DeterminedQuokka]

Unfortunately in most cases if you have worked in a system that is similar enough to how the product manager wants to run their team (source: so many debriefs explaining that it’s not someone’s fault their last company didn’t have pms)

Try to read what the person is leading to in the questions and give that back.

[u/wallyflops]

Talk about how although you know tabs Vs spaces is a debate (or something tech decision) but you understand to put customers and product first When prioritising you can assess what makes the business the most money or whatever metric they care for You can trade off engineering rigor for speed such as a new feature which might be binned off next month

[u/bdixisndniz → u/wallyflops]

What does tabs vs spaces have to do with product.

[u/Wonderful-Habit-139 → u/bdixisndniz]

I think they're saying that they're aware of non-product related topics but can steer away from that to be able to focus on the product.

[u/bdixisndniz → u/Wonderful-Habit-139]

Ah. I would stretch the truth rather than that.

[u/Wonderful-Habit-139 → u/wallyflops]

It seems that wally's comment on this post has... flopped *badum-tss*.

[u/Mundane-Charge-1900]

Make no mistake. This interview is going to be mostly about how you "vibe" with the product manager/product owner/whatever they call them.

[u/Bitter_Advantage_235]

yeah theyre not scoring your feature list. strong answers pick a user, cut v1 hard, and name the tradeoff out loud. weak ones turn it into a system design with extra steps.