Software Engineer Hiring Anti-Pattern #1: Asking About Impractical Knowledge the Team Hasn't Used in Years
You can learn a lot about job candidates by asking about the software knowledge you currently use.
In this series:
Anti-Pattern #1: Asking About Impractical Knowledge the Team Hasn't Used in Years
Programmers may have heard, “You need to know Linked List well because it is a common programmer interview question.” However, in practice, Linked List knowledge is rarely needed in real-world work—it’s mostly just for interviews. In my 25 years in the industry, I’ve never had to use it, and the same goes for my daughter, who has been working at a FAANG company for three years.
There are more impractical interview question examples like this:
“What is the complexity of this code? n^2 or n * log(n)?
These might be necessary for specialized edge-case work but are rarely needed in typical web and mobile app development. Honestly, having worked in multiple roles across dozens of companies, I've never had to use this knowledge. However, these types of questions tend to appear rather common in interviews.
You can learn a lot about job candidates by asking about the software knowledge you currently use.
Some readers might wonder, “Zhimin, can you provide more general examples?” Sure! "Design Patterns" (the Gang of Four) are also a common topic in programmer job interviews, especially when hiring experienced developers.
I recall an interview question I had at Boeing Australia, where I was asked to name a design pattern for a given software design scenario. I immediately provided the correct answer: "Memento." However, I had never used this pattern before and was quite certain I wouldn’t use it in practice. It was purely theoretical knowledge—gained from regularly reading books and some interview preparation.
In practice, most programmers only need to be familiar with one design pattern: Model-View-Controller (MVC). By default, project templates in frameworks like ASP.NET MVC and Ruby on Rails already structure the project folders based on this pattern.
I'm not saying that Design Patterns are useless—rather, many common development tasks simply don’t require them. I came to this realization when I started designing my own TestWise IDE, which is far more complex than typical web development (which I also do concurrently). I began applying GoF design patterns with real understanding, rather than just mechanically as before. A well-applied design pattern makes the code flexible and easy to extend.
With this hard-earned practical knowledge, I created examples to teach my daughter three Gang of Four design patterns:
My daughter’s feedback was “much easier to understand compared to reading the book.”
Design Patterns are usually more relevant for complex, ground-up application development. In reality, many programmers join teams where an existing design is already in place, and their job is primarily to write code, ideally efficiently with fewer bugs (two vast topics that are often overlooked in university education).
Returning to the interview topic, yes, software development encompasses a vast array of knowledge areas (which is why it typically takes 3 to 4 years of full-time study to earn a basic bachelor’s degree). However, asking candidates about a few non-practical knowledge points that you and your team haven’t used in years—and are unlikely to use in the future—seems like a waste of time.
Some wonder, “Why do some senior software engineers like to ask this kind of impractical programming questions during the interview?” Maybe relaying the treatment they received before?
Related reading: