You don't know it until someone asks

Most of us learn by reading. It's cheap, it's available at midnight, and it feels productive the whole time it's happening. Then the thing you read about turns up in a code review or a design discussion, and you find you can follow the conversation perfectly but you can't lead it.

That gap has a boring cause. When you read, the author has already done the hard part: they picked what mattered, they put it in order, and they said it in the clearest words available. You're checking their sentences against a vague sense of agreement. Nothing in that loop ever asks you to produce the idea yourself, which is the only thing you'll be asked to do later.

Recognition is not recall

There are two ways to know something. You can recognise it, which is what happens when you read a paragraph about connection pooling and think yes, that's right. Or you can recall it, which is standing in front of somebody with nothing on the screen and getting it out of your head in order and out loud.

Recognition is much easier and it feels almost identical from the inside, which is what makes it dangerous. The fluency you feel while reading is the author's fluency, not yours. You borrow it for the length of the article and hand it back at the end, and the borrowed version is what you mistake for understanding until something tests it.

This is why re-reading your notes is close to useless and why writing an answer down from memory, badly, teaches you more in five minutes than an hour of highlighting. Producing the thing is the part that sticks. Everything else is preparation for producing it.

A question finds the edge in about a minute

The useful property of a question is that it locates the exact place your understanding runs out, and it does it faster than you could find it yourself. You don't know where your own edge is. That's what an edge is.

A good follow-up walks straight at it. You give an answer, it takes one clause of that answer and asks why, and two steps later you're either explaining a mechanism or you're saying words you picked up somewhere. Both of those are useful information. The second one is more useful, because it's the one you didn't know about yourself.

You can watch the same split in almost any topic. The gap between a junior and a senior answer is rarely a fact one of them is missing. It's that one of them has said it out loud before, under some pressure, and found out which parts they couldn't finish.

Using this when nobody is hiring you

This is where the habit gets interesting, because none of it depends on having an interview coming up. An interview is just a stranger asking you questions about your own field and refusing to accept the first answer. That's a study method that happens to also be a hiring process.

Run one focused session a week on a single topic. Not the whole stack, one area, and answer out loud rather than typing whenever you can, because speaking is harder and closer to the real thing. Thirty minutes is enough. The output you care about isn't the score at the end, it's the two or three moments where you heard yourself go vague.

• Pick the topic you avoid, not the one you're good at. More on that below, because everyone gets this wrong.
• Answer before you look anything up. A wrong answer produced from memory is worth more than a right one you read off a tab. It marks the spot.
• Follow the follow-up. The first question is the doorway. The value is two or three questions in, where you can't recite any more.
• Write down only what you couldn't finish. Not the whole session. Three lines, in your own words, about the three places you ran out.
• Go and read that specific thing, now that you know why you're reading it. This is where articles and source code finally pay, because you have a question they're answering.
• Get asked again next week. If it comes out clean the second time, it's yours.

That last step matters more than it looks. Almost nobody closes the loop. They find the gap, feel briefly bad about it, read something, and never test whether the reading worked. Being asked the same thing a week later is the cheapest way to find out.

Pick the topic you avoid

Left alone, everyone practises what they're already good at. It's more pleasant, the answers arrive quickly, and you finish feeling capable. It also teaches you almost nothing, because you're rehearsing recall that already works.

The topic worth an hour is the one you'd rather not start. For most web developers that's some combination of databases, the parts of the runtime nobody makes you think about until production, and whichever of security or infrastructure they've quietly decided is somebody else's job. Those are also the areas that decide seniority, which is not a coincidence.

What being asked won't teach you

Worth being straight about the limits, because a study method that claims everything is worth nothing. Questions sharpen what you have. They don't manufacture experience you never had.

You still have to build things. Nothing replaces the afternoon you spent finding out that a retry without idempotency doubles every charge, and no amount of being asked will hand you that afternoon. Reading source code is the same: irreplaceable, and slow, and worth it. What questions do is tell you which afternoon to spend and which source file to open, which is exactly the decision most people get wrong when they set out to learn something.

There's also a limit on production. Being asked teaches you to answer under pressure, and answering is a real skill, but it isn't the same as shipping the thing. Treat the session as the diagnostic and the week that follows as the treatment.

And when a screen is coming, it's the same practice

The happy accident is that this habit is also the best interview preparation there is, so you never have to switch modes. Somebody who's been asked about their own stack every week for three months walks into an automated screen with nothing to cram, because the last three months were the cramming.

It works the other way too. People who prepare only in the fortnight before an interview are trying to build recall in fourteen days, on the topics they can guess, while stressed. That's the same work at ten times the price. The full preparation guide covers the fortnight version, and it's a rescue, not a plan.

The drill

1. Choose one topic you'd rather not be asked about. Write it down, so you can't quietly substitute an easier one.
2. Take a focused session on it and answer out loud, with nothing open in another tab.
3. Let the follow-ups run. When you feel yourself reaching for a phrase rather than a mechanism, that's the finding, so say it and keep going.
4. Afterwards, write three lines from memory about the three places you stalled. From memory is the whole point.
5. Spend the week reading or building against those three lines, and nothing else.
6. Get asked the same topic again. Whatever comes out clean the second time is genuinely yours now.

Do that for a quarter and you'll have a map of your own knowledge that no amount of reading could have produced, because the map is drawn from where you failed rather than from where you nodded.