Why We Stopped Using HackerRank (And What We Use Instead)

JustInterview.ai wasn't built for a client. Techdome Solutions built it because we were hiring engineers for our own team and spending roughly 30 hours a week on a hiring process that clearly shouldn't need 30 hours. A meaningful chunk of that time went into running and reviewing standard coding assessments, and the more of them we ran, the less confident we felt that they were telling us anything useful.

What was wrong with the standard coding test?

The format is familiar to anyone who's hired or been hired as an engineer in the last decade: a blank editor, a timed problem, no AI assistance, a pass/fail or percentage score at the end. It made sense when it was designed. It stopped making sense once every engineer on our own team started using AI tools daily to write real production code, which meant we were assessing candidates on a working condition, solving a problem completely alone, that didn't match a single day of the actual job.

The reasoning problem no assessment tool solved

The deeper issue wasn't just that AI tools were banned, it was that a pass/fail score doesn't tell you how someone thinks. Two candidates could both pass the same test, one by working through the problem methodically and one by recognizing the exact pattern from a practice site and reproducing a memorized solution, and the score alone can't tell those two candidates apart. We wanted to see the reasoning, not just the output, and no assessment platform we evaluated was built to capture that.

What did we build instead?

Vibe AI: a built-in AI assistant inside the assessment itself, with every prompt a candidate sends logged and attached to their submission. Instead of trying to detect or prevent AI use, which is hard to enforce and increasingly beside the point, we made AI use fully visible and scored it as part of the signal. Every submission now gets three separate scores: code correctness against test cases, code quality and structure, and a reasoning score drawn directly from the candidate's prompt log, how clearly they framed the problem, how they iterated on a weak first attempt, whether their final understanding actually matches what they submitted.

What changed when we started evaluating how candidates use AI

Candidates who paste a problem into an assistant and submit the first response without modification look different from candidates who iterate, question a wrong answer, and refine their approach, and that difference shows up clearly in the reasoning score even when both submissions pass the same test cases. That's a signal a blank-editor, no-AI test cannot produce, no matter how well-designed the underlying problems are, because it's testing a skill, unassisted recall under time pressure, that isn't the skill our own engineering team actually uses day to day.

What we tried before landing on Vibe AI

Before building Vibe AI, we looked at the obvious alternatives: keep the blank-editor format but shorten it, or keep AI banned but add a live coding round to catch candidates who might be relying on a tool off-camera. Neither addressed the actual problem. Shortening a test that measures the wrong skill just gets you a faster wrong answer. A live-coding round to police AI use turns the assessment into a surveillance exercise instead of a hiring signal, and it still doesn't tell you anything about how a candidate reasons when using the tools they'd actually have access to on the job. The only fix that addressed the real issue was building an assessment format where AI use was expected and visible, not something to detect and eliminate.

Where this leaves teams still running standard coding tests

We're not arguing every coding assessment needs to look like ours. We're arguing that if your engineering team already works with AI tools every day, and for most teams in 2026 that's simply true, a hiring bar that pretends otherwise is measuring the wrong thing. The fix isn't necessarily switching platforms. It's asking whether your current assessment format would look reasonable to your own team if you described it to them: "we ban the tools you use daily, then judge candidates on how well they work without them." If that sounds like a mismatch, it is one, and it was the exact mismatch that got us here.

We also don't think this is the last word on what technical assessment should look like. The tools engineers use will keep changing, and an assessment format that's honest about that will need to keep changing with it. What we're confident about is the direction: an assessment that reflects how your team actually builds software is a better predictor of how someone will perform on the job than one that reflects how the industry built software a decade ago.