The Software Engineering Interview Process is Broken—Here’s Why
Shifting the Focus: Evaluating Strengths, Not Hunting for Gaps
I’ve been in this industry for over 14 years. In that time, I’ve watched the landscape of software engineering shift, sometimes in ways that make perfect sense, other times in ways that leave me wondering, how did we get here?
I’ve been on both sides of the table—assessing candidates as an interviewer and sweating through the hot seat as an applicant. I’ve sat across from bright-eyed junior engineers and been interrogated by teams more interested in testing my ability to recall trivia than in assessing what I can actually do. And let me tell you: hiring in this industry has changed, and not for the better.
In this article, we’ll break down what makes a great (or terrible) interview for a senior software engineer, how to spot a bad one in five minutes, and
will throw in his two cents along the way!The Evolution of Interviews—And Not in a Good Way
There was a time when a bootcamp, a solid portfolio, or a computer science degree was enough to land a junior role—real-world experience wasn’t a strict requirement. Fast-forward to today, and it feels like even entry-level positions demand “senior” level expertise. And sure, that might make sense in a world where techno feudal aristocrats like Mark Zuckerberg declare, “There will be no more mid-level engineers.”
AI is changing the game, no doubt. But if companies want only senior engineers, they need to rethink their interview processes too. While it’s fair to quiz a junior on theoretical concepts—since they’re still building real-world experience—senior interviews should be about much more than trivia. A true senior engineer isn’t just someone who remembers definitions; they’re someone who knows how to apply knowledge to solve problems. If your hiring process doesn’t reflect that, you’re not actually looking for a senior engineer—you’re just testing who studied the hardest.
I’ve built web, mobile, and backend systems, designed microservices, and set up CI/CD pipelines. I don’t know everything, but I’ve never faced an engineering problem I couldn’t solve with time and resources—just don’t ask me to build protein-folding algorithms.
So why do so many interviews feel designed not to assess whether I can actually do the job, but rather to expose the more than handful of things I don’t know?
Take one of my past interviews, for example. I was given a broken application with a dozen issues and told to fix what I could. I patched up ten of them—apparently, “better than most candidates” - as they told. That’s the kind of interview that makes sense. But then, I’ve also been asked, “What is nextTick() in JavaScript?” in a role that was 70% frontend. My honest answer? I don’t know. I’ve never needed to use it. (And my friends and colleagues with similar experiences haven’t had to use it either.)
Cue the interviewer’s disappointed sigh.
Instead of digging into my experience optimizing frontend performance, improving UX, or solving actual challenges in different business domains, they seemed more interested in testing whether I had memorized obscure JavaScript behavior. And that’s a problem.
What Makes a Good Interview?
A great interview isn’t about catching a candidate off-guard—it’s about having a meaningful conversation to determine if they can do the job.
1. Assessing What You Do Know—Not What You Don’t
No one knows everything. Even after 14 years, I’m constantly learning. The best interviewers recognize this and focus on a candidate’s strengths rather than treating the process like a pop quiz.
Good Approach: “Tell me about a challenging asynchronous problem you solved. What approach did you take?”
Bad Approach: “Define nextTick().”
The first question opens up a discussion about real-world experience. The second is a yes-or-no test of whether the candidate happens to have memorized a specific fact.
2. Use Real-World Scenarios, Not Trivia
A great interview reflects the actual work a candidate will be doing.
I once had an interview where I was grilled about caching strategies and message queues—for a frontend role. While I understand these topics, they weren’t remotely relevant to the job.
Good interviews focus on practical challenges. Instead of, “What’s the difference between ‘type’ and ‘interface’ in TypeScript?”, a better question might be:
“Tell me about a performance issue you’ve encountered in a React application and how you solved it.”
See the difference? One is a theory test. The other actually measures experience.
3. Focus on candidates experience -
I’ve often found that the most meaningful conversations start by just asking someone about past projects.
As an interviewer, I usually flow very naturally from asking about what they did in a previous job to specific questions about challenges and achievements in their previous work.
A truly senior developer will be able to
explain the architecture of their previous projects clearly
talk about meaningful improvements they made to the system
pinpoint the biggest problems that their previous projects had
This type of question still gives you plenty of opportunity to poke at their knowledge of specific technologies, while at the same time avoiding pure, no-context trivia questions.
What Makes a Bad Interview?
I’ve seen my fair share of awful interviews. Here’s what separates a bad process from a good one.
1. The Trivia Trap
If your interview is full of “gotcha” questions, it’s probably a bad one.
Example:
❌ “What’s the difference between .call(), .apply(), and .bind() in JavaScript?”
✅ “Have you ever had to deal with tricky ‘this’ bindings in JavaScript? How did you approach it?”
One question tests memorization. The other assesses practical problem-solving. Which one actually matters in a real job?
2. Misaligned Questions
A frontend engineer shouldn’t spend half an interview talking about backend message queues unless that’s actually part of the role. I once had an interview that focused so heavily on DevOps topics that by the end, I had to ask, “Are you sure you’re hiring for a frontend position?”
3. The “Gotcha” Mentality
Some interviews feel designed to eliminate candidates rather than to find great ones. Instead of assessing experience, they seem like they’re hunting for reasons to reject you.
🚩 If an interviewer seems more excited about what you don’t know than what you do, that’s a major red flag.
4. Not Allowing External Resources
In real life, we Google things. We read docs. We check Stack Overflow. But somehow, in many interviews, it’s considered cheating to use resources. A good interview reflects reality—and in reality, engineers look things up all the time.
Have you experienced a bad interview? Maybe one that left you frustrated or questioning the company’s culture?
Share your story in the comments—I’d love to hear your take!
Project-Based Assessments—Fair or Exploitative?
One of the best ways to assess a candidate’s skills is through coding exercises or project work. But there’s a right way and a very wrong way to do this.
A fair take-home project should:
✅ Be scoped to a reasonable time commitment (e.g., 1-3 hours)
✅ Align with the kind of work you’d do in the role
✅ Have a clear evaluation process and follow-up discussion
On the other hand, a huge red flag is when a company assigns you a full-day project, you submit it, and then… silence. No feedback. No follow-up. Nothing.
If this happens, you should seriously blacklist that company—there’s a real chance they’re just using your free labor to solve an internal issue. If they ghost you after a project submission, that’s not just unprofessional; it’s borderline unethical.
A real interview process should be about hiring, not outsourcing free work under the guise of a “test.”
Remember, It’s a Two-Way Street
Many candidates forget this, but you’re interviewing the company just as much as they’re interviewing you. Think of the interview being more like a date than an exam.
A bad interview process is often a sign of a bad company culture, and you can usually spot this in 5 minutes. Interviewers aren’t just testing your skills—they are the face of the company during this process. The way they conduct the interview gives you a direct insight into how they operate internally.
🚩 Red Flags to Watch For:
Arrogance and pompousness: If the interviewer seems more interested in showing off their own knowledge than in understanding yours, that’s a bad sign.
Disrespect or lack of engagement: If they seem bored, dismissive, or uninterested in your responses, imagine what working there might be like.
Unstructured or chaotic process: If interviews are repeatedly rescheduled, if questions feel irrelevant to the job, or if they ghost you after a take-home project—this is not a company that values people’s time.
A focus on What You Don’t Know: If they spend more time grilling you on obscure topics rather than discussing your strengths and experience, they’re not looking for the right fit—they’re looking for reasons to say no.
The questions are out of context. If the role is mostly frontend, but they spend 20 minutes on distributed systems, something’s off.
It’s all trivia, no real-world scenarios. Good interviews test thinking, not memorization.
✅ Green Flags That Indicate a Great Company Culture:
Engaged and curious interviewers: The best interviews feel like a discussion, where the interviewer is genuinely interested in what you bring to the table. Sometimes, they even admit learning from you: “Wow, I didn’t know that! I’ll have to look it up later.”
A structured and transparent process: Good companies respect candidates’ time, provide clear expectations, and follow up promptly.
Alignment between the role and the questions Asked: If they’re asking about real-world challenges that are relevant to the job, it shows they understand the position and respect your expertise.
A conversation, not an interrogation: A company that genuinely wants to hire the best talent will create an environment where both parties learn about each other, not one where they’re just looking for reasons to say no.
✅✅ The interviewer acknowledges learning something new: "Wow, I didn’t know that! I’ll have to look it up later."
If an interview feels off, trust your gut. The interview process is a preview of what working there will be like. If they don’t respect you now, they won’t respect you as an employee either.
Final Thoughts
At the end of the day, an interview should be a conversation about whether you and the company are a good fit. It shouldn’t feel like an exam. It shouldn’t be about proving what you don’t know.
Some of the best interviews I’ve had were with people who were genuinely curious about my experiences. Some of the worst felt like they were designed to make me fail.
If you’re a candidate, remember—you’re evaluating them too. And if you’re an interviewer? Let’s do better. Let’s focus on hiring great people, not on proving how much trivia they know.
—
What’s been your worst (or best) interview experience? I’d love to hear your thoughts. Let’s talk about how we can all make this process better.
So You Want to Be a Software Engineer?
Imagine-and I hope this is possible for everyone- you’re a hairdresser.
The analysis here digs deep, David. You dissect the algorithms, expose the complexity of system design queries. The emphasis on data structures, the demand for optimized code stands out. Your guidance on tackling technical rigor holds solid merit.