Project deep dive: full architecture diagram, design decisions and business impact
Company: Oracle
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: medium
Interview Round: Onsite
Several rounds of this interview loop were built around the candidate's own work. The phone screen opened with a detailed walkthrough of a past project, and the technical rounds each began with a discussion of the current project. The hiring manager round went deep into the current project's architecture: the candidate had to draw the complete system architecture diagram, then discuss the business impact of past projects. A final round probed the architectural decisions behind the current and past projects.
Prepare and deliver this deep dive for a project of your own. Treat the three parts below as one conversation with an interviewer who keeps asking "why?" and "what happens if...?".
### Clarifying Questions
- Should the diagram cover the whole system, or only the parts my team owns and the boundaries around them?
- How long should the walkthrough take, and would you like me to pause for questions as I go?
- Some names and figures are confidential. Is it acceptable to generalize them while keeping the structure and orders of magnitude?
- Should the architectural decisions come from the current project only, or may I also use past projects?
### Part 1 — The complete architecture diagram
Draw the full architecture of your current project and walk the interviewer through it.
```hint Follow one request
Pick one representative request or data record and trace it through every component it touches. A box it never touches either belongs to another flow worth showing, or does not belong in the diagram.
```
#### What This Part Should Cover
- The system boundary: users, upstream and downstream systems, external dependencies
- Every component and data store with its responsibility, and how they communicate (synchronous calls, queues, scheduled jobs)
- The scale and reliability figures that explain the design, such as traffic, data size and latency targets
- Which parts you designed or built yourself
### Part 2 — Architectural decisions
For two or three significant decisions in your current project or a past one, explain the context, what you chose, what you rejected and why, and how the choice has held up since.
```hint A decision needs a rejected alternative
A choice is only worth discussing if a reasonable engineer could have chosen differently. For each one, be ready to name the option you rejected and what it would have cost.
```
#### What This Part Should Cover
- The requirements and constraints that forced each decision
- The alternatives considered and the criteria used to choose between them
- Consequences observed after launch, including costs and mistakes
- What you would decide differently today, and what would trigger a change
### Part 3 — Business impact
Explain what your past projects changed for the business, and how you know.
```hint Connect a number to the project
Choose a measure a business owner cares about, and be ready to explain how much of its change came from this project rather than from something else happening at the same time.
```
#### What This Part Should Cover
- A business-facing metric with a baseline and an outcome
- How the effect was measured and attributed to the project
- Your own contribution versus the team's
- The costs, risks or trade-offs that came with the impact
### What a Strong Answer Covers
- A diagram that is complete at one consistent level of abstraction, including data stores, asynchronous paths and external dependencies
- Precise ownership: what you designed, built or decided, versus what the team did
- Decisions defended with constraints, alternatives and real consequences, including what went wrong
- Impact stated with numbers and an honest account of how it was measured
- Composure under probing on failure modes, scaling limits and alternatives, without bluffing
### Follow-up Questions
- If traffic grew tenfold tomorrow, which component in your diagram would fail first, and what would you change?
- Pick the most critical data store in your diagram. What do users experience if it is unavailable for ten minutes?
- Which decision would you reverse today, and what would reversing it cost?
- How did you get agreement on a design that others initially opposed?
Overview: A project deep-dive interview question that asks you to draw the complete architecture of your current project, defend its key design decisions against alternatives, and explain the business impact of your past work. It tests understanding of the whole system, clear ownership, trade-off reasoning and quantified results under probing.
Read the full Oracle Software Engineer interview experience this question came from