C++ interview questions that do not suck

[vvanders]

Someone mentioned that it would be really hard to learn C++ in two weeks because of its complexity.  I disagree somewhat, I think that's plenty of time to become effective at a new language.  C++ doesn't really have any unique semantics or concepts, that two weeks would really be spent learning syntax, some standard libraries, a handful of gotchas, and maybe becoming familiar with how the average compiler emits the target object code.

There are a fair things that are unique to C++, templates, deterministic destruction, etc. That said most of that you would not want to use in an embedded environment.

[madshaman]

Someone mentioned that it would be really hard to learn C++ in two weeks because of its complexity.  I disagree somewhat, I think that's plenty of time to become effective at a new language.  C++ doesn't really have any unique semantics or concepts, that two weeks would really be spent learning syntax, some standard libraries, a handful of gotchas, and maybe becoming familiar with how the average compiler emits the target object code.

There are a fair things that are unique to C++, templates, deterministic destruction, etc. That said most of that you would not want to use in an embedded environment.

On-demand macro-expansion (which is what templates are) existed before C++ and so did deterministic object tear-down, both are used and have been used long before C++, just not always as an explicit language feature.

Most experienced coders have implemented the former concepts in systems ranging from assembly code to the build process of a large open-source project.

I will admit these are features that set C++ apart from other common languages, but they are concepts one should know as a hacker, and DEFINITELY should know if one has a comp-sci degree.

[John Coloccia]

For EEs you could try "how suitable for embedded development is C++?"

data point: I had an interview at samsung (corp, san jose) yesterday for their SAS storage division.  the enterprise ssd stuff.  all their code ON EMBEDDED CONTROLLERS is c++.  I was very surprised.  I would have guessed C but I guess some 'new kids' thought c++ would be teh new hotness and so they use it.

speed matters and memory matters but they are using c++ on sas controllers?

boggle....

There's no reason in the world not to use C++ in an embedded environment.  You just need to understand the nuts and bolts of what it's doing and when so that you don't screw yourself up.  Used properly, C++ can be even more efficient than C if you turn loose the compiler optimizations.  Knowing the semantics of all of the pointers and structures that are floating around (essentially what classes are) allows the compiler to do optimizations it could never possibly do with home grown structures and function pointers, and this crops up a lot in embedded programming.

What you typically DON'T want to do is suck in the standard libraries.  They're bloated pieces of crap.  Most embedded environments will come with lightweight versions of basic IO like, printf, and things like that.  You also need to be very careful with your coding style and really understand what's going on.  Hidden memory allocations/deallocations and things like that can bite you.  The C++ object mechanism itself, though, is very lightweight and efficient.

re: difficulty in learning C++
If you exclude learning the standard libraries, which can be a little frustrating because of all the obfuscations, iterators, and things like that, really the only thing C++ adds that is not particularly commonly done using structures and pointers is multiple inheritance.  IMHO, multiple inheritance is an abomination that should be banished anyway, so no big loss.

[John Coloccia]

P1 == P2 but ((void *) P1) != (void *) P2)

If so, why?

Hmmm...other people seem to have gotten this straight away.  I consider myself pretty expert as far as C/C++ is concerned, but nothing is really coming to mind other than maybe just a coding error where P1 and P2 are declared as char*, or something like that.  I think you're fishing for a different answer, though.

edit:
never mind. I glanced at it too quickly and saw a dereference in there.  Yeah, that right there is yet another abomination in C++ that should be banished.  I wouldn't let my guys use that either.

[Galaxyrise]

P1 == P2 but ((void *) P1) != (void *) P2)

Yeah, that right there is yet another abomination in C++ that should be banished.  I wouldn't let my guys use that either.

"The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous. " -- Bjarne Stroustrup

I think a proper expert understands not just the language feature, but also when a language feature is a good thing.

I've seen good uses for both language features I can think of which cause that situation (one more so than the other), but they both should give pause to make sure something else isn't a better fit.

