Section 29 · Interview

Role foundations: architect, designer, manager, principal engineer

What each of the four roles is, what it owns, how it is measured and what interviewers test: Solution Architect, Solution Designer, Engineering Manager and Principal Software Engineer. Each role section links to the site topics to master. Use it to tune your stories to the role, then answer "what does a good X do?" with confidence.

Roles at a glance Solution architect Solution designer Engineering Manager Principal Engineer Roles working together

29.1 The four roles at a glance Added

The four roles differ mainly in altitude (how high above the code they work), time horizon and what they produce: decisions, designs, teams or code and technical direction.

Dimension	Solution Architect	Solution Designer	Eng Manager	Principal Engineer
Altitude	Solution, up to enterprise	Solution detail	Team	Code up to cross-team
Horizon	3–36 months	Weeks to a release	Sprint to a year	Today to 2 years
Primary output	Options, ACD/HLD, ADRs	LLD, interfaces, data flows	A healthy team that delivers	Code, RFCs, standards
Decisions owned	Solution shape, build vs buy	Interfaces, mappings, detail	People, priorities, process	Tech approach, quality bar
Influences	Execs, risk, business	Engineers, testers, vendors	Team, product, peers	Engineers across teams
Measured by	Fit, risk, reuse, cost	Rework, defects, clarity	DORA, retention, delivery	Tech outcomes, others' growth
Interview stresses	Trade-offs, NFRs, stakeholders	Requirements to design	People and delivery stories	Depth, design, influence

Titles vary. A solution architect in one company is an enterprise architect in another (who works on portfolio and capability, not one solution). Some companies rank staff above principal, others the reverse. Read the job description, not the title.

Which role are you interviewing for? Tune your answers

🏛️ Solution Architect

Lead with business outcome, options and trade-offs. Name NFRs, risk and the ADR you wrote.

📐 Solution Designer

Show requirements to design: interfaces, data mapping, edge cases and a clean handover.

👥 Engineering Manager

Talk people and flow: hiring, coaching, hard conversations, predictable delivery.

🧭 Principal Engineer

Prove depth, then leverage: RFCs, standards and engineers you levelled up.

Altitude: enterprise, portfolio, solution, team, codebase. Know where your role sits.
Architect owns the shape, designer the detail, manager the team, principal the technical bar.
Higher altitude means a longer horizon and more influence without authority.
Titles vary: read the job description and mirror its words.
Tune every story to the role's primary output.

Four roles. Same project. Very different jobs 👇

🏛️ Solution Architect: decides the shape. Options, trade-offs, ADRs.

📐 Solution Designer: makes it buildable. Interfaces, mappings, edge cases.

👥 Engineering Manager: builds the team that builds it. People, flow, delivery.

🧭 Principal Engineer: sets the technical bar across teams, and still codes.

The difference is altitude and time horizon, not seniority. And titles vary by company, so read the job description first.

Which of the four is closest to what you do today?

#SolutionArchitecture #EngineeringManagement #StaffEngineer #CareerGrowth #InterviewPrep

29.2 Solution Architect foundations Added

A solution architect turns business strategy into a target state, a roadmap and guardrails that many teams can deliver safely. They own the cross-cutting decisions, not the code.

1 · The role and its altitude

Altitude	Horizon	Core question
Portfolio / solution, across many teams	6–36 months	"Are we building the right thing, the right way, for the business?"

2 · What you own

🧭 Responsibilities

Target state and roadmap, NFRs, risk, standards, alignment of teams and vendors.

⚖️ Decisions

Build / buy / reuse, cloud and integration strategy, patterns, AI use-case approval.

📄 Artefacts

HLD, ADRs, C4 context views, roadmaps, risk register.

3 · Core competencies

Competency	Good looks like	Evidence to bring
Business alignment	Tech tied to an outcome	Roadmap linked to a KPI
Trade-off judgement	Options, criteria, decision	ADR with rejected options
NFRs and risk	Quantified and tested	RTO/RPO set and proven
Cloud and integration	Patterns fit the context	A standard teams adopted
AI governance	Safe, useful adoption	A GenAI use-case gate
Influence	Consensus without authority	A decision you turned around

4 · Foundation topics to master

