What you can now do, and what the exam checks

Course 1 was about building safely. This one was about changing something that already works — which is most of what programming actually is.

The part that was never about screeners

You can rebuild rather than restart. Four questions — what survives, what generalises, what is new, what dies — applied before touching code. You extracted a transport layer, generalised a table to exactly two callers and no further, and kept both products working throughout.

You can review code as a process. Four lenses in worst-first order: leaks, cost, lies, failure. Run on a diff every time, and on a whole feature before calling it done. That checklist found three leaks in a nine-line proxy that looked fine.

You know where market data lies. Fractions that look like percentages, floats with tails, numbers too big to read, missing values masquerading as zero, and two currencies in one column. None of these throw. All of them are wrong on screen.

You treat user input as an attack surface. The moment a person can influence a request made with your key, allowlists and clamps stop being pedantry.

You can make a check permanent. You have written tests, watched them fail before trusting them, and know which findings are worth one — the ones that would be wrong quietly.

What is still missing

Your screener sees the market as it is today and cannot ask what would have happened. It has no memory: run it next month and you cannot compare against this month without having saved something. It ranks but cannot tell you whether a rule would have worked.

That is course 3, and it is the one with the sharpest teeth — because a backtest is the first tool in this track that can flatter you, and most of the lessons are about not being flattered.

What the exam asks

Ten questions, seventy percent to pass, twenty-four hour cooldown, deterministic fixtures throughout. They are drawn from a pool several times the size of one paper, so a retake is a different paper. Expect:

• Spot the leak. A proxy route is shown; you name what a stranger can do with it.
• Count the calls. Given a component and a row count, say what one page view costs.
• Convert the number. A raw response field, and what it should render as — the yield is a fraction.
• Read the universe. Given the type breakdown of an exchange, say what a naive screen would wrongly include.
• Judge the ordering. Given a sort and a mixed-currency column, say why the ranking is meaningless.
• Find what is not there. A filter excludes a company; say whether that is a zero or a coverage gap, and how the interface should show it.

Nothing depends on live market state. Every fixture is fixed, so the answer today is the answer next year.

Before you sit it

Re-read your REVIEW.md and run it once more on the screener you built. If you find nothing, you have either written a good tool or a weak checklist, and the way to tell is to hand both to your assistant and ask it to attack them.

Then look at your commit history for this course. A rebuild should read as a sequence of small, explainable structural changes: extract, generalise, add, review. If it reads as one commit called "screener", the code may be fine but the habit is not, and course 4 composes three tools at once — which is not survivable without it.

Try it now

Hand your screener and your REVIEW.md to your assistant and ask it to find three problems your checklist would miss. Read its answers sceptically — some will be wrong. The ones that are right go into the checklist, which is how the checklist gets good.