Recently I had an interview with a company that was looking for someone well-versed in C++. I’ve been working to increase my C++ knowledge by taking online courses and writing my own card game, but I’m still somewhat new at C++. The interview became more useful in helping me clarify the gaps in my knowledge than being a good exploration of their needs and my abilities. It was nice that they did the full hour, instead of cutting the meeting short, giving me good questions to research.

Had they understood my level of knowledge with C++ they probably wouldn’t have wanted to interview me. The problem is, when applying for jobs, we’re often asked how much experience we have with a technology, not how much knowledge. This is usually in the form of “years of experience”, presumably to try and make the measure somewhat objective.

This is a poor measure of someone’s knowledge. For example, if I was doing C++ on an embedded system that needed predictable timing and a small footprint, there are many features of C++ I’m not going to use, such as many string operations that allocate and de-allocate memory from the heap, or design patterns that don’t have much use in a small embedded device. Even if I’ve been using C++ for 10 years, am I an expert C++ programmer? If I haven’t made the effort to learn about the additional features of C++ that I cannot use in my current position, then no; my knowledge is too incomplete.

How do we evaluate someone’s knowledge?

It’s like the old question: do you have 10 years of experience or 1 year of experience 10 times over?

Aside from being a poor measure of quality, even the quantity of “years of experience” is suspect. Any position is going to require you doing several things. Being a developer who primarily uses C++ still won’t be coding 100% of the time; you’ll be defining requirements, architecting the firmware, organizing teamwork, performing verification, etc.

What if you don’t use C++ as part of your job, but are learning on your own? Continually learning is very important for engineers as they can become obsolete if they do the same job for years in a role that isn’t very marketable outside of their current company. Let’s say you’ve been studying something for 5 years on your own. Do you have 5 years of experience? How many hours/week do you need to spend for that to be a valid statement? As much as “years of experience” seems an attempt at making the measure more accurate by measuring something objective, it’s still subjective.

We need guidelines, not just a number

I’d prefer a rating system that breaks your experience into 3 main ratings: novice, proficient, and expert, and break each of those into a similar 3 breakdowns. You end up with a 9-point scale, such as:

Obviously, there are a lot of details you can put in the guidelines; what I’ve listed isn’t at all comprehensive. I’m simply trying to give some guidance to the candidate of how to accurately rate yourself, such that you’d be comfortable being interviewed on these topics.

But what did we really accomplish?

This is no panacea. It has its own issues:

What a hiring team wants in their C++ developers will vary. Do you want Smart Pointers? What design patterns might you use, if any? If you want this level of granularity, I’d break these into separate skills listed in the job description, rather than require a certain overall C++ rating.

A person may be well versed in a feature that’s considered more advanced than something they don’t have any real knowledge of. For example, a developer may be familiar with some design patterns, especially if used in a different language but never had a need to use smart pointers or lambdas. Are they Proficient-Intermediate (5), Expert-Beginner (7), or do we average it out and say Proficient-Advanced (6)?

The guidelines are specific to each skill. Someone knowledgeable in the field has to come up with the guidelines and different people will come up with different guidelines. However, I think it’s possible to have generally accepted guidelines for a specific skill.

Guideline problems aside, I still believe this is a better rating system than years of experience. Even if you didn’t have guidelines, I think people’s belief of their knowledge would still be a better estimate. Any misrepresentation should become clear in a technical interview.

It’s important to remember that everyone’s path is different. Someone may be very knowledgeable about a skill but still have a few holes that they just haven’t found a reason to fill based on their work history. Good interviews are dialogues, where the candidate and company learn more about each other. If you come in with an inflexible set of questions and don’t try to understand the candidate’s background, where they’re proficient and where they have holes, you’ll get an inaccurate understanding of what they can bring to the team, and likely not make the best hiring decision.

Maybe this is the wrong approach. Instead, maybe the job description should list the specific technical knowledge the company is expecting. If you want the best candidates, you’ll need to be able to describe what a makes a candidate the best fit for this position. Then, the interview becomes much more focused as you can target the skills you need.