There’s a thing every recipe book in the world has in common with every engineering syllabus.
You can read it cover to cover, understand every line, pass an exam on its contents, and still not be able to do the thing it describes.
Colonel Sanders’ famous KFC recipe is eleven herbs and spices. The list isn’t actually a secret anymore. It’s been leaked, reverse-engineered, published in newspapers, copied into a thousand internet articles. Walk into any kitchen in the world with the printed list in your hand, and you still cannot reliably reproduce the chicken.
The recipe is the easy part. The cooking is the part that takes years.
This is the gap that most engineering colleges in India have spent a century not noticing.
The classroom was built for a different problem
The default Indian engineering classroom is a hundred-year-old design, and it was designed for a hundred-year-old problem.
Industrial-era education had a specific brief. Take a large group of people. Teach them to follow standardised instructions. Produce them at scale. One teacher up front. Fifty or a hundred students. Same material. Same pace. Same exam. Same outcome. It worked, because the work it was preparing people for was also standardised.
That world isn’t the one our graduates are walking into.
The engineers we need now don’t follow scripts. They write them. They debug a system at 2 AM when the script doesn’t work. They learn a new framework in a weekend because the old one broke. They make architectural calls under uncertainty, and they live with the consequences.
A classroom designed to mass-produce conformance can’t produce that. We’ve kept the classroom anyway, because it’s familiar, and because changing it is slow.
So we keep teaching the recipe. And we keep wondering why the chicken doesn’t come out right.
Two ways to know something
Here’s a question worth sitting with.
You probably haven’t ridden a bicycle in months. Could you ride one tomorrow? Almost certainly yes.
You probably studied calculus six years ago. Could you set up a definite integral tomorrow? For most engineering graduates, the honest answer is no.
Both got into your head. Only one stayed.
The difference isn’t the content. Calculus isn’t harder to remember than balance and pedalling. The difference is how you learned each one. Cycling went into your head through your hands and your legs and a few bruises. You fell. You adjusted. You tried again. Your nervous system kept the part that worked. Calculus went in through your eyes and your short-term memory and a deadline.
There’s a name for this in learning science. Two different kinds of knowing. The kind you can state and the kind you can do. We pretend they’re the same skill. They aren’t.
Most engineering colleges train the first one thoroughly. They train the second one accidentally, in the last few months before placements, when the gap suddenly becomes everyone’s problem at once.
What actually changes when you flip the order
A hands-on engineering programme isn’t a regular programme with more lab sessions. The cosmetic change (chalkboards swapped for screens, a final-year capstone added) doesn’t move the needle. The real change is the order in which things happen.
You start with a thing to build. The build runs into a problem. The theory shows up when the problem needs it. You learn the theory in the context of the problem it solves, which is the only context in which most engineering theory makes any sense.
Then you build the next thing. The one after that uses the same theory in a slightly different shape. By the third or fourth project, the theory has stopped being a thing you remember. It’s become a thing you reach for, without checking.
This is what your nervous system does with cycling. It’s also what it does with calculus, if you actually use calculus to build things. Most engineering graduates haven’t, which is why they don’t.
A hands-on classroom puts the build first. The syllabus is still there. It’s not the bus, though. It’s the road.
A platform that knows where you are
The other piece that hands-on learning needs (and rarely has) is a system that knows where each student actually is.
At Kalvium, that system has a name. HEROS, or Higher Education Real-time Operating System. The acronym doesn’t matter. What matters is what it does. It tracks the actual work, in real time. Every project. Every line of code. Every concept the student has and hasn’t picked up.
That changes what a mentor can do. Instead of teaching to the average and hoping the curve catches everyone, the mentor walks in already knowing which student is stuck where. A struggling student doesn’t fail the assignment first and ask for help second. The signal arrives before the failure does. The intervention is small and specific.
This is what one-to-one looks like at scale. It isn’t more lectures. It’s better data, and the willingness to act on it.
The smallest cultural change that does the most work
The most distinctive thing about a Kalvium classroom isn’t HEROS, or the projects, or the mentors. It’s the names.
Everyone calls everyone by their first name. Students to peers. Students to seniors. Students to mentors. Mentors to students.
This sounds trivial. It isn’t.
In a traditional classroom, there’s a wall built out of titles. “Sir.” “Ma’am.” “Senior.” Each one tells a student where they stand and how cautious they have to be. They’re cautious about asking questions. They’re cautious about being wrong. They’re cautious about admitting they don’t follow.
A first-name room takes that wall down. A student who can call a mentor by their first name will ask them a stupid question, and a stupid question is often the first move in actually understanding something. A student who can argue with a peer two years senior is in a flatter network than they’ve ever been in.
The work runs faster in a flatter network. That’s not opinion. It’s how every engineering team in the world that actually ships software is structured.
Where the real-world on-ramps come from
Two more things matter, and both come from outside the classroom.
The first is open source. FOSS, the world of Linux and Firefox and the libraries every modern company actually depends on, is the largest free apprenticeship the engineering profession has ever invented. A student who contributes to a real FOSS project is writing code that real users are running. They are getting reviewed by engineers who have shipped at scale. They are building a portfolio that anyone hiring them can see and read.
Most engineering colleges in India don’t connect their students to this. We do, because it’s the cheapest, fastest way to put a Year-2 student in contact with real work.
The second is starting something. Not every student should. The honest read is that most students aren’t building a company in college, and that’s fine. But for the ones who genuinely want to, an environment where they can try (with mentors who’ve started things, with peers who’ll join their experiments, with a system that doesn’t penalise them for shipping their own thing) is a different kind of education. The Silicon Valley dorm-room story is a cliché because it has happened often enough to be one.
Both of these are on-ramps. The point of an on-ramp is to make the work feel smaller than the highway, so the student gets on.
What this adds up to
You don’t fix engineering education by improving the recipe. The recipe was never the constraint. The constraint is the cooking.
A hands-on programme isn’t a softer version of the traditional one. In some ways it’s harder. The work is more visible. The gaps are more visible. There’s no exam pattern to game. The build is either working or it isn’t.
That harder version is also the one the next four decades of work are going to ask for. The standardised script that the industrial-era classroom was preparing students to follow is being written by software now. The engineers we are training need to write the next script, not run it.
The Colonel’s recipe is public. The cooking is the part the world is still hiring for.
That’s still the part most engineering programmes treat as the extra. We’re trying to treat it as the point.