Topic	Why it matters
EA toolkit · quality attributes	Target state, trade-offs
NFRs · ADR	Decisions on record
Build vs buy · stakeholders	Investment and influence
Patterns · Strangler Fig	Styles, safe migration
Availability · DR	Resilience targets
Choosing a cloud · 7 Rs	Cloud strategy
Integration styles	Integration strategy
Zero Trust	Security posture
Responsible AI	AI governance
Trade-off cheat sheet	Design rounds

5 · Frameworks and vocabulary

TOGAF ADM: baseline → target → gap → roadmap. See 12.
Capability map, C4 context and container views, ADRs.
ISO/IEC 25010 quality attributes; Well-Architected pillars; ATAM for trade-off reviews.
NIST AI RMF and ISO/IEC 42001 for AI governance.

6 · How you are measured

Reuse: fewer duplicate platforms, legacy retired.
NFRs met in production; few design-gap incidents.
Decision lead time; roadmap delivery; run cost vs forecast.

7 · What the interview tests

Rounds: hiring manager, design kata, case presentation, stakeholder panel and behavioural.

How to answer "What does a good solution architect do?"

Start with the business outcome, not technology.
Name the altitude: many teams, a multi-year horizon.
Three verbs: shape the target, decide trade-offs, guard NFRs and risk.
Give one story with a metric.

8 · First 30-60-90 days

9 · Pitfalls interviewers notice

