What this site is (and what it isn't)
Distilled Prep turns the engineering blogs of major tech companies into senior-level interview practice: real scenarios, the follow-up probes an interviewer would push on, and answer guides that reward reasoning, not trivia. It's free for data science, software engineering, and machine learning candidates, and it has no accounts, no paywall, no algorithm deciding what you should see, and no interest in keeping you here longer than it takes to get better.
The gap this closes
Many of the best interview questions at serious tech companies are rooted in real problems those companies actually faced: scaling systems, allocating scarce resources, measuring interference, handling failure with imperfect information. Remarkably, a lot of those problems get written up in public, on engineering blogs. Meta, Google, Airbnb, Stripe, Uber, DoorDash, Netflix: between them, years of posts about the exact systems, trade-offs, and messes that senior interviews are built around.
Almost nobody preparing for interviews reads those blogs. They're long, uneven, scattered across seven sites, and written to showcase the company, not to prepare you. So candidates fall back on question banks that are stale, generic, or scraped from forums, and then walk into interviews built around the same systems and trade-offs those blogs describe, having never read them.
This site closes that gap. Every week it reads those blogs, finds the posts with real interview material in them, and distills each one into a practice question you could actually be asked: a short setup you can absorb in two minutes, a problem you can work for half an hour, the follow-up probes an interviewer would push on, and an answer guide to score yourself against honestly.
One example, start to finish
Distilling is not summarizing. A blog post describes a destination: the system a team built, the solution they reached, the lessons they drew. A good interview question drops you at the origin, at the decision that team faced before any of it existed. The post's answer becomes one path you might take, never the premise you're handed.
Stripe has written publicly about how its payment APIs stay safe when requests are retried. That post became this library's question on designing an idempotent payment API: you're asked to design the retry-safety mechanism from scratch, then probed on what happens when a retry lands while the first attempt is still in flight, how you avoid a double charge when the server crashed after writing to its database but before charging the processor, and whether to fail open or fail closed when the deduplication store itself goes down. The guide rewards reasoning about failure windows, not recalling Stripe's implementation. The blog post is the raw material; the question is what a good interviewer would build from it.
How it works, in one picture
One person runs this: an editor, not a developer, with AI doing the heavy lifting under editorial supervision. The machines read and draft. A human decides what's worth publishing, rewrites what isn't good enough, and throws out the rest. Everything you see here survived two gates: an automated one for substance, and a human one for taste. Plenty doesn't make it through.
Concretely: the automated gate screens each source post for interview value and checks every draft for structural problems. The editorial pass checks the draft against the source, removes unsupported claims, tests whether the prompt stands alone, and holds every question to one standard above all: the question poses the situation; you supply the judgment. A setup that hands you the diagnosis, the architecture, or the modeling decision has already answered itself, and it gets rewritten or thrown out. To be clear about what AI does and doesn't judge here: it screens sources and quality-checks drafts. It never grades you. The guide you score yourself against is a separate thing, and the scoring is yours.
The library holds two kinds of material. Most questions are distilled from a specific public engineering post, and every one links to its source. Alongside those there's a hand-written core for each company: the canon, written by the editor to cover the recurring themes that no single blog post owns.
What it isn't
The title promises both halves, so here is the other one.
- It is not a database of leaked or recalled interview questions. A small set of company-agnostic leadership questions is drawn from real interview experience, disguised and generalized so that no company's actual questions are reproduced. Everything else comes from public engineering posts or the editor's pen.
- It is not affiliated with any of the companies covered.
- It cannot predict the exact questions you'll be asked. It prepares you for the kind of thinking those questions demand.
- The answer guides are strong reasoning paths, not official company solutions.
- It is not a substitute for practicing out loud, or for knowing your own projects cold.
The ethos, plainly
A few principles are load-bearing here. They aren't aspirations pinned to a wall; they're constraints the site is actually built around.
It's a library, not a feed. Everyone who visits sees the same site. There is no recommendation engine, no personalized ranking, no "because you viewed." You customize what you see by filtering: by role, company, topic, format. Every filtered view is just a URL you can bookmark or send to a friend, who will see exactly what you see.
Your progress is your business. Practice mode lets you mark questions as mastered and score yourself against the guides. Your scores and mastery marks are stored in your browser and are not sent to this site's servers. They don't change what the site shows you or anyone else. Think of it as pencil notes in the margin of a library book, except the next reader gets a clean copy. The one thing that does travel is an upvote, if you choose to give one: an anonymous count on the question, nothing more.
Honest over engaging. Where a growth-minded product would add streaks, randomized feeds, or artificial scarcity, this site declines. The sort order defaults to newest, not to a shuffle designed to make the library feel bigger than it is. If a feature's main job is to keep you on the site rather than make you better at interviews, it doesn't ship.
No accounts. Accounts would make some things easier: syncing progress across devices, tailoring the library to you. They would also create the data obligations and retention incentives that the principles above rule out. Local-first progress keeps the site simpler and more private, and that's the trade this site makes. Nothing here is designed to need an account.
How to actually use it
- Pick a question. Filter the library by your role and target company, or hit the random button and take what fate serves.
- Practice it properly. Use practice mode, which reveals the interviewer's probes one at a time. You commit to an answer before seeing where the follow-up goes, the way a real interview works.
- Score yourself. Every question's answer guide is tiered the way an interviewer actually thinks: what you must establish to stay viable, what separates a strong answer, and the common misses that sink one. Be harsh; the bar is calibrated for senior loops, and flattering yourself here is expensive later.
If you practice with an AI assistant, each question has an export that hands the full scenario to your AI of choice, prompted to act as a rigorous interviewer rather than an agreeable one.
Start with one question
Reading about practice isn't practice. Pick one question in your target company. Give yourself thirty minutes. Don't reveal the first probe until you've committed to an answer, and score yourself the way an interviewer would, not the way a friend would.
What "Notes" is
This section, the one you're reading, is the editor's margin. Occasional posts about what's changing on the site, patterns noticed across hundreds of engineering-blog posts, and thoughts adjacent to interview prep. No schedule, no promises. The questions are the product; this is the workshop door left open.
If you find something wrong, or something great, say so: [email protected]. This site gets better by being argued with.