24 Aug 2026 → 10 Jan 2027 · sixteen working weeks · four weeks off
NeetCode 150, Designing Data-Intensive Applications 2e, GFE 75, and one behavioural story a week — four lanes running side by side, a section of each per week. Tick a task, leave a note on what actually tripped you up.
Loading…
The whole run
The shelf
That guide is a reference and answer key, not a second task list. Treating it as more work to do would roughly double the plan for very little new coverage. Treating it as the place you go when a GFE 75 quiz question stumps you costs nothing and saves hours.
Roughly 12 of the 21 GFE quiz questions have written answers in it: hoisting, closures, event bubbling, event delegation, null vs. undefined vs. undeclared, cookie vs. sessionStorage vs. localStorage, script async vs. defer, z-index and stacking context, the box model, box-sizing, positioning, and how a browser matches a CSS selector. In weeks 7 and 8, read its section first and write the answer in your own words in the note field.
Its bigfrontend.dev list duplicates GFE 75 on curry, throttle, debounce, flatten, memoize, promisify, event emitter, the async-utils family, and _extend (≈ deep clone / data merging). Do them once, in GFE, where you get tests.
Its prototypal inheritance walkthrough (factory → Object.create → new → class), the this-binding corner cases, and the repaint / reflow section have no GFE 75 equivalent and are still asked. Its accessibility and web-performance sections map onto weeks 12 and 13 here — use them as the reading for those weeks.
Its Algorithms track is a Princeton-course-plus-LeetCode-lists plan — a substitute for NeetCode 150, not a supplement. Running both would cost you 200+ extra problems for the same patterns. Pick NeetCode, which you have already started, and ignore that section. Same for its HTML/CSS chapter, which the guide itself labels mostly copy-paste.
Every one of the five loops has a dedicated behavioural round, and two of them — Cloudflare’s Orange Cloud and Spotify’s values round — are scored as filters, not formalities. This is the lane with the best return per hour, because almost nobody prepares it.
STAR, plus an R. Situation in one sentence — just enough to place the listener. Task: what was specifically yours. Action: about sixty per cent of your airtime, and say I, not we — “we” is where interviewers lose the signal. Result: a number. Reflection: what you would do differently. That last beat is what separates an answer that happened from an answer that was rehearsed, and staff-level rubrics probe for it directly.
Cloudflare caps that round at thirty minutes, which is roughly six stories. A six-minute answer costs you half the round. Rehearse against a timer until the whole arc fits in two minutes, and let the interviewer pull the detail out of you — their follow-up questions are where the good signal is anyway.
“We took p95 from 4.2 seconds to 900 milliseconds — here is how that started.” Interviewers write their impression down in the first twenty seconds. Do not spend those twenty seconds on org chart and background.
An answer that stops at your own team reads as senior, however good the work was. Say who outside your team changed what they were doing because of you. Then say what you deliberately did not do: “we consciously didn’t migrate the legacy path, because…”. Volunteering a non-goal is the single strongest staff signal, and hardly anyone offers one unprompted. Pair it with the rollback plan you had.
If you genuinely have no metric, give a size instead: “the three teams that consumed it”, “about forty per cent of our traffic”, “a fourteen-person org”. Precision anywhere buys credibility everywhere. Vagueness reads as invention, so keep a fact sheet in each note: dates, headcount, the metric, the real name of the system.
Do not bring a weakness that is secretly a strength — interviewers have heard it and it costs you trust for the rest of the round. Bring a real one, keep the retelling short, and spend the airtime on what you changed afterwards and what has happened since.
A good story can serve three or four prompts with a different emphasis each time. Sixteen of them covers most loops — as long as you know which angle each one can turn. Note the alternate angles at the bottom of each story.
Expect to be asked how you used AI on the work: where it helped, where you overrode it, how you checked it. Google now grades that explicitly. Have one honest story where the answer is “it was confidently wrong and here is how I caught it”.
These five run genuinely different loops, and the differences are not cosmetic. Of the fifteen-odd rounds below, one is a LeetCode-style algorithm round. Everything else is code you would actually ship, code somebody else wrote, or you explaining a system out loud.
Recruiter → online assessment → technical phone screen → onsite of four or five 45–60 min rounds: one or two coding rounds on practical JavaScript and React patterns, one or two front-end system design rounds, behavioural, and a project deep dive.
The staff difference: at Staff and above a presentation replaces one coding round.
→ Week 15 builds that talk. Week 16 delivers it to someone who interrupts.
Five to seven rounds: hiring-manager screen (architectural reasoning plus a résumé deep dive on hard decisions), Orange Cloud behavioural — strictly 30 minutes — a PM interaction round, a dedicated debugging round, system design, and an AI-assisted coding round. Front-end roles add a one-hour React + TypeScript app-coding round where execution speed counts as much as correctness.
→ Week 14 becomes debugging and code review. Week 15 adds the PM round beside the AI-assisted rehearsal. Week 10 drills speed.
Recruiter → HackerRank (data structures, algorithms and SQL, timed) → 45–60 min live coding → system design → a substantial take-home plus architecture review → bar raiser. Reported as one of the most demanding loops in UK fintech.
The failure mode is specific: most candidates who fail the live round produce working code that is not production quality. A take-home without tests, or half-finished, is an automatic no.
→ Week 10 becomes three 45-minute builds with unit tests plus a cold review of your own code. Weeks 12–13 produce a real take-home artefact. Week 10 adds SQL.
Five to seven stages over two to five weeks: recruiter, technical screen, then a loop of coding, system design, a case study drawn from a real problem the team hit, and a values round. Senior and staff add a 60-minute architecture deep dive through one significant system from your own background.
Two things worth taking seriously: the case study is the round that most often sinks LeetCode-only candidates, and the values round is a filter, not a formality.
→ Week 14 writes up one of your own systems properly. The Stories lane is the values round.
Take-home (48–72 hour window, three to five hours of work) → a pairing exercise modelled on daily work, including code review → a system or domain round → behavioural on remote-first collaboration → hiring manager. Around 36 days end to end.
The take-home is scored on code quality, git hygiene and documentation as much as on the solution.
→ Weeks 12–13 build the artefact README-first, with a commit history you would show a reviewer. Week 14 adds reviewing somebody else’s PR.
A senior answer can be about a system you owned. A staff answer has to name someone outside your team who changed what they were doing because of you — plus the non-goals you chose and the rollback plan you had. That is why every prompt in the Stories lane asks for scope, and why week 16 ends on a cross-team architecture case rather than another algorithm.
Re-weight, don’t pivot. All three sources are still the right ones; what has changed is how much of the loop they cover. The 2026 signal is consistent across sources:
One thing this plan deliberately does not add: a separate LeetCode grind on top of NeetCode 150. The evidence points the other way.
Evgenii Ray — the author of the Notion guide above, now SWE at Meta in London — spent the past year interviewing across HFT, finance and FAANG and turned the questions into a free two-day Frontend Masters intensive in March 2026: around 60 front-end problems solved live, ending in a small Google Sheets clone, with the problems published as a GitHub repo. He has an earlier Frontend Masters course on front-end system design too. Both sit closer to what these loops now ask than the GFE quiz does.
Two of his choices are worth copying. He solved that entire stream by hand, no AI agents — which is the skill 62% of loops still test. And he is redirecting his own learning at client-side AI engineering and model optimisation, alongside Meta’s Dev AI Infrastructure team. If you want one differentiator beyond this plan, that is the one a staff-level front-end candidate can credibly claim in 2026.