And I think "when is this feature good and when is it bad" is a much better interview question than "can you puzzle out this gimmick question" (As research has shown stressful interviews are a terrible place for creative thinking.)

[grumpydoc]

P1 == P2 but ((void *) P1) != (void *) P2)

Is that with a static_cast, dynamic_cast or reinterpret_cast to void * ?

[DmitryL]

P1 == P2 but ((void *) P1) != (void *) P2)

Is that with a static_cast, dynamic_cast or reinterpret_cast to void * ?

It doesn't matter The brackets are not matched; this code won't compile, the question is invalid
On the other hand, it is possible to have the situation (for pure C as well), when P1==P2 and (void*)P1 != (void*)P2;

[grumpydoc]

It doesn't matter The brackets are not matched; this code won't compile, the question is invalid

Oh, I didn't think that nit picking about brackets was where we were at - I mean there's so much fun to be had with globally overloaded operator == and RTTI 

On the other hand, it is possible to have the situation (for pure C as well), when P1==P2 and (void*)P1 != (void*)P2;

OK, I'm struggling a bit in C to think of a case where two pointers would compare equal with == but have different values when cast to void * - even on architectures that do odd things with pointer types. For one thing for the comparison to actually be valid the pointed-to type would have to be the same so any odd behaviour in the cast would be the same for both pointers.

Of course throw in some global variables and interrupts and code such as

Code: [Select]

if (P1 == P2) {
    if (P1 != P2) {
        printf("Hang on a cotton-pickin' moment!\n");
    }
}could easily print the string "Hang on a cotton-pickin' moment!" but, again, I didn't read the original question that way.

[tjaeger]

And I think "when is this feature good and when is it bad" is a much better interview question than "can you puzzle out this gimmick question" (As research has shown stressful interviews are a terrible place for creative thinking.)

Yeah, asking the candidate to second-guess the interviewer's idiosyncratic views on language design is a great way to conduct an interview.

[grumpydoc]

Yeah, asking the candidate to second-guess the interviewer's idiosyncratic views on language design is a great way to conduct an interview.

A good interviewer will not care whether the candidate's views match their own. What is important is that the candidate can muster a reasoned argument - with bonus points for coming across as though the answer comes from experience rather than a google trawl the night before the interview.

[tjaeger]

my point is that their process often rejects the people they should actually be hiring.  and the ones who can memorize a linked list or tree delete are the ones that are NOT the most creative, but just good at memorization.  those are the worst programmers, generally, as they run out of steam quite fast when its not something they studied and memorized, previously.

I'm really puzzled by this comment.  If you need to memorize how to delete an element from a linked list, clearly you've chosen the wrong profession. Any halfway decent programmer should be able to draw a before and after picture on the whiteboard and figure out what they have to do to make this happen.  How you approach the problem is more important anyway than the actual solution, or so they say.

[DmitryL]

On the other hand, it is possible to have the situation (for pure C as well), when P1==P2 and (void*)P1 != (void*)P2;

OK, I'm struggling a bit in C to think of a case where two pointers would compare equal with == but have different values when cast to void * - even on architectures that do odd things with pointer types. For one thing for the comparison to actually be valid the pointed-to type would have to be the same so any odd behaviour in the cast would be the same for both pointers.

Ops, my fault. I meant when P1 != P2  and (void*)P1 == (void*)P2;

[tjaeger]

Yeah, asking the candidate to second-guess the interviewer's idiosyncratic views on language design is a great way to conduct an interview.

A good interviewer will not care whether the candidate's views match their own. What is important is that the candidate can muster a reasoned argument - with bonus points for coming across as though the answer comes from experience rather than a google trawl the night before the interview.

If were the candidate, there's no way I would buy that. I would just offer some generic platitudes that are unlikely to offend anyone and hope that the next question will be a technical one.  If someone were to ask me what I think of the & operator when they mean the ref-qualifier and the correct answer was that it's the devil's work, I doubt I'd even want the job.

