C++ interview questions that do not suck

[DmitryL]

sizeof(P1) > sizeof(void*)

That might do it but offhand I can't think of a modern architecture with different pointer sizes.

Also on an architecture where pointers are different sizes void * needs to be large enough to hold any other type as IIRC the standard says you a cast to void * and back again with the result that you get the original pointer.

At this point, I think someone needs to provide a concrete, non-C++ example of the original comparisons failing, especially since some people are implying that it's some sort of deal breaker and would immediately shut down an interview.  Maybe it is obvious and we've all just missed it.

On the other hand, I can think of several different reasons why that would fail in C++.  Some of them obvious...some of them maybe not so.

Here is a long discussion about similar stuff.
http://stackoverflow.com/questions/3941793/what-is-guaranteed-about-the-size-of-a-function-pointer

I do agree that this question is a very "interview - like" one, with no much practical sense.
On the other hand, it is perfectly legal to have sizeof(char)==sizeof(int)==sizeof(long)==8, C standards don't prevent this, but no one seems to implement compilers like this.

[John Coloccia]

Probably the only time someone actually got burned by this in C was working on some old system that had the concept of far pointers AND Big Endian architecture.  Maybe an old Mac, or something like that?  Perhaps there's some DSP out there where this is common?

[DmitryL]

Probably the only time someone actually got burned by this in C was working on some old system that had the concept of far pointers AND Big Endian architecture.  Maybe an old Mac, or something like that?  Perhaps there's some DSP out there where this is common?

Once I had an interview in a company that makes SOCs, with their custom CPU architecture inside and homebrewed OS. Their CPU wasn't powerful enough to have normal MMU with all bells and whistles, so, they used segmented memory model with NEAR/FAR pointer types, GlobalLock/GlobalUnloc() APIs in their OS and other weird stuff.
Such chips can be everywhere nowadays, audio, video, network controllers, etc.
Linux is not the only OS in the world.

[madshaman]

Re: c++ objects can have different base addresses when converted to pointers of different ancestor classes and other minutia.

The question isn't to primarily to test whether someone will be able to overcome an obscure gotcha they may never see (but their is merit in knowing these things: e.g. you're looking at raw memory where you're trying to find a pointer to a specific object, knowing that your object's pointer could be different if it was converted to a base class pointer will help), it's to get a candidate talking about all the things you guys have been talking about; which *does* give an indication of ability.

Honestly, knowing lots of obscure domain specific trivia is only going to impress so far.  Seeing someone's thought process in action, that's usually what I'm after (while still evaluating specific skills).

Anyway, I find it's a decent question.

[John Coloccia]

Re: c++ objects can have different base addresses when converted to pointers of different ancestor classes and other minutia.

The question isn't to primarily to test whether someone will be able to overcome an obscure gotcha they may never see (but their is merit in knowing these things: e.g. you're looking at raw memory where you're trying to find a pointer to a specific object, knowing that your object's pointer could be different if it was converted to a base class pointer will help), it's to get a candidate talking about all the things you guys have been talking about; which *does* give an indication of ability.

Honestly, knowing lots of obscure domain specific trivia is only going to impress so far.  Seeing someone's thought process in action, that's usually what I'm after (while still evaluating specific skills).

Anyway, I find it's a decent question.

That's what I thought.  The first obvious case was programmer overloaded ==, and the second was comparing different class pointers to the same object, because C++ is guaranteed to return true so long as the pointers reference the same object.

I think we're all in agreement that the C case is extremely obscure and not at all what you had in mind.

[SirNick]

If I were interviewing people, here are the kind of questions I would ask a would-be programmer:

- What do you like to do in your spare time?  (There's no wrong answer.  Let the person get into the mindset of talking to a stranger, on familiar turf -- stuff s/he likes.)

- What was the last project you worked on?  What was your part in it?  (Let's see what this person's immediate background is -- the stuff that is most familiar right now.)

- Tell me about a memorable bug.  Funny, "Doh!" moment, clever hunting, whatever.  (What's your thought process?  How skilled are you?  What constitutes a perplexing problem?  Did you spend three weeks diagnosing '=' != '=='?  Is that because you looked right past it, or because you aren't really used to programming?  Also: More communication warm-up.)

- Have you worked on any open-source projects?  And/or, have you written anything in your free time that you've given to others?  (This is mostly just gauging the candidate's interest level.  Some people leave work at work, and that's OK.  Others live and breathe this stuff.  Neither is wrong or right, but it's helpful to know the difference between a competent professional, an enthusiastic hacker, and someone that likes to watch TV every night until they fall asleep.)

