Consulting and Customer-Facing Roles

The promise changes while you are speaking

Imagine a customer simulation. A strategic account wants a bespoke approval workflow by the end of next month. The account lead says the renewal may depend on it. Product is wary of another one-off feature, and engineering knows the current workflow engine cannot support arbitrary rules safely.

The interviewer asks you to run the first customer conversation.

This prompt looks like a test of diplomacy. It is really a test of whether your engineering judgment survives contact with other people’s urgency. The customer may use workflow to mean an audit trail, a delegation rule, a new screen, or a complete policy engine. “End of next month” may be a production deadline, a board demonstration, or the date when someone needs a credible plan. Until those meanings are known, an estimate is only a guess wearing a calendar.

The work is public in a way that many engineering interviews are not. Your questions affect the customer. Your estimate can constrain a delivery team. Your explanation may become the account lead’s next sentence. A strong answer therefore has to preserve three things at once: the customer’s outcome, the truth of the system, and a next move someone can rely on.

Ask questions that can change the promise

Weak discovery collects background. Strong discovery finds facts that divide the available paths.

Begin with the work. Who requests an approval, who may grant it, and what is allowed to happen afterward? Ask for one recent example and trace it from request to decision. Find the current workaround and the failure it creates. Then locate the deadline: what event happens next month, and what would count as useful progress by then?

In the modeled conversation, the answers change the problem. Approval requests already exist in the product. Administrators export them to a spreadsheet so a regional director can delegate decisions while managers are away. The real need is to record who possessed authority at the time of approval and to show that record during a quarterly control review. Only twenty administrators are in the first region. Next month’s event is a demonstration to the review team, not a company-wide launch.

Those facts are more valuable than a long requirements inventory. They reveal that the first useful claim might be smaller than “bespoke workflow”: explicit delegation, an immutable decision record, and a review export for one group. They also expose questions that could still overturn that slice:

• Must delegation be scheduled, revoked immediately, or approved by another person?
• Which system is authoritative for employee identity and manager status?
• Does the review require a reproducible export or merely a visible screen?
• May an administrator correct a bad assignment after a decision, and how must that correction appear in history?
• Who can accept a manual bridge for the demonstration, and who decides whether it is safe enough for real approvals?

Each question earns its place because a different answer changes scope, architecture, or authority. “I would gather requirements” hides this reasoning. Tracing one approval lets the interviewer hear it.

Put a boundary around the noun

Once the outcome is visible, say what the current conversation can and cannot promise. For this case, a candidate might offer the following boundary:

For the review demonstration, we will support one administrator group with
time-bounded delegation and a downloadable decision history. The existing
identity directory remains authoritative for active managers. We will not yet
promise arbitrary approval rules, write-back to the customer's HR system, or
a production rollout. Those decisions follow validation of identity changes,
revocation, and the review team's evidence needs.

This is not a polite refusal. It is an engineering claim with edges. It gives the customer something concrete to correct, gives product a coherent slice to evaluate, and gives engineering a source-of-truth decision before anyone draws services and arrows.

The boundary should remain negotiable where evidence is missing. If the review team actually requires production records, a demonstration may be useless. If delegation must propagate back into the HR system, the source-of-truth model changes. If the existing product already records the required evidence, the right answer may be configuration and training rather than new code. Discovery has not succeeded merely because the first request became smaller.

Estimate the next reduction in uncertainty

When trust is on the line, an estimate should help people decide what to do next. A single number offered before the important unknowns are inspected does the opposite.

In this case, separate the estimate you can defend from the plan you can only forecast. You can commit to a short validation pass: inspect representative identity events, confirm the review evidence with its owner, and test whether the existing audit model can represent delegated authority. You can give a provisional range for the demonstration, but attach it to its assumptions and say what will narrow it.

For example:

With the facts we have, I would plan for a two-to-four-week demonstration for one administrator group. That assumes the current audit record can carry the delegator, delegate, effective interval, and decision; it excludes HR write-back and production rollout. I can commit today to a two-day validation pass and a revised estimate on Thursday after we test those assumptions.