[andyturk]

If someone were to ask me what I think of the & operator when they mean the ref-qualifier and the correct answer was that it's the devil's work, I doubt I'd even want the job.

Fortunately, we don't have to worry about the devil's work until ISO C++29A is approved.

 

[John Coloccia]

On the other hand, it is possible to have the situation (for pure C as well), when P1==P2 and (void*)P1 != (void*)P2;

OK, I'm struggling a bit in C to think of a case where two pointers would compare equal with == but have different values when cast to void * - even on architectures that do odd things with pointer types. For one thing for the comparison to actually be valid the pointed-to type would have to be the same so any odd behaviour in the cast would be the same for both pointers.

Ops, my fault. I meant when P1 != P2  and (void*)P1 == (void*)P2;

I can come up with other C++ reasons why that wouldn't work, but I still can't think of a good reason for it to fail in straight C.  I'd like to hear the answer.  Maybe I'll learn something, or just jog my memory.

[Galaxyrise]

Ops, my fault. I meant when P1 != P2  and (void*)P1 == (void*)P2;

I can come up with other C++ reasons why that wouldn't work, but I still can't think of a good reason for it to fail in straight C.  I'd like to hear the answer.  Maybe I'll learn something, or just jog my memory.

sizeof(P1) > sizeof(void*)

[John Coloccia]

Ops, my fault. I meant when P1 != P2  and (void*)P1 == (void*)P2;

I can come up with other C++ reasons why that wouldn't work, but I still can't think of a good reason for it to fail in straight C.  I'd like to hear the answer.  Maybe I'll learn something, or just jog my memory.

sizeof(P1) > sizeof(void*)

While there is no requirement in C for all pointers to be the same length, I would think if you're working on such an architecture that this wouldn't be an issue.  Is there some common case where the original comparison would fail, other than C++?

[vvanders]

Someone mentioned that it would be really hard to learn C++ in two weeks because of its complexity.  I disagree somewhat, I think that's plenty of time to become effective at a new language.  C++ doesn't really have any unique semantics or concepts, that two weeks would really be spent learning syntax, some standard libraries, a handful of gotchas, and maybe becoming familiar with how the average compiler emits the target object code.

There are a fair things that are unique to C++, templates, deterministic destruction, etc. That said most of that you would not want to use in an embedded environment.

On-demand macro-expansion (which is what templates are) existed before C++ and so did deterministic object tear-down, both are used and have been used long before C++, just not always as an explicit language feature.

Most experienced coders have implemented the former concepts in systems ranging from assembly code to the build process of a large open-source project.

I will admit these are features that set C++ apart from other common languages, but they are concepts one should know as a hacker, and DEFINITELY should know if one has a comp-sci degree.

Close, but not quite, they are both code generation tools however there's some subtle differences as explained here:
http://stackoverflow.com/questions/180320/are-c-templates-just-macros-in-disguise

Specialization, type checking, other features make them more than just fancy macro expansion.

WRT deterministic destruction, C++ is one of the few popular languages where true RAII can be done, it's something that I often find reaching for in other languages.

[westfw]

P1 == P2 but ((void *) P1) != (void *) P2)

Ok; I don't really consider myself a c++ programmer.  Are you looking for anything sneakier than "the == operator might be overloaded for typeof(P1)"?  This should routinely be the case for common data types like Strings, right?

A good interviewer will not care whether the candidate's views match their own.