- Here's a simple program and a compiler.  Spot three bugs that are probably not what the author intended.  (Can you catch the difference between ++i and i++?  Do you see details like "int8_t  i;  i = 254;"?  Yeah, experts can miss these things too.. that's OK.  If you have to compile the program and put in some debug printf's, that's cool.  Can I trust you to find and fix these things, though?)

Interview questions shouldn't be hard or tricky.  The candidate is not in their comfort zone, and their performance will probably show that.  Get them to open up a little, check and see if the essential skill set is there so you're not wasting time hiring someone with nothing to offer.  Then give them a shot.

[ejeffrey]

Any question that involves writing code is pointless. At best you get a small routine, hastily written by someone under pressure using a pen that doesn't support deleting mistakes or copy/paste. If they are unlucky it could be something they are not familiar with or they might make a mistake that a compiler would have caught and been easily corrected. There is no shame in googling for information, in fact it's better than relying only on your own experience much of the time.

No.  Never hire someone as a programmer without asking them to write some code in front of you.  They don't have access to an IDE/compiler/online documentation, so you should give them something simple and explain that you understand the limitations of a whiteboard, but you need to see them write code.  A portfolio is good, but you don't know how long that took them, how many times their TA / code buddy had to send back broken code, or even how much they did themselves.  You ask someone to write something simple in front of you, and you see if it is simple for them to do.

[miguelvp]

It's not about usable code, but to see how the candidate approaches the problem from a code point of view.

Without code, its ok too but you don't know how the subject will deal with it in code. It's not just about problem solving, but about problem solving with algorithms.

Not all smart people can translate thoughts to code.

[Kremmen]

Interestingly, there is a very low correlation between the impression a candidate gives in an interview and actual job performance. This has been studied by professionals at length and while i am sure almost no-one on this forum believes it, nevertheless it is a fact: You will do just as well by reading the CVs and applications of the candidates as you will by extensively interviewing them. Only the first method will save you lots of time.
I am not saying don't look the candidates over. But honestly, that serves more to check that they don't have 2 heads or an intolerable BO. A properly written and _properly_ analyzed CV is just as good and even better estimator in practice. But the CV must fulfill a number of key criteria (which a well written CV normally does).

Why is this then? Put simply - because almost none of you is a psychologically qualified interviewer. And the psychology part is not about shrinking the interviewee, it is about controlling the hidden biases and error sources in the interviewer him/herself. Trust me when i say there are those, and sometimes to an embarrassing degree. Don't believe me? Then check if you know what the following terms mean and how they could sabotage your interview results:

- confirmation bias
- regression towards the mean
- availability bias
- experimenter expectancy effect
- illusionary correlation
- representativeness heuristic
- availability cascade
- response bias
... and there are more. If you didn't know about these you are vulnerable and practically guaranteed to fall into the pits.

Every one of the above items is a well defined concept and a known source of cognitive bias, elimination of which is the foundation of scientifically valid proof processes. An interview situation is not a scientific proof process, but then neither are the interviewers as a rule qualified experimenters either. If i was to hazard a guess i would say that an average tech pro may be able to guard against zero to maybe a couple of those effects. Which is natural, seeing as how this is not in their focus during the daily work. At the same time it means that interviews by those blokes may not mean that much or confirm something different than the interviewer thinks.

Now you say no way will i hire someone who hasn't done this, that & the other etc etc. OK, but all of that you can find out from the CV. Do you believe the guy more if he says so aloud to your face in the interview? Most of us suck at judging people due to the above effects. Mentalists can handle that but then they tend to make their money by other means. The rest of us should not kid ourselves.

[madshaman]

Is it seriously being suggested that interviewing a candidate yields no more useful information than looking at a CV?

I respectfully disagree; I don't follow the reasoning that leads to that conclusion.

[rollatorwieltje]

