Damn, I ballparked a 7 on both occasions. I guess that just makes me a gentleman's average.
7 is in my opinion the best answer ever. It would at least hook me up to test your skill, and if you proved it in impressive way, I would be luckiest guy to hire you to serve me :)
Anything over an 8 means one of two things. They've either written a solid, production ready compiler frontend and runtime support library, or they're a 4. 7-8 from someone with a background that matches means "I've seen horrible things, and know how to avoid/diagnose them, but there are still fell and terrible things lurking in the dark corners of the earth".
An approach we used from time to time, at least for people that claim to be Really Good and Technical with it, is to just have them start drawing out the memory layout of an instance of a class object, working up from the trivial case, through to the virtual diamond one, and see where the floundering starts. Bonus points for knowing how dynamic_cast and rtti work (and a slight bit of walking through the process usually serves as a good reminder of why they aren't exactly free).
Anything over an 8 means one of two things. They've either written a solid, production ready compiler frontend and runtime support library, or they're a 4. 7-8 from someone with a background that matches means "I've seen horrible things, and know how to avoid/diagnose them, but there are still fell and terrible things lurking in the dark corners of the earth".
An approach we used from time to time, at least for people that claim to be Really Good and Technical with it, is to just have them start drawing out the memory layout of an instance of a class object, working up from the trivial case, through to the virtual diamond one, and see where the floundering starts. Bonus points for knowing how dynamic_cast and rtti work (and a slight bit of walking through the process usually serves as a good reminder of why they aren't exactly free).
So, what do you do with someone like me that has been avoiding diamond patterns for so long that I refuse to acknowledge their existence? :)
Assuming it's for a deep magic code ninja type position, ask why, and likely be satisfied with a coherent answer. If it's not a position that involves staring at hex dumps for bugs, it probably doesn't even come up... unless someone claims they have a better grasp of C++ than Stroustrup or Sutter.
Or, on bad days, be very relieved, as it means I don't have to dig that bit of the standard out of cold storage.
I once had someone say that his old boss told him to never say 8 and so he's only a 7.
I interpreted that as meaning that he thought he was an 8 but didn't have the brass to say it, so I just asked him the "9" level questions (e.g. the "can you write a reasonably conforming compiler" questions) just to watch him squirm a bit, but quickly found out he didn't even qualify as a "3".
Overall, the question is stupid anyway, though, and I've since developed an interview style that avoids that kind of vague nonsense. Especially because the only people who'd ever answer with 6+ are the people too junior to realize just how little they actually know about a language with a 1,400 page dense specification (that's only getting bigger over time as we add more language facilities and more standard library features).
Overall, the question is stupid anyway, though, and I've since developed an interview style that avoids that kind of vague nonsense. Especially because the only people who'd ever answer with 6+ are the people too junior to realize just how little they actually know about a language with a 1,400 page dense specification (that's only getting bigger over time as we add more language facilities and more standard library features).
That's the sort of thing that makes the question so ridiculous to me. I answered a "7", not because I thought I was knowledgeable enough to write even a reasonably non-conforming compiler, but because a "5 average" is a skill level of "really pretty terrible" in comparison. It feels like the sort of question that really depends on where you fit your scale.
By itself, I agree that it is a poor question. Self assessments are usually flawed. Dunning-Kruger Effect (and their later research) shows that most people will rate themselves in the 75% quarter. The lowest 25% rate themselves above average, not knowing of their incompetence. The highest quarter know they don't know that much, so they lower their score. Those in the middle generally know they're in the middle, those slightly above the middle know they are there also. So you get about 1/4 saying they are at 50% skill, and about 3/4 saying they at 75% skill, and a small number saying they are low-skilled or highest-skilled.
If it were followed up with "why?" it becomes a far more interesting question.
If it were followed up with "why?" it becomes a far more interesting question.
I'll buy that, but counter that you can ask even more interesting questions in the same time span. e.g., if you ask detailed questions about say graphics architecture and they can answer competently then (a) you know that they know how to write code at a useful competence level, enough to have learned intricacies of graphics and (b) that they know graphics architecture. You get more useful information in a similar time span, and like all things in life, interviews' primary limited resource is time. :)
Programming language trivia isn't that interesting. If someone has the domain knowledge you need and also has an understanding of programming and hardware fundamentals, the fact that they learned all that via years of C# instead of C++ is pretty much irrelevant. They'll be able to learn the syntactical idiosyncracies of C++ far faster than they'll be able to learn how to write graphics architecture or optimize for target hardware.
Some of the best programmers in our office are only average C++ programmers. Likewise, I often feel the need to beat the C++ out of some of our engineers who know the language far better than they know how to structure maintainable efficient code. I find that the cost of misusing an advanced language feature when unneeded (in C++, Python, you name it) to be far higher than the cost of _not_ using appropriate features. Which again, comes back to finding out if your candidate is a good programmer, not whether they know C++ inside out.
Concentrate on what they know how to do, not how they learned to do it.
I'm not perfect at this and still need to evolve my interviewing technique, but that evolution is moving towards less language lawyering and more substantive questions that I couldn't just get out of a code test.
Self assessments are usually flawed.
It's far worse than that. The person asking the question has overwhelmingly subjective expectations for the answer as well.
The reason that it's an outright stupid question though, is because you're trying to measure two interdependent variables with a single query. It's like asking someone, "Using a ruler with arbitrary-length units, what is the length of my desk across an arbitrarily selected axis?" and then expecting to hear a result within your own arbitrarily predetermined range.
less language lawyering and more substantive questions that I couldn't just get out of a code test.
A well thought out code test could create a basis for conversation that could uncover the programmer's reasoning, I think. The "why" is certainly a much better goal, but if someone can't fizzbuzz (bad example) then there's not really a reason to ask.
Some companies do this in order to match interviewer skillsets to candidate ones. But they do supply a calibration for the numbers; in one case 9 is something like "I wrote the book" with a note that there should be an actual book. And there are points like "I write code in it, but need a book handy".
I used to be a reasonably decent C++ dev (my rating is falling these days[1] because everyone wants me to write Python instead -- and at the new gig I've learned WAY more PHP than I ever wanted to) so I used to get assigned to interview people who rated themselves an 8 at it.
Now, my C++ interviews weren't THAT hard and almost none if the high-self-rankers passed them. I tended to ask things like "Write a template for a tree structure which'll store stuff at the leaves" with the rest of the spec being part of the conversation. But people couldn't write the basic bits of templates.
All that the trivia questions tell me is that people can memorise Stack Overflow; not whether they can connect stuff together to build useful things.
Eventually I turned my self-rating on the matching systems down to a 4 so I could stop doing such depressing interviews. I did the same for "UNIX internals" after spending horrible hours trying to interview UNIX experts who couldn't tell me what a file descriptor is or how they work.
Part of the problem is that people think these ratings are part of the assessment for being hired so they inflate them whereas they're supposed to be part of tuning the interviews to work well. All that the over-bigging achieves is to burn a valuable interview slot getting a low score against expectation and it only takes a couple of low scores before you're gone.
[1] I've written no commercial code in 11 for instance, although I still hobby-write code.