You assume that good interviewers are more common than good C++ interview questions :-(
If you're a reasonably sized company, you probably have quirks or particular pieces of C++ that you use that you hope a new hire will already be familiar with, or will pick up quickly.  Go ahead and expose some of YOUR code and ask what the interviewee thinks.   See if they can explain some ancient bug from you bug database, perhaps.

There are lots of questions where a good answer will indicate that the interviewee is indeed wizardly, but the lack of a good answer doesn't mean much of anything.  You're not hiring someone to implement a binary search or quicksort; you're hiring someone (probably) to use the primitives that you've already developed to do useful things, find and fix bugs, etc.  And that can be a different skill set.  The circumstances under which you want to hire someone who is going to come in and say "I'm a C++ wizard and all your code sucks, so I'm going to re-write it from the ground up" are pretty rare, even if it's true that your code sucks.

[John Coloccia]

FWIW, if you want to see what a real systems programming language looks like, done right, check out D.  I guess Walter Bright pissed off Stroustrup at some point.  Whatever.  D is what C++ should have been, IMHO.

Really, though, none of this really matters, anymore than the brand of screwdriver matters.  Design is king.  Interface design, specifically.  User interface, and programmatic interfaces.  No one seems to be able to do either anymore.  User interfaces are almost universally garbage, and interfaces in code are usually ad hoc, crappy nightmares.  Truthfully, I don't see why my microwave needs to have more than a couple of knobs and a couple of buttons, but instead I have a control panel reminiscent of some complicated, process control unit...like something you'd find in a nuclear power plant.  It's nothing but laziness....or maybe stupidity...and the coding is typically no better.

I have my own philosophies on this sort of stuff, but none of it really has much to do with C++ or any other language.  When I was in a position to hire, I rarely asked technical programming language questions.  I can teach someone how to program in any given language.  I was far more interested how they thought about problems.  I might ask a couple of fluff ball questions about stuff on their resume just to make sure they're not full of crap, but the last thing I needed was a code jockey that couldn't think his way out of a paper bag.

[westfw]

Templates seem like a legitimate area for C++ questions, but there's a big difference between "how familiar are you with the C++ STL?" and "How would you use template meta programming to implement efficient bitwise IO on this microcontroller?"

[John Coloccia]

Templates seem like a legitimate area for C++ questions, but there's a big difference between "how familiar are you with the C++ STL?" and "How would you use template meta programming to implement efficient bitwise IO on this microcontroller?"

Once, early in my career, I had an interviewer ask me:

"Write a program that produces this output:

                      1  2   3
4    5   6   7   8   9  10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

"

I said, "Fine".

int main()
{
     printf("                      1  2   3\n");
     printf("4    5   6   7   8   9  10\n");
     printf("11 12 13 14 15 16 17\n");
     printf("18 19 20 21 22 23 24\n");
     printf("25 26 27 28 29 30\n");

     return(0);
}


He said, "Why'd you do it like that?  Everyone else used a loop."

I asked him how long everyone else took, and if anyone was able to get it right the first time without any errors?  Further, he didn't ASK for a calendar.  He asked for a peculiar list of numbers.  If he turns out wanting a generic calendar, now I have the better part of a month to design one, implement it and debug while the user if off using my perfectly functional calendar until then...AND I haven't saddled myself down with a crap load of buggy code based on vague specifications and guessing.  I had an offer before I left. 

I never forgot that interview, and I always thought back to it whenever I had the urge to ask a question like, "Implement this, on paper in the next 10 minutes."  I never forgot just how stupid I thought it was, and thinking to myself that I should just get up and leave because I don't want to be here...although I did take the job and worked there for several years.

[zapta]

I happen interview often people for software engineering positions.  I try to avoid aha-moment questions, provide hints when needed (no need to abandon a good multi level question because of one snag), not insisting on any specific programming language ('what language do you feel comfortable the most")  and throughout the interview I try to identify the candidate strength points. The idea is that a smart and creative person with excellent analytical skills will be able to pick on any language and technology and you end up with a productive and versatile engineer. Deep understanding of the minute details of a language is nice but I never target it, if I ask to write a piece of code I prefer straight forward code that show good understanding of the problem, the abstraction and the algorithm rather than fancy, compact or prematurely optimized code.

The bottom line, the details are not that important, smart people will figure them out.

[grumpydoc]

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.

[John Coloccia]

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.