You have inherited a system nobody left behind any knowledge of, and you have two weeks to produce a plan. Walk me through it.

The brief behind the brief

Two weeks is not enough to understand the system, and pretending otherwise is the fastest way to fail this question. It is enough to understand what the system does for the business, where it is most likely to hurt you, and what to do first. Say that framing out loud at the start, because it tells the interviewer you know which deliverable is being asked for. The output is a plan under uncertainty, not an architecture.

It also matters why you were handed this. A plan requested after an incident needs a different first week from one requested because a rewrite is being considered or because the last team resigned. Ask, and let the answer set your emphasis.

Week one: build the map from evidence

Documentation is a description of a system that may once have existed. Code tells you what is possible, not what happens. Prefer sources that reflect the system as it is running, in roughly this order.

Follow the money and the traffic first. Which endpoints and jobs carry revenue, which have contractual commitments, and where does load concentrate. The cloud bill is an underrated architecture document: it tells you what is big, what is always on, and which datastores exist, including the ones nobody mentioned.

Read the incident and support history. Six months of incidents and the support team's ticket categories will tell you the real failure modes and the real fragility, in priority order, for free. This is the highest-yield hour of the fortnight and the one candidates most often skip.

Read the deployment pipeline and the last hundred deploys. How often can this system change, who changes it, how long a release takes, and what has to be done by hand. Change capability determines every option in your plan, so establishing it early prevents you from proposing work the system cannot absorb.

Derive the dependency map from telemetry, network flow logs, or database connection sources rather than from a diagram. Then instrument the gaps immediately — request rates on the entry points, error rates, and a way to follow one request end to end. Adding observability is legitimate week-one work because everything after it depends on being able to see.

Verify one restore. Not the backup configuration, an actual restore of something into somewhere. It is the single fastest way to find out whether the organisation's belief about its own resilience is true, and it is frequently the most important finding in the report.

Ask the same five questions of everyone

Interview widely and cheaply: current engineers, the operators and on-call staff, support, the product owner, whoever ran it before if they are still reachable, and one customer-facing person. Use a fixed set of questions so the differences between answers become data.

Question	What the answer tells you
What breaks most often, and what do you do when it does?	The real failure modes, and how much undocumented manual operation exists
What part would you not touch, and why?	Where the fear is, which is usually where the coupling is
What takes longest to change, and what makes it slow?	Whether the constraint is architecture, process, or a single person
If something is wrong in production, how do you find out?	Whether you have observability or customers as your monitoring
Who has to be asked before you release?	The real ownership and decision structure, which will not match the org chart

Two patterns are worth listening for. Where several people give the same answer, you have a fact. Where one person is named in every answer, you have found the load-bearing human, and reducing that dependency is on the plan whether or not anything else is.

Week two: write a risk-ordered plan

Turn the evidence into a small set of artefacts. Keep them short enough that an executive reads all of them.

A one-page context diagram: the system, its consumers, its dependencies, and where the data of record lives. Boxes drawn from observed traffic, with anything unverified marked as unverified.

A risk register of no more than ten entries, ordered by expected harm rather than by technical offensiveness, each with a likelihood, an impact in business terms, and a cheapest available mitigation. This is the document that gets used; the diagram is what gets read.

A ninety-day proposal in three sequenced workstreams — stabilise, then make change safe, then change structure — with the explicit statement that later phases will be re-planned on what the earlier ones reveal.

An unknowns list. Naming what you have not established, and what it would cost to establish it, is the part that builds trust with a technical audience. A two-week plan presenting itself as complete is the least believable artefact you can hand over.

Why stabilise before restructure

The order is not caution for its own sake, it is a dependency. You cannot safely restructure a system you cannot deploy, cannot observe, and cannot restore. So the first workstream is repeatable deployment, alerting on the paths that carry money, a verified restore, and removing the manual steps that only one person knows. None of it changes the architecture, and all of it converts the system from something you are afraid of into something you can work on.

The second workstream buys change capability: a test harness around the highest-risk seam, contract tests at the boundaries, and the removal of the one dependency that makes every release a coordination exercise. Only then does structural change — extracting a component, replacing a datastore, splitting a deployable — become a decision you can make on evidence rather than a leap.

The two answers that lose this question

The first is arriving with a target architecture. A candidate who spends two weeks producing a diagram of where the system should be in three years has answered a question nobody asked, and has done it without the evidence to support any of it. The plan is asked for because someone needs to decide what to do next month.

The second is proposing a rewrite. It is tempting precisely because nobody understands the system, and it is wrong for exactly that reason: the undocumented behaviour you cannot see is the behaviour the rewrite will omit, and it is the behaviour customers depend on. The strong version of this answer says explicitly that a rewrite decision is not available in week two, that it may become available once the system is observable and the true scope of its behaviour is known, and that if it happens it will be incremental. Committing to a rewrite from a position of ignorance is the one move in this scenario that is almost always fatal, and interviewers ask this question partly to see whether you reach for it.

Two weeks buys you evidence and a first move, not understanding — so hand over a risk-ordered plan with the unknowns named, and make the first workstream the one that lets you see and safely change the system at all.