Knowing the concepts is half the job. The other half is showing it under time pressure: telling clear stories, answering rapid technical questions, designing live and presenting a decision. This page turns the rest of the site into an interview plan. It covers the interview loop, the STAR method, a behavioural and a technical question bank, ten timed architecture katas, how to present a case study, and what to ask them.
All examples are generic and illustrative. Replace every [your example] with a real story from your own work, told without confidential details.
A senior or architect hiring loop is a series of 4–7 conversations, and each one tests something different: fit, depth, design thinking, communication and judgement.
| Round | What they assess | How to prepare |
|---|---|---|
| Recruiter / HR screen | Motivation, logistics, red flags | A 60-second "why this role" and a 2-minute career story |
| Hiring manager | Scope match, impact, ways of working | 3 headline achievements with numbers; research their products and strategy |
| Technical deep dive | Real depth, not buzzwords; honesty about limits | One-line answers for 25.4; be ready to go 3 levels deep on your own projects |
| System design | Structure, trade-offs, NFRs, estimation | The interview framework plus 3–4 timed katas (25.5) |
| Case presentation | Clarity, decision-making, handling challenge | A 20-minute deck or whiteboard story (25.6); rehearse out loud twice |
| Behavioural / values | Judgement, influence, ownership, learning | 8–10 STAR stories that cover the themes in 25.3 |
| Stakeholder panel | Communication across audiences, risk awareness | Explain one design for a business, a risk and an engineering listener |
More weight on coding, debugging, design within a service, and code quality. See 23 and 24.
| Plan · week | Pages to cover | Practice |
|---|---|---|
| 2 weeks · week 1 | 20, 03, 10, 08, 14 | 8 STAR stories; 2 katas |
| 2 weeks · week 2 | 12, 19, 17, this page | 1 mock interview; 1 case presentation |
| 4 weeks · week 1 | 01–05: foundations, protocols, scale, distributed systems, caching | Technical bank 25.4, out loud |
| 4 weeks · week 2 | 06–11: data, governance, APIs, APIM, integration, patterns | STAR stories; 2 katas |
| 4 weeks · week 3 | 12–16: security, DevOps, GenAI, agents, banking | 2 katas; record yourself |
| 4 weeks · week 4 | 17–19, 24, this page | 2 mocks; final presentation |
| 8 weeks · weeks 1–6 | About 4 pages a week, in order, plus 20–23 for .NET, cloud and coding depth | 1 kata and 2 STAR stories a week |
| 8 weeks · weeks 7–8 | Revise the remember boxes; re-read 17, 18, 24 | 3 mocks with feedback; polish the presentation |
Ask the recruiter for the exact format: number of rounds, who is on each panel, whether there's a take-home or presentation, and which skills matter most. Most will tell you.
An architect interview is not one test. It's seven different ones 🎯
📞 Screen: why this role, in 60 seconds
🔬 Deep dive: can you go three levels down on what you built?
🧱 System design: structure and trade-offs beat a perfect diagram
📊 Case presentation: problem, options, decision, risks
🤝 Behavioural: influence, conflict, failure, learning
Prepare for each round on purpose. Which round do you find hardest?
#SolutionArchitecture #InterviewPrep #SystemDesign #CareerGrowth
Answer every "tell me about a time…" question as a short story: Situation, Task, Action, Result, plus a final Reflection on what you learned.
| Part | Prompt | Your notes |
|---|---|---|
| Situation | Where, when, what system, why it mattered | [your example] |
| Task | What was I accountable for? What was the constraint? | [your example] |
| Action | 3 things I did; the options; the trade-off; who I influenced | [your example] |
| Result | Numbers; business outcome; what changed for users | [your example] |
| Reflection | What I learned; what I'd do differently | [your example] |
| Themes it covers | Tag it so one story can answer several questions | e.g. influence, migration, trade-off |
Related pages: batch & file integration, CDC, strangler fig, idempotency, ADR.
The example above is invented to show the shape of an answer. Never present someone else's story as your own: interviewers probe, and a second question exposes it fast.
Most interview stories fail in the Action part, not the Result ⏱️
🧩 Situation + Task: 30 seconds, no more
🛠️ Action: 60 seconds of what I did, including the trade-off
📈 Result: a number or a clear before/after
🔁 Reflection: what you'd do differently next time
STAR becomes STARR when you add the learning. That last R is what makes it sound senior.
#InterviewTips #STARMethod #Leadership #SoftwareArchitecture
Behavioural questions test judgement under real conditions: influence, conflict, failure, risk and leadership. Each question has a hidden question behind it.
Want full answers? Each role has its own set of 25 questions with the psychology, the philosophy and a complete STAR(R) answer: 26 Solution architect, 27 Solution designer and 28 Engineering manager.
| Question | They're really testing | A strong answer includes |
|---|---|---|
| Influence Tell me about a time you changed a team's technical direction without authority. | Influence through evidence, not rank | Understood their goals; prototype or data; built allies; outcome |
| Influence How did you get a reluctant team to adopt a standard or pattern? | Empathy and patience | Why they resisted; made it easy (templates, paved road); adoption numbers |
| Conflict Describe a conflict with a senior stakeholder. | Calm, respectful pushback | Their concern restated; options with cost and risk; agreed next step |
| Conflict Two teams wanted opposite designs. What did you do? | Facilitation and fairness | Shared decision criteria first; trade-off matrix; ADR; both teams heard |
| Failure Tell me about an architecture decision that turned out wrong. | Ownership and learning | A real mistake; how you noticed; how you fixed it; what changed after |
| Failure When did a project you designed miss its goals? | Honesty, no blame | Root cause, including your part; recovery plan; lesson applied later |
| Trade-off Tell me about a trade-off you had to defend. | Reasoning under constraints | Options; criteria (NFRs, cost, time); what you gave up and why; review date |
| Trade-off When did you choose the "less elegant" option? | Pragmatism over purity | Business deadline or risk; contained the debt; plan to revisit |
| Saying no Tell me about a time you said no to a business request. | Protecting the business, kindly | Understood the real need; offered an alternative; risk in business terms |
| Saying no How have you pushed back on an unrealistic deadline? | Honest estimation | Data on effort; options (scope, phases, people); agreed plan |
| Leading Describe a large migration you led. | Planning and risk control | Phased or strangler approach; fallback; reconciliation; measurable result |
| Leading Tell me about a major incident you were involved in. | Calm under pressure; learning culture | Your role; mitigation first; blameless review; fix that stopped a repeat |
| Mentoring How have you grown other engineers or architects? | Multiplier impact | Specific person or forum; method (pairing, reviews); their growth |
| Mentoring How do you give feedback on a poor design? | Psychological safety | Questions before verdicts; principles, not taste; follow-up |
| Ambiguity Tell me about a project with unclear requirements. | Creating clarity | Assumptions written down; spikes; small first release; feedback loop |
| Ambiguity How did you design for something likely to change? | Reversible decisions | Seams and contracts; option value; what you deliberately deferred |
| Tech debt How did you get tech debt prioritised? | Speaking business language | Debt tied to cost, risk or speed; small slices; tracked outcome |
| Tech debt When did you decide to live with tech debt? | Judgement on timing | Cost of fixing vs carrying; a trigger to revisit; it was recorded |
| Security Tell me about delivery pressure versus a security or compliance control. | Integrity and risk balance | Didn't bypass; found a compliant path; involved risk early; outcome |
| Security How did you handle a late audit or regulatory finding? | Accountability | Triage by risk; owners and dates; evidence; prevention |
| Vendors Tell me about a difficult vendor or partner. | Commercial and technical maturity | Facts and contract, not emotion; escalation path; exit or fallback |
| Vendors How did you evaluate build vs buy? | Structured decision-making | Criteria (fit, TCO, lock-in, risk); proof of concept; documented decision |
Map your 8–10 stories against these themes. One good migration story can answer "leading", "trade-off", "ambiguity" and "influence" with a different emphasis each time. See also soft skills: trade-offs & stakeholders.
Every behavioural interview question has a hidden question behind it 🕵️
🗣️ "Changed direction without authority?" → can you influence with evidence?
💥 "A decision that went wrong?" → do you own mistakes and learn?
🚫 "Said no to the business?" → can you protect them and still help?
🔐 "Pressure to skip a control?" → do you have integrity under deadline?
Answer the hidden question, not just the spoken one. Which question catches you out?
#BehavioralInterview #SolutionArchitect #Leadership #InterviewPrep
Rapid technical questions check breadth; the follow-ups check depth. Give a crisp one-line answer, then a trade-off, then an example.
| Question | One-line model answer | Read |
|---|---|---|
| CAP in one sentence? | During a network partition you choose consistency or availability; PACELC adds latency vs consistency when there's no partition | 03 · PACELC |
| How does a quorum give consistency? | If W + R > N, every read overlaps at least one node with the latest write | 04 · Quorum |
| 2PC or saga across services? | Saga: local transactions plus compensations; 2PC blocks and couples services | 04 · 2PC vs Saga |
| Why can't you trust timestamps for ordering? | Clocks drift; use sequence numbers, logical clocks or a single partition per key | 04 · Time |
| Cache-aside vs write-through? | Cache-aside loads on a miss (simple, may be stale); write-through updates cache with the DB (fresher, slower writes) | 05 · Strategies |
| What's a cache stampede and the fix? | Many misses hit the DB at once when a hot key expires; use request coalescing, locks or jittered TTLs | 05 · Problems |
| When would you pick NoSQL over SQL? | Known access patterns at large scale and flexible schema; SQL for joins, ad hoc queries and strong transactions | 06 · SQL vs NoSQL |
| Why use CDC instead of dual writes? | CDC reads the DB log, so the event and the data can't disagree; dual writes can half-fail | 06 · CDC |
| How do you make a payment API safe to retry? | An idempotency key stored atomically with the result; replay returns the same response | 08 · Idempotency |
| Token bucket vs sliding window? | Token bucket allows bursts up to a limit; sliding window gives a smoother, more exact rate | 08 · Rate limits |
| OAuth vs OIDC? | OAuth 2.0 delegates access (access token); OIDC adds identity on top (ID token) | 08 · OAuth/OIDC |
| What does an API gateway do that a load balancer doesn't? | Auth, rate limits, transformation, versioning, analytics per API and consumer | 09 · Gateway vs LB |
| APIM versions vs revisions? | Versions are breaking changes consumers choose; revisions are safe, non-breaking changes you roll out | 09 · Versions |
| Exactly-once delivery: real? | Not end to end; use at-least-once delivery plus idempotent consumers (effectively once) | 10 · Guarantees |
| Queue vs event stream? | A queue hands each message to one consumer; a stream keeps an ordered log many consumers replay | 10 · Queue vs Event |
| Orchestration vs choreography? | A central coordinator owns the flow vs services reacting to events; orchestration is easier to see and change | 10 · Orch vs Chor |
| How do you replace a legacy system safely? | Strangler fig: route slices of traffic to the new system behind a facade, one capability at a time | 11 · Strangler |
| mTLS: what does it add over TLS? | Both sides present certificates, so the server also authenticates the client | 14 · TLS/mTLS |
| Zero Trust in one line? | Never trust the network; verify identity, device and context on every request, with least privilege | 14 · Zero Trust |
| Blue-green vs canary? | Blue-green switches all traffic at once with instant rollback; canary shifts a small percentage first and watches metrics | 15 · Deployment |
| Logs, metrics and traces: why all three? | Metrics tell you something is wrong, traces show where, logs explain why | 15 · Observability |
| RPO vs RTO? | RPO is how much data you can lose; RTO is how long you can be down | 03 · DR |
| RAG or fine-tuning? | RAG for fresh or private facts with citations; fine-tuning for style, format or narrow skills | 17 · Approach |
| How do you evaluate a RAG system? | Measure retrieval (recall, precision) and generation (faithfulness, relevance) on a golden set, in CI | 17 · RAG eval |
| How do you keep an AI agent safe? | Least-privilege tools, input and output guardrails, human approval for risky actions, full tracing | 18 · Guardrails |
| async/await: does it make code faster? | No; it frees threads while waiting on I/O, so a server handles more requests at once | 01 · Sync vs Async, 23 |
"I don't know, but here's how I'd find out" beats a confident guess. Interviewers probe until you hit your limit; they're testing honesty as much as knowledge.
An architecture kata is a short, timed design exercise from a brief. You practise turning vague requirements into characteristics, components, trade-offs and a written decision.
Katas started as a workshop format by Ted Neward ("great architects only get to architect a handful of times in their career, so practise"). Do them alone with a timer, or with a friend playing the customer who answers your clarifying questions.
Each brief below is generic and simplified. Make and state your own assumptions about volumes and rules.
Context: customers want a push, SMS or email within seconds of any incoming or outgoing payment, across real-time, card and batch channels.
Requirements: < 5 s for real-time payments; preferences and quiet hours; no duplicates; peaks of 10× on payday.
Hard decisions: one event model across channels; at-least-once plus dedupe; per-channel providers and fallback; what is safe to put in an SMS.
Read: 21 · Notification, 19 · NPP, 10 · Guarantees
Context: staff need one view of a customer across products, but data sits in many systems and use is limited by consent and purpose.
Requirements: near-real-time; consent and purpose enforced on read; audit of every view; mastered customer identity.
Hard decisions: virtual (API composition) vs materialised view; MDM matching; where consent is checked; retention and deletion.
Read: 07 · MDM, 07 · Privacy, 06 · CDC
Context: applicants upload payslips and statements; the lender wants faster decisions without losing control.
Requirements: extract fields with confidence scores; human review below a threshold; full audit trail; decision in hours, not days.
Hard decisions: workflow engine vs choreography; human-in-the-loop thresholds; storing documents securely; model risk and explainability.
Read: 22 · Onboarding, 18 · HITL, 06 · Storage
Context: score transactions in real time and alert customers and analysts on suspicious activity.
Requirements: score in the payment path within tight latency; rules plus ML; case management; feedback loop.
Hard decisions: inline (block) vs async (alert); fail-open vs fail-closed; feature store freshness; false-positive cost.
Read: 22 · Fraud, 03 · Resilience, 10 · Real-time
Context: expose standard data-sharing APIs to accredited third parties, with consent the customer can withdraw.
Requirements: strong security profile; consent dashboard; published availability and performance targets; versioned standards.
Hard decisions: gateway and auth server placement; consent store design; versioning as standards change; protecting core systems from load.
Read: 19 · CDR, 09 · APIM security, 08 · OAuth
Context: show nearby branches and ATMs with opening hours and live status in the app and website.
Requirements: fast "near me" search; status changes within minutes; high read volume; works when the core is down.
Hard decisions: geospatial index choice; CDN and cache strategy; source of truth for status; public vs authenticated API.
Read: 06 · Geospatial, 05 · CDN, 22 · Proximity
Context: produce periodic regulatory returns from many source systems, with reconciliation and sign-off.
Requirements: lineage from report cell to source; repeatable runs; late data handling; segregation of duties.
Hard decisions: ETL vs ELT; lakehouse layering; data quality gates; how to restate a past period.
Read: 06 · Lakehouse, 07 · Lineage, 10 · Batch
Context: agents need fast, correct answers from policy and product documents while on a call.
Requirements: cited answers; no customer data leaking into prompts or logs; answers in seconds; measurable quality.
Hard decisions: RAG design and chunking; permission-aware retrieval; evaluation and guardrails; build on a platform vs buy.
Context: publish account and transaction events from a legacy core so new digital services stop polling it.
Requirements: ordered per account; replay; schema evolution; no extra load on the core.
Hard decisions: CDC vs outbox vs core adapters; partition keys; event schema governance; canonical vs domain events.
Read: 19 · Core & ledger, 06 · CDC, 10 · Events
Context: a critical customer-facing service must survive a region loss within agreed tolerance levels (as APRA CPS 230 expects for critical operations).
Requirements: RTO and RPO from tolerance levels; tested failover; data residency in Australia; cost-aware.
Hard decisions: active-active vs active-passive; data replication mode; DNS or global load balancer failover; how often to test.
Read: 03 · DR, 03 · Multi-region, 19 · Regulation
Finish every kata with a one-page ADR (12 · ADR) and a list of risks. Then compare with the design review checklist and note what you missed.
Architects only design a few big systems in a career. So how do you practise? Katas 🥋
⏱️ 60 minutes, one brief, a timer
🎯 Clarify requirements, then pick the top 3 quality attributes
🧱 Sketch the context and containers
⚖️ Spend real time on 3–4 hard decisions
📝 Finish with an ADR
Try one this week: "real-time payment notifications in under 5 seconds". What's your first hard decision?
#ArchitecturalKata #SoftwareArchitecture #SystemDesign #Banking
A case presentation tests whether you can tell a decision story: the problem, the constraints, the options, what you chose and why, and what could go wrong.
See the C4 model for notation. Label every arrow with what flows and whether it is sync or async.
Let them finish. Restate the question: "So the concern is failover time?"
"Yes, that's a real risk." Defensiveness costs more than the weakness.
"We accepted X because Y mattered more, and we mitigate with Z."
"If volumes grew 10×, I'd revisit by doing…" Shows the decision isn't dogma.
| Heading | What to write (1–3 lines each) |
|---|---|
| Decision | One sentence: "We will…" |
| Context & problem | Why now; business impact; who is affected |
| Constraints | Regulation, budget, deadline, skills, existing platforms |
| Options considered | 2–3 options with one pro and one con each |
| Recommendation & rationale | The option, the criteria it wins on, what we give up |
| Risks & mitigations | Top risks, owner, mitigation |
| Cost & roadmap | Rough cost; phases; first milestone |
| Ask | What you need: approval, funding, people, a decision by a date |
The best architecture presentations spend more time on "why" than "what" 🧭
❓ Problem: what hurts, and for whom
🚧 Constraints: regulation, budget, deadline
⚖️ Options: at least two, honestly compared
✅ Decision: what you chose and what you gave up
⚠️ Risks: name them before the panel does
Defending a design is easier when the trade-off is already on the slide. How do you structure yours?
#SolutionArchitecture #Presentation #C4Model #ArchitectureDecisions
Your questions show how you think about the role. A 30-60-90 day plan shows you can land well. A checklist stops avoidable mistakes on the day.
Keep one page of notes next to you in a video interview: your story list, key numbers and your questions. Glance, don't read.
"Do you have any questions for us?" is still part of the interview 🎤
🏛️ How are architecture decisions made and recorded here?
🧱 What tech debt slows you down most today?
👥 Are architects embedded in teams or central?
🎯 What does success look like in 90 days?
Good questions show how you'll work, not just whether you want the job. What's your go-to question?
#InterviewTips #SolutionArchitect #CareerGrowth #Leadership
About two minutes. Spend most of it on the Action, in the first person, end with a measurable Result and a short Reflection, then stop and let the interviewer ask follow-ups.
Eight to ten strong stories, each tagged with the themes it covers (influence, conflict, failure, trade-off, migration, incident, mentoring, ambiguity). One story can answer several questions with a different focus.
Say so, then reason out loud: what you do know, how you'd find out, and what you'd check. Honesty plus a structured approach scores better than a confident wrong answer.
A short, timed design exercise from a brief: clarify requirements, choose the top quality attributes, sketch components, discuss trade-offs, and record a decision. The format started as a workshop by Ted Neward.
Problem and goals, constraints and NFRs, two or three options, the decision and design (C4 context and containers), risks and mitigations, roadmap and outcome, then a short summary. Leave time for challenge questions.
Learn (stakeholders, systems, pain points) in the first 30 days, contribute (a quick win, design reviews, a first ADR) by 60, and lead (an agreed target state and roadmap) by 90.