One of the greatest bonding experiences I had with my classmates at Carnegie Mellon was our shared vitriol of “grinding LeetCode.” LeetCode, along with its more beginner-friendly competitor Hackerrank, were platforms that commanded the bandwidth of any college student seeking employment at a FAANG company, high frequency trading firm, or systematic hedge fund. Often the first filter separating serious candidates from unserious ones, the stakes felt existential: you hoped the problems given would resemble the ones you had spent all night practicing, and that the unknown bug blocking test case #31 would resolve itself before the clock ran out.
Although I detested the LeetCode grind and the stress that came with it, I understood why it was stressed so heavily in the recruitment process. There are thousands of students who apply to a single position, and an assessment that proves you are:
Interested enough in the role to dedicate 45 to 90 minutes of your afternoon to take an assessment
Proficient in programming and pattern recognition under time pressure, as higher-level problems often require recognizing the right approach immediately and brute-force is not a viable option
Able to read the words “given an array of integers” without your eyes completely glazing over, as you have likely spent hours solving Neetcode 150 problems beginning with the same dreaded introduction
While these attributes are not completely deterministic in predicting success in software engineering roles, one could argue they are a reasonable proxy. A student unwilling to spend an afternoon on a screening assessment is unlikely to go the extra mile once hired. A student who does not understand dynamic programming, binary search trees, and time complexity will not be able to build a system that performs when their product’s user base grows from a thousand to a million.
But that is all over now with AI, right?
Vibecoding has become a primary tool in a software engineer’s toolkit, and with further AI integration into codebases through tools such as Cursor and Claude Code, adoption is only accelerating. By early 2026, 92% of US developers were using AI coding tools daily, and GitHub reported that 46% of all new code written globally is now AI-generated. The implications for technical screening have been immediate. While ChatGPT was unable to solve a LeetCode medium problem a couple of years ago, it can now solve virtually any problem on LeetCode’s platform. I’d wager a meaningful percentage of college students desperate to join a prop trading firm out of college have a separate tab open with their LLM of choice the moment they receive an assessment invite, especially considering the vast majority of programming screeners are asynchronously administered without a proctor. The data backs this up: across over 50,000 candidates, AI-assisted cheating more than doubled from 15% to 35% in the second half of 2025 alone.
The global talent assessment market sits at roughly $29 billion today and is projected to nearly double by 2035, with nearly 63% of Fortune 1000 companies depending on at least one assessment platform in their hiring workflow. The incumbents in this space, LeetCode and HackerRank among them, have largely responded to the AI moment by flagging AI usage, a notoriously difficult task. While HackerRank has touted 93% accuracy in detecting AI-generated submissions, a 7% error rate is significant when it means filtering out candidates who followed the rules. Beyond the error rate, the approach seems to miss the point entirely. Attempting to lock AI out of a coding assessment is akin to banning calculators from a math exam: a well-intentioned effort to preserve the integrity of an existing test, rather than grappling with the fact that the test is no longer relevant in a world in which technology has ingratiated itself into all aspects of our lives. Some firms have responded by returning to live coding interviews for a select group of applicants, but this only recreates what asynchronous screening was designed to replace: an unscalable and expensive process quietly biased toward candidates who rise to the top of the resume stack through connections, target school pedigrees, or sheer luck. They have shied from fundamentally rethinking what their assessments should measure, and that is a significant gap in a market being disrupted by the very technology it is trying to police.
Universities have paralleled the approaches of programming platforms and firms by issuing strict bans on AI usage and shifting to in-person assessments, with Princeton announcing it will proctor in-person exams and revising a 133-year-old tradition in the process. Yet universities find themselves in an equally uncomfortable position. While banning AI and reverting to proctored exams preserves the integrity of a curriculum built around writing code from scratch, it risks graduating students who are unprepared for workplaces where AI fluency is required to stay afloat. Permitting it risks the opposite: students who can generate working code but have never been forced to understand it. A potential path forward is a curriculum that requires students to first master the fundamentals of their field without AI, then develop a working understanding of how to engage with it, select the right model for a given task, and apply it in practice, all while remaining flexible enough to adapt as the models themselves continue to evolve. However, expecting institutions that have slowly evolved over the course of centuries to redesign themselves on a timeline shorter than a model release cycle is a different kind of problem entirely.
Given the adoption of platforms such as Claude and Cursor by both big-tech software engineers and citizen developers alike, some have gone as far as to claim software engineering itself is dead. Generative AI platforms have enabled teams to ship in days what once took months, and motivated individuals can now build functional applications with little formal training. But the death of software engineering and the death of software engineering expertise are not the same thing. Firms that rely primarily on model-generated code without understanding what it is doing will inevitably encounter a crisis when their product breaks in production and no one on the team can explain what is happening underneath the hood. While memorizing pandas syntax and sorting algorithms has now been rendered obsolete, the technical expertise required to audit and maintain AI-generated code is more important than ever, as production code is being written at the fastest pace in history. Aside from accounting for space and time complexity, software engineers must now introduce an additional constraint: token efficiency. While time and space complexity have been taught in computer science programs for decades, the standard playbook for token efficiency is largely unwritten, and any conventions that do emerge risk becoming obsolete before they can be standardized. Unlike Big O, which holds regardless of the underlying system, token efficiency is model-specific, version-specific, and in constant flux as models continuously update. The economics make this urgent. AI compute is far from free, and the industry is beginning to reckon with what that means at scale. Jensen Huang famously stated his engineers should be spending AI tokens worth at least half their annual salary, or he would be deeply alarmed. OpenClaw creator Peter Steinberger’s team spent $1.3 million on OpenAI API tokens in a single month, totaling 603 billion tokens. Mercor CEO Brendan Foody recently revealed that his company spends more on tokens than on salaries, and expects this to become the norm across the average enterprise within five years, because models can compound intelligence in a way humans cannot. Token spend is no longer a rounding error on an engineering budget. Given the black-box nature of AI, software engineers are largely reverse-engineering token-efficient solutions on their own, and the companies hiring them have yet to build a screen that accounts for it.
We are at an inflection point where a widening gap has opened between what computer science programs teach, what technical assessments screen for, and what companies actually require from their software engineers. While firms face less immediate urgency than institutions to adapt, they risk being the last to realize that the skillset has already shifted. Writing code from scratch is no longer the core competency; knowing which model to deploy for a given task, how to prompt it efficiently, and how to audit what it produces are. A candidate who cannot do those things will struggle just as much as one who could never get past test case #31. We just have not built the screen that proves it yet.