You join as the architect for a 60-service estate you have never seen. What do you do in the first month?

What the interviewer is testing

Whether you build understanding before making pronouncements, and whether you know what to look at first.

Weeks 1–2: understand the reality

Follow a request end to end, in production, through every hop. This teaches more about the true architecture in a day than any documentation.

Read the last six months of incidents. They tell you where the system is actually weak, which is frequently not where the documentation or the team's anxiety suggests.

Look at the delivery metrics — lead time, deployment frequency, change failure rate, per component. These identify where the pain is objectively rather than by whoever complains loudest.

Talk to on-call engineers, who know more about the system's behaviour than anyone.

Find out what the business is trying to do over the next 18 months, because architecture serves that and not the other way round.

Weeks 3–4: identify the leverage

Map the estate at low resolution: services, ownership, dependencies, data stores. Derived from traces, build manifests and access logs rather than from a register, which will be wrong.

Identify the few things that are structurally significant — the shared components everything depends on, the boundaries that generate the most cross-team coordination, the data model at the centre.

Find the one or two problems that, if fixed, unblock everything else. There are usually one or two, and they are usually already known to the team.

What not to do

Do not propose a target architecture in month one. You do not yet know which constraints are real and which are historical, and a plan produced without that knowledge is the fastest way to lose credibility.

Do not begin with what is wrong. Every estate has obvious flaws, most of which the team knows about and has reasons for.

What to deliver at the end of the month

A shared understanding of the current state, the two or three highest-leverage problems with evidence, and one small, useful thing already done. Credibility is earned by contribution, not by analysis — and the first visible contribution is what buys the standing to propose larger changes.

What a strong answer adds

Asking each team what they would fix if given a month. The answers converge, and the convergence is usually the right priority list — arrived at with the teams rather than delivered to them.

Common weak answers

A target architecture and a maturity assessment. A tooling or technology recommendation before understanding the constraints.