Frontend System Design Certification
One paper across the whole course: rendering strategy trade-offs from CSR through streaming SSR, state management at scale, performance engineering against Core Web Vitals, micro-frontends and architecture at scale, design systems, and worked interview scenarios. Sat in one two-hour-twenty sitting.
- Sitting
- 140 minutes
- Questions
- 55
- Pass mark
- 70%
- Price
- ₹199$9.99
Sit this when you can do these without looking them up
This is not a certificate of attendance. It is 55 questions in 140 minutes at 70% with no partial credit and one attempt, and roughly a third of the paper is foundations — the certificate is for the whole language, not the parts you enjoyed.
- Explain when you'd reach for ISR over plain SSR or SSG, and what staleness window you're accepting to get there
- Say why hydration is expensive even after a fast server-rendered first paint, and what islands or resumability change about that cost
- Choose between local, lifted, and global state for a described case, and defend why 'just make it global' is the wrong default
- Explain why server state and client state need different tools to manage, not just different variable names
- Diagnose which Core Web Vital a described symptom is actually hurting, and name the concrete fix rather than a generic 'make it faster'
- Justify — or rule out — micro-frontends for a described team's actual pain point, instead of reaching for them as a default architecture
- Walk a 'design a feed' style prompt end to end: clarify requirements, name trade-offs explicitly, and say 'it depends' with the specific conditions that make it true
If several of those are unfamiliar, the course below is free and covers all of it. If you would rather find out than guess, there is a practice paper at the same level — ten questions, marked as you go, no account, nothing recorded.
Take the free practice paperSyllabus
Every paper is drawn to this mix, so the weights are a promise rather than a guide. The numbers are how many of the 55 questions come from each area.
- 3
CSR, SSR, and SSG: the real trade-offs
What each rendering strategy actually does, and the honest trade-offs in TTFB, time-to-interactive, SEO, and infrastructure cost.
- 2
Incremental Static Regeneration
Stale-while-revalidate at the page level, time-based versus on-demand revalidation, and where ISR is the wrong tool.
- 2
Streaming SSR and Suspense
Why one slow dependency blocks a whole SSR response, and how Suspense boundaries let fast content ship first.
- 3
Hydration and why it's expensive
What hydration actually re-executes after paint, why a finished-looking page can still be unresponsive, and partial/progressive hydration.
- 2
Resumability, islands, and choosing a rendering strategy
Islands architecture, resumability as a further alternative to full-page hydration, and a repeatable framework for choosing per route.
- 2
Local, lifted, and global state
Defaulting to the smallest scope that works, lifting to a common ancestor, and why 'everything global' erodes locality of reasoning.
- 2
Normalizing state shape
Duplicated nested entities as a bug source, ID-keyed normalization, and the write-time/read-time trade it makes.
- 4
Server state vs. client state
Why server-owned data is a fundamentally different problem — staleness, revalidation, deduplication, cache invalidation — from local UI state.
- 2
Optimistic updates and rollback
Hiding latency by updating before server confirmation, the rollback path this obligates, and reconciling concurrent mutations.
- 3
State machines for complex UI
Why independent booleans allow impossible states, and modeling explicit states and named transitions instead.
- 2
The critical rendering path
DOM/CSSOM to render tree to layout to paint, which resources block it, and the concrete levers (defer/async, critical CSS, resource hints).
- 2
Code-splitting and bundle budgets
Route- and component-level splitting, the prefetching trade-off it introduces, and enforcing a real, CI-checked bundle budget.
- 2
Virtualization for large lists
The real cost of rendering unbounded lists in full, windowing to render only the visible range, and fixed vs. variable item heights.
- 3
Memoization strategy and its costs
React.memo, useMemo, and useCallback as a comparison-cost-for-render-cost trade, and why memoizing everything can be net slower.
- 2
Core Web Vitals, images, and fonts
LCP, INP, and CLS as distinct, targeted metrics, and the concrete image and font strategies that move each one.
- 2
Why and when to split a frontend
The organizational problem micro-frontends actually solve, and the real costs — duplicated dependencies, cross-team contracts.
- 2
Module federation and composition models
How independently built pieces compose at runtime, and the build-time versus run-time composition trade-off.
- 2
The well-organized monolith alternative
What actually makes a monolith painful, and how enforced module boundaries and fast CI deliver the same benefit without splitting.
- 2
Building a component library that scales
Layering tokens, primitives, and patterns, resisting scope creep on shared components, and real ownership of the library's coherence.
- 2
API design for shared components
Composition over configuration, controlled versus uncontrolled components, and consistent naming across a component library.
- 1
Versioning and breaking changes
Honoring semantic versioning as a promise, deprecation windows, and codemods for migrating consumers.
- 1
Theming and design tokens
Tokens as indirection between a design decision and its usage sites, and semantic tokens as what makes dark mode and rebrands tractable.
- 2
How to approach a system design interview
Clarifying requirements before proposing a solution, naming trade-offs explicitly, and when 'it depends' is the strongest answer.
- 2
Worked scenario: a social media feed
Splitting rendering strategy by public/indexable versus personalized, normalized feed data, virtualization, and optimistic likes.
- 2
Worked scenario: an image-heavy e-commerce PLP
ISR for SEO-sensitive periodically-changing listings, image strategy against LCP/CLS, and URL-driven filter state.
- 1
Worked scenario: a real-time collaborative editor
Why the editing surface is a CSR case, optimism at typing-latency stakes, and CRDTs/OT conceptually for concurrent edits.
Everything on this syllabus is taught free
The System Design course covers the whole syllabus above across 26 lessons, with a playground in each one. Work through it first — the exam is the same material under a clock.
Open the System Design courseWhat sitting it is like
The exam opens full screen with a countdown, a question at a time, and a grid showing what you have answered and what you have flagged to come back to. Nothing is submitted until you say so, or the clock reaches zero.
Every answer saves to the server as you give it. If your laptop dies at question forty, sign back in and you will find question forty exactly as you left it — with however much time was left still ticking, because the clock does not pause.
Leaving full screen or switching tabs is noted but does not end your exam. It is a record, not a trap: nobody is auto-failed for a notification stealing focus.
When it ends you get your mark, a topic-by-topic breakdown, and every question with the right answer and an explanation — whether you passed or not. Passing also produces a certificate with a link anyone can verify.