How to hire a C++ developer: “What I want to see is how the candidate thinks and how they approach problem solving”
In his 20-year-long career in software design, engineering, and management, Andriy Syrovenko has developed a wide and varied range of skills. His interests include database management systems, information and network security, parallel computing, network technologies, VoIP, billing systems, virtualization, and much more.
As a Team Lead and Senior C++ Developer, Andriy frequently conducts job interviews. We’ve asked him to describe his process for interviewing C++ engineers, and here’s what he shared:
When I think back to how I conducted interviews twelve years ago, I can’t help but wince. Those talks were chock-full of standard C++ developer interview questions that I’d use over and over again with a single purpose — to demonstrate my superiority to the candidate.
These days, I no longer have any kind of set-in-stone interview routine. The questions I ask depend heavily on the project for which I need to hire a C++ developer.
The most basic technical task I give C++ candidates is to describe, in their own words, what a pointer is.
Whether I’m talking to a senior C++ developer or a junior candidate, I like to start with the basics. I’ve met engineers with over 10 years of experience whose beginner-level knowledge had rusted simply because they hadn’t had the chance to use it in their projects. If you spend years working with high-level libraries, it’s hardly surprising that you don’t remember the low-level C programming that any good C++ developer is generally expected to know. So I want to be extra sure the candidate I’m interviewing understands what C is all about.
The most basic technical task I give C++ candidates is to describe, in their own words, what a pointer is. This is a very primitive question, but it allows me to understand how the candidate views the language, and how well they understand the basics of C++ development. It’s also universal: any C++ developer, regardless of their level of experience, should be able to answer it.
What I want to see is how the candidate thinks and how they approach problem solving.
Sometimes I ask candidates to explain the difference between big-endian and little-endian architecture. Usually, when asked about such things, candidates start describing real life examples and difficulties they’ve encountered in their own work. This information allows me to judge how versatile and in-depth their experience is.
I also love to task candidates with logic problems relating to programming. For example, I could lay out a generic problem that is usually solved using the classic merge sort algorithm. Some people instantly recognize it and go straight to explaining how it works.
Over time, I’ve come to the conclusion that the one type of candidate I’m definitely not looking for is a multipurpose developer.
However, this algorithm — although relevant to my current project — isn’t especially widespread, so most people don’t know anything about it and request some time to think it over. Some can work it out pretty fast, while others start suggesting wrong solutions. Either way, we discuss their answers together. This stage can take anywhere between five and twenty minutes. I’m not necessarily interested in the right answer here. What I want to see is how the candidate thinks and how they approach problem solving.
I know most articles on the subject of tech interviewing tell you to organize live coding sessions, but I consider this practice a waste of time.
Over time, I’ve come to the conclusion that the one type of candidate I’m definitely not looking for is a multipurpose developer. These people are very rare, and if you do find one, you’ll soon realize that they’re too conceited and lazy for their own good. Having someone like that on a team is highly ineffective, so it’s a much better idea to hire someone whose skillset isn’t quite as varied, but who’s ready to learn fast and will approach their job with diligence.
If I decided to meet a candidate in person, it’s safe to assume that their resume caught my eye and they’re likely to be a good fit. The goal of the interview is to either prove or disprove this assumption. This is what it all boils down to.
Another type of candidates you want to avoid are developers who read their way through every new trend and try to implement it in their work immediately. From my experience, these candidates tend to feel very smug about how forward-thinking they are, but what they often miss is that business doesn’t care about using advanced technology for the sake of it, business cares about making money.
I know most articles on the subject of tech interviewing tell you to organize live coding sessions, but I consider this practice a waste of time. How should you check the code quality then? That’s what the trial period is for.
To conclude, here’s what I think about interviews: if I decided to meet a candidate in person, it’s safe to assume that their resume caught my eye and they’re likely to be a good fit. The goal of the interview is to either prove or disprove this assumption. This is what it all boils down to.
