24 Aug 2026 → 7 Mar 2027 · twenty-four working weeks at ~6 h · four weeks off
NeetCode 150, Designing Data-Intensive Applications 2e, GFE 75, one behavioural story a week, and one system-design problem a week from HelloInterview — five lanes at about six hours a week, seven mocks from week 6, applications from week 12. One goal: a senior/staff offer at Cloudflare/Datadog/Spotify/GitHub scale — at a company you would want to stay at.
a session · a planned night not yet used · break · the chain is weeks with two or more sessions, never days. Three a week is the plan. Judo nights and evenings off are not misses.
— 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.
You do not rise to the level of your goals. You fall to the level of your systems. Everything below names the exact thing on this page that does each job, so that on the nights your motivation is gone, you can see the system is still there and all you have to do is use it.
This page has a habit layer and an outcome layer. The habit layer is the box at the top: the I sat down today button, the chain of squares, the sessions-this-week line. The outcome layer is everything else — 16/150, the ring, the block fractions, the tasks line. On a bad night, look only at the habit layer. Outcomes lag the habit by weeks; judging yourself on them nightly is how a plan dies. The tasks line has no colour and no verdict for exactly this reason.
Not “finish NeetCode 150”. The kind of engineer who sits down three nights a week and belongs in a Datadog loop. Every press of the button is a vote for that person. You do not need every vote. You need a majority, and August’s are already in the bank.
Around week 3, and again around week 9, the novelty is gone and the results are not here yet. That gap is where most plans die, and it is where the work is compounding. An ice cube does not melt at 25, 26, 27 degrees, and then does at 32. Nothing visible happened at 31. Everything happened at 31. The chain is what you look at during 25 to 31.
Redesign the plan mid-block because it feels slow. Add a resource because a forum said it was essential. Start over “properly” from week 1. Do a six-hour Sunday to “catch up” and then skip Tuesday. These all feel like progress and they are all forms of quitting. The plan is already pragmatic. The only way it fails is if the button stops being pressed.
Every week card carries one line written for the night you open it feeling like this. Press the button. Read the line. Do the smallest task on the card. Close the laptop.
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.