Are Technical Interviews Broken

Dr. Kai Dupe • May 22, 2026

Software engineering is not simply coding.

As someone who has spent more than 30 years working in software engineering and now teaches computer science at the college level, I have increasingly found myself asking an uncomfortable question:


Are technical interviews actually measuring software engineering ability?


Or are they measuring something else?


I have worked in technology long enough to watch the industry change dramatically. I began my career in an era when software development looked very different. Over the years, I have written code, trained technology professionals, worked with cloud technologies, and watched development practices evolve from traditional software processes to modern DevOps pipelines and cloud-native systems.


Today, I also have the privilege of preparing future software professionals in the classroom. I teach programming, software development tools, career preparation, and computing concepts to students who are working hard to enter the field. Many of them ask me some version of the same question:


“What should I study to get hired?”


And increasingly, my answer feels more complicated than it should.


Modern software engineering involves far more than writing algorithms on a whiteboard.


Professional developers collaborate using version control systems like Git. They work with cloud platforms. They debug existing systems. They read code written by others. They participate in code reviews. They communicate technical ideas to teammates and stakeholders. They work within continuous integration and deployment pipelines. They navigate ambiguity, changing requirements, and real-world constraints.


Software engineering is not simply coding.


It is problem solving, communication, systems thinking, collaboration, and engineering judgment.


Yet many technical interviews continue to emphasize a narrow set of skills.


Students spend hours grinding algorithm problems and practicing coding puzzles under artificial time pressure. They memorize patterns. They rehearse solutions. They learn interview strategies.


To be clear, problem-solving ability matters.


Algorithms matter.


Data structures matter.


Computer science fundamentals absolutely matter.


But I worry that we have created an interview ecosystem that sometimes rewards interview preparation more than engineering capability.


Imagine two candidates.


One candidate can quickly reverse a binary tree during a timed interview.


The other candidate has experience working with Git workflows, cloud deployments, debugging complex systems, collaborating on software projects, and building maintainable applications.


Which candidate is the stronger software engineer?

The answer is not always obvious.


And that is precisely the problem.


Some companies have started evolving their hiring processes. Portfolio reviews, pair programming exercises, take-home projects, system design discussions, and conversations around previous technical work are becoming more common.


These approaches may provide a more complete picture of a candidate’s abilities.


As educators, this creates challenges as well.


Should we spend more time preparing students for interview puzzles?


Or should we continue emphasizing software engineering practices that mirror professional environments?


My belief is that we must continue teaching students how to build software — not merely how to pass interviews.

Version control.

Debugging.

Collaboration.

Cloud technologies.

Testing.

DevOps practices.

Communication.

Requirements analysis.

Professionalism.


These are not secondary skills.


They are software engineering skills.


I tell my students regularly that becoming a software engineer is not simply about learning programming languages. It is about learning how to solve problems alongside other people while building systems that matter.


Technical interviews are not entirely broken.


But when hiring systems place too much emphasis on memorization and artificial problem-solving environments, we risk overlooking talented future engineers who may excel at building real software in real teams.


As both an educator and someone who has spent decades in this profession, I believe we should continue asking difficult questions about how we evaluate technical talent.


Because the future of software engineering may depend on whether we are measuring what truly matters.

Qualified Isn’t Enough: Breaking Into Tech in the Trump Era

By Dr. Kai Dupe • September 18, 2026
A mentor gives you advice. A sponsor creates opportunities.

Where Are the Black Computer Science Professors?

By Dr. Kai Dupe • August 20, 2026
Representation alone will not solve the persistent racial disparities in computing.

Programming Is About Data First, Code Second

By Dr. Kai Dupe • July 28, 2026
The truth is that most software applications exist to manage information.

The AI Generation Still Needs Human Mentors

By Dr. Kai Dupe • July 1, 2026
Artificial intelligence has become the newest member of nearly every software development team.

Juneteenth and the Power of Access to Information: What Computer Science Can Learn from Delayed Freedom

By Dr. Kai Dupe • June 17, 2026
The true promise of computing is not found in the machines we build, but in the human potential we unlock when knowledge becomes accessible to everyone.

Twenty-One Years as a Microsoft Certified Trainer: A Reflection on Lifelong Learning

By Dr. Kai Dupe • June 3, 2026
One of the reasons I value the MCT program so highly is that it represents more than technical knowledge.

The Tech Industry’s Race Problem Is Bigger Than Google

By Dr. Kai Dupe • May 15, 2026
Companies often promote the idea that technical skill alone determines success.