Q1. "Write a linked-list class template. Here's some paper and a pen."

Only valid answer is a punch in the face. Don't create your own basic containers.

But seriously, asking somebody to write a silly program that has nothing to do with what happens in the field is useless. Template and pointer voodoo black magic don't belong in any piece of production code ever. Writing maintainable code is far more important.
I would ask if the applicant has experience with design patterns, version control systems, continuous integration and unit testing + code coverage. It's absolutely disturbing to see how many professional programmers have no experience at all with those things. I had to explain to way to many people how subversion works. Many people didn't even see any problems with releasing an executable made on their own PC. I even heard once (from a very large and highly regarded engineering company) that they didn't consider a version number system for their software because "our software is well tested and doesn't contain bugs after delivery".
I don't care if you're a C++ guru. I don't care about pointer magic, bitshift voodoo, template metaprogramming etc. I want maintainable, readable and well documented code. 99% of most software code doesn't need to be optimized for speed using hacks.

I would rather have an average programmer that understands quality assurance processes than some C++ guru that produces unreadable unmaintainable stuff.

Bonus points for people that are familiar with Scott Meyers' books.

[Kremmen]

Is it seriously being suggested that interviewing a candidate yields no more useful information than looking at a CV?

I respectfully disagree; I don't follow the reasoning that leads to that conclusion.

It may yield "useful" information depending on what you consider useful. What i referred to was, that the interview result does not have a significantly higher statistical correlation to the candidate's performance than does the CV alone, provided the CV is "good" and properly analyzed. I know, you find it hard to believe. And you are entitled to your opinions but note that i didn't express an opinion. I semi-quoted actual studies made. Next you will ask for references so here is one http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.169.9712. You won't find the outcome stated in a simple one sentence conclusion but you will find what i write below.

Let me elaborate. Competence in a topic (any topic) is built up over time by practicing activity in that topic and getting feedback (critical this, otherwise the result is just false self-confidence) until the activites subject to that topic become in a fundamental way different mental processes from those of a novice. I won't go deeper into the psych theory behind this because it is perhaps not essential. Now, assuming people don't actually directly lie in their CVs or applications (there are ways to detect this also), a careful reader will be able to extract this information from the document. There are several key items that should be present and recognized and if they are, the interviewee just saying so or demonstrating ad hoc the same skill provides only limited additional info.

If you insist on having an interview with quizzes - and most don't have the courage to do without - here's a hint. When you present the quiz, arrange so that you can see the eye pupils of the interviewee during the performance. The are about as reliable as clockwork to indicate the level of mental effort. The pupil size is more or less directly correlated and varies almost instantaneously. Don't believe me? Then take a video clip on your handy phone of your own face when doing some mental arithmetic - say multiplying 2 digit numbers in your head. You might be surprised. Anyway, an expert will expend visibly less mental energy in solving tasks in his/her knowledge domain than will a novice and this difference is visible in the relative pupil size.

Finally, please don't take this as a recommendation to skip interviews altogether. More perhaps as a note and warning that most of us delude ourselves into thinking the interview is somehow a way to find an objective truth. It is not.

P.S. During my career i have hired between 150 and 300 people for employment and consultation assignments. Mostly programmers for various languages and environments, but other kinds of IT experts as well. Their personality was assessed in an interview in every case, but notably not a single time did i have them perform a quiz. Instead there were requirements on the format of CV such that the relevant ionfo was available and this system worked entirely satisfactorily. With hindsight, i could have skipped almost all of the interviews with no ill effect whatsoever...
It should be noted that there was absolutely no perceivable difference between these persons and those recruited by other means. Specifically the employment termination rate and causes was in line with the averages always.

Edit: typos.

[krivx]

Q1. "Write a linked-list class template. Here's some paper and a pen."

Only valid answer is a punch in the face. Don't create your own basic containers.

I agree, but there is certainly value in knowing how basic data structures actually work. I wouldn't want to roll my own containers for anything serious but I think I have gained a lot from implementing toy versions. I would go as far as saying that I wouldn't trust someone to use a list in C if they couldn't come up with some kind of basic version of their own.

I do fell that linked-lists may be a bad example, as it's such a classic case that people candidates may just regurgitate memorized code though.

[madshaman]

