C++ interview questions that do not suck

[mrflibble]

See subject.

I've been checking out several lists with "typical interview questions" and generally they put me in a state somewhere between giggling like a little girl and perpetual eye-rolling.

Sooo, any and all lists with actually relevant questions you can think are much appreciated!

[andyturk]

Q1. "Write a linked-list class template. Here's some paper and a pen."
Q2. "Write a predicate function that says whether two time segments overlap. Here's some more paper."
Q3. "How can you prove that your code actually works?"

Only Q1 is C++ specific.

[mrflibble]

A1: singly, doubly, or curiously linked?
A2: In what way are those time segments defined? Given a discretized bit-array where each bit represents a time slice I can make do with a bit-reduce and operator. Or if each time segment is denoted by T_start and T_stop, then I think I can manage to return a boolean based on some < not and.
A3: First actual brain teaser, being a bit of a math pedant. To which the proper answer probably is: "Are you management? if yes, jump out of window now, because the answer is the unsatisfactory YOU CANNOT for all non-trivial problems solved in an economically viable way." The best you can do is arrange for decent test coverage to reduce the change of error to an acceptable level, whatever that level may be. Hell, you should already be so happy if you can mathematically prove the algo you designed is correct. Let alone the implementation on irradiated actual hardware.

And speaking of which, how do you typically estimate what decent test coverage is in the embedded area? And how does one do unit testing? It's come up before in other threads, but never really read an in depth answer. What I can think of is to do standard boring unit tests against stubs at every stage during development. And testing on actual hardware as well at a later stage (aka not every stage, because this form of testing is more time consuming == expensive).

Right now I do a bit of a mix of that, but that's only for my own fun projects. So I was wondering how that's done Out There [tm].

Edit: And shame on me. Of course thanks for your reply. Guess reading all the drivel on the interwebs makes the pedantic bit go into overdrive.

[madshaman]

One of mine: write an implementation of Tetris, any platform you want.  I'll want to see the source.

[madshaman]

More: what's an ABI?  what's a calling convention?  Why might it be important to know these things?

Can the numerical value of a pointer change after an assignment?

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

If so, why?

You're debugging some code, and you notice that an array of yours gets partially trashed after stepping through some trivial code that shouldn't or can't effect that array.

What might be happening?  Describe how you'd
continue to isolate the problem.

You have a robust library which targets the correct processor, has no dependencies beyond the C standard library but was produced for a different OS, uses a different ABI, and has a different object file format than the target platform.

You only have the binary for the library but it's archive and object file format are well known.

How would you create a native library with the same entry points from this binary?

[Neilm]

A3: First actual brain teaser, being a bit of a math pedant. To which the proper answer probably is: "Are you management? if yes, jump out of window now, because the answer is the unsatisfactory YOU CANNOT for all non-trivial problems solved in an economically viable way." The best you can do is arrange for decent test coverage to reduce the change of error to an acceptable level, whatever that level may be. Hell, you should already be so happy if you can mathematically prove the algo you designed is correct. Let alone the implementation on irradiated actual hardware.

About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.

[AG6QR]

This is not in an EE context, nor in an embedded systems context, but I've worked on software for CAD/CAM and analytic geometry.  I've presented this question to interview candidates:

Write a function to plot a circular arc on an x-y plane using a sequence of straight lines.  Assume the graphics system gives you two functions, moveto(x,y) and drawto(x,y), where moveto positions the cursor to a spot, and drawto draws a straight line from the current position to the place you specify.

Your function will accept the x,y coordinates of the arc's center point, the radius, a start angle in radians, an end angle in radians, and a tolerance, defined as the maximum distance your straight lines are allowed to deviate from the actual ideal circle.  All the numbers are of type float.

I ask the candidate to write the function out on a whiteboard, explaining what they were doing.  It's OK to ask for clarifications on the problem statement as needed.  I don't worry much about minor syntax errors.


In my experience, this question very clearly separated out candidates into two distinct groups.  Those who thought it was so trivial that they had trouble understanding why I was wasting their time on such a kindergarten exercise, and those who didn't have a clue where to begin, and even with some coaching on where to begin, couldn't figure out the middle or end of the solution.  Most candidates fell into the latter group, unfortunately.

Of course, this question isn't C++ centric; it could be done in any language.  It's mostly about understanding of algorithms and basic geometry, but it's also about ability to interact and explain yourself on the fly.  And since the candidates were applying for jobs involving writing code to implement geometric algorithms, this question was very fair game.

But for a different employer, where the job involved implementing code for different types of applications, I'd expect very different questions.

[miguelvp]

See subject.

I've been checking out several lists with "typical interview questions" and generally they put me in a state somewhere between giggling like a little girl and perpetual eye-rolling.

Sooo, any and all lists with actually relevant questions you can think are much appreciated!

How about these assessment questions before they even granted you an interview?

Question 1
Write a function that supplies a color masking operation on two colors (Source and CMask) supplied as 32-bit unsigned integers.  8-bit red, green, and blue components are packed into these integers. 
For each color component, perform the following operation:
 If the CMask component is non-zero, the output  is CMask.  Otherwise, the output is Source.
#define R_MASK 0x00FF0000
#define G_MASK 0x0000FF00
#define B_MASK 0x000000FF

Question 2
Write a function that tests if a point is within a specified distance (dist) of any part of a filled 2D rectangle.  The rectangle is specified by bottom left corner, a width, and a height.

Question 3
Write a function to swap two adjacent elements (elem and elem->next) in a singly-linked list. Assume that you do not have access to the data component of the elements (and thus cannot just swap the data).
This is tricky since the pointer has to be passed by reference, there is no guarantee the invoking method will pass the actual pointer element.

