
The Best C++ Interview Question – Ever - edw519
http://blogs.windwardreports.com/davidt/2009/12/the-best-c-interview-question-ever.html
======
tptacek
This is a completely broken C++ interview question. It asks the candidate to
reason through a worst-practice, which exposes you to their knowledge of
trivia and tells you nothing about whether they can actually get stuff done in
C++.

My old Sonicity C++ code, which was built on ACE, is littered with "delete
this" calls for Reactor callbacks. Obviously, "delete this" is OK if you're on
the heap and you can guarantee that the code isn't going to touch the object
again. But what I remember most about that ACE Reactor code was how fragile
the event handling was; "delete this" is a recipe for horrible memory
corruption flaws.

This is what you get when your C++ interviewers decide that interviews are
more about proving how smart they are than about qualifying candidates.

~~~
scott_s
If someone can explain what happens, then one of two things is probably true:
they've purposefully memorized an edge case for the sake of trivia, or their
knowledge of language semantics and runtime behavior is deep enough to figure
out what happens in an unusual circumstance.

I agree that doesn't tell you if the candidate is good at solving problems
using C++, but there is potential to discover how deep their understanding is.

~~~
tptacek
It also selects for developers who deliberately code up to the limit of what
the runtime will allow, regardless of the obvious fact that having code like
this is like sprinkling landmines across your product.

~~~
flaub
When you're looking for an expert in a field, do want to find someone that
claims to know what they're doing because they read a book somewhere? Or do
you want to find a seasoned pro that has actually tried and possibly failed
using different techniques? Their failures may give them more insight and
experience than their successes. Especially if they can tell you what they did
to improve themselves afterwards.

~~~
Retric
Becoming an expert has far more to do with knowing how to get things done in a
known time frame than knowing every little piece of triva. One you code in the
same language with 3 or 4 compilers you start to look at edge cases as a
dangerous no mans land to be avoided if at all possible.

PS: I worked with code from the 1984 Macintosh days that was still in use in
2005. You could see where people had updated from Motorola 68020 to PPC and if
it had not been stripped out some poor coder might have updated the remaining
ASM to x86.

------
raganwald
This question and the associated discussion remind me very strongly of
something I learned very early in own professional C++ development:

C++ the language is an _extremely_ leaky abstraction. There are so many places
where you really do need to think about what the compiler is doing and what is
happening behind the scenes rather than thinking at a consistent abstract
level.

Is that a bad thing? I suspect that C++ programmers would say no. But then
again, there would be a lot of bias in that answer...

------
pingswept
As an outsider looking in at the world of C++ development (I work on
hardware), my first thought is "Why would you want to use a tool that requires
an understanding at that level of complexity for mastery?"

Perhaps C++ has some extraordinary benefits that I don't understand, which
makes deleting the v-table before the method returns the stack to the heap
worth the trouble [1]?

[1] I might have mixed up some of the terminology a little here. Feel free to
correct me vigorously.

~~~
kscaldef
Do you find it useful, in your field, to understand how your tools work? If
so, perhaps you might allow that if someone is interviewing for a job using
another tool (C++, in this case) that they might be expected to know how that
tool works.

Also, with respect, it's fairly clear from your second paragraph that you
don't understand the terminology being used at all. Which is okay, it's not
your field. But, it makes your assessment of how complex this discussion is
somewhat suspect.

~~~
pingswept
Totally agreed about understanding how tools work being useful.

I'd just be wary of using an extremely complex tool. From what I can tell,
this "C++" looks like it could self-destruct at any minute, unless handled by
an expert. Perhaps that makes the case even more strongly that you ought to
filter your hires most strictly, but I wonder whether there might exist a
simpler tool that could do the job with fewer risks.

------
nomoresecrets
When I was interviewing C++ programmers, we had a C++ test, and some stock
questions I asked face to face.

However, I found I could pretty much weed the good C++ programmers from the
mediocre/just read about C++ before the interview by asking one question:

"What is a virtual function?"

If they have trouble starting to answer it, give them a hint with "What would
cause you to type the keyword 'virtual' in your code?"

You would be amazed how many C++ coders don't really know the answer to this,
or what is going on (vtables etc, or even just the behaviour).

One candidate answered "I'd make a function virtual if there were any other
virtual functions in the class." It seems like there is no shortage of bad
answers to this question. All the people who ever gave me a correct answer
(hit rate was <10% of candidates) were good C++ developers.

It's a good question :-).

------
nearestneighbor
C++ is my main language these days (and my guess at the answer happened to be
correct), but I think this interview question misses the point.

The key to using C++ successfully, like it or not, is not to understand what
happens in every possible circumstance (this is pretty much impossible). The
key is to carve out a subset of the language (and some usage patterns) that
you know how to use and stick with it. I wouldn't use _delete this_ without
consulting the documentation first, even if I suspect it's legal (hell, I use
"idiomatic" _delete_ maybe once in 5000 LOC)

