Anand Vijay Sankar Guntuku (2017)
Arjun earned his MTech from an IIT in 2020 and walked into a data scientist role at an MNC. His role was building price-modelling algorithms for an airline, the kind of job that once felt like a safe summit for an engineering graduate. Two years later, he quit his job to prepare for the UPSC Civil Services exam, betting that his skills and industry background would carry him into public service. But repeated unsuccessful attempts made him quit after years of toil. When he came back to the job market in 2026, he discovered that neither his extensive UPSC preparation nor his work experience in data science modelling matched the skills employers now wanted.
His IIT degree told him he was worth more than what was being offered. Moreover, the entry- to mid-level roles he might have settled for were themselves shrinking, increasingly handled by AI. He was caught between a pride that the market no longer validated and a fallback that no longer existed.
His problem is a visible crack in the way India now measures readiness for work. According to Business Standard, there is a widening gap between what employers need and the skills graduates have. Mercer–Mettl’s India Graduate Skill Index makes Arjun’s problem visible at scale: only about 43 out of every 100 Indian graduates are deemed employable, and even Tier-1 colleges manage just around half (49%). Recruiters are no longer impressed by where someone studied or how hard they prepared for an exam; they are asking a different question: Can this person design, build, and maintain systems in a world where AI, data and software touch every decision?
To put it into perspective, the institutions that are teaching AI and data analytics focus a lot on mathematical models based on techniques like regression and classification; it is always models and more models. However, the student equipped with these skills, when entering the industry, often realises that building models occupies just 5% of the overall problem. As Andrew Ng from DeepLearning.AI puts it, it is in closing the PoC (Proof of Concept) to Production Gap where the real work lies.
Understanding Skill Gap
To me, the gap between a college project and a production system is best understood not as a knowledge gap but as a thinking gap.
To see what this gap looks like in practice, let me give you an example: designing a commercial loan decision system for a bank.
The first step is to understand what the business is actually asking. This is the most important step.
When a company approaches the bank for a loan, the bank does not simply want a risk score; it wants to know the full repayment history of that company, including arrears with other lenders. That means the engineer must first understand how the bank’s data is structured across branches, what gaps exist, and’ how to design an integrated system that can pull verified history from all existing sources reliably. In most of the cases the data will be scattered across legacy systems. So what data truthfully answers it comes first.
Once the data architecture is settled, the engineer confronts a second analytical layer of decisions: rules and risk. What collateral assets are acceptable? What loan-to-value ratios are legally permissible? How should conflicting signals, a good credit score but pending litigation, for instance, be weighted? These rules must be codified, tested, and periodically revised according to the governance (BASEL / Central Bank’s) norms. A model that scores risk without surfacing the logic behind the score is useless in a regulated industry, because every lending decision must be explainable to an auditor. So the logic cannot be a black box with neural nets; it should be based on traditional, explainable algorithmic models.
That leads to the third layer: integrity and security. Technologies like blockchain offer an immutable audit trail, but they come with cost–speed trade-offs and governance questions: who controls the nodes, how are disputes resolved, and what happens when a correction is legitimately necessary? These are not hypothetical concerns; they are design decisions that shape how the entire system behaves under legal scrutiny.
The fourth layer is where most fresh graduates find themselves underprepared: scale, cost, and user diversity. The same lending system will be used by a relationship manager reviewing a client’s file, an internal auditor verifying compliance, and eventually, perhaps, a customer checking its own loan status. These three users have fundamentally different needs, different permissions, and different interfaces, but they are reading from the same underlying data.
The engineer must ask: how do I build one back end that serves all three cleanly? How do I keep the app responsive when hundreds of users are simultaneously querying a large database? How frequently am I building and deploying the pipelines? What are the trade-offs in using an open-source model vs a paid model with API costs? And critically, how do I reduce the cost of infrastructure as usage scales, without sacrificing performance or security?
The fifth and final layer is the one that no engineering syllabus formally teaches: communication, feedback, and proof of robustness. The engineer who has solved all of the above still has to convince the Governance and Risk Officer that the system is trustworthy. That means translating technical architecture into business language: not “we use a gradient-boosted ensemble with a threshold of 0.7” but “the system flags loans above a certain risk band for mandatory human review.” It means designing a feedback loop with actual users, defining metrics that are meaningful to multiple stakeholders.
Although it is not an exhaustive list, this is what the gap between a proof of concept and a production system actually looks like. The models and theory learned in college address only a small percent of the dynamic problem.
Enter AI
Artificial intelligence does not eliminate any of these five layers. If anything, it deepens the demand for each one. AI now scans documents, reads financial statements, and pulls repayment histories from multiple sources in minutes rather than days. How do you make sure it reads everything perfectly?
AI-generated summaries for the relationship manager still need to be audited; AI that detects fraudulent transactions must be explained to regulators. The engineer who built the model must now also design the explanation layer, the audit log, and the override mechanism. What AI changes is the floor of expectation; in fact it makes each layer faster to fail, more consequential when it fails, and more difficult to explain when someone asks why. The person who can design the system around the model, govern it, and explain it, is more valuable. According to PWC, in India, AI may open up 2.6 million new technology jobs by 2028 precisely because this infrastructure work requires people who understand systems at this level of depth.
In 2021, being a good data scientist meant building reliable models. By 2026, it meant understanding data engineering, deployment infrastructure, agentic orchestration, system governance, and the ability to explain AI-driven decisions to business users and regulators. This is not a different job; it is the expectation of the same job.
Arjun is not unlucky, he represents the first wave of a problem that is about to get much more common: a skill gap that is increasing at a faster rate than the market can handle but one that inevitably needs to be closed. The question for a fresh graduate in India in 2026 is not simply “what job should I take” or “should I do an MBA.” It is: which combination of domain depth, systems thinking, and AI fluency I have to develop and apply. So your engineering degree is not a destination, it is merely a starting point. The market does not care how hard you prepared. It only asks one question: Can you build what it needs, right now?
