#What Is Actually Being Assessed

Before studying anything, get clear on the job. A Chief Architect loop is not a senior-engineer loop with harder questions. It is a different evaluation with different failure modes.

#1. The job behind the job description

The bullets you were given:

• Lead architecture across enterprise Databricks engagements
• Design secure, scalable and high-performing Lakehouse platforms
• Deep expertise in Apache Spark, Delta Lake and Lakehouse architecture
• Remain hands-on with Spark performance, debugging and optimisation
• Deliver Databricks solutions at enterprise scale

Read these as a set and a specific shape emerges. This is a player-coach engagement architect:

• "Lead architecture across engagements" (plural) → you are not owning one platform, you are the authority pattern across many. They will test reusability of your thinking: do you have patterns, or just war stories?
• "Secure, scalable, high-performing" → three named non-functional axes. Expect at least one question on each, and expect to be asked to trade them off against each other.
• "Remain hands-on" → the organisation has been burnt by architects who cannot open a Spark UI. There will be a live or verbal debugging exercise. This is the bullet most candidates under-prepare, and the one most likely to be the differentiator.
• "At enterprise scale" → multi-team, multi-workspace, regulated, migration-heavy, cost-scrutinised. Your examples must have organisational complexity, not just technical complexity.

The synthesis to say out loud in the room:

"The way I read this role, it's the person who makes architecture repeatable across engagements — so that the tenth customer gets the benefit of the first nine — while staying close enough to the metal to be credible when a pipeline is failing and everyone is looking at you."

#2. The competency model

Every senior architecture loop scores some version of these seven. Grade yourself 1–5 honestly now, and again after the sprint.

Competency 7 is scored more heavily than candidates expect. Databricks field loops in particular are widely reported to test whether a candidate can absorb feedback mid-interview and implement it. If an interviewer redirects you, the correct response is not to defend — it is to say "that's a better frame, let me redo that part" and visibly do it.

#3. The four ways senior candidates fail

Know these; they are avoidable and they are the entire margin.

1. Feature recitation instead of judgement. Asked "how would you design X", the weak candidate lists Databricks features. The strong candidate states the two or three decisions that actually determine the outcome, picks one, and says what it costs. Antidote: every design answer must contain the phrase "the trade-off here is…".

2. No discovery. Jumping to architecture without asking about volumes, latency, team skills, regulatory constraints, incumbent estate, or budget. In a field role this is close to disqualifying — it is literally the job. Antidote: the first 3–5 minutes of any scenario answer are questions, always.

3. Stale product knowledge. Saying "Delta Live Tables" when the product is now Lakeflow Declarative Pipelines, or not knowing what shipped at the last summit. It reads as "this person stopped learning two years ago" — fatal for a role whose value is being current. Antidote: 01-platform/09-platform-2026-whats-new.md.

4. Altitude lock. Either stuck high (all strategy, cannot explain a shuffle) or stuck low (all internals, cannot say why the CFO should care). The role explicitly requires both. Antidote: practise the altitude ladder below.

#4. The altitude ladder

The single most valuable drill in this repo. Take any topic and explain it at four altitudes. You should be able to move between them on command, because interviewers switch deliberately to test range.

Worked example — liquid clustering:

Do this for: Photon, Unity Catalog, AQE, MERGE, medallion, serverless, Delta Sharing, vector search.

#5. Evidence inventory

Senior interviews are won with specifics. Before you study anything else, fill this in. Twenty minutes now saves you from vague answers later.

For each of your last three or four significant engagements:

The last row matters most. "We tested truth-seeking and they had no self-critical example" is a common scorecard comment. Have two genuine failures with what you learned, and do not pick fake failures ("I care too much").

If you cannot fill the numbers row from memory, estimate and mark it as an estimate — in the room say "order of magnitude, roughly X". Confident estimation beats vagueness; false precision is worse than both.

#6. Two-variant positioning

You are covering both archetypes, so prepare two versions of your opening pitch and know which room you are in.

Variant A — field / delivery architect (Databricks or an SI practice)

"I've spent the last N years as the architect customers get when the Databricks programme is big enough to fail publicly. My value is that I've seen the same ten problems across different industries, so I can tell a customer in week one which of those they're about to hit. I stay hands-on because credibility in those rooms comes from being able to open the Spark UI and tell them what's actually wrong."

Variant B — enterprise chief architect (customer side)

"I build the platform and the operating model around it. The technology decisions are maybe 40% of it — the rest is the governance model, how teams onboard, how cost stays defensible to finance, and how we avoid the 'we bought Databricks and now have 200 unmanaged workspaces' failure mode. I stay hands-on because architecture that hasn't been pressure-tested against a real workload is just a diagram."

Both are the same person. The emphasis moves; the substance does not.

#7. What to do next

1. Fill in the competency grid (§2) and the evidence inventory (§5) — do it now, not later.
2. Read 02-interview-loop-playbook.md to see how the rounds work.
3. Start the sprint in 03-ten-day-sprint.md.