The Greenfield That Wasn't

“You've been asked to design a new Unified Search from scratch. Three weeks in, you discover the 'clean slate' has four legacy services underneath it with no clear ownership.”

The Situation

You're a Principal Android engineer leading the design of a new Unified Search feature — your company's first cross-product search experience spanning marketplace, messages, and user profiles. Leadership described it as a 'greenfield opportunity.' Three weeks into discovery, you've found that search data lives across 4 internal services, two of which have informal owners (one engineer each), and none of which have a unified API contract. Building on top of them as-is will make your architecture fragile. Rewriting them is 6+ months out of scope.

Context

The 4 services have inconsistent data schemas, different authentication models, and different SLA guarantees
Two of the four service owners are willing to add a search API; two are unavailable for this quarter
The product team has already user-tested the full unified search experience and has strong qualitative signal that users want it
A competitor launched a similar feature 2 months ago — there is time pressure
Your manager has committed to engineering leadership that the feature will ship this quarter

The Question

“Tell me about a time you discovered that a 'new' project had hidden constraints that fundamentally changed the design. How did you adapt without losing the user value?”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I redesigned around the constraints and proposed building a search aggregator service that federated queries to all 4 services behind a unified API — accepting the inconsistent SLAs as a known tradeoff.

I immediately surfaced the constraint discovery to leadership with a revised scope proposal: ship Phase 1 with the 2 cooperative services (marketplace + messages), explicitly excluding profiles, with a dependency on the remaining service owners being available in Q4. I presented the user research signal showing that marketplace + messages covered 80% of the high-value searches, and proposed a federated API design that could add profiles without rearchitecting when Q4 unlocked.

I requested 6 weeks to do a full technical discovery spike across all 4 services before committing to any architecture, to avoid building on a broken foundation.

I escalated to the two unavailable service owners' managers to force their engineers to be available this quarter, since the feature was a company priority.

The Debrief

Why the Best Response Works

Answer B works because it does two things simultaneously: it surfaces the constraint immediately (preserving leadership trust) and it provides a specific alternative that still delivers the user value (preserving the product promise). The 80% coverage point is the business case: if marketplace + messages cover 80% of high-value searches, phased delivery is not a compromise — it's a pragmatic first version. The extensible API design is the principal-level move: it means Q4 is additive, not a rewrite.

What to Avoid

The workaround-in-silence approach is the most common principal engineer failure mode. Building a federated aggregator over inconsistent SLA services 'works' technically — but it bakes in unpredictable latency degradation and makes leadership discover the constraint through a bad user experience rather than a design review. Surprises at launch are leadership trust deficits that are hard to recover from.

What the Interviewer Is Probing

The interviewer is evaluating whether you can operate under organizational constraint without hiding it. Principal engineers who architect around org reality and surface scope changes proactively are trusted with larger systems. Those who silently work around constraints create technical and political debt simultaneously.

SOAR Structure

**Situation:** Greenfield unified search; 4 legacy services; 2 cooperative owners; 2 unavailable; quarter commitment already made. **Obstacle:** Inconsistent schemas, SLAs, and auth models; time pressure; user research invested in full scope. **Action:** Surfaced constraints to leadership immediately; presented 80% coverage data for Phase 1 (marketplace + messages); proposed federated API design extensible to profiles without rearchitecting; revised quarter commitment to Phase 1. **Result:** Phase 1 shipped on time; user satisfaction scores matched full-scope projections; Q4 profiles integration completed with 0 architectural changes.

The Learning Arc

"This taught me that 'greenfield' is a product description, not an engineering one. Every new system is built on existing systems, and those systems have owners, SLAs, and constraints that weren't in the brief. Since this project, I do a 2-day dependency map at the start of every design engagement — not to delay the architecture, but to find the constraints before they become surprises."

IC Level Calibration

senior

Surface the constraints to your manager, propose a phased scope with the cooperative services first, and ask for guidance on the commitment.

staff

Surface the constraints with a scope revision proposal and an extensible architecture that accommodates the phased delivery. Make the proposal specific enough for leadership to approve without needing to redesign.

principal · Primary Target

Surface constraints immediately with the user research evidence for why the phased approach still delivers the core value promise. Design an architecture that accommodates future service addition without rearchitecting. Make the constraint change a management decision with your recommendation attached, not a unilateral scope reduction.

Company Calibration

Google

Engineering excellence: design for the org, not just the system