Q313: Architecture Critique Prompts and Reviewer Mindset

What Interviewers Want To Evaluate

Interviewers want to know whether you can critique a design constructively instead of only creating your own design from scratch.

They are checking risk detection, fairness, trade-off analysis, communication, ability to ask clarifying questions, and whether you can improve an architecture without dismissing the people who built it.

Short Interview Answer

Architecture critique should start by restating the goals and assumptions, then evaluating the design against requirements, risks, trade-offs, and operating constraints. I would look for unclear ownership, unsafe state, weak API contracts, performance bottlenecks, accessibility gaps, security issues, migration risks, observability gaps, and missing rollback. The tone should be collaborative: preserve what works, identify what is risky, and propose realistic improvements.

Detailed Interview Answer

Critique is not complaint.

A good reviewer asks:

What problem was this design solving?
What constraints shaped it?
Which parts are strong?
Which assumptions are risky?
What would I change first?

This creates useful feedback.

Critique Prompts

Practice prompts:

Critique a dashboard architecture that stores all filters in global state.
Critique a search UI that fetches on every keystroke.
Critique a micro frontend plan with shared runtime dependencies.
Critique a design system with no accessibility testing.
Critique a progress tracker that marks completion after one click.
Critique a realtime editor that only says "use WebSockets".
Critique a deployment plan with no rollback.

Each prompt tests a different senior instinct.

Review Lens

Use lenses:

requirements
state ownership
data flow
API contracts
rendering
performance
accessibility
security
observability
rollout
maintenance
team ownership

Do not apply every lens equally.

Focus on the highest risk.

Preserve What Works

Good critique starts with useful parts.

Example:

The route-level separation is good because it keeps the reader and practice console independent.
The risk is that console execution lacks rate limiting and output isolation.

This tone helps people hear the feedback.

Risk Ranking

Rank critique by severity:

P0: can leak data or break core workflow
P1: likely production reliability issue
P2: maintainability or performance risk
P3: polish or future improvement

This prevents a long list from feeling chaotic.

Improvement Proposals

Critique should include options.

Example:

Option A: keep local progress only for v1.
Option B: add cloud sync with conflict resolution.
Option C: sync only completed state, not detailed reading history.

Options make critique actionable.

Interview Framing

Say:

I would first confirm the goals, then critique the design by risk: correctness, security, performance, accessibility, operability, and maintainability.

Then add:

I would preserve the parts that fit and propose the smallest changes that reduce the biggest risk.

Common Mistakes

• Critiquing without understanding goals.
• Replacing the whole design unnecessarily.
• Focusing on personal style.
• Missing severity.
• Giving feedback with no path forward.
• Ignoring constraints.
• Being too polite to name real risk.

Learning Studio Example

Critique the current Learning Studio:

Strength: static MDX content is fast and reviewable.
Strength: batches create good learning cadence.
Risk: content volume makes route generation slower.
Risk: practice console should keep improving editor ergonomics.
Opportunity: better volume progress summaries can guide users.

This is fair and actionable.

Final Mental Model

Architecture critique is collaborative risk reduction.

The best reviewers:

understand context
name strengths
rank risks
offer options
protect users
respect constraints