The numbers belong to the modeled prompt; the form of the judgment transfers. Scope tells people what was counted. Assumptions reveal the estimate’s load-bearing facts. A range admits variation. The validation milestone purchases better information. A change trigger prevents new work from entering under an old date.

If the interviewer says, “The customer needs one date today,” do not answer with either false precision or a recital of uncertainty. Give the safest commitment available and make its consequence plain: “I can commit to the validation result on Thursday. If you need a date for planning today, use four weeks for the bounded demonstration and do not present it as a production launch. I will recommend a different path if the identity or evidence checks fail.”

Let new evidence change your answer

Customer simulations often introduce a fact after you have started to settle the plan. The interviewer may now say that the customer expects approvers to change decisions from its HR system, and that sales described the demonstration as “the new approval workflow.”

This is where adaptability becomes observable. Do not defend the earlier answer as though consistency were the goal. State exactly what changed. Bidirectional control introduces conflict ownership, authorization, replay, and correction semantics that the demonstration boundary deliberately excluded. Sales and engineering have also used demonstration to mean different things.

A useful response sounds like this:

The write-back expectation changes the safety model, so I would not fold it silently into the earlier estimate. I would show the customer the bounded delegation demonstration on the current date and schedule a separate decision on bidirectional control after we inspect the HR API and agree which system wins a conflict. If write-back is essential to the review, I would reset the date now rather than stage a capability we could not safely operate.

Changing the recommendation in response to evidence is not indecision. The senior signal is preserving the reasoning: what new fact arrived, which claim it invalidated, what remains safe, and who must choose between the new options.

Repair the promise without assigning a villain

Customer-facing conflict usually begins as drift, not confrontation. One person heard “pilot” and imagined real users. Another meant a staged demonstration. An engineer discussed a possible range, and an account plan recorded its early edge as a date. Product believed a customer-specific path would end after the deal; support discovered it had become permanent.

Blame makes the history simpler and the repair harder. Name the mismatch in language everyone can own: “We have used demonstration for two different outcomes. The current plan proves delegated approval history with sample data; it does not let the HR system change production decisions.” Then restore a shared record of scope, assumptions, owner, and next decision.

Firmness belongs here. A customer-facing engineer is not an order taker, and commercial importance does not make unsafe behavior operable. But a useful no contains the need it is protecting. If write-back cannot be made safe by the date, offer the bounded demonstration, a manual evidence path, a later production pilot, or an explicit decision to decline. Explain the customer consequence of each. “Engineering says no” abandons the translation work; agreeing to an undefined workflow abandons the engineering work.

Translate one risk without changing its truth

Translation is not simplification by omission. Consider the identity risk in the case: a manager may be deactivated while a delegation remains active.

To the customer administrator, the consequence is that someone could retain approval authority after it should have ended. To the account executive, it is a reason the production date cannot be promised until revocation behavior is verified. To product, it is evidence that delegation needs explicit lifecycle semantics rather than another configurable field. To an engineer, it becomes questions about directory events, polling gaps, idempotent revocation, authorization checks, historical records, and failure recovery.

The vocabulary changes because each listener has a different decision to make. The underlying risk does not. If the executive version says “minor integration work” while the engineering version says “we do not know how authority is revoked,” the speaker has not translated; they have concealed.

Practice exact sentences, especially when the news is unwelcome:

• “The demonstration date is intact; production use is not yet committed.”
• “We can preserve the deadline by narrowing the outcome, not by hiding the write-back risk.”
• “The current estimate excludes historical backfill. If the review requires it, I will return with a new range after sampling the records.”
• “I recommend the manual bridge for this review because it is bounded and reversible. The product owner should decide whether the recurring need earns a supported capability.”

These sentences are credible because each gives the listener both a boundary and a next move.

Leave the room with inspectable state

A good customer conversation should survive the meeting. The artifact need not be elaborate; it must prevent memory from renegotiating the promise.

Outcome: demonstrate delegated approval history for one administrator group.
Decision today: validate a bounded demonstration; no production commitment.
Included: time-bounded delegation, decision history, review export.
Unverified: manager revocation, correction history, review evidence format.
Excluded: HR write-back, arbitrary rules, historical backfill, broad rollout.
Recommendation: keep the review date with sample data and a manual identity check.
Next evidence: identity-event test and review-owner confirmation by Thursday.
Owners: engineering lead for feasibility; product owner for product scope;
        customer review owner for evidence acceptance.

