Cloud Architect interview loops

A cloud architect is hired for decisions whose cost arrives later. Which account a team's data lands in, which address range a network is given, where the business recovers when a region goes, what a three-year commitment is bet on, which systems are moved as they are and which are rebuilt on the way: each is cheap on the day it is made and expensive to change once other teams have built on it. The architect rarely builds most of it. They are the person who has to be right about it two years later, and the person who has to get the teams it affects to accept it, in writing, before anyone starts.

That makes the role awkward to interview for in two ways. The first is that the vocabulary is everywhere — every provider publishes a framework of pillars and principles, and a candidate who has read one can talk fluently about all of them. The second is that a whiteboard design starts from nothing, and this job never does: it starts from a platform in one region, a bill nobody has read closely, a data centre with a contract end date, and decisions already marked accepted. So the rounds below hand the candidate something that already exists and has something wrong with it, and score what they notice, what they price, and what they are willing to promise.

The rounds are written to be provider-neutral. A candidate from any of the large providers can take them, and naming a service from their own is welcome; knowing one provider's catalogue is not what is scored.

A loop is a set of round plans in order. Each round scores one to three competencies, every must-have is scored in at least two rounds by different interviewers, and the debrief goes competency by competency rather than round by round, so no single interview decides the hire. How these plans work covers the rest of the method.