Engineering & Hiring
Oct 18, 2026 · 12 min read
H*ckerRank Said Sorry for L**tCode Interviews. But What Should Replace Them?
HackerRank is questioning the coding interview culture it helped popularize. As AI changes how engineers build software, the real challenge is figuring out how to recognize engineering ability beyond a correct answer.
Chandan Giri
Founder @ Mindfries
For years, aspiring software engineers have followed a familiar routine. Open LeetCode, solve a few problems, study data structures and algorithms, revisit dynamic programming, and repeat the process until technical interviews start to feel predictable. For many developers, this routine has become almost a second job, running alongside college, full-time employment, or the search for a first opportunity.
Then HackerRank, one of the companies that helped popularize technical coding assessments, did something unusual. Its CEO, Vivek Ravisankar, publicly apologized for making developers grind LeetCode-style problems. The message appeared on billboards in San Francisco, accompanied by a larger argument: technical hiring has spent too much time measuring interview preparation and not enough time measuring the ability to build software.
It is a striking admission from a company that has been part of the ecosystem for years. But the more interesting question is not whether HackerRank is right to apologize. It is what the industry should learn from the problem it has acknowledged.
The problem was never algorithms. It was what we started measuring.
There is a good reason coding interviews use algorithms. They can reveal how candidates break down problems, reason about complexity, recognize patterns, and implement solutions under constraints. These are valuable skills, and dismissing them entirely would be a mistake.
The trouble begins when success in a technical interview becomes almost synonymous with the ability to solve a particular class of problems quickly, under artificial conditions, without the resources an engineer would ordinarily use.
Consider two candidates interviewing for a backend engineering role. One has spent months practising interview questions and can recognize a familiar pattern almost immediately. The other has built production APIs, investigated database bottlenecks, traced intermittent failures, and worked through unfamiliar codebases. They may have very different strengths, yet a process dominated by algorithmic puzzles could favour the first candidate, even if the second is better prepared for the actual job.
Neither candidate is necessarily better in every respect. The problem is that the interview may not give the hiring team enough evidence to tell.
A coding assessment is supposed to help answer a practical question: can this person do the work we are hiring them to do? When the assessment measures something narrower, employers risk confusing a useful signal with the whole picture.
AI has made that gap harder to ignore.
A few years ago, writing code from a blank editor was a reasonable approximation of certain engineering tasks. Today, developers increasingly work with AI assistants that can generate implementations, suggest fixes, explain unfamiliar code, and help explore possible solutions.
That changes the nature of the job, but it does not make engineering expertise less important. In some ways, it makes sound judgment more important.
An AI assistant can generate a plausible implementation that fails on an edge case. It can suggest a database query that works on a small dataset but performs poorly at scale. It can introduce a dependency that conflicts with the existing architecture or fix one bug while creating another.
Someone still needs to recognize these problems.
The engineer's responsibility is not simply to produce code. It is to understand the requirement, choose an appropriate approach, inspect the result, test assumptions, investigate failures, and decide whether the solution is good enough to ship.
This is the distinction HackerRank is now emphasizing through its newer interview experience and its AI-assisted interviewer, Chakra. Its Plan-Build-Review approach moves candidates toward practical repository tasks, where they can plan a solution, implement it with AI assistance, and review what they have built.
The shift makes sense. If the workplace allows engineers to use AI, an interview that prohibits it may measure a workflow that no longer reflects the job.
But allowing AI is only the first step. A more realistic environment does not automatically produce a more reliable assessment.
A realistic task can still be a poor assessment.
Imagine giving a candidate an existing application and asking them to implement a feature. The candidate completes the task, the tests pass, and the evaluator records a high score.
What do we actually know?
We know that the candidate produced a working result under the conditions of that assessment. We do not necessarily know whether they understood the existing architecture, investigated the right files, considered alternative approaches, or noticed the limitations of their implementation.
Perhaps they arrived at a strong solution after careful investigation. Perhaps they relied on an AI-generated patch they barely understood. Perhaps they took a longer route but identified a subtle failure that the initial tests did not catch.
The final code alone may not distinguish between these situations.
This is where the next generation of technical assessments needs to go further. It must examine not just what a candidate produces, but also the evidence behind the result.
Did they understand the problem before writing code? Did they identify relevant constraints? Could they explain why they chose one approach over another? When something failed, did they debug systematically or keep changing things until the error disappeared? Did they write meaningful tests? Could they identify what remained incomplete?
These are not soft alternatives to technical skill. They are part of technical skill.
The missing piece is evidence of how someone thinks.
At Mindfries, we believe that a technical assessment should reveal more than whether a candidate reaches the expected output. It should help a hiring team understand the engineering decisions that led to that output.
That begins with the task itself. A well-designed assessment should resemble a meaningful piece of work: investigating a codebase, researching an unfamiliar technical concept, designing a system, implementing a feature, or debugging a failure. The task should be challenging enough to reveal differences in ability without becoming an endurance test.
The evaluation must then follow the work. If a candidate chooses a particular architecture, the assessment should examine whether that choice fits the requirements. If they research an unfamiliar library, the evaluation should consider how effectively they find and apply relevant information. If their first implementation fails, the important question is how they respond.
A candidate who encounters an unexpected bug is not necessarily performing poorly. In fact, the debugging process may reveal more about their engineering ability than a solution that works immediately. Strong engineers make mistakes, revise assumptions, and learn from evidence. A useful assessment needs to recognize that process.
The same principle applies to system design. A diagram can look convincing while concealing unrealistic assumptions about traffic, data consistency, failure recovery, or operational complexity. The quality of the design becomes clearer when the candidate explains the trade-offs and responds to questions about the decisions they made.
The goal is not to reward candidates for narrating every keystroke. It is to collect enough meaningful evidence to distinguish genuine understanding from a result that merely looks correct.
HackerRank is right about the direction. The industry still has work to do.
The reaction to HackerRank's announcement reflects a frustration many developers have expressed about puzzle-heavy interviews. Some welcome a move toward realistic engineering tasks because they believe it better reflects day-to-day work. Others point out that take-home assignments and practical projects can create their own problems: excessive time commitments, inconsistent evaluation, unclear expectations, and opportunities to submit work that candidates cannot independently explain.
Both concerns are legitimate.
Replacing a timed algorithm puzzle with a large take-home project does not automatically make hiring fairer. Replacing it with an AI-assisted interview does not automatically make it more accurate, either. A realistic task can still be poorly scoped, and an automated evaluator can still misunderstand a reasonable solution.
There is also a danger in treating AI fluency as a substitute for engineering fundamentals. A candidate who can prompt an AI assistant effectively but cannot recognize an incorrect answer is not necessarily a strong engineer. Equally, a developer who understands algorithms deeply should not be dismissed simply because they work differently with AI tools.
The better approach is to evaluate these capabilities together, with the emphasis depending on the role. Algorithmic reasoning matters for some positions. Production debugging matters for others. System design, security, testing, research, and AI-assisted development may carry different weights depending on the work a person will actually perform.
No single score can capture every dimension of engineering ability. Hiring teams need a structured way to interpret the evidence, understand its limitations, and decide what deserves further investigation.
The future of technical hiring is not another leaderboard.
For a long time, developers have been encouraged to optimize for a visible outcome: solve the problem, pass the test cases, and move on to the next interview round. It is an understandable system because the results are relatively easy to compare.
But the work of engineering is rarely that clean. Requirements are incomplete. Documentation is outdated. Existing systems contain surprising dependencies. Tests miss edge cases. The first solution is not always the best solution, and sometimes the most important decision is recognizing that the proposed approach should be reconsidered.
A hiring process that ignores these realities risks selecting for the ability to perform in an interview rather than the ability to perform in a job.
The next step is not to abandon structure or make interviews entirely subjective. It is to build assessments around clear expectations, realistic tasks, consistent evaluation criteria, and observable evidence of technical judgment. Candidates should understand what they are being assessed on, and hiring teams should be able to explain why one candidate's work provides stronger evidence than another's.
AI makes this shift more urgent, but the underlying problem existed long before generative AI arrived. We have always needed better ways to distinguish someone who can solve a prepared exercise from someone who can handle the uncertainty of real engineering work.
HackerRank's apology is therefore worth paying attention to, not because LeetCode-style interviews have suddenly become useless, but because a major player in technical hiring has acknowledged that the old approach has limitations.
For Mindfries, that is the question worth pursuing: not how quickly a candidate can produce the right answer, but how confidently a hiring team can understand the reasoning, decisions, and engineering ability behind it.
Because hiring a great engineer should mean finding someone who can build, investigate, question, and improve—not simply someone who has learned how to pass the interview.