Product Story • 4 min
We Stopped Asking Students to Write Code First — Meet the Programming Coach
For years, a green tick on a coding question meant one thing: the student understood. Run the code, pass the test cases, move on. That tick is quietly losing its meaning.
In September alone, more than 32,000 students on our learning portal started 3.3 million coding questions. 82 out of every 100 first attempts passed, and the typical question was solved in about three minutes, in just 1.35 attempts. On paper, that looks wonderful. But in a world where a working answer is one prompt away, a passing run only tells us the code works. It says nothing about whether the student knows why.
So instead of asking students for code first, we started asking for something much harder to fake — their thinking. This is the story of the Programming Coach, and how a three-stage mock interview now lives inside the practice questions students already solve.
A Green Tick Is Not Understanding
Think of a driving test where you only have to reach the other end of the road. Reach it, and you pass — even if a friend steered the whole way. That is roughly what a passing test case measures once help is everywhere: the destination, never the journey.
The job has moved too. Entry-level hiring has tightened, and the work itself is shifting from typing code from scratch to specifying it, reading it, checking it and fixing it when an AI gets it wrong. Students were still training for the old job.
Interviews have always tested the new one. Nobody hands you a test runner in an interview. They say, “Walk me through how you would solve this,” and listen to how you think.
So We Borrowed From the Interview Room
The idea was simple to say and tricky to build: turn every coding practice question into a short mock interview. No new course. No ban on AI. No extra work for instructors. And no new content for the curriculum team to write — more than 15,000 coding questions already sit in our library, ready to be asked differently.
The same questions students already solve now have an interviewer wrapped around them — our AI Tutor, playing the part. Three phases: clarify the problem, implement it, explain your solution. Together they teach students to specify, implement and explain code, not just produce it.
Everything leans into the interview feeling — the name, the tone, the timer, even how it ends — because that is what makes students take it seriously.
First, Clarify Before You Build
The student sees the problem and exactly one worked example. Nothing more. The other edge cases stay hidden, on purpose.
Then they write their approach as ordered steps, from input to output — typed, or spoken out loud if they prefer, with the transcript shown back so they can fix any misheard word.
The interviewer reads it and asks follow-up questions. It does not hand over the missing cases; it probes until the student finds them. “What happens when the list is empty?” teaches far more than being told.
Then Implement, With Hints and Not Answers
Now the student codes. They can run the visible test cases as many times as they like, then submit. The interviewer helps with hints, examples and syntax — never the solution — and steps in by itself if tests keep failing or the student goes quiet for two minutes.
Here is the rule I like most. If the tests fail, they stay the gate. But if the tests pass and the code does not match the approach the student described, we do not block them. The interviewer asks them to walk through the change: “your approach said this, but your code does that.”
Because a student who improved their plan halfway through has done something good, not something wrong. We would rather start that conversation than punish it.
Finally, Explain the Line That Matters
Once the code passes, the interviewer picks one line — two at most, and only for a bigger solution. Not a trivial line like setting a counter to zero, but the load-bearing one: the loop condition, the recurrence, the index maths that holds everything together.
Then it asks the question interviewers love: why is that line there, and what breaks without it? Not what it does — why it matters.
You can copy a solution. You cannot bluff your way through that question. And a student who built it themselves usually finds the words, and discovers they know more than they thought.
Never Trapped, Never Graded
A strict interviewer can easily turn into a wall. So we built an escape hatch. After three follow-ups on the same step, the student may move on. There is also an always-available “I think this is right — move on” button. We simply flag it, so we can learn from it.
Timers show the expected time, but they only inform — they never block, and they never become a score. When it is over, the end screen reads like a post-interview debrief, not a lesson-complete badge.
Behind the scenes, a simple read-only dashboard shows a mentor which of the three skills a student is weakest at, and tells the curriculum team which questions are broken — without creating a single hour of grading.
Where It Stands, and How We Will Know It Worked
As I write this, the Programming Coach is in testing with our developers. Designing the screens took days. Teaching the interviewer to tell a student’s plan from their code took much longer, and our new WaveKit design system needed one more component before it could ship.
The Coach will make a question take longer on purpose. Today a typical coding question is solved in about three minutes and 1.35 attempts, so that is the baseline we are measuring against. But the number we watch first is not speed or even completion. It is how often students use the escape hatch. If many do, the interviewer is too strict — not the students too weak. The number that matters most comes later: do students who finish the Programming Coach do better in later assessments and mock interviews than those who do not?
We cannot stop students from using AI, and we should not try. What we can do is make sure that when they pass, they understand. A green tick should mean what it used to mean. The Programming Coach is our attempt to earn it back.
Want to work together?
Feel free to reach out for collaborations, inquiries, or just to say hello.
Let’s Be Friends
Feel Free to Hit Me Up!
I always enjoyed product discussions and If you’re a startup founder or PM/Growth person and interested to chat! Hit me up on any social media platforms.
Crafted with ❤️ on Framer, All Rights Reserved © 2026 Guruprakash.