Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Rank business capabilities needed for cross-sell and distinguish legal merger, user experience, data consolidation, and technical standardization. Identify regulatory, contractual, and divestiture reversibility constraints.
Establish scale assumptions
- Map customer overlap, identity cardinality, data volume, cross-platform call latency, and expected cross-sell flows. Concentrate early work on the few journeys that realize acquisition value.
Functional and non-functional requirements
- Enable shared identity and selected entitlements, preserve both products’ availability, make ownership explicit, and avoid synchronous cycles. Integration decisions need sunset criteria and accountable product owners.
High-level architecture
- Create an anti-corruption integration layer with federated identity mapping, entitlement exchange, and event-based synchronization of narrowly defined facts. Keep each platform authoritative for its domains until a deliberate domain migration.
Data model and flow
- Use stable cross-company customer and operation mappings with provenance and reconciliation. Events expose business facts through versioned contracts rather than leaking internal database schemas.
Consistency and transaction boundaries
- Shared money, entitlement, and account-linking invariants need one declared authority. Other data may converge with visible freshness; conflicts route to a business-owned resolution policy.
Failure modes and recovery
- Bulkhead cross-platform calls, cache safe entitlements, and design a product fallback if either side is unavailable. Reconciliation finds missed events and duplicate customer links.
Security and privacy
- Re-consent data sharing, align identity assurance, restrict cross-company service accounts, and inventory residency and retention changes. Do not inherit trust merely because networks are connected.
Observability and SLOs
- Measure cross-platform journey success, mapping conflicts, synchronization lag, entitlement errors, and integration dependency availability. Track temporary adapter age and removal milestones.
Capacity and cost
- Short-term duplication and adapters are intentional option value. Compare migration cost per domain against actual product and operational benefit instead of optimizing for a visually unified diagram.
Alternatives and trade-offs
- Immediate consolidation promises simplicity but creates a high-risk freeze. Federation moves faster and preserves reversibility but becomes permanent unless each bridge has a strategic destination and owner.
Evolution and migration
- Deliver identity linking and one cross-sell journey, stabilize contracts, then choose domain-by-domain keep, migrate, or retire decisions. Move data only after authority and customer semantics are settled.
What Staff and Principal candidates should emphasize
- Principal candidates resist equating integration with centralization. They connect architecture to acquisition value, trust boundaries, team ownership, reversibility, and deliberate bridge retirement.
Decision trade-offs
Initial integration
Option A
Consolidate databases and services immediately
Option B
Federate through explicit contracts and mappings
Recommendation:Federate to realize business value quickly, then consolidate only domains with clear ownership and migration economics.
Platform standardization
Option A
Mandate the parent stack everywhere
Option B
Select standards per strategic destination and evidence
Recommendation:Standardize interfaces and risk controls first; choose implementation platforms through domain needs and total migration cost.
Follow-up interview questions
- 01Who owns a customer identity that exists in both platforms?
- 02How do you avoid the integration layer becoming a permanent business-logic service?
- 03What if the acquired platform must later be divested?
- 04Which capability should be migrated first?
Common weak answers and mistakes
- 01Starting with network connectivity and database replication before defining business authority.
- 02Forcing one platform stack for political symmetry rather than product value.
- 03Creating synchronous calls in both directions and a distributed monolith.
- 04Building temporary adapters without owners, metrics, or sunset decisions.
Interviewer evaluation rubric
Proposes data replication and API calls but cannot define domain authority, trust, or phased business value.
Uses federation, identity mapping, explicit contracts, isolation, reconciliation, and domain-by-domain migration.
Adds consent, divestiture reversibility, bridge governance, acquisition metrics, and deliberate keep-migrate-retire decisions.
Uses architecture to preserve strategic options while realizing near-term deal value and reshaping team ownership without a freeze.