The 15-Second Filter That's Dividing the Programming World
Let's be honest—technical hiring is broken. You've probably been on both sides of it. As a candidate, you've spent hours on take-home assignments only to hear nothing back. As a hiring manager, you've waded through hundreds of applications, most from people who can't actually code. The whole process feels inefficient, unfair, and frankly, exhausting.
That's why Jose Zarazua's 15-second coding test went viral. A former CTO claims he can filter out 50% of unqualified applicants in less time than it takes to brew coffee. The programming community exploded when this hit Reddit—847 upvotes, 433 comments, and enough hot takes to power a small city.
But here's what nobody's telling you: This isn't just about a quick test. It's about a fundamental shift in how we think about technical screening in 2026. I've been on both sides of the interview table for fifteen years, and I've tested dozens of screening methods. Some work. Most don't. Let's unpack what actually makes sense.
What Exactly Is This 15-Second Test?
Zarazua's method is deceptively simple. He presents candidates with a basic coding problem during initial screening. Nothing fancy—we're talking fizzbuzz-level stuff. The twist? He gives them just 15 seconds to start typing.
Not 15 seconds to solve it completely. Not 15 seconds to produce perfect code. Just 15 seconds to begin demonstrating they can actually write code. The test typically involves:
- A simple function definition
- Basic input/output handling
- Elementary logic or looping
- No complex algorithms or data structures
"The goal isn't to find brilliant programmers," Zarazua explains. "It's to filter out people who literally cannot code at all." And according to his experience, about half of applicants fail this basic threshold.
Think about that for a second. People are applying for programming jobs who can't write the most basic code. They might have impressive resumes, degrees from good schools, even previous job titles that sound technical. But when you put them in front of an editor and ask for something simple? Crickets.
Why the Reddit Community Exploded
The r/programming discussion revealed something fascinating. Developers weren't just debating the test—they were debating the entire state of technical hiring. The 433 comments fell into several clear camps.
First, the supporters. These were mostly hiring managers and senior developers who've been burned. "I've interviewed 'senior engineers' who couldn't write a for-loop," one commenter shared. "We waste hours on people who clearly lied on their resumes. Something has to change."
Then came the critics. "This is gatekeeping nonsense," argued another. "Some people freeze under pressure. Some need time to think. You're filtering for fast typists, not good engineers."
But the most interesting perspective came from those in the middle. Developers who acknowledged the problem but questioned the solution. "The test isn't wrong," wrote one senior engineer with 20 years experience. "But 15 seconds? That's arbitrary. Why not 30? Why not a minute? The arbitrary nature feels disrespectful."
What everyone agreed on? The current system isn't working. Resumes lie. Take-homes are exploitative. Whiteboard interviews test memorization, not skill. We're all searching for something better.
The Real Problem: Resume Inflation and Interview Fatigue
Let's talk numbers. In 2026, the average technical role receives 250+ applications. Maybe 50 are from genuinely qualified candidates. The rest? A mix of hopeful juniors, career switchers, and what the industry politely calls "resume optimizers"—people who exaggerate or fabricate their experience.
I've seen it firsthand. Candidates with "5 years of Python experience" who can't explain what a list comprehension is. "Full-stack developers" who've never touched a database. It's not always malicious—sometimes people genuinely believe they're qualified. But the result is the same: wasted time for everyone.
The traditional solution? Multiple interview rounds. Coding challenges. Technical screens. But this creates its own problems. Good candidates get tired of jumping through hoops. They have options—why spend 10 hours on your process when another company only needs two?
And let's be honest about take-home assignments. They're often unpaid work disguised as assessment. I've seen companies give candidates real business problems to solve, then use their solutions without hiring them. It's unethical, and candidates are rightfully suspicious.
So we're stuck between filtering too little (wasting time) and filtering too much (missing good candidates). Zarazua's approach tries to solve the first problem. But does it create the second?
What the 15-Second Test Actually Measures
This is where things get interesting. Proponents claim the test measures basic coding competency. Critics say it measures typing speed under pressure. Who's right?
From what I've observed, it measures something in between. The test isn't really about solving the problem in 15 seconds. It's about whether you can immediately engage with a simple coding task. Can you start writing? Can you show you understand the basic syntax and structure?
Think about it like this: If I asked you to write a function that returns the sum of two numbers, and you can't even start typing within 15 seconds, what does that tell me? Either you don't know the syntax of the language you claim to know, or you freeze completely under minimal pressure.
Neither is great for a programming role. But—and this is crucial—neither necessarily means you're a bad programmer. Some excellent engineers are slow starters. Some need to think before they type. Some have anxiety disorders that make timed tests particularly challenging.
That's the trade-off. You're filtering out unqualified candidates, but you're also filtering out some qualified ones who don't perform well under this specific condition. The question becomes: Is that trade-off worth it?
Practical Implementation: How to Use This Test (If You Must)
Let's say you're convinced there's value here. Maybe you're drowning in applications. Maybe you've been burned too many times. How do you implement something like this without being, well, kind of a jerk about it?
First, context matters. Don't spring this on people unexpectedly. In your initial screening email or message, be transparent: "We'll begin with a very brief coding exercise to ensure basic competency. It should take less than a minute." This sets expectations and reduces anxiety.
Second, make the problem ridiculously simple. I mean, embarrassingly simple. We're talking "write a function that returns 'hello world'" simple. The goal isn't to test problem-solving. It's to test whether you can write code at all.
Third, consider extending the time. Why 15 seconds? Why not 30? Or 45? The principle is the same—quick filtering—but with less pressure. You'll still filter out people who can't code, but you might keep some slow starters who are actually competent.
Fourth, use the right tools. Platforms like CoderPad or CodeSignal let you watch candidates code in real-time. You can see their thought process, not just their final answer. This gives you more data than a simple pass/fail.
Finally, remember what this test is and isn't. It's a filter. Nothing more. Passing doesn't mean you're hired—it just means you proceed to the next stage. Failing doesn't mean you're a bad programmer—it just means this particular screening method didn't work for you.
The 2026 Alternative: Smarter Screening Methods
Here's what I've found works better than arbitrary time limits. These methods achieve similar filtering goals but with more nuance and less potential for false negatives.
First, portfolio review. Ask candidates to share something they've built. It doesn't have to be production-ready. A side project, a GitHub contribution, even a well-commented script. Then have a conversation about it. "Why did you choose this approach? What would you change now?" You'll learn more in 10 minutes than any timed test could tell you.
Second, pair programming on a real problem. Not a trick algorithm question. A simplified version of something your team actually works on. Watch how they think, how they communicate, how they handle feedback. This tests actual job skills, not test-taking ability.
Third, staged assessments. Start with something very simple (like Zarazua's test, but maybe with more time). Those who pass get a slightly more complex challenge. Those who pass that get a collaborative session. You're filtering at each stage, but with increasing investment that matches candidate quality.
Fourth, consider automated screening tools that go beyond simple coding tests. Some platforms now use AI to analyze coding patterns, problem-solving approaches, even code quality metrics. They're not perfect, but they're getting better. Just be careful about bias—always validate what the tool is actually measuring.
Common Questions and Concerns (FAQs)
Doesn't this discriminate against neurodivergent candidates?
Potentially, yes. Timed tests can be particularly challenging for people with anxiety, ADHD, or other conditions that affect processing speed. That's why context and alternatives matter. If you use timed screening, offer accommodations. Better yet, use multiple assessment methods.
What about senior developers who haven't coded recently?
This is a real concern. Someone who's been in architecture or management for years might be rusty on syntax but brilliant at system design. The test might filter them out unfairly. That's why role-specific screening matters. Don't use the same test for a staff engineer and a junior developer.
Can't people just cheat?
Sure. They can have someone else do it. They can look up answers. But here's the thing: Cheating on a test this simple is almost harder than just doing it. And if they cheat here, they'll be exposed immediately in the next round. The test isn't security—it's a speed bump.
What's the actual failure rate?
Zarazua claims 50%. In my experience, it varies wildly. For entry-level roles, I've seen 60-70% failure rates. For senior roles, maybe 10-20%. The more experienced the candidate pool, the lower the failure rate. Which makes sense—people applying for senior roles are less likely to be completely unqualified.
When This Approach Actually Makes Sense
Let's be practical. There are situations where quick filtering is necessary. Maybe you're a startup with limited resources. Maybe you're hiring for a high-volume role with clear, basic requirements. Maybe you've been inundated with clearly unqualified applications.
In those cases, something like the 15-second test can be a useful tool. But—and this is important—it should be one tool among many. Use it to filter, not to evaluate. Follow it with more nuanced assessments. And always, always be transparent with candidates about what you're doing and why.
I've found it works best for:
- High-volume junior roles
- Roles with very specific technical requirements
- Situations where you're getting obvious spam applications
- Initial screening before more comprehensive interviews
It works worst for:
- Senior or specialized roles
- Roles where soft skills matter as much as technical skills
- Companies that value diversity and inclusion (without careful implementation)
- Situations where candidate experience is a priority
The Bottom Line: Efficiency vs. Humanity
Here's the uncomfortable truth Zarazua's test exposes: Hiring is a balance between efficiency and humanity. The 15-second approach prioritizes efficiency. It saves time. It filters quickly. But it does so at the cost of potentially missing good candidates and creating a poor candidate experience.
The alternative—more comprehensive, thoughtful screening—prioritizes humanity. It's slower. It's more work. But it's fairer and more accurate.
In 2026, the best companies are finding a middle ground. They're using automated tools for initial filtering, but with careful design to minimize bias. They're being transparent about their process. They're respecting candidates' time while still thoroughly assessing skills.
My recommendation? Don't copy the 15-second test exactly. But do learn from its underlying insight: Basic competency screening is valuable. Just implement it thoughtfully. Give people reasonable time. Be clear about expectations. And always follow up with more meaningful assessment.
Because at the end of the day, hiring isn't just about filtering out the unqualified. It's about finding the qualified. And that takes more than 15 seconds.
