Research and sources

What we read while building Fanpilot, what we took from each source, and how sure we are. The short version: the explanations are ours, the study advice rests on real but indirect evidence, and a longer problem list alone doesn't make a guide teach better.

Interview-prep guides

Source	What it offers	How we use it
NeetCode's interview preparation guidance	Topics in a sensible order and a manageable starting set.	Topics follow what they depend on, and each problem is paired with the idea it teaches.
AlgoMonster's flowchart	Questions that narrow down which technique might fit.	We treat those cues as guesses to check, and confirm the choice with a reason it works.
Sean Prashad's LeetCode Patterns	Practice problems sorted by topic.	We pair examples with variations, and say where each technique stops working.
Grind 75's FAQ	Why and how to schedule a fixed set of practice problems.	The next exercise depends on what you've learned and where you struggled.
USACO Guide: Practicing	Advice from experienced competitors on attempts, editorials, and follow-up.	Get help when you're stuck, then rebuild the solution yourself and try a variation.

These are good teaching references, not experiments showing that one list or schedule works best. Organizing lessons around the slow solution, what makes it slow, the fixing observation, and why the fix is correct is our own editorial choice.

What learning research supports

Studies support two parts of our study advice: learning from worked examples, and practicing recall. They don't show that any particular LeetCode curriculum or review schedule is best.

In an introductory programming study, worked examples labeled with subgoals improved some early results, but not average exam scores. That is why we ask you to solve problems on your own after a lesson, not just follow along while reading.
Roediger and Karpicke's recall experiments tested remembering prose after a delay. Applying them to rebuilding algorithms is our extrapolation.
The interleaving study cited in the guide was about math teaching, not coding-interview practice.

So our practical advice is to track three things separately: solving with help right away, rebuilding the solution days later, and solving a new problem that needs the same idea. The review intervals in the guide are reasonable starting points, not scientifically proven ones.

System design references

Reference	What we reviewed	What we took from it
SystemDesign Academy: LRU cache	The public LRU lesson.	A model for connecting requirements, objects, operations, and extensions. Our lab adds state checks and compares against a separate implementation.
ByteByteGo: foreword	The public foreword only, not the full course.	Framing a design discussion around open-ended requirements, communication, bottlenecks, and tradeoffs.
Hello Interview: file-system design	The public community question and visible discussion.	Concrete API and data-layout choices to compare. Community answers assume different requirements, so our lesson states its own.
ByteByteGo: file-search example	The public README, traversal, and search-filter code.	Keep walking the tree separate from the filters you search with. Searching a tree is a different job from implementing the file-system API.
AlgoMaster: in-memory file system	The public explanation and overview; we didn't review paywalled material.	Compare storing full paths in one map with a tree of folders, and trace each operation on visible state.

We used these to decide what to cover and how to teach it. Our writing, models, and interactive labs are original. We haven't reviewed every lesson on these sites, and we don't claim our first edition teaches better than their courses.

Technical claims need their own evidence

The patterns bibliography links algorithm references and Rust documentation. The LRU lesson separates a teaching implementation from what production caches do, using the official Redis eviction documentation and the Caffeine design notes.

The interactive labs run the same code printed in their lessons, and our automated tests import it too. The LRU tests compare short sequences of operations against a separate, simpler model. The file-system tests compare updates against a store of full paths, and check that invalid operations fail. These tests show the code works. They don't show that a curriculum improves learning.

How to improve a lesson

Make each claim specific enough to check. State the input and what the code must do, show the slow solution and what makes it slow, explain why the fix is correct, count the cost of keys and output, and find an input that breaks a tempting wrong approach. Then add an exercise that changes one requirement and tests the same idea.

When you use outside material, link the exact source, and keep what the source says separate from what we conclude. Keep third-party credit and licenses. Being able to read a course for free doesn't mean we may republish it.