Why Hackathons Matter: Lessons from the Skagit Valley College Computing Club

By Dr. Kai Dupe • May 3, 2026
Hackathons also strengthen teamwork and communication skills.

What If I Had Studied Computer Science at Morehouse?

By Dr. Kai Dupe • April 22, 2026
Stepping onto the campus of Morehouse College this past weekend for Admitted Students Day was more than a visit—it was a moment of reflection. As I watched young Black men walk with purpose across the yard, I found myself asking a simple but profound question: What would it have been like for me to study computer science here? My journey into computing was shaped in environments where I was often the only Black man in the room. That reality brings with it an unspoken weight—the need to prove you belong, the awareness of being watched, and sometimes, the quiet isolation that comes with underrepresentation. Standing at Morehouse, I realized that this burden is not a given. It is a condition of the environment. At Morehouse, the environment is different by design. Here, Black men are not anomalies—they are the standard. I imagined what it would feel like to learn algorithms, data structures, and software development in a space where my identity was not questioned but affirmed. Where excellence is expected, not in spite of who you are, but because of it. As a computer science professor, I understand the academic rigor required to succeed in this field. There is no shortcut through recursion, no bypass around debugging, no substitute for disciplined problem-solving. But what struck me during my visit is how much context matters. When students are free from the psychological burden of proving they belong, they can redirect that energy toward mastering the material. They can collaborate more openly, ask questions more freely, and take intellectual risks without fear. I also thought about legacy. At Morehouse, students walk the same grounds as Martin Luther King Jr.. That kind of history does something to a person. It raises the bar—not just academically, but personally. It invites students to see their education not just as a pathway to a career, but as preparation for impact. Leaving campus, I felt inspired—but also reflective. I cannot rewrite my journey, but I can appreciate what spaces like Morehouse offer the next generation. For a Black male pursuing computer science, it is more than a degree. It is an opportunity to develop skill, confidence, and identity in alignment. And that combination is powerful.

If Women Were the Original Programmers, What Happened?

By Dr. Kai Dupe • March 25, 2026
If you walk into most computer science classrooms today, you might assume that computing has always been a male-dominated field. As someone who has spent decades in the industry and now teaches the next generation of developers, I can tell you—that assumption is not only common, it’s historically inaccurate. In the early days of computing, many of the first programmers were women. Ada Lovelace is widely recognized as the first computer programmer, having written what we would now call an algorithm for Charles Babbage’s Analytical Engine. Fast forward to the 1940s, and women were programming some of the first electronic computers, including ENIAC. These were not peripheral roles. These women were solving complex computational problems, often inventing programming techniques as they went (Abbate, 2012). So what happened? From a systems perspective, the answer is not mysterious—it’s structural. In its early stages, programming was considered clerical work. It required precision, patience, and attention to detail—qualities that, at the time, were socially assigned to women. But as computing became more central to business, government, and innovation, its status changed. What was once seen as routine work became prestigious and lucrative. And when that shift happened, the demographics shifted with it. By the 1980s, we see a clear inflection point. Personal computers entered the home—but they were marketed primarily to boys. This created an early access gap that translated into confidence, experience, and eventually career pathways. At the same time, hiring practices and workplace cultures began to favor men, reinforcing a feedback loop that pushed women out of the field (Hicks, 2017). Over time, the narrative changed. Computing was no longer something women had built—it became something they were seen as entering late. But that narrative is not just incomplete—it’s a distortion. Understanding this history is not about nostalgia; it’s about accuracy. When students learn that women were foundational to computing, it reshapes how they think about the field. Diversity is no longer framed as a modern intervention—it is recognized as part of computing’s original DNA. In my classroom, I’ve seen what happens when students encounter this truth. It disrupts assumptions. It broadens participation. And perhaps most importantly, it changes who students believe belongs in this space. So, if women were the original programmers, what happened? Part of the answer lies in systems—education, marketing, hiring, and culture. But another part lies in storytelling. The stories we tell about computing shape who feels invited to participate in it. As educators, technologists, and leaders, we have an opportunity—and a responsibility—to tell that story more accurately. References Abbate, J. (2012). Recoding Gender: Women’s Changing Participation in Computing. MIT Press. Hicks, M. (2017). Programmed Inequality: How Britain Discarded Women Technologists and Lost Its Edge in Computing. MIT Press. Evans, C. L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. Portfolio. Shetterly, M. L. (2016). Hidden Figures. HarperCollins.