Question 4
Describe a system for representing the following types of entities that may occur in an MMO.  All are visually represented in the world, and may have to be sent to the client:
* NPC – Needs to run AI, may be involved in combat, needs to walk and collide with objects
* Player – Connects to the client, may be involved in combat, needs to walk and collide with objects
* Crowd NPC – Fills up a city, runs limited AI, not involved in combat, does not collide with objects
* Door – Has an open and shut state, may be destroyed by combat, may obstruct other entities
The server has limited memory; design a system with as little waste as possible.  Please compose your response in the form of a graph or code that depicts a set of classes with stub functions inside.

Question 5
Write a function that will be used to help compose a resistance circuit.  The function takes a list of resistors with resistance values in Ohms specified for each.  It also takes a target resistance in Ohms and returns whether that resistance can be composed using the input resistors.  Resistors are only attached in simple parallel and series relationships.  Not every resistor needs to be used.
Consider that two resistors may be attached in series or in parallel.  If attached in series, the resulting resistance is the sum of the two component resistors: (R1 + R2).  If attached in parallel, the resulting resistance is given by Inv(Inv(R1) + Inv(R2)) where Inv(X) is 1 divided by X.
You may consider doing the following: removing two resistors from your list of remaining resistors, attaching them either in parallel or series, and adding a ‘pseudo’ resistor back to the set with the value of (R1 + R2) or Inv(Inv(R1) + Inv(R2)).  This ‘pseudo’ resistor can then be composed with any other resistor in the set using the series or parallel rules.
Note that there is no need to special case a set of three or more resistors.  The resistance of three resistors is the same as the resistance of the ‘pseudo’ resistor formed from the first two added to the third in both the series and parallel case.
No knowledge of electrical engineering is required to answer this question. All necessary information is included in the above description.

I got the interview but they scheduled me too late so I ended up taking another job elsewhere that interviewed me earlier and was for a better position anyways.

Glad I did, since now we are interviewing people that were in that company because they closed down.

Edit: This was 5 years ago btw, now they probably will ask you about lambda expressions and all kinds of C++11 related things as well.

[andyturk]

A1: singly, doubly, or curiously linked?
A2: In what way are those time segments defined?

etc.

Yes, exactly.

Part of the interview is to see how the candidate deals with incomplete specifications. Can s/he recognize when more information is needed, or will s/he zero in on one interpretation that seems to be the most obvious and blame the user later on when it turns out the simplifying assumptions were wrong.

Back when I was doing technical hiring, it was really useful to give the same question (Q2) to every candidate programmer over a number of years. The time span overlap is a pretty simple idea that any competent engineer *should* be able to implement in 20 minutes. Plus, it seems easier than it actually is, so even folks who get nervous in interview situations jump right in without second guessing themselves too much. As I remember, there were 4 or 5 distinct solutions that actually worked, and after the first few minutes, I could usually tell if the candidate was going to come up with a solution.

[Stonent]

Q: Why did they call it C++ ?

You never know, they may get it wrong!

[miguelvp]

Q: Why did they call it C++ ?

You never know, they may get it wrong!

Not that it will matter on a hire.

My understanding is because of BCPL. C derived from B, C++ derived from C, so it could be called P instead.

Stroustrup called it C with Classes, maybe he didn't want to call it P (don't blame him) but someone else called it C increment (++) and it stuck.

[Jeroen3]

Here you have an UML diagram.
Give the classes.h file.

Of the UML diagram of class A, write the constructor and destructor.

[AndyC_772]

What sort of area is the person you're hiring going to be working in?

Most of the code I write is low level, embedded / driver stuff. A lot of the 'gotchas' are to do with the way the code interacts with the hardware... registers changing half way through being read, interrupts triggering at just the wrong time, that sort of thing. The hardware may have bugs of its own still to be found (hardware fault), or it may not be set up correctly (software fault). Stopping the CPU with a debugger doesn't also freeze the rest of the hardware on the board (and the hardware the board is connected to), so you can't just 'stop the world' and step through it to see where errors creep in.

Imagine, for example, that you're writing code that takes in a continuous stream of data from a reliable external device, processes it, and delivers the results to some other I/O port. Every so often, your outgoing data stream appears to have an error in it. Describe how you would approach such a problem.

[madshaman]

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.

I ask candidates to provide this before they come to their in-person interview, nothing helps me assess someone better than looking at how they code and/or design a system.

I've never asked a candidate to write code in front of me, but have been asked to write code myself plenty off times.

I see nothing wrong with this though.  Sure it's okay if a candidate needs to look something up, but getting flustered and not being able to perform under stress and time-pressure is something employers need an idea of sometimes; it does indicate a candidate's mastery to a degree.

[nctnico]

When hiring someone I always have the person take a test. Not to determine the absolute level of competence but just to see if they can do what they say they can do. There are lots of people out there which are full of BS. It prevents wasting time with firing someone in their trial period.

[aroby]

About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.

That's just bad architecture.  The string should be externalized so you don't have to touch the code.

[_Sin]

I get candidates to write some code in the interview, but I just hand them a laptop with a development environment on it. I don't rate asking people to write code down on paper with a pen as it's not how I'd expect them to ever work.

[Neilm]

About 10 years ago I was talking with a guy who knew about the embedded code in tank fire control systems. He told me that even to correct the spelling mistake in a string on the display would required over £1.5m of testing.

That's just bad architecture.  The string should be externalized so you don't have to touch the code.

Still have to prove it it would not make a difference. Given that it is embedded there were probably all sorts of other issues - checking files linked correctly and did not affect the control algorithms.

Much better to ask them to bring examples of code they have written and then talk about it. You want someone who will do a good job, you don't so much care how they get there, so look at the end result. Working, debugged code will tell you a lot more than something they scribbled out in ten minutes.

Only if they coded at home. Anything from a company would be copywrited by that company (and in cases I have worked in - Classified)

[retrolefty]

Best question: Who created C++
Best answer:  Barney Shoestrap.

[AG6QR]

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.