This note performs real work. It distinguishes outcome from mechanism, records exclusions beside inclusions, and assigns the remaining decisions to people who can make them. A generic risk register or meeting summary would add paperwork without adding safety.

Make the conversation technically expensive to fake

Consulting and customer-facing interviews still require technical depth. The difference is that depth should follow the customer’s constraint instead of arriving as an inventory.

For the approval case, establish one authority for identity and one valid path for changing approval state. Preserve tenant boundaries. Treat duplicate or out-of-order identity events idempotently. Keep a rejected event visible rather than guessing a manager. Record the actor, authority, effective interval, and correction history needed to explain a decision later. Give operators a way to see stale data and revoke access safely. Roll out to a named cohort, define the evidence that permits expansion, and keep a disable path that does not erase history.

Those details give follow-up questions somewhere to land. In system design, trace a manager deactivation through ingestion, authorization, an approval attempt, history, alerting, and recovery. In a practical exercise, make replay and partial failure visible. In a project deep dive, explain the moment real customer data or behavior disproved the clean design. Technical vocabulary earns its place when it protects a customer outcome.

Production judgment also includes support. Who can diagnose a failed identity mapping? What may support inspect without seeing sensitive approval content? How will the customer learn that data is stale? Which condition pages engineering, and which asks an administrator to correct a record? A feature that works only while its author attends every customer call is not a supported capability.

Carry the commitment boundary through the loop

Different rounds expose different parts of the same judgment.

In a customer simulation, ask questions that alter the available paths, reflect the customer’s words accurately, recommend rather than merely facilitate, and close with a bounded commitment.

In an estimation discussion, distinguish the next defensible commitment from the whole uncertain program. State scope, assumptions, confidence, the validation event, and what would force a new estimate.

In system or integration design, connect source of truth, identity, tenant safety, failure visibility, rollout, rollback, and support to the stated customer outcome. Do not draw a generic integration platform around an unexamined noun.

In a behavioral answer, choose conflict with legitimate interests on both sides. Show the evidence you gathered, the language you used to reset the promise, the option you recommended, and how trust was repaired afterward. Avoid stories whose lesson is that sales, product, or the customer finally learned to listen to engineering.

In a project deep dive, make the external consequence present without exposing confidential information. Reconstruct the system class, stakeholder roles, decision, failure, artifact, and result in neutral terms. The interviewer needs the shape of your judgment, not the customer’s identity.

Rehearse the moment the answer stops being easy

Prepare three pieces of evidence: a discovery that changed the requested solution, an estimate you revised when an assumption failed, and a customer-visible disagreement you repaired without hiding the consequence. For each, recover the exact decision you owned, the evidence available at the time, the words used to set the boundary, and what the other party could do next.

Then practice the chapter’s prompt with a partner who withholds information. Begin with the vague approval request. After five minutes, learn that the deadline is a review demonstration. After you offer a plan, learn that the customer expects write-back. After you estimate, hear that the account plan already carries the earliest date. Your task is not to preserve your first answer. It is to revise it without losing the customer outcome, the technical truth, or forward motion.

Write the follow-up note immediately afterward. If it cannot state the outcome, current commitment, exclusions, evidence, owners, and next decision in a few lines, the conversation probably did not reach a usable conclusion.

Investigate the employer with the same care. Ask who owns promises made before engineering discovery, how estimates are revised, where customer-specific work lives, who supports it after launch, how recurring needs reach product, and who may accept a commercial exception. The answers reveal whether the role has real decision authority or is expected to absorb contradictions indefinitely.

Customer-facing seniority is not a talent for making every room comfortable. It is the ability to leave a tense room with a truer promise: narrow enough to build, useful enough to matter, and explicit enough that nobody has to guess what happens next.

Related links

• Company Research and Interview Intelligence
• Communicating Trade-Offs Like a Senior Engineer
• API Design
• Cross-Functional Stakeholders
• Customer-Facing and Forward-Deployed Engineering