"How Do You Use C++?"

This is something of a rant. But the question from the title kept bouncing around in my head, mostly because I still can't decide whether it was meaningless, badly phrased, or accidentally revealing.

Some time ago I had a 30-minute interview with a recruiter who was screening candidates for a larger and fairly well-known C++ codebase. It would have been a mostly remote position with occasional travel.

The call was full of the usual checklist material.

"What is your availability?"

"Do you have a work permit in the EU?"

That kind of thing. Most of it could have been a written questionnaire. It was pretty clear that the recruiter either didn't have a first clue about software development or simply didn't care much about the role beyond filling boxes on a form. I can hardly blame her. She probably had several calls like that every day.

The last ten minutes were reserved for questions that were apparently meant to be the more technical part. That was where the call was supposed to become useful. It didn't. The questions were only slightly more interesting and still badly worded. One of them was this:

How do you use C++?

I was immediately confused. It sounded like asking somebody how they use a chair.

After a few seconds of mental recovery, my answer was basically the equivalent of "I sit on it."

I said something like: I guess like everybody else? I use it to implement software with requirements that suit it.

I then tried to explain that I've used C++ for more than 25 years and still found the question odd. I also tried to make clear that I don't think of myself primarily as a "C++ programmer," even though I have a lot of experience with it. The language is just one of the tools I happened to have used a lot in the past.

After my attempt at an answer, I even asked if that is how she meant the question, but all I got was a short "Sure," or something like that.

There was no follow-up. She just noted something down, I think. It felt like talking to a robot, except, ironically, in that moment I would actually have expected a better interview from a robot.

There were a couple more almost equally weird questions on unrelated topics after that. No feedback on those either.

After 30 minutes we said goodbye and that was it. She was cordial enough. Still, I was annoyed by how much time had just been wasted.

Early on, salary expectations came up as well, and mine were not low. That was intentional. I knew the project, I had seen the codebase, and it was old, open source, and definitely not trivial. If somebody wants experience dealing with that kind of system, they can pay for it.

Somewhat unsurprisingly, I was later told they would like to keep me on their candidate backlog but had no use for me at the moment.

Fine. Just don't interview me like that again.

Why The Question Is Bad

What kept bothering me afterward was not that I didn't get the role. It was the question itself.

"How do you use C++?" is bad because it sounds specific while actually being vague. It can mean at least four different things.

• Maybe they wanted to know what kind of systems I built with it.
• Maybe they wanted to know what language features I am comfortable with.
• Maybe they wanted to know whether I write modern C++ or cling to habits from 1998.
• Maybe they wanted to know whether I think C++ is the answer to every problem.

Those are all different questions, and they produce very different useful answers.

As asked, though, it is the kind of question that tempts either a meaningless answer or a long monologue where the candidate has to guess what the interviewer actually wanted. Good interview questions reduce ambiguity. This one adds it. That is not a good interview question. It's a bad prompt.

A Better Question

If the goal was to learn something useful, a better version would have been something like this:

In what kinds of projects have you used C++, and how did the language fit the requirements of those systems?

That at least gives the candidate something real to respond to. It invites discussion about constraints, not mythology.

Another decent version would be:

How do you decide whether C++ is the right tool for a project?

That is a question I can answer without feeling like I'm being asked how I operate cutlery.

My Actual Answer

If I had been asked one of those questions instead, my answer would have been fairly straightforward.

I use C++ where native code, performance, control over resource management, platform integration or existing ecosystem constraints make it a good fit. I have used it for a long time, so I am comfortable in that world. But I don't treat it as an identity or as a default answer to every software problem.

Sometimes C++ is the right tool because latency matters, memory layout matters, startup time matters, hardware interaction matters, or because the surrounding system is already deeply invested in it. Sometimes C++ is the wrong tool because development speed, simplicity, portability of staffing, or operational concerns matter more.

That is really the answer I care about when talking to other engineers as well. Not whether somebody can perform C++ as an identity, but whether they can explain why it belongs in a specific place and why it might not belong somewhere else.

And maybe that is why the original question annoyed me so much. It reduced a real engineering judgment call to something that sounded like fandom.