At my workplace, we occasionally do some collaborative coding and brainstorming on the whiteboard.  Of course the details of the semicolons and other minor things that would be caught by the compiler don't matter.  But an employee who can clearly communicate an algorithm on the whiteboard is more valuable than one who cannot.

[zapta]

Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

[miguelvp]

Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

compiler or preprocessor?

and will adding a comment /*blah*/ do the same thing? (preprocessor changes the comments with spaces)

[westfw]

this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin

Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  For your hypothetical geometric application, I'd rather have someone who understood geometry than someone who could argue obscure C++ syntax standards issues.  I've hired people who weren't well-educated in the language I expected them to program in.  I've BEEN hired to program in a language I wasn't well educated in.  And surely there is a big difference between some who you expect to write embedded C++ code while carefully avoiding "expensive" C++ features and unimplemented libraries, vs someone you expect to write "standard windows L&F C++ using the XYZ GUI library."

[miguelvp]

this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin

Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  For your hypothetical geometric application, I'd rather have someone who understood geometry than someone who could argue obscure C++ syntax standards issues.  I've hired people who weren't well-educated in the language I expected them to program in.  I've BEEN hired to program in a language I wasn't well educated in.  And surely there is a big difference between some who you expect to write embedded C++ code while carefully avoiding "expensive" C++ features and unimplemented libraries, vs someone you expect to write "standard windows L&F C++ using the XYZ GUI library."

Agree with this.

The place I ended up with didn't do the online test like the others did. Pretty much they asked me for sample code and flew me there for an interview, got some problem solving generic questions, some C++ proficiency quick questions and that was it.

The problem solving is what got me the job. The C++ proficiency is what closed the deal.

Edit: but I'm oversimplifying, there was more to it than just that, and the combination of all of it is probably what got me the job.

[AG6QR]

this question very clearly separated out candidates into two distinct groups.  Those who thought it was trivial [...], and those who didn't have a clue where to begin

Questions that make THAT division are pretty easy to create, although you should perhaps avoid cliches ("binary search") that could be specifically studied before the interview.

But is it possible to do significantly BETTER than that with an interview question?  To divide the people who know C++ into those who REALLY know their C++ from the people who know Python and Perl but took a quick glance through a C++ book.  Or does it really matter?  ....

Agree with all you said.  And I think it certainly IS possible to probe into how well a person knows the nuances of the language, if you consider that important.  In the context I was talking about, as you suggest, that's not what I was looking for.  For my context, knowledge of the application area is far more important than knowledge of the language subtleties. 

The right algorithm, implemented in a straightforward and not-super-smart way, usually outperforms a brilliantly slick and clever implementation of a less-than-optimal algorithm.  And it's probably easier to maintain, too.


But sometimes you want a brilliantly slick and clever implementation of the right algorithm.  I can imagine that, if you're working in an embedded system under tight memory constraints, you might want to hire someone who is aware of how to get the most out of the compiler and processor under those circumstances.  Another reason to hire someone who really knows the language inside-out is if you're hiring someone to write a compiler.

It all depends on what the employer is looking for.  Which is why it's hard to give good specific interview preparation advice, other than to know your potential employer well, and know the things your resume says you know.

[Galaxyrise]

Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

The first that came to mind is the one that's "fixed" in C++ 0x11, but then I'm not sure that qualifies as a "semantic" change.  Then I can think of one that's precedence-based.

[Galaxyrise]

Can the numerical value of a pointer change after an assignment?

I don't understand this phrasing.

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

If so, why?

I thought this was cute!  I'm not sure if it's a good face-to-face interview question; if the candidate doesn't get it immediately then I'm not sure there's a lot to talk about and you risk the stress of the situation shutting them down.

I got the answer you're looking for almost instantly.  But later I realized that the code snippet above can be explained by a second, very different (and fairly C++) answer.  Very nice  

You're debugging some code, and you notice that an array of yours gets partially trashed after stepping through some trivial code that shouldn't or can't effect that array.

What might be happening?  Describe how you'd continue to isolate the problem.

  I second this one.  I love discussing debugging during an interview, especially for more senior people

[JuiceKing]

It's been a while since I interviewed C++ software engineers. A great question back when I did was, "What do you think of the C++ ampersand operator?"

Possible answers:

1. I don't know
2. Um, it's great?
3. It sucks

We liked #3 because it showed that we were interviewing someone with real team programming experience.

[westfw]

"What do you think of the C++ ampersand operator?"

Possible answers:

I'd hope for "Which one?", I think.  Binary "&" and "&&" should be fine, right?   Unary "address of" is just like C, and doesn't seem too awful.  But the whole "passed-by-reference argument" makes me really nervous (do you still consider that an "operator"?)  I mean: I actually managed to redefine 0, once, in a fortran program...

[andyturk]

It's been a while since I interviewed C++ software engineers. A great question back when I did was, "What do you think of the C++ ampersand operator?"

Possible answers:

1. I don't know
2. Um, it's great?
3. It sucks

We liked #3 because it showed that we were interviewing someone with real team programming experience.

Um, maybe the rest of your team wasn't really comfortable with C++? ... "const T &x" is a crucial concept to master.

[Psi]

Ask them to write out any bit of code or function which they think is interesting, or maybe just something they have recently written which is fresh in their mind.
Then get them to explain how it all works.

Usually that's less stressful. As opposed to giving them a random task and asking for a function to solve it.
You want to see if they can A) write code  B) Understand it

[AndyC_772]

I'm surprised to see so many questions focusing on the syntax and semantics of the language, which is stuff which I'd have thought would be easy enough to pick up on the job as and when (and if) it becomes relevant.

If you're hiring someone to write code, presumably you're hiring them to write code that will run on a particular platform and will ultimately solve some problem. Why not ask questions that probe their understanding of the context in which their code will be running? Things like:

- Knowledge of the OS
- techniques to ensure their code 'plays nice' with other tasks, and doesn't break them
- reasons why code which works in the debugger might fail in a production build, and vice versa
etc.

[miguelvp]

so, I know how to speak and think, so maybe I could just work as a German translator, well I'm fluent in 3 languages  other than German, and I can think in either. Actually i dream in all of them and my wife freaks out when I speak in tongues! 

So I should get a job because I will learn German while at the job, right?

Nah, you gotta know the language they work with. Being bright is a plus but unless the job is for an internship, there is no way I'll hire you.

You gotta know the actual programming language the job is for. I don't mind if we have to train you on our ways of doing things (toolchains etc) but you better know the programming language you are going to work with. Actually you better have a good grasp on concurrency and asynchronous processing.

And you better keep up with changes in programming. Think of it as you never left college.

[zapta]

Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

The first that came to mind is the one that's "fixed" in C++ 0x11, but then I'm not sure that qualifies as a "semantic" change.  Then I can think of one that's precedence-based.

The answer I know is

#define A(x)
  vs
#define A (x)

The first defines a macro with one argument that is expanded to nothing. The second defines a zero argument macro that is expanded to '(x)'.

(Not recommended as interview question, it's too much of an aah-moment question).

[amyk]

Here you have an UML diagram.
Give the classes.h file.

Of the UML diagram of class A, write the constructor and destructor.

Did you miss the "not" in the title?

Not an interview question but a quiz. A C/C++ program has two adjacent lexical tokens (on the same line). Inserting a space character between them changes the semantic of the program. How come?

Greedy parsing? Here's an example:

Code: [Select]

x = a+++b; /* parsed as a++ + b, i.e. a is incremented */
x = a+ ++b; /* parsed as a+ ++b, i.e. b is incremented */

[JuiceKing]

"What do you think of the C++ ampersand operator?"

Possible answers:

I'd hope for "Which one?", I think.  Binary "&" and "&&" should be fine, right?   Unary "address of" is just like C, and doesn't seem too awful.  But the whole "passed-by-reference argument" makes me really nervous (do you still consider that an "operator"?)  I mean: I actually managed to redefine 0, once, in a fortran program...

As you guessed, I mean the "passed-by-reference argument." In C, you could be certain that a called function would leave your local variables alone, unless you passed pointers to them. In C++, you never really know.

[JuiceKing]

It's been a while since I interviewed C++ software engineers. A great question back when I did was, "What do you think of the C++ ampersand operator?"

Possible answers:

1. I don't know
2. Um, it's great?
3. It sucks

We liked #3 because it showed that we were interviewing someone with real team programming experience.

Um, maybe the rest of your team wasn't really comfortable with C++? ... "const T &x" is a crucial concept to master.

That depends on best practices of the writer of the called function, doesn't it? I like being about to step over a function in a debugger and not having to worry about local variables being messed up.

[andyturk]

In C, you could be certain that a called function would leave your local variables alone, unless you passed pointers to them. In C++, you never really know.

On the flip side, C++ lets you return useful data in an "output" argument, and a boolean from the call itself to say whether the call succeeded. In C, you usually return a possibly-NULL pointer which you have to check.

Another great thing about references (aka the ampersand operator) is that they can't be NULL--at least not without having to fool the compiler explicitly. So if you write a C++ API that passes something by reference, that's effectively saying you *must* have an actual data object, and thus you never even have to check the argument for NULL.

[AndyC_772]

I absolutely agree, the language itself is a means to an end. It's an important tool, for sure, but focusing on the language itself ignores the much more important fact that the software is a part of a wider system.

It's the software engineer's role to make that system live and breathe, and that means the most important skill the engineer can have is the ability to understand how the system works. That's not something that can be googled as necessary, or copied from existing code fragments.

[free_electron]

Best question: Who created C++
Best answer:  Barney Shoestrap.

bjarne hoestsiroop (in dutch). hoestsiroop = cough syrup ..

[madshaman]

Best question: Who created C++
Best answer:  Barney Shoestrap.

bjarne hoestsiroop (in dutch). hoestsiroop = cough syrup ..

lolololol

[vvanders]

I would never hire the best C++ programmer not even for a C++ job. I would hire a very good programmer with good C++ skills. C++ is the best proof of thousands of way to kill evolution. I am programming C++ since it came into being. It's limitation caused libraries with tons of megabyte of code, because of the absurd C++ philosophy. Stroustrap himself is a bad evangelist who was good only in succeeding.  Electronics evolved thousands of times more in all this time. Electronics engineers seem to have more imagination and creativity as their imagination and creativity is stimulated versus the creativity and imagination of C++ programmers that is just killed. I discovered some love for mcu-s, but I had to acknowledge that C++ arrived here as well. That is not yet as bad... But when the bloat will arrive... I am telling you the bloat will arrive but mcu's will not do much more  

So C++ interview question tips: distribute your questions: 2% C++ (this means no question ) the rest of the 98 percent equially distributed to see how smart the guy is and how creative he is. A hyper intelligent guy will learn for you C++ in two weeks! An idiot C++ programmer will never ever be able to cut a potato in two equal pieces     

That's being a bit harsh on the language, the best C++ programmers know when to avoid features or omit them entirely. I very much doubt that someone could learn C++ in two weeks, there's quite a few concepts like templates, value type semantics, placement new, deterministic destruction and many others that take a while to understand in C++.

Yes the language is complex but that allows for a much greater expression and control. And as always, using the right language for the job. I regularly switch between Python, Javascript, C#, C++ and Java depending on the task, domain space and technical requirements.

This is a great talk that covers why C++ is still relevant today and where it should fit into your toolbox(also some great performance stuff that most CS people aren't aware of):
http://channel9.msdn.com/Events/Build/2014/2-661

As for EE vs SE, I won't even go there

[AndyC_772]

This is why I'd choose to concentrate on how well the candidate understands concepts and systems, rather than syntax and semantics. If a newly hired engineer spends a few months learning more efficient, elegant, or just plain fashionable ways to write code, then that's OK.

If, however, that time is spent writing code which contains race conditions, poorly handled interrupts and buffers which are liable to overflow, then that's a problem.

[grumpydoc]

One question I've used where people claim to have good C++ (or C) skills is "tell me what you do not like about C++, or how it could be improved".

[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.

The programmer doesn't have to become a C++ geek either, a handy assortment of references will suffice until some things are committed to memory.

It's not black and white because some programmers, especially those without low-level experience or experience in many types of languages, might have a much longer learning curve and can't possibly hit the ground running.

Candidates run the gamut from those with a Master's degree who can't do anything useful other than get good marks to high-school drop-outs who can run circles around the former.

This thread seems to be turning into "how to hire good coders", and I'd say the best way is to get your best coder(s) to interview the final cut in person.  Anyone worth their salt, whatever methods they use can easily determine someone's skill.

[linux-works]

Asking someone to write pseudocode in an interview is not ideal but okay I suppose. You have to keep in mind that some people are not good at jumping into new things quickly during a short interview, but perfectly competent programmers. Not everyone works the same way.

Interviews are overrated anyway. You just have to accept that you won't really know how good somoene is until they have been working for you for a few weeks, which is what the probation period is for.

bingo!

this is a hot button for me.  I've been writing software since I was in my early teens and I'm early 50's now.  I have decades of programming under my belt and I've written probably over a million lines of code by now.

yet, I fail horribly when asked to 'perform, live' in an interview.  I just cannot do it well!  and few employers seem to understand that; and almost no engineers I meet during the interviews understand it, either.

I think some of it is age.  when I was in my 20's, I could code 'in front of people' just fine, but now, I'm not wired that way (lol) and find it difficult to write code on a board or even on paper, while under the magnifying glass.  its also not my style anymore, I will usually consult online examples, grab some code, modify it and adapt it.  we used to use books for ref, but now we use online examples and I feel almost naked without being online and having a real text editor (not paper or whiteboard) to do the program entry.

my programming skills are more than enough to get the job done, and my resume should prove that to employers, but time and time again, they insist on these stupid coding tests and they put all their faith into it.

its rare to find a company that cuts thru that BS and its refreshing to run into them, when I do.  maybe 1 out of 50 don't do the stupid tests.  maybe even 1 out of 100, these days.  its really a tiny minority.

it also cracks me up with I interview with people very much younger than me.  more times than I can remember, the person at the other end of the table has been alive less time than I've had work experience, and yet they're passing judgement over me based  on 15 minutes of 'stand up' coding on a whiteboard.

the whole thing is farked up.  not everyone works that way.  I don't.  and yet, companies won't change the way they interview.  they don't hire folks like me and they are missing out on good people, to be sure.

[linux-works]

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....

[madshaman]

the whole thing is farked up.  not everyone works that way.  I don't.  and yet, companies won't change the way they interview.  they don't hire folks like me and they are missing out on good people, to be sure.

So, start your own software company, then your success will be directly related to how good you are.  You can eventually hire the good people these other companies are passing up.

You can't expect a company to change itself for you.  Behind that company are investors and founders who did what was required to form a company that generates enough money to be able to give people like yourself a stable and predictable income; they've actually earned the right to run themselves however they see fit.

You have a better way, so do the same thing the founders of those companies did (including taking on all the risk and hard work it takes to do that) and then your company can have whatever hiring policies you choose.

[linux-works]

starting a company usually ends in failure, given the stats.  I can't afford that right now.  few people can.

the rest of what you posted is neither here nor there.  companies need programmers but they are going about it all wrong and the state of software quality in the industry is PROOF that they are doing it all wrong.

been there, seen 'production' code by so-called wiz kids and its total BS.

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.

the only way to be sure is to try someone out.  in the US, the new culture is to hire 'contractors' for trying them out and then make them 'perm' 3/6/12 months later if it works out.  you don't need to spend a lot of time testing contractors during an interview; the JOB is the test and it will be obvious in short time if they can do the work or not.  and you'll see them in real world conditions, not synthetic ones.

[madshaman]

starting a company usually ends in failure, given the stats.  I can't afford that right now.  few people can.

Well then lucky for you *others* took that risk and made sacrifices so that they can provide *you* with a nice stable job, group benefits etc.

As far as "I can't afford that", bullshit, and I'm calling you on it; there are a number of billionaires, who started with much less than you, who would disagree with you there.

You're an SE, what is your overhead?  A computer?

Have you tried?  If you did, didn't you learn anything so the next time you'll have a better chance?

Honestly, I think it's easier to say "it's not possible because: a, b, c, d, e...." than risk failure.

I'm being pretty critical of you, but it's not to derogate you.  I could be wrong but I'm worried you're learning to be helpless, it doesn't sound from your experience like you are helpless.

the rest of what you posted is neither here nor there.  companies need programmers but they are going about it all wrong and the state of software quality in the industry is PROOF that they are doing it all wrong.

I respect your opinion, but if they're "doing it all wrong" and there's proof, isn't that an opportunity?  I'd be very pleased if someone came to me and said "you're doing it all wrong, I can show you how to do it right" and was able to deliver; I'd probably give them money to keep making me more money.

If you think you're right (and I'm positive your opinions aren't 100% groundless), then prove it; I'll be first in line to support you and sing your praises.

[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.

[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...

[SirNick]

Valgrind helps quite a bit with that.

[grumpydoc]

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...

That's more a Windows thing than a C++ thing.

TBH I'm more of a Unix guy but have done my fair share of Windows development.

This can also lead to problems when something which should be a singleton actually has multiple copies (one per DLL)

I recall one morning chasing down an STL bug on a Windows box - a STL r-b tree traversal was crashing. Turns out the the implementation used an "empty" node to cap unused branches in the tree. Fine but it compared the address of the node with its "empty node" and ran off the ends when the comparison failed. The problem was that the tree had been allocated in one DLL and was being traversed in another. 

[ejeffrey]

No. You can't realistically appraise someone's coding ability in a short interview. You even admit it in the third sentence where you point out that without the usual tools there are some major limitations. Programming is as much about using the tools as it is about just churning out code.

No, programing is *not* about using tools.  Tools are great, they increase our productivity, manage complexity, and do simple jobs for us, but they aren't what programming is about, and they don't make you a good or bad programmer (unless you refuse to use them).

If you need an IDE and the online help to write a simple routine of 10-20 lines with clear specifications you are never going to make it to the hard stuff.  It is like if you ask a basketball player to walk down the court and dribble and they have to constantly look at the ball.  It isn't that you want them to play blindfolded, but if they don't just *know* where the ball is like they know how to breathe, they can't possibly handle the stress of a real game.  Likewise, if I ask a programmer to write a simple routine like a binary search or finding the longest substring that is in alphabetical order I expect them to write down the answer basically as fast as they can write.  If they stand there for two minutes holding the marker and make two false starts, then they aren't going to be able to solve real problems.

You need to stop trying to rely on the interview alone to evaluate the candidate, because the interview is inadequate.

I never said or even suggested that.

[SirNick]

Hehe.. This makes me glad I'm not looking for a programming job.  I wrote a couple hundred lines of code on a pet project today.  Once, I saved my changes to a few files (I use the Kate text editor, not an IDE), ran my Makefile, and it compiled without any syntax errors on the first try.  I was shocked!  That... like.. never happens.

Then I realized there was an error in my Makefile.  I had changed the name of a target file, so it hadn't rebuilt all the libraries.  Fixed the Makefile, and then got a few lines of cranky syntax errors.  Ah.  All is right with the world.

So yeah.  Glad no one sees my work before I get a chance to close all the braces, add the semicolons, name the typedef'd structs, add the parameter name after the data type in the function definitions...     (Yeah, I know, there's a difference between typos and not knowing how to write code.  But I still fear the day when a potential employer stares at a whiteboarded code snippet and asks, "so... did you mean to return a char array from sprintf?")

[linux-works]

bottom line: as good as you think you are (as an interviewer) you will miss a large portion of people with your petty 'tests' and come to more wrong conclusions than right ones.

interviewing is an art and you either have people skills to detect 'ability' or you do not.

tests are useless.  but go on thinking they are useful.  if you only have 1 tool in your shed, I guess that's the one you'll always use.

I'm just glad that I occasionally run into interviewers who can look way beyond this test BS and get a feeling for the person and their skill set.  it happens maybe 1 out of 20 interviews but it does happen and those are the jobs that I often accept or want to accept.  the ones with 'tests' are usually the 2nd choice companies with a more 'do what you're told!' kind of culture.  blech!

go on believing you can know about a candidate's ability from some syntax on a white board or paper.  but you're wrong more often than you're right.  its a lousy way to evaluate a creative person and not everyone works or thinks the same way or even at the same speed.  faster does NOT mean better, btw!

[ejeffrey]

tests are useless.  but go on thinking they are useful.  if you only have 1 tool in your shed, I guess that's the one you'll always use.

I didn't say that, either, and you are the person advocating restricting what you consider.  Obviously I also believe you need to find out how someone interacts with people, and how they talk about their accomplishments.

go on believing you can know about a candidate's ability from some syntax on a white board or paper.  but you're wrong more often than you're right.

I am glad you magically know that out of thin air.

its a lousy way to evaluate a creative person and not everyone works or thinks the same way or even at the same speed.  faster does NOT mean better, btw!

Creativity is an extremely valuable talent, but it is not a replacement for fundamentals.  I want to hire people who are creative, but also who are going to be successful at harnessing that creativity productively.  People who can do that are people who can do the mechanical aspects of their job "in their sleep" and save their time and energy for the hard stuff.  At the end of the day you have to produce a product, not just an idea.  You sound like someone who has no interest in actually accomplishing anything.  Also, faster is better than slower.  Speed isn't everything, but it is important.  Real projects have deadlines and requirements and consequences.  If deadlines slip and requirements aren't met, projects get canceled or you get beaten to market.  I don't know what fraction of new software projects (or any engineering project) never ship, but I know it is a lot.

[miguelvp]

I don't know what fraction of new software projects (or any engineering project) never ship, but I know it is a lot.

Funny thing, I shipped every project I worked on and always on time, and surely that goes proudly on my CV.

Another thing to ask is about their "crunch time" experience, myself I go home and sleep at least 8 hours, I mean I will put extra time but not to the point of exhaustion like some people do. To me it's kind of a red flag, and the only reason I stay late is because of support to the team or taking other people's tasks because their plates are too full.

Granted, you might need to put extra time at the end of the project because other people were blocking your progress, but it's your fault that it got that way. I don't wanna hear how you pretty much lived at the office for the last month of a project because your tasks were not done in time. I do expect that from a lazy teen in high school and also college, but not professionally.

And I know, sometimes deadlines are not within the scope of reality, but then it's not crunch time, it's non stop for the whole project's length.

[John Coloccia]

Creativity is an extremely valuable talent, but it is not a replacement for fundamentals.

Exactly.  I was pretty well known for my creativity and problem solving, not just for software but also for mechanical widgets, interface design, etc.  I would have been pretty worthless if I wasn't also a damn fine engineer that could actually pull off the whacky ideas I came up with.

I think a lot of interviewers ask some pretty dumb questions, but I can truthfully say I've never feared going into an interview and being asked technical questions.  Whatever...I chew them up and spit them out.  That's part of being a pro, under pressure or not.  What are you going to do when the manager of some fab in Taiwan is screaming at you over a video conference because they're loosing $20,000 every minute they're down and it's YOUR machine that's holding everything up.  Or when it's 3:00 in the morning, and you have Air Force chief head mucky mucks, program managers, and government suits screaming at you because the very expensive flight test they just finished has NO DATA and was a complete waste of time because your stupid data recorder screwed up?

Keeping a cool head under pressure is really just part of being a pro.  Admitting when you're unsure of something, or when you're a little flustered and you need a minute to collect your thoughts, is part of being a pro too.  Bullshitting and guessing is amateur hour behavior.

[John Coloccia]

Yeah, I don't think anyone is expecting perfect syntax or something that's completely bug free.  Sometimes you have doubts that someone knows how to program at all, and you just want to see that they have at least a reasonable working knowledge.  This is more the case with new grads.  Some are rock stars, and others just really don't know what they're doing and it's obvious, but you still want to give them a chance to prove you wrong instead of just dismissing them.

[ehsmeng]

I'd try some irl examples. like, "do make this class thread safe"

The expected outcome would be something like in the POSA2 book (pattern oriented software architecture) that you have a mutex in the object and in the interface functions you have a Guard class

void Example_class::fun(int apa) {
    Guard<Thread_Mutex>guard(monitor_lock_);
    ....
}

Guard destructor is called regardless of where you get out of fun() and regardless of if it's return or an exception. So it's totally safe. If applicant has habits like this, nice code will be produced.

[linux-works]

sigh.  I just don't agree that testing is at all valid.  I've seen 'stars' ease thru interviews but can't do real world coding to save their lives.  they wrote 'school style code' which is meant to show off or impress but is hard as hell to support.  hate hate HATE when kids try to show off how much of a language they know and try to use all obscure features.

I've seen people freeze up during interviews but knew they could have handled the job.

the correlation is as random as it can be.  so I don't even care about giving anyone a coding test.  I'll talk to them and that's a far better judge of their logical thinking ability than spitting out algorithms they memorized or language syntax.

I just don't see the correlation.  a lot of people are GREAT at memorizing the classic problems and they ease thru interviews.  but... SO WHAT?  does not prove a damned thing in the real world.

[jpb]

I've seen 'stars' ease thru interviews but can't do real world coding to save their lives.  they wrote 'school style code' which is meant to show off or impress but is hard as hell to support.  hate hate HATE when kids try to show off how much of a language they know and try to use all obscure features.

Without entering the debate on interview questions, I agree that the best code is simple code - far less likely to introduce bugs and far easier to maintain. It also is far easier to move to different platforms and if you switch compilers you should get the same results.

Even from the speed point of view, modern compilers can optimise very well and so there is no reason to try and speed things up by writing complicated code.

I like the story of the Pope looking for an artist in the 13th/14th Century and having them submit examples of their work. The artist Giotto simply drew a perfect circle free hand and he got the commission.

http://100swallows.wordpress.com/2007/09/14/giottos-o/

[linux-works]

some people do well on 'tests' and some do not.  if you use on the spot coding tests as any kind of serious evaluation of programming ability, you will be wrong as many times as you are right.

a lot of people can cram for an exam and fool people into thinking they know more than they really do.

and those that freeze up on stressful tests may know more than the interviewer, in fact, but are just not good at psych pressure tests.

correlation is all over the place.  therefore, I, personally, will never give a single line of coding test to anyone coming in for a programming job.  I'll talk to him, see how he thinks, see what things he was proud of, what he would have redone some other way - stuff like that.  I find it more telling to engage in chat than to put the pressure cooker thing on anyone.

I suck at interviews when there is a test; yet I've been writing code nearly all my life (I'm in early 50's) and I know I can do any coding job given me.  NOT IN 15 MINUTES - but if I'm allowed to go to my desk, use resources that we normally have during the day, yes, I can solve nearly any problems that is expected for the job I would be applying for.

just trying to warn people that you will reject a lot of good guys by this highly synthetic pressure-based test system that so many people just default to, for some reason.  honestly, I think its easier on interviewers and so they take the easy way out.  odd, since they put the candidate on the spot and yet they laze out with scripted programming questions from comp sci 101.

[retrolefty]

  Interviewing job applicants is more an art then a skill set. While never interviewing programmers I did interview lots of electronic techs applicants at a oil refinery I worked at, both individually and as part of team interviews.

 The best method we came up with after several years was just ask a series of maybe 8 very open ended questions that forced the the applicant to show his thought process, work experiances, as well as the accuracy of his answers. Give the interview a decent period to talk and he/she will tell you why you should or should not hire him/her.

 The last effort we had to interview 30 applicants for 12 positions in a 5 day period, and that was after the HR department had narrowed down 700 applicants down to 70 resumes that they passed on to us, of which we selected 30 for the interview, we could only allocate one hour per interview. It was quite an effort but very rewarding in that after five years all but 4 hired had been promoted to front line maintenance supervisor positions and only one left the company.

 So spend a lot of time working out your open ended questions, and ask all the applicants the same questions. Make sure the question can't be answered with a simple yes or no or answered in less then 5 mins. Make them have to ask questions back to better answer the question, as that too reflects on their thought process.

[linux-works]

agreed with lefty

conversation is all that is needed.  and, the interviewers MUST be senior.  please, folks, do NOT send your 20somethings to interview candidates in who are twice their age.  its insulting, the young kids have no idea what the hell to ask and it rarely works out when you do it that way.

it sounds ageist: but its really how it works out; the younger ones try to show off and 'beat the older guy' for some kind of sadistic pleasure.  otoh, when I run into people more my own age, they always ask reasonable questions, don't immediately put you down as 'no ability' if you stutter on one question and you can see there is mutual respect going both ways, which really puts the candidate at ease and lets him be more like his real self.

I never forgot this one interview I had at a storage company.  the girl was in her early 20's.  she kept paging thru my resume saying 'wow, you were there?  and there too?  wow, you've been at a lot of places!'.  finally, she came right out and said 'gee, mister, you've been working longer than I've been alive.'

she actually said that.

and yet, this is a person who is passing judgement on me.

fwiw, I never got that job.  everyone was a 20something and they clearly didn't want any old greyhairs in the group.  can't have that!  it would ruin the party atmosphere!

(sigh...)

contrast that to my last interview: 4 phone screens, nothing really threatening or scary, all conversational, all reasonable.  I got the job.  never even went on-site (even though its local to me) but was still offered the job.  no coding tests, just some questions about the field I'm in.  I loved that experience and interestingly enough, almost everyone in my group is a grey-hair

[jlmoon]

Creativity is an extremely valuable talent, but it is not a replacement for fundamentals.

Exactly.  I was pretty well known for my creativity and problem solving, not just for software but also for mechanical widgets, interface design, etc.  I would have been pretty worthless if I wasn't also a damn fine engineer that could actually pull off the whacky ideas I came up with.

I think a lot of interviewers ask some pretty dumb questions, but I can truthfully say I've never feared going into an interview and being asked technical questions.  Whatever...I chew them up and spit them out.  That's part of being a pro, under pressure or not.  What are you going to do when the manager of some fab in Taiwan is screaming at you over a video conference because they're loosing $20,000 every minute they're down and it's YOUR machine that's holding everything up.  Or when it's 3:00 in the morning, and you have Air Force chief head mucky mucks, program managers, and government suits screaming at you because the very expensive flight test they just finished has NO DATA and was a complete waste of time because your stupid data recorder screwed up?

Keeping a cool head under pressure is really just part of being a pro.  Admitting when you're unsure of something, or when you're a little flustered and you need a minute to collect your thoughts, is part of being a pro too.  Bullshitting and guessing is amateur hour behavior.

So how about if we throw a little "Common Sense" into the equation as well? 
Creativity, Fundamental Understanding and Common Sense are what really make things happen in a good way!

JLM

[westfw]

the interviewers MUST be senior.  please, folks, do NOT send your 20somethings to interview candidates in who are twice their age.  its insulting...

Sorry, but I think you're off-base here.  The people who interview you need to be the people that you're going to work with and for.  If they're half your age, well - that's they way it is and the way it's going to be if you get hired.  And at a modern startup, the 20-something might be the star engineers...

the younger ones try to show off and 'beat the older guy' for some kind of sadistic pleasure.

Which is entirely different than the older interviewer doing the same thing to young interviewees?
(I guess this is a key point.  An interview should not be a contest; it's more like a date...  Questions need to toe the line between extracting data and intimidation.  Although I suspect the line blurs if it IS a contest between 50 candidates...)

'gee, mister, you've been working longer than I've been alive.'
she actually said that.
and yet, this is a person who is passing judgement on me.

So?  Sounds respectful enough, and perhaps she's the one that will have to work with you.  I remember I was a 20-something and interviewed <HW engineer> in the early days of <since-successful startup>; basically all the engineers at the time interviewed all engineering candidates.  This guy had retired and spent a few years as a piano tuner before reentering the industry, back before I got out of HS!  I don't think we HAD anyone who was much more than half his age.  It made for an interesting interview.  (and we hired him, and he went on to design <important and successful product>) (AND he fit in pretty well with the younger online-focused group that was there.)

[vvanders]

agreed with lefty

conversation is all that is needed.  and, the interviewers MUST be senior.  please, folks, do NOT send your 20somethings to interview candidates in who are twice their age.  its insulting, the young kids have no idea what the hell to ask and it rarely works out when you do it that way.

it sounds ageist: but its really how it works out; the younger ones try to show off and 'beat the older guy' for some kind of sadistic pleasure.  otoh, when I run into people more my own age, they always ask reasonable questions, don't immediately put you down as 'no ability' if you stutter on one question and you can see there is mutual respect going both ways, which really puts the candidate at ease and lets him be more like his real self.

I never forgot this one interview I had at a storage company.  the girl was in her early 20's.  she kept paging thru my resume saying 'wow, you were there?  and there too?  wow, you've been at a lot of places!'.  finally, she came right out and said 'gee, mister, you've been working longer than I've been alive.'

she actually said that.

and yet, this is a person who is passing judgement on me.

fwiw, I never got that job.  everyone was a 20something and they clearly didn't want any old greyhairs in the group.  can't have that!  it would ruin the party atmosphere!

(sigh...)

contrast that to my last interview: 4 phone screens, nothing really threatening or scary, all conversational, all reasonable.  I got the job.  never even went on-site (even though its local to me) but was still offered the job.  no coding tests, just some questions about the field I'm in.  I loved that experience and interestingly enough, almost everyone in my group is a grey-hair

Westfw covered it pretty well but an attitude like that is extremely counter-productive and will only hurt your career.

While we have a bunch of senior people, some with decades of experience a good 50% of our developers are in their 20s. Many of them interview candidates and give a fair assessment that's in line with our senior developers. We make sure that they follow good practices and shadow experienced interviewers to understand the correct techniques.

In my 20s I was regularly stack ranked at the top of my peers, don't mistake age for years of experience. Some of us got started in software development very early and took non-traditional paths(I.E. skipped college).

We don't have tricks in our interviews or play 'beat the older guy'. We look for a solid understanding of CS fundaments, excellent problem solving skills, interpersonal communication and a grasp of common problems and solutions. Age does not discriminate on those factors and I think it's a great disservice to have a bias for either the age of the interviewer or interviewee.

[andyturk]

[...] fwiw, I never got that job.  everyone was a 20something and they clearly didn't want any old greyhairs in the group.  can't have that!  it would ruin the party atmosphere!

Well, maybe the right thing happened. It's nice to get offers and all, but working with people who don't "click" is no fun, and not so productive in an engineering environment. Plenty of other fish in the sea.