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.
Companies often promote the idea that technical skill alone determines success.
Hackathons also strengthen teamwork and communication skills.
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 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.
During Women's History Month, we often celebrate women who have made groundbreaking contributions to science and technology. What many people do not realize, however, is that in the earliest years of the computing industry, programming was largely done by women. This overlooked chapter of history reveals how deeply women helped shape modern computing—and how cultural shifts later obscured their contributions. One of the most famous examples comes from the development of the ENIAC, one of the first general-purpose electronic computers built during World War II. When the machine was unveiled in 1946, public attention focused primarily on the hardware and the male engineers who built it. Yet the individuals responsible for programming the computer were six women mathematicians: Jean Bartik, Kathleen McNulty, Betty Jennings, Frances Bilas, Ruth Lichterman, and Marlyn Wescoff. Their work was extraordinarily complex. Programming ENIAC did not involve writing code in a modern programming language. Instead, they programmed the machine by rewiring plugboards, configuring switches, and designing logical sequences of operations to compute ballistic trajectories for the U.S. military. In effect, they were inventing the practice of programming as they went along. Despite the significance of their work, these women were largely left out of the early historical record. Photographs from the ENIAC project sometimes showed them standing beside the machine, but they were often misidentified as models rather than as the programmers who made the system function. For decades, their contributions were largely forgotten. Women continued to play critical roles in computing in the years that followed. One notable figure was Grace Hopper, who helped develop one of the first compilers and contributed to the development of the programming language COBOL. Her work helped transform programming from a hardware-focused task into the software-driven discipline we know today. Ironically, programming was not initially considered a prestigious profession. In the early decades of computing, it was sometimes viewed as routine clerical work, and organizations often hired women to perform it. However, as software became more central to the technology industry in the 1960s and 1970s, the status of programming began to change. Companies started redefining the role as a highly technical and prestigious occupation. At the same time, hiring practices began emphasizing personality profiles and educational pathways that favored men, while early home computers were heavily marketed to boys. These cultural and institutional shifts gradually pushed many women out of the field. By the 1980s, computer science programs had become overwhelmingly male-dominated, creating the demographic pattern that still exists in much of the technology industry today. Understanding this history reminds us that the gender imbalance in computing is not inevitable or inherent to the field. Women were present at the very beginning of modern computing and were instrumental in building the foundations of programming itself. For readers interested in learning more, two excellent resources are Recoding Gender by Janet Abbate, which examines the historical role of women in computing, and Broad Band by Claire L. Evans, a narrative history of women’s contributions to the development of the internet and computing culture.
For those of us who have spent decades working in technology, it is easy to forget how different the industry looked thirty years ago. When I began my career, the tech world was rapidly expanding, but it was also strikingly narrow in who it included. Conversations about equity, representation, and access were often peripheral — if they happened at all. That is why the work of Rev. Jesse Jackson in Silicon Valley stands out to me, not just as a moment in civil rights history, but as a turning point in the culture of technology itself. Many people know Jesse Jackson for his role in the Civil Rights Movement, but fewer recognize how intentionally he turned his attention toward the tech industry. He understood something early that many of us working in the field were only beginning to realize: technology would shape the future economy. If entire communities were excluded from participation in tech, they would be excluded from opportunity, wealth, and influence in the decades ahead. Jackson’s approach was practical and strategic. He challenged major technology companies to release diversity data at a time when transparency was uncommon. As someone who has watched the industry evolve over three decades, I can say that this push mattered. Today, annual diversity reports are routine, and companies are expected to discuss representation openly. That shift toward accountability did not happen by accident — it came from sustained public pressure and advocacy. What impressed me most about his work was that he framed equity as more than a hiring issue. He emphasized supplier diversity, entrepreneurship, and access to capital, arguing that inclusion meant participation in the entire technology ecosystem. That perspective resonates deeply with me as both a technologist and an educator. I have seen firsthand how access to networks, mentorship, and opportunity often matters just as much as technical skill. The ripple effects of that advocacy are visible today. Conversations about ethical AI, algorithmic bias, and inclusive design reflect a growing understanding that technology is shaped by the people who build it. As someone who has worked through multiple generations of technological change — from early software development practices to cloud computing and now AI — I can say with confidence that the industry now recognizes diversity not only as a social responsibility but as a driver of innovation. Of course, progress is not linear. The tech industry continues to wrestle with questions of equity, and current debates around DEI show that the work is far from finished. Yet the fact that these conversations are central rather than marginal is itself part of Jackson’s legacy. From my vantage point after thirty years in technology, I see Jesse Jackson’s Silicon Valley work as a bridge between the civil rights struggles of the past and the innovation challenges of the future. He reminded the industry that technology is not just about code or products — it is about people, access, and who gets to help shape the world we are building together.
The field of computing is often portrayed as a neutral, merit-based domain driven solely by innovation and technical brilliance. Yet this narrative obscures a critical truth: the systematic omission of Black contributions from computing history has materially shaped who feels welcome, visible, and valued in the field today. The underrepresentation of African Americans in computing is not an accident of interest or aptitude—it is the cumulative result of historical erasure, structural barriers, and distorted storytelling. Factor 1: Historical Erasure from Canonical Narratives Black technologists played foundational roles in early computing—as mathematicians, programmers, systems architects, and trainers—yet their work has been routinely excluded from textbooks, curricula, and popular histories. As documented in Hidden Figures by Margot Lee Shetterly, Black women were essential to NASA’s computational breakthroughs, but their contributions remained invisible for decades. This erasure sends a powerful signal: computing is framed as a space where Black excellence is anomalous rather than foundational. Factor 2: Structural Barriers to Access and Credentialing Beyond storytelling, African Americans were systematically excluded from the institutions that conferred legitimacy in computing—elite universities, corporate research labs, and early tech firms. Historian Joy Lisi Rankin documents how access to early computer systems was tightly controlled, favoring already-privileged institutions and populations. Even when Black technologists contributed, intellectual credit and ownership often flowed elsewhere. Factor 3: The Myth of the Lone Genius Technologist Dominant computing narratives emphasize individual genius—often white and male—while minimizing collaborative and community-based labor. Scholar Ruha Benjamin argues that these narratives reinforce racial hierarchies by defining innovation narrowly and excluding socially grounded forms of technical expertise. Conclusion The underrepresentation of African Americans in computing cannot be solved by recruitment alone. It requires historical repair—restoring omitted contributions, reframing who computing is for, and teaching students that Black people have always been builders of digital futures. Sources: Shetterly, M. L. (2016). Hidden Figures. HarperCollins. Rankin, J. L. (2018). A People’s History of Computing in the United States. Harvard University Press. Benjamin, R. (2019). Race After Technology. Polity Press.
Every few years, the tech industry reinvents itself. New tools appear, old practices fade, and entire job roles evolve. As we move toward 2026, one thing is clear: the definition of “software developer” is expanding. Writing code is still essential — but today’s successful developers must also think like system architects, security analysts, automation engineers, and lifelong learners. At the top of the priority list is AI-driven development . Artificial intelligence is no longer just a feature inside applications; it is becoming a core collaborator in the development process. Tools like GitHub Copilot and large language models are reshaping how code is written, tested, and maintained. Aspiring developers should focus on learning how to integrate AI into workflows, design prompts effectively, and understand how these systems generate and evaluate code. Those who treat AI as a productivity partner — rather than a shortcut — will move faster and build better software. Equally important is cloud and automation fluency . In 2026, nearly every serious application will be cloud-based. Developers must be comfortable working with platforms such as AWS, Azure, or Google Cloud, and understand cloud-native design: microservices, serverless computing, containerization, and continuous integration pipelines. Automation is now part of the developer’s job description. Knowing how to deploy, monitor, and scale software is just as important as writing it. With this growing complexity comes increased risk, making cybersecurity and secure coding non-negotiable. Modern developers must think about security from the first line of code: managing credentials, protecting APIs, preventing injection attacks, and integrating security checks into development pipelines. Security literacy will increasingly separate entry-level developers from trusted professionals. Yet for all the new tools and trends, strong fundamentals remain the backbone of the profession. Algorithms, data structures, debugging, and system design still determine whether software performs well, scales, and remains maintainable. AI may generate code, but it cannot replace sound engineering judgment. Finally, the developers who thrive in 2026 will possess exceptional human skills: communication, collaboration, adaptability, and curiosity. Technology evolves too quickly for any single skillset to last a career. The most valuable developers are those who learn continuously and translate complex technical ideas into real business solutions. The future of software development isn’t about chasing every new trend — it’s about building a resilient foundation and learning how to evolve with the industry. That’s the real competitive advantage.
One of the biggest misconceptions students have about software development is believing that learning a programming language is the finish line. It’s not. In reality, languages are just one piece of a much larger ecosystem known as the developer toolchain—and employers expect graduates to understand that ecosystem on day one. In industry, software is rarely written in isolation. Developers collaborate, experiment, break things, fix them, test constantly, and deploy incrementally. None of that works without tools. Version control systems like Git allow teams to work safely in parallel. Platforms like GitHub provide structure for collaboration, feedback, and accountability. These tools are not optional add-ons; they are the foundation of professional software development. Equally important is proficiency with an IDE such as Visual Studio Code. A modern IDE is more than a text editor—it is a thinking environment. Debuggers, code navigation, and refactoring tools help developers reason about complex systems and fix problems efficiently. Students who rely solely on print statements quickly hit a ceiling when projects grow beyond a few hundred lines. Command-line skills are another quiet differentiator. While graphical tools are convenient, many professional workflows—build systems, servers, automation, and cloud deployments—live in the terminal. Comfort at the command line signals independence and readiness for real-world environments. Today’s toolchain is also evolving. Containers like Docker have changed how software is packaged and deployed, while AI tools such as GitHub Copilot are reshaping how code is written and reviewed. The goal is not to let AI replace thinking, but to learn how to evaluate, guide, and improve AI-generated output—an essential skill for modern developers. For students, the takeaway is simple: languages get you started; tools make you effective. Mastering the developer toolchain builds confidence, supports collaboration, and prepares you not just to write code, but to work as a software developer.
Computer science has often been portrayed as a field where only a select few can succeed. Yet decades of research in computer science education suggest something far more encouraging: student success in computing is strongly influenced by how we teach, how students are supported, and how learning environments are designed. When instruction aligns with research-based practices, student learning and persistence increase across experience levels. One of the most consistent findings across STEM education is the effectiveness of active learning. A large meta-analysis by Freeman et al. found that students in active-learning environments performed better and were significantly less likely to fail than students in traditional lecture-only courses (Freeman et al., 2014: https://www.pnas.org/doi/10.1073/pnas.1319030111). In computer science, active learning includes structured labs, guided coding exercises, peer discussion, and opportunities for students to reason through problems. Programming is a skill developed through practice, iteration, and feedback—not passive observation. Research also emphasizes the role of self-efficacy, or students’ belief in their ability to succeed. Albert Bandura’s foundational work shows that confidence influences persistence, motivation, and academic performance (Bandura, 1997: https://www.uky.edu/~eushe2/Bandura/BanEncy.html). In computing, studies indicate that students who believe success comes from effort and effective strategies—rather than innate talent—are more likely to continue in the major (Lewis et al., 2016: https://dl.acm.org/doi/10.1145/2839509.2844593). Early, well-scaffolded successes and explicit normalization of struggle, particularly around debugging, help reinforce this belief. Collaborative learning further supports student success. Research on peer instruction and pair programming demonstrates improvements in conceptual understanding and student engagement, especially in introductory computer science courses (Porter et al., 2013: https://dl.acm.org/doi/10.1145/2445196.2445248). Working with peers helps students articulate their thinking, learn from alternative approaches, and develop communication skills central to professional computing practice. From a cognitive perspective, worked examples and scaffolding are especially effective for novice programmers. Cognitive Load Theory shows that learners benefit from studying annotated or partially solved examples before tackling problems independently (Sweller, 1988: https://link.springer.com/article/10.1007/BF00375144). As students gain expertise, these supports can be gradually removed. Finally, real-world and challenge-based projects increase motivation by helping students see computing as relevant and impactful. When students understand why their code matters, they engage more deeply and persist longer. The message from the research is clear and hopeful: computer science students thrive when instruction is intentional, supportive, and evidence-based.