Three signs your kid is actually getting better at CP.

Every few weeks a parent messages me something like: "The rank hasn't moved in a month. Should I be worried?" I understand why they ask. The rank shield is right there on the dashboard, it has a name, it has a color — it feels like the thing to watch. But it is genuinely the worst signal of real progress I know. It's a lagging indicator. It reflects what your kid already learned weeks ago, averaged across hundreds of problems. By the time it moves, the actual improvement happened long before.

So what do I actually look at? Three things. None of them are on a leaderboard.

1. The rejection rate goes up before it comes down.

When a student is coasting — solving problems comfortably within their current level — their approval rate looks great. Lots of green, very little red. Parents see this and feel reassured. I see it and sometimes get a little nervous.

A student who never gets rejected is often a student who stopped reaching. The problems I assign have a stretch component built in, but the most reliable sign that a student is growing is when they start voluntarily attempting things that are too hard for them. They see something in the catalog or on Codeforces, they try it without being told to, and they submit something that isn't quite right yet. It comes back as "needs fix." They try again.

That cycle — attempt, rejection, revision — is the actual training. A spike in your kid's rejection rate, especially if it's followed by a second or third attempt on the same problem, is not a warning sign. It's the best sign I can show you. If you open the parent dashboard and look at the recent-activity feed, you're looking for that pattern: a problem marked "needs fix," then the same problem attempted again a day or two later. That loop is what I'm trying to produce.

2. How fast they bounce back — and how they bounce back.

Retry latency is something I track informally in my head for every student. When a problem comes back rejected, how long does it sit before they try again? A week? Three days? A few hours?

Early on, most students stall. A rejection feels like failure, so they avoid the problem and pick something else instead. That's normal. But over time — and this is one of the clearest signs of real development I see — the wait shrinks. Not because the problems get easier, but because the student stops treating rejection as a verdict and starts treating it as information.

You can see this pattern in the activity calendar on the parent dashboard. Look at the density of marks around a problem that came back for revision. A student who bounces back fast will show activity on nearby days — they stayed in contact with the problem. A student who's stuck will show a gap. Both are useful to know; the gap is something I can address if you flag it to me, because usually I've already noticed it before you have.

The quality of the bounce-back matters too, but that's harder for a parent to read from the outside. I see it in the notes they leave on resubmission. Early fixes are often just "I changed this line." Later fixes come with an explanation of what was wrong in the original thinking. That shift — from patching to understanding — is the thing I'm actually trying to cultivate. When I see it, I know the training is working.

3. What they solve when nobody's watching.

I give every student a core set of assigned problems. But the students who develop fastest are the ones who solve things outside those assignments — problems they found themselves, on platforms I didn't point them to, on topics they got curious about independently.

This is visible in two places on the parent dashboard. The recent-activity feed will show solves that aren't tied to a specific assignment. And the activity calendar will show active days that don't map neatly to when I assigned something new — meaning they were working on their own initiative.

I don't require this. I don't reward it with extra XP by default. When it happens, it's genuine. And it tells me something no leaderboard ever could: the student has started to own the process. They're not solving because there's a task in front of them. They're solving because they want to know if they can.

The platform I use shows me a calendar of every day a student was active, what they submitted, and what came back. When I open that calendar and see a student who solved something on a Saturday afternoon — something that wasn't assigned — I already know the trajectory before I look at any rank number.

The leaderboard is a lagging indicator. The behavior is the leading one.

I'm not saying ignore the rank shield. It matters, eventually — and for students targeting OI or OIJ, the top-percentile thresholds I've set in the system are real milestones. But the rank reflects accumulated past work. The behavior I described above is what creates the future rank.

If you're watching the parent dashboard and wondering whether your kid is on track, look at the activity calendar first: are they showing up consistently? Then look at the recent-activity feed: do you see the attempt-rejection-retry cycle, or do you see only clean approvals on easy problems? Those two things tell you more than the tier name does.

And if you're not sure what you're looking at — ask me. That's what the weekly digest is for, and it's always easier to course-correct early.