"Realistic" is the single most overused word in interview design. Every team's coding test, take-home, and system design exercise is described in the brief as "a realistic problem our engineers actually work on." In most cases, that's charitable. The exercise the candidate is doing has usually been stripped of almost everything that makes the actual work feel like work.
A realistic job interview isn't about the topic of the exercise. It's about the texture of the experience. Two interviews can cover the same technical ground and produce very different reads depending on whether the shape matches what the job is actually like.
What teams usually mean by "realistic"
When a hiring manager calls an exercise realistic, they usually mean one of two things. Either the exercise is phrased in the language of the company's product ("imagine you're building a checkout flow..."), or it's based on a simplified version of a problem the team genuinely solved six months ago. Both are fine as starting points. Neither is what makes the experience realistic.
The reason is that the stuff stripped out to fit the problem into a 90-minute exercise is usually the stuff that makes real work feel like real work. A problem framed cleanly, with a closed scope and a correct answer, is the least realistic version of itself. Real engineering problems rarely show up that way.
What real work actually feels like
Think about the last non-trivial problem you shipped. The part that took the time was almost never the implementation. It was figuring out what the problem actually was, under the version someone wrote in a ticket. It was noticing the constraint nobody mentioned until halfway through — usually something about an existing system, a deadline, or a person who won't be available until Thursday. It was realising the first approach was wrong and deciding whether to back out or push through. And it was finding the right person to ask when you got stuck, and asking the question in a way that got a useful answer back.
None of that shows up in a closed-scope coding exercise. All of it shows up in the job on day one. The gap between the two is why experienced hires so often say the interview didn't feel like the work.
The shape of a realistic round
A realistic round looks different from a closed-scope one in a few specific ways. The problem is slightly under-specified, so the candidate has to decide what it is before they solve it. The candidate has access to the tools they'd actually reach for — documentation, a search engine, an AI collaborator — because pretending those don't exist is itself the unrealistic part. And the output includes the reasoning and trade-offs alongside the artefact, because that's what a colleague would want in a design doc.
A round built that way doesn't feel like a test. It feels like a Tuesday afternoon. The candidates who are good at real work usually do well; the candidates who are only good at interview performance usually don't. That's roughly the filter you were hoping to apply in the first place.
Why live coding on a whiteboard fails the test
The classic live-coding interview fails the realism test on every front. The problem is closed-scope, because the interviewer needs a right answer to compare against. The tools are banned, because the format was designed before modern tools existed. And the reasoning usually lives only in the interviewer's head, because the format doesn't leave time for the candidate to write it down. Live coding tends to reward composure precisely because the format has quietly filtered out everything except composure. "Realistic" isn't a word that applies.
The candidate's half of realism
There's a second half of this most teams forget. A realistic job interview has to feel like real work to the candidate, not just look realistic to the hiring manager. A candidate who spends 90 minutes writing a production-quality checkout flow under a timer didn't have a realistic experience, even if the topic was real. The pressure was wrong. Real work doesn't have a countdown overlay.
This is why candidate time budgets matter almost as much as the problem design. An exercise that eats a weekend is not a realistic sample of anyone's weekday; an exercise that asks for 45 minutes of intense typing is not a realistic sample of anyone's engineering either.
A test you can run
Take your current exercise and try this. Describe it out loud to a colleague who doesn't work on your hiring process, phrased as "this is the day-one project a new hire would walk into." If the description makes you wince — because the real day-one project has a bunch of things the exercise stripped out — your interview isn't as realistic as the brief claims. That's not a failure; it's a thing you can fix. CriticCode is one way to build rounds that actually match the work, but the bigger move is the one you make before you pick any tool: decide that the exercise should feel like the job, and scope it from there.