------
RiderOfGiraffes
You know, the more I read suggested interview practices and the responses they
elicit, the more I think that the best interview question would be to get the
candidate to critique a few interview questions.

The point here is not whether this is good practice, or whether the candidate
knows the answer, or whether they would write it themselves, or whether they
get the right answer immediately, or whether they automatically know the
darkest corners of the C++ spec (of which this isn't one).

The point is whether they can reason through, with the interviewer, and then
potentially change their mind if they find that they're wrong.

Part of being a good programmer is finding the good ideas among the dross,
finding the right implementation technique among the many at their fingertips,
and finding the right design among the myriad plausible constructions.

If you can't find the good ideas in these sorts of interview questions, if you
can't read carefully enough to see that the whole point was to uncover whether
of not the candidate can reason through then potentially change their mind, or
if you think that to do so isn't an important characteristic to test for, then
that tells me something.

Yes, it's important to see why things don't work, or are broken, or are a bad
idea, but the ability to find _good_ ideas is infinitely more important.

I like this interview question, and if you don't, then we're not a good fit.
It doesn't mean you're a bad programmer, it doesn't mean (necessarily (I
hope)) that I'm a bad employer/manager/programmer/interviewer - but it doesn
mean we probably won't work well together.

But I could change my mind if you provide better arguments than the ones I've
seen so far.

------
DanielBMarkham
I'm cold on C++ (haven't coded in several years) but let me try this out:

deleting "this" releases memory held by the instance data of the object. The
programmer can't be sure that any subsequent references to that data will
return valid data (although the compiler will allow it). Static data and type-
level methods should be fine to call -- although every time the program
counter ticks you can't be sure that you're continuing to walk through
uncontaminated memory.

I think that's it.

Sounds like a BS question to me because you're going way, way under the hood
with exactly how the compiler runs the code. It's like those coding questions
where you have to start byte-counting to get the answer. Neat trivia perhaps,
but I'd much rather have somebody who delivered clean, organized, easily-
maintainable code and got the answer wrong.

EDIT: Seems like I've seen delete this on several occasions (although I can't
remember where), but hell if I'd use it unless I had no choice. Even then,
it'd be the last statement in the method.

~~~
machrider
The function's body is not part of the object itself. When you delete the
object, you can keep executing the function just fine, as long as you don't
access any member variables.

~~~
haseman
You keep executing the function because it's on the stack. The program counter
keeps moving through the method until it hits a return statement. God help you
if you try to reference one of the class' internal data objects as their heap
space could have been allocated to something else running on another thread.

------
ryanwaggoner
_These are people you do not want to hire under any circumstances because they
cannot think outside their initial preconceptions._

I know nothing about C++, but I know that this is bullshit. I also think that
it's pretty ironic if you think about it for a minute.

------
brg
Looking over the responses, it is really hard to believe many of the people
here have worked in C++. This is basic style for anyone who has ref counted,
such as implementing IUknown.

------
InclinedPlane
I'm torn on whether this is a good question or not. The important part of the
question is definitely the "why?" step. Finding out whether a developer will
question their own assumptions, fall back to solid knowledge and ask questions
to acquire the knowledge needed to proceed or if they will simply bumble down
the garden path of ignorance, making things up as they go with no basis in
fact other than a gut feeling is very important.

~~~
roc
It's just a language-specific variant of a 'Microsoft problem': you don't want
the answer, you want to watch the process. It's similarly useful _in theory_.
But in practice I think it has the same key failing: Performance is too skewed
in interview situations for it to give you consistently useful insight into
candidate fitness.

If you want to thin out a hundred otherwise-equivalent candidates - knock
yourself out. But at that point you might as well be flipping coins.

------
Batsu
I always find it curious when the number of comments on an article exceed that
of the point value. It leads me to suspect that users get angry over the
article for some reason.

To add to the discussion, however, I knew the answer because I had a run in
with doing this sort of thing. I had built a simple game with OpenGL - stuff
moved around on the screen and you could shoot it. Due to the way I
constructed the objects, it was trivial to "Delete this" when the object
should disappear - a bullet collides with an enemy, perhaps. I did it, it
worked exactly as expected.

The follow up question - "What can you do after delete this; ?" - also reared
it's head, and that's when I found the other edge to the sword and shied away
from it's usage.

It felt so much more elegant as "delete this;" :(

~~~
tptacek
The fact that the comments are often better than the articles they attach to
is the thing a lot of us like about HN.

------
wglb
At the level of this question, checking out Scott Meyer's 50 ways will show
you some that he got wrong. An interesting one is how to write a smart pointer
class, and how many ways it can go wrong.

