You finished the bootcamp. In three weeks you'll forget half of it.
You had it. Demo day, the capstone deployed, the panel of instructors nodding. You could build a REST API from scratch, you could explain closures, you could debug a stack trace without panicking. Then the cohort ends, the Slack goes quiet, and you start applying to jobs.
Three weeks in, a recruiter sends a take-home. You open a blank file and freeze. Not because you never learned it. Because the thing you learned was never stored the way you think it was. You pattern-matched your way through a guided project with an instructor nearby and lesson scaffolding doing half the thinking for you. Alone, with no scaffolding, the hands don't move the same way.
This is not a confidence problem. It's a recall problem. And almost nothing written about "what to do after bootcamp" names it.
The listicles are right about networking and wrong about what happens to your hands
Every post that ranks for this question says the same five things: polish your portfolio, practice interviewing, network strategically, contribute to open source, keep building side projects. Add bootcamp career services and maybe an internship. This advice is not wrong. Networking works. A clean portfolio works. Mock interviews work.
What none of it addresses is that while you're doing all of that, the actual code fluency you built in twelve intense weeks starts eroding, and nobody tells you how to stop it. You can polish a portfolio for six hours and not type a single new line of syntax from memory. You can go to three meetups in a month and still freeze on a FizzBuzz variant because you haven't written raw code without a tutorial open in another tab since graduation.
Forum threads are blunter about this than blog posts. The consensus there is that a bootcamp is a start, not a finish, and that the real-world readiness gap gets closed by months of unpaid project work and grinding leetcode-style practice. That's closer to true. But it still frames the fix as "do more projects," which is good advice for breadth and terrible advice for retention. Building a new side project doesn't reinforce the fundamentals you're about to get quizzed on in a phone screen. It just exercises whatever subset of skills that particular project happens to need.
Tutorial hell and post-bootcamp amnesia are the same bug
If you're reading this mid-way through self-teaching instead of fresh off a bootcamp, you already know the feeling by a different name: tutorial hell. You follow a course, you feel sharp the whole way through, you nod along and copy the code down. Then you close the tutorial and try to build something of your own, and the rug gets pulled out. The confidence was real. It just wasn't yours. It belonged to the instructor's scaffolding, and it left when the scaffolding did.
Post-bootcamp amnesia is the same mechanism on a longer timer. The bootcamp was the scaffolding. Demo day was the last day you had it propping you up. Everything after that is you, alone, finding out what actually transferred into your own memory and what was borrowed.
The standard fix for tutorial hell is "stop watching, start building." That's half right. Building teaches you to apply concepts in a new context, which tutorials can't. But it doesn't reload the base-level stuff you need instantly recallable in an interview: syntax, common patterns, the twenty things you'll type a hundred times across any project. For that you need deliberate, repeated retrieval, not another greenfield app.
What "keeping it" actually looks like day to day
Keeping it doesn't look like more courses. You don't need a sixth tutorial on React hooks. You need to be able to write a useState call, a list comprehension, a binary search, or a SQL join from a blank file without reaching for a search bar, under mild time pressure, repeatedly, until it stops costing you any thinking.
That's a different kind of practice than building projects. It's closer to what athletes call conditioning than what they call playing the game. You still need the game — projects, interviews, real problems. But conditioning is what lets you show up to the game without gassing out in the first five minutes.
Concretely: pick the patterns and syntax you know you'll be tested on. Write them from memory, not by reading then retyping, but by recalling first and checking after. Space the repetition out instead of cramming it, because cramming creates the same shallow, borrowed-confidence problem tutorials do. Do it daily, in small doses, for the entire stretch between bootcamp and offer, because that stretch is exactly when the forgetting curve is steepest and nothing else in your job search schedule is fighting it.
Boot.dev and LeetCode get you in. This is how you stay in.
Boot.dev and LeetCode are built for breadth and for interview-specific grinding. They're good at what they do and you should keep using them if they got you this far. What they're not built for is the daily maintenance of what you already learned so it doesn't quietly leak out of your head while you're busy applying, networking, and doing mock interviews.
This is the gap I built FlashCode for. It's spaced-repetition practice where you type real code from memory, not flashcards, not multiple choice. The idea is simple: treat the syntax and patterns you already learned like a gym treats muscle, something you maintain in short, regular sessions, not something you learn once and assume stays. It's meant to sit next to boot.dev and LeetCode, not replace them. Free tier to start, Pro is $7.99 a month if you want the full library across Python, JavaScript, TypeScript, and Java.
A 15-minute-a-day plan for the job-search stretch
Here's what the daily version of this actually looks like, no matter what tool you use. Fifteen minutes before you check job boards: five recall drills on syntax and patterns you already covered in your bootcamp, pulled from your own notes or a repetition tool, done from a blank file with no reference open. Then your actual job search work: one portfolio tweak, one outreach message, one mock interview question, rotating daily so none of it piles up. Then, separately, your project time: thirty to sixty minutes building something new, which is where applying concepts in fresh contexts happens.
The fifteen minutes is the part every other guide skips. It's small on purpose. It's not there to teach you anything new. It's there so that when the take-home arrives in week three, your hands already know what to do.
That's it. There's no trick to this, and I'd rather you know the mechanism than take my word for it. The job search is long and uneven, and the only thing fully in your control during it is whether you keep what you already built.