The customer asks you to build something you are fairly sure will not solve their real problem. Do you build it anyway?

Short answer

Separate a disagreement about the mechanism from a disagreement about the goal, then test your objection cheaply rather than argue it: a week spent proving the request will not move the number is usually worth more than either refusing or complying in silence.

Keep forward deployed explicit in the answer because that is the concept the interviewer is actually trying to test. A good forward deployed explanation names the trade-off, the failure mode, and the evidence you would use before choosing. Use forward deployed once more at the decision point so the answer reads as judgement rather than a detached example.

Keep forward deployed explicit in the answer because that is the concept the interviewer is actually trying to test.

Assume first that you are missing a constraint

Before treating this as a disagreement, treat it as a gap in your own information, because on an embedded engagement you have been in the building for weeks and they have been there for years. The request that looks pointless is very often serving something you cannot see: a regulator asked for it in a specific form, a previous attempt at the sensible approach failed for reasons nobody wrote down, another department will withdraw its cooperation unless their view is included, or the sponsor needs a visible deliverable before a funding review in order for the rest of the work to continue at all.

The diagnostic question is not "why do you want this" — which sounds like a challenge and produces a defensive restatement — but a question about the outcome. What will be different once this exists, who will do something differently, and how will you know it worked. If the answers are concrete and the mechanism still looks wrong to you, you have a real disagreement. If the answers reveal a constraint you did not know about, the disagreement evaporates and you have learned something that will change other decisions too.

Separate the goal from the mechanism

Most of these situations are disagreements about mechanism, not about purpose, and that is good news because mechanism disagreements are resolvable with evidence. The customer wants a dashboard showing claim ageing across every team, and you believe nobody will look at it and the actual bottleneck is that claims sit unassigned for three days. You both want the cycle time down. You disagree about whether visibility changes behaviour.

Stated that way, the argument becomes a question about the world rather than a contest of judgement, and it also becomes something you can be wrong about. Sometimes visibility does change behaviour, particularly when a manager will now be asked about a number weekly, and an engineer confident that dashboards never help is applying a general prior to a specific organisation they do not know well. Holding your objection as a hypothesis rather than a conclusion is both more accurate and considerably more persuasive.

Test the objection instead of arguing it

The response that separates a strong forward deployed engineer from an adequate one is to convert the disagreement into a cheap experiment rather than a longer conversation. You have access to their data, which means most claims about what will and will not move the number are checkable in days.

If you believe the bottleneck is assignment rather than visibility, measure the current distribution of time spent in each stage and show it. If three of the fourteen days sit in one queue before a human touches the claim, that single figure does more than any amount of advocacy, and it does it without requiring anybody to concede that they were wrong. If the measurement shows the delay is spread evenly across stages and no single queue dominates, your objection was mistaken and you have found that out for the price of a day.

A useful way to put it to the customer, which costs you nothing and preserves the relationship:

"I'll build the ageing view — it's a fortnight. Before I start, give me two days to check something. If most of the delay turns out to be in one place, the view will show you a number you already know and we'd both rather spend the fortnight on the queue. If the delay is spread out, the view is exactly right and I'll get on with it."

That framing works because it commits to their request rather than resisting it, puts a bounded cost on the check, and specifies in advance what result would settle it in either direction. It is very hard to refuse and it removes the interpersonal element entirely.

Building it anyway is often correct

If the test does not settle it, or there is no cheap test, building the thing they asked for while stating your reservation clearly is frequently the right call, and candidates who cannot bring themselves to it are answering a question about their own conviction rather than about the engagement.

Three reasons. You may be wrong, and the cost of being wrong while refusing is much higher than the cost of being wrong while complying. It is their organisation, their money and their consequence to own — you are advising, not deciding. And credibility on an embedded engagement is accumulated by delivering, so an engineer who has shipped three things the customer asked for has standing to be listened to on the fourth, where one who has spent a month litigating scope has none.

What makes this defensible rather than merely compliant is that the reservation goes on the record once, in a form that is factual rather than aggrieved: what you expect to happen, why, and what you would suggest instead. Say it in the meeting, put a short version in writing, and then commit to the work properly. A half-hearted build of something you disapprove of is the worst outcome available, because when it underperforms nobody can tell whether the idea or the execution was at fault, and you will not be believed the next time.

Instrument it so the answer arrives on its own

If you are building something you expect not to work, build in the measurement that will reveal it. Record the metric it is supposed to move, from before it ships. Log whether anyone opens it and how often. Establish, with the customer's agreement and in advance, what evidence would mean this succeeded — usage by the intended team and a movement in the number by a stated date.

This is not point-scoring and it should not be presented that way. It is what turns the engagement into something that learns: in six weeks either the dashboard is used and the number is moving, in which case your prior was wrong and you should update it, or it is not, and the conversation about the assignment queue happens with evidence rather than opinion. Agreeing the success criterion before the build also protects the customer from the more common failure, which is a delivered thing that nobody ever evaluates and that quietly becomes part of the furniture.

Where the line genuinely is

None of the above applies when the objection is not about effectiveness. If the request is unsafe, misleading, or would produce a number that other people will rely on and that you know to be wrong, then "they asked for it" is not a defence and never has been. A model that will make decisions about individuals on a feature that acts as a proxy for something it must not consider, a report that omits a category in a way that flatters a result, a pipeline that will silently drop records feeding a regulatory return — these are refusals, and they are refusals you escalate inside your own firm as well as theirs, because your name is on the delivery.

The distinction to keep sharp is between "I would have done this differently and I think it will underperform" and "this will produce a false statement that somebody will act on". The first is a disagreement you should voice once and then set aside. The second is not a scoping matter at all, and treating it as one — negotiating a compromise, building a slightly less wrong version — is how engineers end up attached to work they cannot defend.

Test your objection cheaply, state it once on the record, then build it properly and instrument it so the customer finds out for themselves. Save refusal for the requests that would make something untrue, not the ones you merely think are misguided.

---

© 2026 Preptima. Originally published at preptima.com.