It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”.

> Or did they really get by with writing broken C++ all those years without knowing the basics?

Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place

> I'm not 100% certain it's wrong with just 50 lines of context.

These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules.

A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”)

> I think C++ is a special case when it comes to interviews.

I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.