Something I’ve noticed over multiple cohorts is that the students who struggle most in their second year aren’t usually the ones who found the material too hard.
They’re the ones who found it too easy to pass.
A few hours of theory a week. Some labs. One exam at the end of the semester. A grade that moves them forward. By the time they’re expected to do something real with what they learned, the material has been gone for months. Not because they weren’t paying attention. Because the programme was designed in a way that guaranteed the forgetting.
This isn’t a student failure. It’s a design failure.
I lead programme design and delivery at Kalvium. That means I spend a meaningful portion of my time reading what the research actually says about how people learn complex skills, and then trying to make a live programme behave consistently with it. The research doesn’t flatter the standard B.Tech. Five findings, in particular, explain why most engineering programmes don’t produce engineers. They also explain what a programme has to do differently if it wants to.
Memory doesn’t work the way most syllabuses assume
The forgetting curve is 140 years old. In 1885, Hermann Ebbinghaus ran a series of experiments on himself, memorising lists of nonsense syllables and tracking how much he could recall over time. The result: without retrieval, the rate of forgetting is steep and roughly exponential at first, then flattening. Within days of learning something once, most of it’s gone.
This isn’t contested science. It’s been replicated across populations and material types, most recently by Jaap Murre and Joeri Dros in 2015.
A standard four-year engineering programme teaches a subject for one semester and moves on. Data structures in semester two. A systems design course in semester four that assumes the data structures foundation is intact. By then it isn’t. The forgetting curve has done its work, and the retrieval that would’ve prevented it never happened.
Henry Roediger and Jeffrey Karpicke sharpened this picture in a series of studies published from 2006 onward. Students who were tested on material after learning it retained significantly more than students who re-read the same material. The re-reading group felt more confident. They scored worse when tested a week later. Pulling information out of memory doesn’t just check whether learning happened. It produces the learning. Retrieval is the mechanism, not re-reading. Most students re-read because it feels productive. It isn’t.
Robert Bjork at UCLA extended this into what he calls desirable difficulties. Design choices that make learning harder in the moment tend to produce better long-term retention. Spacing practice sessions instead of cramming. Interleaving topics instead of blocked study. Using retrieval prompts during a course, not just at its end. Each of these is uncomfortable in the moment. Each of them, across careful research, outperforms the alternatives.
The programme-design implication is direct. Retrieval has to be built into the weekly rhythm of the programme, not saved for end-of-semester exams. A terminal exam per course is convenient for the institution’s calendar. It doesn’t serve the student’s retention.
I’ve written about the Ebbinghaus and Karpicke findings in more depth in the forgetting curve piece. The point here is what the research implies for how an entire programme should be structured, not just how an individual student should study.
Expertise is built through volume, not insight
K. Anders Ericsson spent three decades studying how people become genuinely expert at hard things.
Chess grandmasters. Surgeons. Musicians. Software engineers. The finding that held across every domain is called deliberate practice, and it has a structure that most curricula find uncomfortable.
Expertise isn’t built primarily through understanding. It’s built through high volumes of practice that push slightly beyond current ability, with specific and immediate feedback on errors, repeated across thousands of hours. Understanding is necessary. It’s not sufficient. The bottleneck is volume.
Consider two students who’ve both grasped recursion fully. One has written thirty recursive functions. The other’s written three hundred. They’re not in the same place. The second student has built reflexive fluency: she can reach for recursion in a real system, under time pressure, without reconstructing the concept from scratch. The first student hasn’t done that yet. It doesn’t matter how good the lecture was. The fluency doesn’t come from the understanding. It comes from the accumulated volume of practice.
This is why a daily coding practice isn’t an add-on. It’s the core mechanism. At Kalvium, students work through DOJO, a daily coding challenge system that runs a belt progression across multiple programming languages. It’s not scheduled once a week. It’s built into every day. Six days a week. Eight hours a day. The intensity isn’t arbitrary: that’s what Ericsson’s research implies the volume of practice needs to look like if genuine expertise is the goal.
Ericsson’s work also identifies something specific about feedback. Improvement requires feedback that’s immediate and specific to the attempt. A grade assigned three months later, after a semester ends, can’t function as feedback for deliberate practice. You can’t use it. The practice that builds expertise is practice where you write a function, see exactly how and where it failed, and try again in the same session.
The full-stack development in first year piece gets at why this matters in programme architecture. A first-year student at Kalvium is already building and shipping real code. That’s not about rushing students or pretending they’re ready for everything. It’s about getting to the volume of deliberate practice that actually builds the skill, early enough that four years of accumulation is possible.
Vidvath J., a first-year student from Squad 49, was selected for Google Summer of Code, out of more than 43,000 candidates across 172 countries. He’d been in the programme for one semester. That outcome doesn’t come from a single semester of instruction. It’s what builds when the programme’s design is consistent with what Ericsson’s findings require from the start.
Working memory has limits that most syllabuses push past
John Sweller developed cognitive load theory in a series of papers across the 1980s and 1990s.
The core finding: human working memory can only process a limited number of things simultaneously. When a learning environment exceeds that capacity, learning stops. The student isn’t struggling because the material is beyond them. They’re struggling because the way the material is presented is overloading the cognitive system they need to use in order to understand it.
A traditional engineering lecture is an efficient generator of this problem. The professor writes a derivation on the board. Students try to copy it, follow the logical thread, and maintain the overall argument simultaneously. They can’t do all three at once. Something drops. Most of the time, it’s the understanding.
Sweller documented one version of this as the split-attention effect. When the relevant information is spread across multiple separate sources, working memory has to spend its limited capacity just holding those sources in parallel before integration can even begin. A diagram on the board, an explanation in the textbook, different parameters on a lab sheet: the student is overloaded before the learning starts. That spent capacity doesn’t go toward learning. The cost is real and measurable across experimental conditions.
The implication for programme design: theory and practice can’t be separated into different sessions if efficient learning is the goal. When explanation and application are in the same session, in the same context, working memory’s capacity goes toward the actual conceptual difficulty, not toward holding two separate sources together.
At Kalvium, the guiding principle is “Learn it. Build it. Same session.” It’s not a tagline. It’s a specific design response to what Sweller’s research implies. A concept is introduced and immediately applied in context. The scaffolding changes as students develop schemas. Novices get worked examples before they’re asked to solve novel problems independently. The difficulty level matches where the student actually is, not where the syllabus expects them to be.
None of this removes difficulty. It removes the unnecessary difficulty that comes from poor presentation design rather than from the subject itself. A student who’s struggling because a concept is genuinely hard is developing. A student who’s struggling because the explanation and the practice are two weeks apart and in different formats probably isn’t. Sweller’s research distinguishes between those two kinds of struggle.
Learning is social and situated, not individual and abstract
Jean Lave and Etienne Wenger published “Situated Learning: Legitimate Peripheral Participation” in 1991.
Their argument: complex skills aren’t learned effectively through abstract instruction removed from the real context of the skill. They’re learned by participating, initially in supporting roles, in communities of practice where the skill is actually being exercised.
The traditional example is apprenticeship. An apprentice electrician doesn’t learn by studying electrical theory for three years and then being placed on a job site. From the start, they’re on real job sites, initially doing simple peripheral tasks and observing more complex ones, gradually taking on more as their competence grows. The learning is embedded in the doing. The community provides the context that makes the abstract meaningful.
Most engineering programmes invert this structure completely. Years of theory in classrooms, removed from any professional engineering context. A final-year project that looks like real work but isn’t. An internship, sometimes, after the degree is finished. By the time a graduate arrives at their first engineering job, they haven’t spent a meaningful amount of their degree in anything resembling the environment they’re now expected to function in.
From classroom to codebase examines what this gap looks like in practice. The difference between a student who’s built real software alongside experienced engineers and one who’s studied the same topics in isolation isn’t just a skills gap. It’s a gap in how knowledge is held: whether it’s situated in real problems they’ve actually encountered, or abstract in a way that hasn’t been tested against anything real yet. That gap matters the moment the student arrives in a real team.
At Kalvium, the squad structure is a direct design response to what Lave and Wenger’s research implies. Small groups of students work alongside mentors who are active practitioners, on real codebases, from semester one. Not year three. The professional context isn’t separate from the curriculum. It’s part of the curriculum, from the first week.
This is also part of why the programme involves engineers and founders from Zerodha, PhonePe, CRED, Google, Microsoft, and others in curriculum design and review. Not as occasional advisors. Their professional judgement shapes what the curriculum actually contains. The community of practice, in Lave and Wenger’s sense, starts at the design level before a student even enrols.
What these five findings say together
Five traditions. Ebbinghaus and Karpicke on memory and retrieval. Bjork on the structure of difficulty. Ericsson on deliberate practice. Sweller on cognitive load. Lave and Wenger on situated learning.
Each was developed independently, in different domains, by researchers who weren’t designing engineering curricula. But they all identify the same structural problem with how most engineering programmes work.
The standard engineering programme wasn’t designed against the question “how do people actually acquire complex skills?” It was designed against a different question: how do we teach large numbers of students within the constraints of an academic institution? Those are different questions. They produce different answers.
The institutional constraints are real. Fixed semester lengths, limited faculty contact time, accreditation requirements, assessment systems designed to rank students cleanly: these pressures all push toward one-exam-per-semester structures and deferred building. None of it’s malicious. It’s what happens when the constraints of running a college at scale, rather than the constraints of how learning works, are the design brief.
A programme designed against the research looks different. Retrieval built into every week. Daily high-volume practice from month one. Explanation and application in the same session. A real community of practice from the first day.
Why learning at Kalvium feels different is about what that texture looks like in practice. Why studying feels impossible covers motivation and attention research that sits alongside what I’ve described here. Rajesh’s essay on India’s engineering education is about why the structural problem persists at the system level, even when the research pointing away from it has been available for decades.
Where the evidence is genuinely uncertain
I want to be honest about something that most content about “evidence-based learning” leaves out.
Some of what I’ve described is well-established. The basic shape of the forgetting curve. The testing effect on factual and procedural learning. The general advantage of spaced practice over massed practice. These have been replicated across many contexts and populations.
Other parts are less settled.
The optimal spacing interval for retrieval practice isn’t a solved problem. It varies by material, by student, and by how long the retention needs to last. Anyone who’s selling a precise spaced-repetition algorithm as “scientifically optimal” is overstating what the evidence supports.
The transferability of Ericsson’s deliberate practice findings from chess and music to software engineering is also genuinely contested. Ericsson’s work is clearest in domains where the performance criteria are specific and measurable. Software engineering is messier. The criteria for expert performance aren’t cleanly defined. The practice structures aren’t standardised across the field. We design as if the core principles transfer, because the underlying mechanism is plausible, but I hold that with some genuine uncertainty.
I’m most uncertain about the interaction effects. Each research tradition was studied largely in isolation. What happens when you try to apply all five simultaneously in a live programme, with real students, over four years, is something we’re finding out through actually running the programme. Not through reading papers.
Why Kalvium’s capstone projects start in semester two is partly about this. The decision to start early was grounded in the research, but it’s also tested against real student experience each cohort. We don’t treat the research as a blueprint we follow. We treat it as a set of constraints the programme has to satisfy, and then we watch what actually happens and adjust. That process doesn’t end.
The question worth asking any programme
There’s one question I’d suggest asking any B.Tech programme you’re seriously considering, including Kalvium.
What does a student build by the end of semester one, and how does the programme’s design get them there?
A programme that can’t answer that question concretely hasn’t wrestled seriously with the research I’ve described. It might still be a sound programme for reasons unrelated to pedagogy. But it hasn’t designed against the evidence.
A programme that can answer it, and can point to specific design choices and their rationale, is one that has. That’s worth knowing before you commit to four years.
The complete programme guide for families covers the curriculum structure, the nine partner universities for Admission Year 2026-27, the DOJO and squad systems, and what the four years actually involve.
As of March 2026, 82.40% of Kalvium’s first graduating batch were placed before completing their degree, with a median salary of ₹16.5 LPA. I mention that not as a promise about what any programme can guarantee, but as evidence that a design built around the research I’ve described produces real outcomes. The five traditions I’ve described aren’t prescriptions. They’re descriptions of how learning actually works. A programme that takes them seriously tends to produce graduates who can actually build things.
Ebbinghaus made the core finding in 1885. Sweller’s key papers are from the late 1980s and 1990s. Ericsson’s are from the same decade. Lave and Wenger’s book came out in 1991. Roediger and Karpicke’s key studies are from 2006.
None of this is new. Most engineering programmes haven’t acted on it. The question worth asking is whether the one you’re considering has.