📚 Prerequisites & Resources - Full-Stack Engineer Job Simulation

Read this before starting the clock. Nothing to install, no repo to clone, no API keys - both tickets are read-and-reason work: a buggy code listing to debug and a design brief to defend. What the simulation does assume: you can read React + TypeScript code slowly enough to see what it actually does, and you know enough HTTP and data-modeling to make defensible calls. Both are learnable in an evening - resources below.

Who this is for

Freshers and switchers targeting Full-Stack Developer / Frontend Engineer / Backend Engineer / Software Engineer roles. If both checklists below feel comfortable, start the clock. If not, prep first - the timer counts everything.

⏱️ The rules at a glance

Rule	What it means for you
The clock	Starts when you start a ticket, pauses while your work is in review, and resumes on retry. Your total active time is what ranks you on the weekly leaderboard.
First submission - 12 hours	Make at least one submission within 12 hours of starting, or the simulation deactivates.
Everything - 48 hours	Submit both tickets within 48 hours of starting. Plan it like a real take-home: one sitting per ticket.
Free submissions	2 per ticket. After that: one instant retry for ₹49, or wait 6 hours for a free slot.
No dataset download	Unlike our analyst simulations, everything you need is inside each ticket's brief - the code listing and the schema excerpt. There is nothing to download.
Deactivated?	Restart free after 7 days, or instantly for ₹99. A restart resets progress.
Results	Within 24 hours, usually much sooner - email plus in-app status the moment grading finishes.

🧮 How you're graded (pass: 70/100 on each ticket)

FS-101: 60% automated answers to five precise debugging questions + 40% AI review of your fix memo - where explaining the root cause is worth more than naming the fix.
FS-102: 50% automated design calls (method, replay status, index, auth, data model) + 50% AI review of your design memo - where failure handling for the real flow outweighs architectural vocabulary.
Feedback always tells you the score math and exactly which components lost marks, so a retry is never a guess.

✅ Skill checklist - Ticket FS-101 (Debugging)

You should be able to:

Skill	What it means in practice
Trace a React render cycle	setState → re-render → effects with changed deps re-run. Loops live in that cycle.
Spot dependency identity	`{} !== {}`. An object/array/function created in the component body is new every render - as a dependency it re-fires the effect every time.
Recognise a stale closure	A function created on render N captures render N's state. Register it once (empty deps) and it reads that old state forever. Fix: functional updates, correct deps, or a ref.
Read `useEffect` deps precisely	`[a, b]` = run when a or b changes (by identity) · `[]` = run once on mount · no array = run after every render.
Know your status codes	2xx success · 400 invalid input · 401 unauthenticated · 403 forbidden · 404 missing · 405 wrong method · 409 conflict · 5xx server fault. 200-with-an-error-body is a contract violation, not a style choice.
Explain a bug in writing	Root cause (the mechanism) → fix → why the fix addresses the cause. That structure IS the memo rubric.

Self-test: in one sentence each, explain (a) why useEffect(fn, [{x: 1}]) fires every render, and (b) what value of count a mount-only listener logs after five increments. If both answers are instant, you're ready.

✅ Skill checklist - Ticket FS-102 (API Design)

Skill	What it means in practice
REST resource design	Creating a thing = `POST /things` → `201` with the created resource. Method choice is semantics, not preference.
Idempotency	A client retry with the same `Idempotency-Key` must not create a duplicate. Know both defensible replay responses - `200` (return the stored result) and `409` (conflict) - and be ready to argue yours.
Embed vs reference	Decide from access patterns: unbounded arrays that other queries need independently → reference; small, always-loaded-together data → embed.
Indexing for real queries	Index the field the hot query filters on. "The list screen filters by X on every visit" is the sentence that picks the index.
Server-side authorization	Anything the client enforces is UX, not security - the API is reachable without the button. Role checks live in the route handler before any write.
Failure-first thinking	Double submits, partial writes, concurrent updates. Name each failure and its defense before you name any technology.
Proportionate scaling	~50 req/min needs indexes and pagination, not Kafka. Overbuilding is a design error here, scored as one.

📖 Mini glossary

Referential identity - objects are compared by reference, not contents; React's dependency check is Object.is, so a fresh object literal is always "changed".
Stale closure - a function that captured old state/props because it was created in an earlier render and never replaced.
Functional update - setItems(prev => …): reads the latest state at update time, immune to stale closures.
Idempotent - safe to repeat: doing it twice has the same effect as doing it once. The property that makes retries safe.
Idempotency key - a client-generated ID sent with a request so the server can recognise (and refuse to re-execute) a retry of the same operation.
Embed vs reference - MongoDB modeling choice: store child data inside the parent document, or in its own collection with a link.
Partial write - a multi-step operation failing midway, leaving data half-updated; the reason transactions and reconciliation exist.
Race condition - two concurrent operations interleaving on shared data (two receipts updating one stock count) so the result depends on timing.
Design review - the meeting where an engineer defends design decisions before implementation. FS-102 simulates exactly this.

🔗 Free resources

React & JavaScript

React docs - Synchronizing with Effects and Removing Effect Dependencies - the exact material FS-101 tests
React docs - useEffect reference - including what each dependency-array shape means
MDN - Closures - the mechanism behind every stale-state bug

HTTP & API design

MDN - HTTP response status codes - keep it open during both tickets
Stripe - Idempotent requests - the industry-standard idempotency-key pattern
MongoDB - Data modeling: embedding vs referencing - the Q5 decision, from the source

From OneRoadmap

🛣️ Full-Stack learning path - free, in-depth roadmap - (/roadmap/full-stack)
🛣️ React learning path - (/roadmap/react)
🛣️ System Design learning path - (/roadmap/system-design)

🏋️ 45-minute warm-up drill (recommended)

(20 min) Write (on paper is fine) a tiny component with useEffect(fetchData, [filters]) where filters is an object literal in the component body. Trace, render by render, why it loops - then fix it three different ways (move it out, primitives as deps, useMemo) and say which you'd ship.
(15 min) Sketch POST /api/bookmarks for a note-taking app: request body, success response, and the exact status code for each failure - missing URL, not logged in, duplicate bookmark, server error.
(10 min) For that same endpoint, list what happens when a user double-clicks "save" on bad Wi-Fi - and one defense. Congratulations: you've rehearsed both tickets.

⚙️ Practical setup

A browser and a text editor for drafting memos is all you need. Laptop strongly recommended over mobile - you'll be reading a ~120-line code listing.
Answers are literal: component and function names spelled as they appear in the code (case/spacing forgiven), status codes as plain numbers.
The memos have hard character caps (2,500 / 3,000). Draft outside the form, trim, then paste.