Back to Journal
The Technical Interview Is Broken. Here’s How to Fix It
Jun 11, 2024
Reading Time
3 min
Let’s be real, the technical interview process is a nightmare.
Endless rounds. Timed algorithm quizzes. Engineers grinding LeetCode in their free time just to get a job they’re already qualified for. Meanwhile, your best candidates are ghosting after round three, and your team’s losing full workdays to interviews that go nowhere.
"How did this candidate even get in here?"
Sound familiar?
If you’re a startup scaling your engineering team, this problem is real. Time is absolutely your most valuable resource and technical interviews are chewing through it like candy. Worse, most of that time isn’t even spent generating the right signal.
What’s Actually Broken?
Let’s break it down:
Engineers are wasting time. Your senior devs are sitting in interview rooms instead of building product. Every hour spent in a technical screen is an hour not spent shipping.
The candidate experience sucks. Solve this graph traversal problem in a Google Docs interview? WTF, no thanks. Top engineers are tired of high-pressure tests that feel more like hazing than hiring.
We’re testing the wrong things. Unless your job is reverse-sorting linked lists for a living, most interviews have nothing to do with what you’ll actually do on the job.
AI just nuked the old model. ChatGPT can solve most LeetCode questions instantly. If your interview relies on problems a language model can ace, you’re not testing anything useful.
The truth? We’ve confused test-taking ability with job ability. That confusion is costing you time, talent, and traction.
So... What Do We Do Instead?
Fixing technical interviews doesn’t mean giving up rigor. It means switching from irrelevant rigor to real rigor.
Stop testing for memorization. Nobody’s impressed by a candidate who prepped 200 LeetCode problems. Why not build something relevant instead?
Start testing like it’s real work. Let them use an IDE. Let them use AI. Let them build something. That’s what they’ll be doing on the job anyway.
Use take-home projects- the right way. I’m not saying 12-hour unpaid labor. Give them a scoped project that takes 1-2 hours and reflects your actual dev environment. Isn’t that a better gauge of who they are as a builder?
Automate the review. You shouldn’t need four engineers to decide if a pull request makes sense. Use AI and rubrics to scale.
This isn’t just an ambitious thought. We’ve built a platform around this new model.
Welcome to the Prova Era
At Prova, we ditched the broken playbook. Our interviews look more like humane onboarding sprints than pop quizzes.
We let candidates use their own IDEs, build in familiar languages, and show how they’d actually solve real problems. Then we give hiring managers a clean, ranked report that cuts through the noise.
No more guesswork. No more 3-hour debriefs. No more InterviewCoder f*cking your screen system. Just better signal, faster hires, and engineers who are still fresh when they start.
The technical interview doesn’t have to suck. Let’s fix it.