I don't disagree with some of what you say, but if I talk to a coder, I get a very good idea of exactly how good they are.

I'm not every interviewer because I have significant experience and background knowledge; because of this, it makes it much easier to assess the same.

I can also tell quite quickly if someone can get along with and work effectively in a team, that's even more important than skill once a certain degree of competency has been met.

Some body language queues are useful but can be misleading; in real life one isn't always aware what a person has their attention on, they could be thinking about the past or the future or another place and their body language is a reaction to their inner world.

[John Coloccia]

I remember one interview in particular that turned into a train wreck.  We were interviewing someone, talking about previous experience, recent experience, etc etc.  He had said something like, "...and I just implemented a binary search algorithm for such and such...it was very cool because I did this, this and that to make it more effecient", etc etc etc.  I said, "OK...I'm thinking of a number from 1 to 1000.  Find it".  It started off OK:  500....too low....750....too low...

And then it went off into the weeds....900?  Uhm, too high.  800?  Too low.  825?  I finally had to do a mercy killing and stop the process because it was getting ridiculous.  We didn't hire him.  It's not solely because he got completely lost, but it certainly didn't help.

[miguelvp]

I remember one interview in particular that turned into a train wreck.  We were interviewing someone, talking about previous experience, recent experience, etc etc.  He had said something like, "...and I just implemented a binary search algorithm for such and such...it was very cool because I did this, this and that to make it more effecient", etc etc etc.  I said, "OK...I'm thinking of a number from 1 to 1000.  Find it".  It started off OK:  500....too low....750....too low...

And then it went off into the weeds....900?  Uhm, too high.  800?  Too low.  825?  I finally had to do a mercy killing and stop the process because it was getting ridiculous.  We didn't hire him.  It's not solely because he got completely lost, but it certainly didn't help.

Two extra steps and the next one would  have needed rounding off. I would have respond in a way that you'll do the math for me, asking: is bit 9 on? bit 8? all the way to bit 0

Edit: of course I will ask for bit 0 only if any other bits were on

[John Coloccia]

It actually would have been fine if he had asked for a calculator, or even just described the process when the arithmetic started getting more difficult.  If he had just said, "You just keep dividing in half until you get it", that would have been find too.  It was obvious, though, that he knew you started by chopping the array in half, but he just had absolutely no clue that you keep going like that until you seal the deal.

[SirNick]

I remember one interview in particular that turned into a train wreck.  We were interviewing someone, talking about previous experience, recent experience, etc etc.  He had said something like, "...and I just implemented a binary search algorithm for such and such...it was very cool because I did this, this and that to make it more effecient", etc etc etc.  I said, "OK...I'm thinking of a number from 1 to 1000.  Find it".  It started off OK:  500....too low....750....too low...

And then it went off into the weeds....900?  Uhm, too high.  800?  Too low.  825?  I finally had to do a mercy killing and stop the process because it was getting ridiculous.  We didn't hire him.  It's not solely because he got completely lost, but it certainly didn't help.

Were you expecting a perfect binary routine?  You were interviewing a person, not a calculator.  :-)  If I had to guess-the-number, I would probably pick convenient round numbers to start narrowing down -- probably a pattern along the lines of what you're saying is in the weeds.  By the initial responses (500, 750..) you can see there's a fundamental understanding of how binary search patterns work.  But when you have to then add 750+125, and then 875+62-and-a-half, I can see why your poor candidate chose to abandon the idealistic routine and go with something more human.  Yes, the point was to illustrate an algorithm, but it's pretty easy to botch simple math when you're doing it in your head and you're afraid of screwing up a first impression in front of a potential employer.

This is the same problem I have with code quizzes, especially pen-and-paper ones.  I use a half dozen scripting and programming languages.  It's so incredibly easy to mix up whether you initialize an array with { these } or ( these ).  Do structs have semicolons between the elements, or commas?  What was the order of parameters in sprintf again?  Now, I'm not a professional developer, and maybe if I were I wouldn't mix these things up as much.  But as a professional network admin, I do still sit down at a Juniper router and type "configure terminal", or "show ip int brief" from time to time.  Even when I'm not throwing in Cisco commands, I might not remember if it's "show interfaces" or "show interface" since IRL, I use command completion and hardly ever get past "int" before the CLI fills in the rest for me.

