Interview Prep: A 30-Day PDF Plan to Learn a Framework Cold

Your offer expires in 30 days.
The role is React + GraphQL + Postgres.
You know React. GraphQL is foggy. Postgres is "I can write a SELECT."
You have 30 days to be confidently competent in all three.
This is the plan.
Table of Contents
- The 30-Day Reading Sprint
- Week 1: Foundations
- Week 2: Hands-On
- Week 3: Edge Cases
- Week 4: Ship Something Real-Shaped
- Why Offline Reading Beats YouTube for Retention
- Daily Tactical Rhythm
- What This Doesn't Replace
- Build Your 30-Day PDF Stack
The 30-Day Reading Sprint
Most "learn a framework" advice is structured around tutorials. Code along, build a TODO app, ship a side project.
That's fine for "have you ever written a useState." It's not enough for an interview where the interviewer is expecting two years of fluency in 30 days.
The plan that works is:
- Read the canonical docs cover-to-cover (week 1)
- Build something hands-on (week 2)
- Read the deep cuts and edge cases (week 3)
- Ship a real-shaped project (week 4)
The reading parts are where most people fail. Tutorials are seductive. Reading docs feels slow. But the quality of "reading the canonical docs" is what differentiates a fluent senior from someone who's just shipped some code.
PDFs make week 1 and week 3 actually possible.

Week 1: Foundations
For each of your three weak areas, generate a PDF:
| Skill | URL to bundle |
|---|---|
| GraphQL | graphql.org/learn (or apollographql.com/docs/react if you're using Apollo) |
| Postgres | postgresql.org/docs/current/tutorial.html (start with the tutorial, not the full manual) |
| Anything else | Same flow, paste the canonical docs URL |
Use OfflineDocs — paste, generate, done. Same from-url flow we use for GitHub READMEs and everything else.
The GraphQL tutorial is ~50 pages. Postgres tutorial is ~50 pages. Add a third skill — call it 150 pages of week-1 reading.
That's 20 pages a day. An hour of reading per day. Doable on a commute, lunch break, or an evening you'd otherwise have spent doomscrolling.

Week 2: Hands-On
Build something with all three.
A blog. A todo list with auth. A Reddit clone. Anything where:
- React renders the UI
- GraphQL is the API layer
- Postgres is the database
Not for the portfolio. For the integration. You want to feel the seams between the three technologies. The docs don't teach you those seams. The build does.
Time-box: ~2 hours a day. ~14 hours total. That's enough for a working app.
Document the gotchas as you go. Note them in the margins of your PDFs.

Week 3: Edge Cases
Now go back to the docs and read the parts you skipped.
For GraphQL: subscriptions, error handling, schema design patterns, performance (N+1 problem, dataloader).
For Postgres: indexes, transactions, query planning, JSON types, full-text search, CTEs.
For React (refresher): useMemo / useCallback / Suspense / Server Components, depending on the role.
These are the topics interviewers love. "Tell me about your approach to N+1." "How would you index this query?" "When would you use useMemo?"
Generate a focused PDF for each. Don't bundle the full docs. Bundle the chapters you need.
This is the TypeScript reference workflow at a smaller scale — pick the modules that matter, skip the rest.

Week 4: Ship Something Real-Shaped
Take your week 2 build. Make it production-shaped.
What "production-shaped" means:
- Auth (real, not faked)
- Validation
- Error handling
- Tests (at least one happy-path integration test)
- Deployed somewhere with a public URL
This is the project you'll talk about in the interview. Not the most impressive project ever shipped, but a project you can speak to in detail. Where you made specific choices. Where you can answer "why did you do it that way?"
The PDFs from weeks 1 and 3 keep you grounded during week 4. When something feels off, you flip to the relevant chapter. You don't go to Stack Overflow.

Why Offline Reading Beats YouTube for Retention
This is the part most "interview prep" advice gets wrong.
YouTube is great for first-pass exposure. Watch a video, get the vibe, see the syntax.
Reading is what makes it stick.
Studies on retention show physical / focused reading beats video reliably for technical material. You re-read a paragraph. You think. You make connections. You can't do that during a video without pausing constantly.
For interview prep specifically, where you need to recall and explain, reading is the higher-leverage activity.
The PDFs are just the medium. The medium matters because browsers are hostile reading environments, and you need a quiet one for retention.
Daily Tactical Rhythm
A schedule that worked for me, last time I did this:
| Slot | What |
|---|---|
| Morning, 30 min over coffee | Read 5-10 pages of one PDF |
| Commute (each way, ~30 min) | Read 10-15 pages |
| Lunch | Quick refresher of yesterday's notes |
| Evening, 1-2 hours | Code from week-2 build OR read deeper |
That's roughly 2-3 hours of learning per day, no single block over 90 minutes.
It compounds. By day 20, you'll feel the framework click. By day 25, you'll be answering interview questions in your head before the imagined interviewer finishes asking.
What This Doesn't Replace
- Mock interviews (do them, ideally with a friend)
- LeetCode if the role expects it
- System design practice if you're senior
- Behavioral interview prep
The 30-day PDF plan is the technical knowledge leg of interview prep. You also need the practice / performance legs. Don't skip them.
For the broader argument on building a personal reference library, the personal dev library guide walks through the longer-term pattern.
Build Your 30-Day PDF Stack
offlinedocs.ai/new → paste the docs URL for each weak area → generate.
Three minutes per skill. Twenty pages a day. Thirty days from now: confident in three new technologies.
Save your reading list. Future-you will be glad.
Ready to Get Started?
Start creating your Offline Docs Now! Reduce screen time and save your eyes.