Ivory tower: diagrams with no run cost.
Tech first: products before the problem.
Governance as a gate, not a paved road.
Too deep: designing every interface (the designer's job).
No exit plan for vendors or AI models.

Altitude is portfolio: many teams, multi-year.
Own the target state, roadmap, NFRs and risk, not the code.
Every big call gets an ADR with rejected options.
Influence comes from evidence and trust, not authority.
Treat AI as a governed capability: use-case gate, evaluation, exit plan.

A solution architect isn't the person who draws the best boxes 🧭

🎯 They start from the business outcome, not the product catalogue

⚖️ They make trade-offs visible: options, criteria, an ADR

🛡️ They turn "fast and secure" into numbers: RTO, p99, error budgets

🛣️ They build paved roads so governance feels like help

🤝 They lead without authority, through evidence and trust

Good architecture is a set of decisions that still make sense in three years. Which of yours would pass that test?

#SolutionArchitecture #EnterpriseArchitecture #TechLeadership #InterviewPrep

29.3 Solution Designer foundations Added

A solution designer takes one solution from requirements to a build-ready HLD and LLD, detailed enough that developers and testers can act without guessing.

1 · The role and its altitude

Altitude	Horizon	Core question
Solution: one change, in depth	Weeks to months	"Exactly how will this work, and fail?"

	Solution architect	Solution designer
Focus	Breadth, strategy	Depth, detail
Scope	Many teams	One solution
Output	Target state, ADRs	LLD, contracts, mappings
Works with	Business, EA, risk	BAs, devs, testers

2 · What you own

🧭 Responsibilities

Requirements to design, traceability, build and test support.

⚖️ Decisions

API contracts, integration pattern, data model, error handling, controls.

📄 Artefacts

LLD, OpenAPI specs, sequence diagrams, field mappings, traceability matrix.

3 · Core competencies

Competency	Good looks like	Evidence to bring
Requirements analysis	Gaps found early	A rule you clarified
API and contracts	Versioned, idempotent	A spec teams built from
Data and mapping	Every field sourced	A mapping with edge cases
Failure design	Retries, timeouts, DLQs	An unhappy path you designed
Security controls	Threats mapped to controls	A threat model you ran
Collaboration	Devs and testers unblocked	Fewer SIT defects

4 · Foundation topics to master

Topic	Why it matters
REST design · idempotency	Contracts
API auth · AuthN vs AuthZ	Controls
APIM versions · policies	Exposure and change
EIP · delivery guarantees	Integration and retries
SQL vs NoSQL · data migration	Data models
LLD · ADR · NFRs	Design documents
Threat model	Security by design
Payment ledger	Worked depth
Design principles · SOLID	Code-level design
Testing strategy	Testable design

5 · Frameworks and vocabulary

C4 container and component views; UML sequence and state diagrams.
OpenAPI for REST, AsyncAPI for events, RFC 9457 problem details for errors.
Enterprise Integration Patterns; DDD bounded contexts.
STRIDE threats; Given/When/Then criteria; a traceability matrix.

6 · How you are measured

Design defects, especially interface defects in SIT.
Rework after review; developers blocked on questions.
Traceability coverage; NFRs met; on-time sign-off.

7 · What the interview tests

Rounds: technical deep dive, API or integration design exercise, LLD walkthrough and behavioural.

How to answer "What does a good solution designer do?"

Contrast with the architect: depth, not breadth.
Walk the chain: requirement → HLD → LLD → test.
Stress the unhappy paths: errors, retries, security.
Prove it with a story: fewer defects or faster build.

8 · First 30-60-90 days

9 · Pitfalls interviewers notice

Happy path only: no timeouts or compensation.
Vague contracts: "returns customer data", no schema.
Strategy talk: an architect's answer to a designer question.
Designing alone, then throwing it over the wall.

Altitude is one solution, in depth.
Architect = breadth and strategy; designer = depth and detail.
Own contracts, data mappings, sequences and error handling.
Design the unhappy paths first.
Every requirement traces to a design element and a test.

A design is finished when a developer can build it without guessing 🔬

📋 Every requirement traces to a component and a test

📜 Every API has a contract: schema, errors, versioning, idempotency

🗺️ Every field has a source, a rule and an edge case

💥 Every call has a timeout, a retry and a plan for failure

🤝 BAs, testers and developers shape it with you

Architects decide where we're going. Designers make sure we get there. What's the first unhappy path you design?

#SolutionDesign #APIDesign #SystemIntegration #InterviewPrep

29.4 Engineering Manager foundations Added

An Engineering Manager builds a team that delivers: the right people, healthy ways of working and predictable, reliable outcomes. You succeed through the team, not your own commits.

1 · The role and its altitude

🎯 One line

Hire, grow and lead engineers who ship the right things, sustainably.

🧭 Altitude

Team(s) and people: 1–3 teams, 5–15 engineers.

⏳ Horizon

This sprint to 2–4 quarters.

2 · What you own

📋 Responsibilities

Hiring, onboarding
1:1s, feedback, performance
Career growth, team health
Delivery, incidents
AI-assisted engineering

⚖️ Decisions

Who to hire
Capacity split: features, debt, ops
Performance, promotions
When to say no

📄 Artefacts

Team charter
OKRs, roadmap
Capacity plan, budget
Hiring plan, growth plans

3 · Core competencies

Competency	Good looks like	Evidence
People	Specific feedback, no review surprises	A promotion you enabled
Hiring	Structured loop, clear bar	Hires retained
Delivery	Small batches, forecast ranges	Predictability gain
Operations	SLOs, blameless postmortems	Repeat incidents down
Stakeholders	Bad news early, in business terms	A scope trade-off won
Change	Pilot, measure, scale	AI rollout with results

4 · Foundation topics to master

🚀 Delivery & ops

🧩 Teams & cost

🎤 Interview

5 · Frameworks and vocabulary

Framework	Say it like this
Team Topologies	Stream-aligned, platform, enabling, complicated-subsystem; limit cognitive load
DORA	Lead time, deploy frequency, change fail rate, recovery time, rework rate
SPACE	Satisfaction, Performance, Activity, Communication, Efficiency; never activity alone
OKRs	Objective plus 3–5 measurable Key Results
Situational leadership	Direct, coach, support or delegate, per person and task

Also: psychological safety (Edmondson), error budget, WIP limits, Conway's law.

6 · How you are measured

Outcomes: OKRs, say/do ratio, DORA trends.
Reliability: SLOs met, on-call load.
People: regretted attrition, engagement, promotions.
Money: on budget, capacity on priorities.

7 · What the interview tests

Rounds: hiring manager, people behavioural, delivery, a lighter system design, a product or peer panel.

🗣️ "What does a good EM do?"

One line: builds a team that delivers sustainably.
Pillars: people, delivery, operations.
One practice per pillar.
Measures: DORA, SPACE, retention.
A story with a number.

8 · First 30-60-90 days

9 · Pitfalls interviewers notice

Hero coder: the team waits on you.
Metrics as targets: ranking teams on DORA.
Surprise feedback at review time.
AI tools mandated without guardrails.

Altitude: team and people. The team's output is yours.
Pillars: people, delivery, operational health.
Use DORA + SPACE as team trends, never to rank people.
Match style to person and task (situational leadership).
Share bad news early; protect capacity for debt and ops.

The best engineering managers I've seen write the least code on the team. On purpose. 👇

👥 People: weekly 1:1s, specific feedback, no surprises at review time

🚀 Delivery: small batches, forecasts as ranges, honest trade-offs with stakeholders

🛟 Operations: SLOs, blameless postmortems, an on-call rota people can live with

📏 Measures: DORA and SPACE trends for the team, never a leaderboard of individuals

🤖 AI tools: pilot, measure, add guardrails, then scale

Your output is the team's output. What did your best manager do that others didn't?

#EngineeringManagement #Leadership #DORA #TeamTopologies #InterviewPrep

29.5 Principal Software Engineer foundations Added

A Principal Engineer is a hands-on technical leader across teams: sets direction, solves the hardest problems and raises the bar for everyone. A multiplier, not a lone hero.

1 · The role and its altitude

🎯 One line

Set technical direction, solve what others can't, make engineers better.

🧭 Altitude

Codebase and systems across teams.

⏳ Horizon

6–24 months for strategy; hours in a P1.

2 · What you own

📋 Responsibilities

Technical strategy
Performance, reliability, scale
Engineering standards
Design and code review
Mentoring seniors

⚖️ Decisions

Cross-team patterns (via RFC)
Which tech debt to pay
Build, adopt or retire

📄 Artefacts

RFCs, ADRs
Strategy doc
Golden-path templates
Prototypes, benchmarks

3 · Core competencies

Competency	Good looks like	Evidence
Depth	Debugs to runtime and OS	A fix, before/after
Design	Trade-offs, failure modes	A design doc you wrote
Influence	RFCs adopted without authority	A cross-team standard
Execution	Lands big migrations	One finished, not abandoned
Multiplier	Others grow	A mentee promoted

4 · Foundation topics to master

⚙️ Fundamentals

🔬 .NET & code

🧱 Design rounds

5 · Frameworks and vocabulary

Idea	Say it like this
Staff archetypes	Will Larson, Staff Engineer: Tech Lead, Architect, Solver, Right Hand
RFC / design doc	Context, goals, non-goals, options, decision, risks; then an ADR
Technical strategy	Rumelt's kernel: diagnosis, guiding policy, coherent actions
Staff Engineer's Path	Tanya Reilly: big picture, execution, levelling up others

6 · How you are measured

Outcomes: latency, cost, availability gains.
Adoption: RFCs and standards used beyond your team.
Risk: repeat incidents down, migrations done.
People: engineers grown. Not lines of code.

7 · What the interview tests

Rounds: system design, a deep dive three levels into your systems, sometimes coding, and influence stories.

🗣️ "What does a good principal do?"

Direction, hardest problems, multiplier.
Name your archetype.
Examples: an RFC, a fix, a mentee.
Partner: architect on big picture, EM on people.
End with a number.

Behavioural prompt	Tests
A cross-team decision you drove without authority?	Influence
The hardest production bug you debugged?	Depth, method
When did you change your mind?	Evidence over ego
How did you grow a senior engineer?	Multiplier

8 · First 30-60-90 days

9 · Pitfalls interviewers notice

Ivory tower: designs with no code.
Hero bottleneck: nobody else learns.
Shiny tech for the CV.
Winning arguments, not alignment.

Altitude: codebase and systems across teams; stay hands-on.
Three jobs: direction, hardest problems, multiplier.
Influence through RFCs, reviews and prototypes.
Know your archetype.
Prove depth with numbers.

A principal engineer isn't the best coder on the team. It's the engineer who makes every team better. 🧭

📝 Direction: RFCs and a written strategy people actually follow

🔬 Depth: the p99 spike, the deadlock, the migration nobody else could land

👀 Standards: reviews that teach, not just approve

🌱 Multiplier: senior engineers who grow into staff

🤝 Partnership: architects on the big picture, managers on people and delivery

Will Larson's archetypes: Tech Lead, Architect, Solver, Right Hand. Which one are you?

#StaffEngineer #PrincipalEngineer #SoftwareEngineering #TechLeadership #InterviewPrep

29.6 How the four roles work together Added

One initiative passes through all four roles: the architect shapes it, the designer details it, the principal makes it technically sound, and the manager gets a team to deliver and run it. Clear handoffs and artefacts stop work falling between them.

RACI across the lifecycle

R does the work · A owns the outcome (one per row) · C consulted · I informed. The product or business owner is accountable for the business case.

Stage	Architect	Designer	Eng Mgr	Principal
Idea / business case	R (feasibility)	I	C (capacity)	C
Architecture & options	A / R	C	C	R (spikes)
Detailed design	C (conformance)	A / R	C	C
Build	I	C (queries)	A	R (with team)
Test / release	I	C	A	R
Run / incident	I	I	A	R (deep fixes)
Improve	A (target state)	C	R (team practices)	R (tech debt)

RACI varies by company. In an interview, say who you'd confirm it with in your first weeks, not that it's fixed.

Friction points and how strong candidates handle them

Friction	Root cause	Strong move
Architect vs principal on tech choice	Standards vs local fit	Write both options in an ADR against agreed NFRs; time-boxed spike decides
Designer vs manager on scope and dates	Design detail vs capacity	Slice scope into a thin first release; make the trade-off visible to the product owner
Manager vs architect on standards vs autonomy	Consistency vs team speed	Paved road plus guardrails; exceptions via ADR, not by silence

Handoff artefacts

Architect → all

ACD, HLD, NFRs

Designer → team

LLD: interfaces, mappings, sequences

Anyone → record

ADRs: decision, options, consequences

Team → operations

Runbooks and alerts before go-live

Architect shapes, designer details, principal de-risks, manager delivers and runs.
One A per stage; ambiguity about who decides causes most friction.
Settle technical disagreements with an ADR and evidence, not seniority.
Fix scope-vs-date tension by slicing scope, not by cutting quality.
Handoffs are conversations backed by artefacts, not documents thrown over a wall.

Most delivery pain isn't technical. It's a handoff between roles 👇

🏛️ Architect to designer: an HLD with no NFRs means the designer guesses.

📐 Designer to manager: an LLD with no slicing means one huge, late release.

🧭 Principal vs architect: settle tech choices with an ADR and a spike, not rank.

👥 Manager vs architect: paved roads beat both mandates and free-for-alls.

Agree one accountable owner per stage, and write decisions down.

Where does work fall between the cracks in your organisation?

#SolutionArchitecture #EngineeringLeadership #RACI #ADR #DeliveryExcellence

⚡ Quick-fire Q&A

How is a solution architect different from a principal engineer?

The architect works at solution altitude (options, NFRs, build vs buy, ADRs) across business and risk stakeholders. The principal works from the codebase up: technical approach, quality bar and cross-team standards, and still writes code.

How is a solution designer different from a solution architect?

The architect decides the shape of the solution and its trade-offs; the designer turns that into buildable detail: interfaces, data mappings, sequences and edge cases in an LLD.

What does a solution architect own that a delivery team doesn't?

The cross-team decisions: target state, roadmap, NFRs, build/buy/reuse, integration and cloud strategy, and the risks between systems. Teams own how they build inside those guardrails.

How does a solution architect lead without authority?

Through evidence and trust: involve teams early, show options and criteria in an ADR, prove ideas with a spike, and make the standard the easiest path (a paved road).

Solution architect vs solution designer: where is the line?

The architect works in breadth (many teams, strategy, target state). The designer works in depth on one solution: LLD, API contracts, data mappings, sequences and error handling.

When is a low-level design "done"?

When a developer can build it and a tester can test it without guessing: contracts and errors are specified, every field is mapped, failure paths are designed and every requirement traces to a test.

How should an Engineering Manager use DORA and SPACE?

As team-level trends for improvement, read together: DORA for delivery speed and stability, SPACE for satisfaction, collaboration and flow. Never rank teams or judge individuals on them, or they get gamed.

What is situational leadership?

Hersey and Blanchard's model: adapt your style (directing, coaching, supporting, delegating) to a person's competence and commitment on a specific task. A strong senior may need delegating on design but coaching on stakeholder work.

What are the staff engineer archetypes?

From Will Larson's book Staff Engineer: Tech Lead (guides one team's execution), Architect (owns direction for a critical area), Solver (goes deep on the hardest problems) and Right Hand (extends a senior leader's reach across the org).

How does a principal engineer differ from an architect and an EM?

The principal stays hands-on in the code and systems across teams. The architect owns the wider solution or enterprise picture and governance. The EM owns people and delivery. The principal partners with both and leads through RFCs, reviews and prototypes.

A principal engineer disagrees with your architecture standard. What do you do?

Write both options in an ADR against the agreed NFRs, run a time-boxed spike if evidence is missing, decide, and record the consequences. Allow an exception if local fit justifies it.

Who is accountable during build and run?

Usually the engineering manager is accountable; the principal and team are responsible for the work, and the architect and designer are consulted or informed. Confirm the local RACI early.