Here is something that took me longer to say plainly than it should have.
The skills that make a CSE graduate actually employable, the ability to build software that runs, to debug systems you didn’t write, to ship something a real user can touch, can’t be reliably measured by a written exam. Not because they’re too advanced. Because they’re the wrong shape. A written exam is an instrument designed to test whether you know something. The question “does this code run?” cannot be answered by asking someone to describe how code should run.
Once that distinction was clear, the design decision almost made itself.
At Kalvium, the curriculum runs on three parallel layers. Essentials covers the AICTE-compliant degree subjects: the content that earns the 164 credits and gets assessed through university examinations. Mastery covers employability: industry-aligned work verified through codebases, deployed systems, and real software artifacts, not through written tests. Excellence covers ownership: open-source contributions, mentoring, and the kind of sustained real-world work that builds a record beyond the degree.
Essentials goes through the exam system. Mastery does not. This post is the explanation.
What exams are actually good at
I want to start with what exams do well, because the argument here isn’t that examinations are useless.
In 1990, an American educator named Grant Wiggins published a paper he would spend the next decade expanding into a body of work that serious curriculum designers still return to. His claim was precise. Traditional tests are reliably good at measuring whether students know things and can recognise the right answer in a structured setting. They are poorly suited to measuring whether students can do things: whether they can perform in authentic contexts with real constraints, genuine uncertainty, and no answer key in the room. He called this the authentic performance problem, and it’s particularly sharp in technical fields where performance is the point.
The distinction between knowing and doing isn’t philosophical for software engineering. It’s operational.
A written exam can ask a student to explain the steps in deploying a web application. It can’t ask them to deploy one, encounter the permission error that appears halfway through, reason backward from the error message to the configuration problem, fix it, and ship a working system. The first is knowledge retrieval. The second is performance. Tests are reliable for the first. They can’t replicate the second.
Why Mastery cannot be examined
There are two distinct reasons. They’re both worth stating separately.
The first is measurement.
Code either runs or it doesn’t. A deployed system either handles the expected load or it fails. A pull request either passes a code review or it doesn’t. The artifact is the evidence, and the artifact has a clear test: does it work in the environment it was built for? A written exam can’t produce that test. It can produce a description of how such a system should work, which is useful for assessing whether a student understands the concept. It can’t tell you whether the student can build the thing.
This is why the DOJO belt system assesses programming mastery through actual performance on real problems, not through questions about programming. You pass a belt level by writing code that meets the criteria for that level, across Java, C++, JavaScript, and Python, six belt levels per language, each earned through testing rather than attendance. The evidence is the code. Asking someone to describe the code they would write is a different skill and a weaker signal.
The same logic applies to the Internship and Project modules that begin in Semester 3 and run through the Final Capstone in Semester 8. What gets assessed is a working codebase, a deployed system, a technical artifact that can be interrogated by someone who did not design the brief. The question being answered isn’t “do you know how this should work?” It’s “did you build something that actually works?”
The second reason is the evolution problem.
University exam syllabi move slowly. They’re written, reviewed, approved, and then locked for a curriculum cycle. That’s appropriate for the Essentials layer, because foundational computer science content, data structures, operating systems, discrete mathematics, changes slowly enough that a fixed review cycle is reasonable. But the Mastery layer needs to track what a CSE fresher entering the job market this year actually needs to know.
If Mastery were tied to formal university exams, it would inherit the exam’s review cycle. The skills assessed in Year 4 would be decided at the point the syllabus was locked, and the industry does not hold still for four years. Keeping Mastery outside the degree structure keeps it updatable. That’s not a workaround; it’s the design intent. As the curriculum guide puts it directly: “Mastery shows what a student is ready to do.” Ready implies present tense. A syllabus locked three years ago can’t reliably define present-tense readiness.
What the three layers mean in practice
Each layer produces a different kind of evidence.
Essentials produces 164 credits across eight semesters, earned through university examinations and the subjects in the formal curriculum. These are what the degree says. They’re the formal academic record, the mechanism by which the programme satisfies AICTE requirements, and the credential the degree is built on.
Mastery produces codebases, deployments, and system artifacts. The DOJO runs daily coding practice six days a week, with belt progression across four languages, each demonstrated through performance rather than description. Live Books capture project work, assignments, and hands-on tasks in a form that mentors can inspect and that tracks real progress across the four years. The Internship and Project modules, from Semester 3 onward, produce working systems rather than reports about what working systems should look like.
Excellence produces a record. Open-source pull requests merged into projects real users depend on. Technical writing that engineers outside the programme actually read. Mentoring contributions visible to the cohort. There’s no exam for Excellence because Excellence is defined by real external stakes, not internal performance criteria.
A student who takes all three seriously leaves with all three: a degree, a body of demonstrable work, and a record of what they contributed.
The practical implication
This distinction matters for how you spend your time inside the programme.
Your university exams matter. They determine whether you pass the Essentials layer, they produce the credits the degree is built on, and the subjects in that layer are worth learning. Discrete mathematics and operating systems are not in the curriculum by accident.
But if you optimise exclusively for the exam score, you’ve optimised for the one layer that a software engineering employer can least directly use. Most technical hiring processes don’t primarily assess a candidate’s university grade. They assess whether the candidate can solve a problem they haven’t seen before, build something that works, and reason through a system they don’t fully understand. These are Mastery skills. The exam can’t build them, and the exam result doesn’t demonstrate them to a technical interviewer.
Wiggins’s distinction translates directly into a hiring context. The test tells an employer what you know. The artifact, the code you wrote, the system you shipped, the codebase you can walk through and explain, tells them what you can do. For a CSE role in 2026, the artifact is the primary evidence. The degree gets you past the initial filter. The Mastery layer determines the outcome.
Where the evidence gets thin
A piece like this one should be honest about what isn’t settled.
The case for keeping Mastery outside the exam structure is strong on two counts. Measurement: written tests genuinely can’t assess whether a deployed system works. Evolution: locking skills to exam cycles genuinely does freeze them at the review point rather than the present moment. Both arguments hold up.
What is less settled is whether every specific implementation of artifact-based assessment is optimal. Do the DOJO belt levels track precisely what a fresher needs in the current hiring market? At what point does artifact-based assessment develop its own proxy-optimisation problem, where students learn to produce artifacts that look like working systems without genuinely understanding them? These are open questions. I ask them regularly. The answers are still being refined.
The honest claim isn’t that the approach is perfect. It’s that the approach is consistent with what the research on authentic assessment says, the measurement logic holds, and the system is designed to update as we learn more.
The fuller picture
This post covers one design decision. For the research on why the broader programme structure produces more durable capability than a lecture-and-exam approach, that argument is in why most engineering programmes don’t produce engineers. For the specific learning habits that make the Mastery layer actually useful rather than just completed, they are in learning how to learn for real engineering, not for exams.
The exam is part of the degree. The Mastery layer is what the degree is in service of.
Arvind is Head of Programme Design and Delivery at Kalvium. He writes about the cognitive science of learning and how it shows up in the design of a live programme, grounded in named research and honest about where the evidence is still being worked out. Read more from Arvind or browse the B.Tech category.