The stress of trying to keep this kind of detail straight is likely to befuddle your poor candidate, and lead to silly mistakes and brain freezes.  So consider having a chat instead.  If the coder has ever written anything, they have opinions about which IDEs they like, which languages suck at what and why.  (The answers to the latter will reveal misinformation and ignorance as well.)  If their idea of programming is copying and pasting examples from the Internet, they won't.  This should be enough to tell you in short order whether their resume (and example code from their portfolio) is fact or fiction.

[andyturk]

Q1. "Write a linked-list class template. Here's some paper and a pen."

Only valid answer is a punch in the face. Don't create your own basic containers.

Oh really? Well, Mr. Interviewee, which published linked list implementation do you recommend for an embedded application?

Hopefully it doesn't require dynamic memory allocation, because we've decided not to use it.

[madshaman]

Q1. "Write a linked-list class template. Here's some paper and a pen."

Only valid answer is a punch in the face. Don't create your own basic containers.

Oh really? Well, Mr. Interviewee, which published linked list implementation do you recommend for an embedded application?

Hopefully it doesn't require dynamic memory allocation, because we've decided not to use it.

Lol, OS code running in unpageable RAM isn't fond of STL nor boost either.

[westfw]

Is it seriously being suggested that interviewing a candidate yields no more useful information than looking at a CV?

That's not quite what was said:

there is a very low correlation between the impression a candidate gives in an interview and actual job performance.

is somewhat different.  Although I think it's a questionable assertion: how many candidates give an AWFUL impression at their interviews, but go on to get hired anyway, and then perform well?  Usually they don't get to the "hired" part, so you're only saying  that interviewing well doesn't correlate to performing well, which probably only "some employees don't work out well", since "did well in the interview" is a constant.

I always figured that an interview was a two-way street.  When I interviewed people, I assumed that their technical skills were more-or-less as depicted on their resume, and wanted to see whether I thought they would "fit in" with the company in other ways.  Also, I wanted to SELL the company, so that they would want to accept our offer (if we made one.)  Of course, we were usually interviewing for specific skills in a day when the pool of applicants was very tiny.  A company that regularly hires significant numbers of entry-level people, in an economic downturn, has a different problem.

[rollatorwieltje]

Q1. "Write a linked-list class template. Here's some paper and a pen."

Only valid answer is a punch in the face. Don't create your own basic containers.

Oh really? Well, Mr. Interviewee, which published linked list implementation do you recommend for an embedded application?

Hopefully it doesn't require dynamic memory allocation, because we've decided not to use it.

STL containers with a custom allocator that uses a memory pool.

Honestly, the amount of bugs I've seen in custom container implementations... I've worked on projects that had about a dozen custom containers because the c++ support was piss poor and STL couldn't be used, even template was broken. Lots of wasted hours writing boilerplate stuff instead of actual features.

[John Coloccia]

Were you expecting a perfect binary routine?

No.  As I said in the post right above yours, I expect him to be able to at least describe the routine, make reasonable estimates, or ask for a calculator, not start going up like: 825?  850? 875?  If you boast about being a wiz at Altivec optimization, I probably won't ask you write a routine to perform convolution, but we ARE going to talk about cache management, alignment issues and things like that, and you'd better have a working knowledge.

[miguelvp]

STL containers with a custom allocator that uses a memory pool.

Honestly, the amount of bugs I've seen in custom container implementations... I've worked on projects that had about a dozen custom containers because the c++ support was piss poor and STL couldn't be used, even template was broken. Lots of wasted hours writing boilerplate stuff instead of actual features.

I found out over the years that STL leaves std:: all over your code. Kidding aside, on large projects with third party libraries STL can cause havoc. Different implementations with the same name mangling and letting the linker pick them from different object files is asking for trouble.

[rollatorwieltje]

I found out over the years that STL leaves std:: all over your code. Kidding aside, on large projects with third party libraries STL can cause havoc. Different implementations with the same name mangling and letting the linker pick them from different object files is asking for trouble.

Some things in C++ are just completely broken. The way libraries work is one of those. One day it will explode in your face. Try to find that segfault where memory was allocated in a DLL and released by the executable...