Building Mio, an AI coach that backs every rating with evidence
Most training judges a cricket match by its first and last over. Mio was built to watch every ball: an AI interviewer that checks what engineers actually understand, at every step of a program.
- Role
- Senior Delivery and Product Lead
- Where
- Trumio
- When
- 2024 – Present
- Worked with
- Founders, product team and engineers
- 500–1,000enterprise learners interviewed
- 1,500data points per learner
- 25–30page evidence report per learner
- 100%completion across concurrent enterprise programs
How I got here
I joined Trumio in April 2024. The founder reached out to me, and the founding team had led engineering and business at companies like Microsoft, Cisco and IBM. Trumio already had a product manager, so they offered me the other side: everything that happens after a sale. I took it on purpose. I knew how to build products, but not how to sell them, and here I could learn from a co-founder with 25 years in IT sales.
Trumio's first product was a marketplace where companies posted small projects and students bid to do them. I owned the student side. Instead of emailing college directors, I went through student leaders: Gymkhana presidents, general secretaries and tech club heads. I spoke with more than 5,000 students, onboarded about 2,000, and signed agreements with seven institutions, including IIT Kharagpur, IIT Kanpur, IIT BHU and IIT Bhubaneswar.
Then Trumio pivoted. Companies didn't just need cheap work done. They needed proof that their engineers could do the work, especially now that AI writes so much of the code. That became Trumio Enterprise, a platform where engineers learn by doing real work and show what they can do.
The problem: judging the match by two overs
Most training measures people twice: a test at the start and a test at the end. A coding test tells you where someone is today. It says little about whether they can deliver on a real project, and nothing about what happened in between. It's like judging a whole cricket match by the first over and the last.
Trumio's early programs tried to fix that with people. Technical Project Advisors interviewed every learner and assessed their work. It worked for 5 to 10 people. It couldn't work for hundreds: advisors were expensive, interviews took time, and the analysis piled up. I was the one watching it break, and that was the starting point for Mio.
What Mio does
Mio is an AI interviewer and coach that runs through a whole program, like a Test match where every ball counts.
- A gap analysis at the start. Mio interviews each learner on the exact tech stack the program targets, tied to a real outcome. Not "learn Java," but "solve Java problems on your project independently and be interview-ready."
- A path that fits the person. Based on that interview, each learner starts where they actually are, from complete beginner to partly experienced.
- An interview after every module. Programs have 10 to 20 modules of lessons, videos and coding. After each one, Mio interviews the learner, checks what they learned and coaches them on the spot. It knows the full context: their gap analysis, past projects, résumé and the whole program.
- Checks inside the code editor. While learners build, Mio pauses them with short questions about code they just wrote or accepted from AI, so understanding is tested in the moment, not only afterwards.
- An exit interview and an AI code reviewer. Coding work is checked against the task brief, and everything feeds one detailed report per learner.
My part
Mio was a team effort. Here is the honest split.
What I drove
- Seeing that human-led delivery couldn't scale
- The idea of a Mio interview after every module, with full context on each learner
- Testing Mio with real learners
- Rolling it out to clients
- The daily feedback loop between clients, learners and the product team
What others built
- The interview design and question flow
- The scoring rubric
- The engineering behind Mio
Led by the product team, designers and founders.
I was the client-facing person and spoke with participants every day. That made me the bridge: I brought what customers and learners told us back to the people building the product.
What went wrong, and what we changed
Long interviews started to drift
Mio adapts each question to the last answer, and at first interviews had no length limit. Past 20 to 25 minutes, it drifted, asking advanced questions on a beginner program. That produced false highs and false lows in scores.
A better voice service and models, live transcription, a clearer interface, and questions locked to the program's level. We redesigned the interview without weakening it, and the experience improved significantly.
Learners used AI to beat the AI
Some learners ran ChatGPT or Claude voice agents alongside the interview and repeated their answers. Cheating was widespread.
Proctoring. Interviews are recorded and checked for webcam, device and full-screen integrity. If a check fails mid-session, the attempt is voided and retaken under clean conditions, so every score comes from a verified session.
Would clients trust an AI's scores?
An AI rating someone's engineers is easy to doubt.
Radical transparency. Every learner gets a detailed report: every question, every answer, the expected answer, the scores and the skills found. Nothing is hand-entered; every number traces back to what Mio recorded. Clients didn't push back on the scores.
| Skill | At entry | At exit |
|---|---|---|
| SQL | Basic · 45 | Advanced · 86 |
| Spring Boot | Aware · 30 | Working · 62 |
| REST APIs | Basic · 40 | Proficient · 74 |
| Testing | Aware · 28 | Working · 58 |
The finding that mattered most
In one pilot, engineers scored high on the quality of their code submissions while accepting AI-written code 90 to 100% of the time without checking it. Their work looked good. Mio's interviews showed they didn't understand it.
Clean, working pull requests that passed review.
of AI-written code accepted without checking, and little understanding of it.
It also works the other way. Some engineers accepted AI code without checking it, yet explained it well when Mio asked. That is a different problem: a habit, not a gap in knowledge. One needs teaching; the other needs a review step before accepting AI code. Looking only at the output can't tell them apart. Asking people about their own work can.
Results
- Every participant was interviewed at every stage, with no extra headcount.
- Time and cost that used to go to human-led interviews were freed up.
- Data for analysis arrived quickly and in a consistent format, about 1,500 data points per learner.
- The reports helped clients decide which engineers were ready to deploy onto projects.
What I'd take from it
Measure the whole match, not two overs.
A test at the start and end tells you where someone was. Checking at every step tells you how they're actually changing.
Output isn't understanding.
With AI writing code, good-looking work proves little. Ask people to explain what they built.
AI fails at the edges you didn't set.
Mio drifted once interviews ran long. Limits on length and level aren't restrictions on the product. They are the product.
Every incentive is a game someone will try to win.
At MX Games it was hacked leaderboards. Here it was AI answering for AI. Ship the guardrail with the feature.
Transparency is what earns trust.
Clients accepted an AI's judgement because they could see every question and answer behind it.
The best ideas for Mio came from talking to learners and clients every day. That's still how I build.
Back to selected work