The fact that there are more than 0 interviewers who think there is a difference is sad, because I think this makes a great question to separate out those who understand C and those who don't - it's even easier than FizzBuzz for the first group, and much harder for the second.
Anecdote time: I once interviewed a new candidate for a Python job along with three other developers on my team. One of the people on our team who was not a part of the interview handed us all a list of Python interview questions about 30 seconds before we headed down to talk to the candidate. He said these were the "best practice" questions he just found and thought they'd be good to ask. We figured "why not?". Well, turned out the questions were pretty obscure Python stuff, that in fact none of us could answer on the spot. We did figure these out later as a group, but it certainly made me feel very unprofessional.
Since then I've stopped asking questions like this. Trick questions and logic questions I think are a bad metric. A person can be great at sudoku but be a horrible developer in terms of writing maintainable code. Instead, I tend to just talk about the macro-level stuff. "What have you built? Can I see it? How long did you maintain it? What was the trickiest part? I imagine it had performance issues; did you spend time optimizing it?" I do ask some tech questions. For example, for web developers I ask "Describe how an XHR request happens in detail." But that is as deep as typically go.
This isn't specific to comp sci. While I can't cite a specific story this many years out, I definitely recall my classmates in Physics going for their nuclear power interviews (I had already decided that wasn't for me) coming back their bragging/complaining that they had to explain the proper application of Schrodinger's equation to an interviewer.
Given the tight market for programmers, it's actually a nice way of learning about the company before you go work there, if you think about it that way.
Kind of like if you got an interviewer that responds with a blank stare if you talk about version control and says they just make copies of the directory, or something like that.
Some people there on SO are suggesting this could be a "self-confidence testing" question where the interviewer already knows what he's asking is bullshit and expects you to react accordingly. Sort of like a HR-ish kind of question.
I can't fanthom how would one come to the conclusion that there is a difference between the two otherwise.
It's also potentially a good test for how you approach correcting people, especially when you're in a subordinate position. Some people can be too forceful ("you're wrong!") quite a lot of people will let it slide ("I'll implement this terrible idea because I can't say no").
I hate this thinking (I know it is not yours, it's a hiring meme).
If an interviewer makes some crazy assertion, then I pretty much flip into the mode of "how do I get out of this interview ASAP, as there is no way I'm working with this idiot". Whereas in the office, I'm the guy that sends the really difficult mass email that calls out his boss, if it is really needed. Engineering is not interviewing, and vice versa; why would you expect identical behaviors in both?
And yup, I am self selecting out of the situation where the interviewer is not an idiot and just 'testing' me. I'm fine with that, because I'm also selecting out of a job where people aren't willing to treat me with respect.
Interviewing is largely voodoo; we shouldn't be inflicting cognitive pain on people based on our random selection process. The only measure that has ever been shown to be predictive is past performance. So let's talk about my past performance, and leave this amateur hour psychological testing in the trash bin where it belongs.
It's a psychology test, designed by non-psychologists.
Don't try something because you sit down and think "hey, I am going to create an artificial situation, and then guess at what a good candidate would do[1]." Then see if he does that.
Other nervous circumstances that are not the same as interview circumstances. For me at least, test and interview stress is of a nature and effect that I have never experienced in other circumstances in 12+ years as an engineer of various disciplines.
The type of place who needs people who can develop under that type of pressure doesn't sound like a great place to work... That type of pressure sounds a lot like cowboy coding.
TBH if you're nervous about a technical interview, maybe you don't actually have the technical level required for said job.
Or maybe that's just me; nervousity in presentations or interviews or even talking is IMHO an indication of not knowing what you're talking about. And knowledge is confidence.
I've interviewed a number of people who were incredibly confident in their language, voice and body language who clearly had no idea what they were talking about.
Similarly, I've interviewed people who clearly knew way more about the subject matter of the job than I did but who were incredibly nervous during the interview either because they were intimidated by the idea of working outside of academia, real/preceived language limitations, or because they were just incredibly shy and awkward.
I've generally tried to look for people who fit the sweet spot in-between: confident and sociable enough to be reasonably comfortable during the interview and humble enough to not be brash. The more "customer/client" facing the position, the more I care about the confident and sociable part.
Totally depends on the person. I'm shy in interviews, always have been, but I'd happily challenge anyone with my knowledge. (I'm not saying I know everything or even a lot, but I am very confident of what I do know)
Is it normal for an interviewer not to clarify that "actually, I was wrong" on these sorts of self-confidence tests?
Personally at the end of the interview (as the interviewer) I would refer back to any of those sorts of questions and say.. "actually I was trying to catch you out, you did good there", or some such.
This not only stops them doubting themselves, but also clears the air if I was to come back to them and offer them the job. Who knows, maybe the interviewee ran off to SO and categorically proved me wrong.
Could've been a disgruntled developer who told the manager "oh yeah, here's a good question to ask". Spent the evening laughing and feeling good about scaring the interviewee away.
Comments
The fact that there are more than 0 interviewers who ask questions like this is pretty damn sad.
The fact that there are more than 0 interviewers who think there is a difference is sad, because I think this makes a great question to separate out those who understand C and those who don't - it's even easier than FizzBuzz for the first group, and much harder for the second.
Anecdote time: I once interviewed a new candidate for a Python job along with three other developers on my team. One of the people on our team who was not a part of the interview handed us all a list of Python interview questions about 30 seconds before we headed down to talk to the candidate. He said these were the "best practice" questions he just found and thought they'd be good to ask. We figured "why not?". Well, turned out the questions were pretty obscure Python stuff, that in fact none of us could answer on the spot. We did figure these out later as a group, but it certainly made me feel very unprofessional.
Since then I've stopped asking questions like this. Trick questions and logic questions I think are a bad metric. A person can be great at sudoku but be a horrible developer in terms of writing maintainable code. Instead, I tend to just talk about the macro-level stuff. "What have you built? Can I see it? How long did you maintain it? What was the trickiest part? I imagine it had performance issues; did you spend time optimizing it?" I do ask some tech questions. For example, for web developers I ask "Describe how an XHR request happens in detail." But that is as deep as typically go.
This isn't specific to comp sci. While I can't cite a specific story this many years out, I definitely recall my classmates in Physics going for their nuclear power interviews (I had already decided that wasn't for me) coming back their bragging/complaining that they had to explain the proper application of Schrodinger's equation to an interviewer.
Given the tight market for programmers, it's actually a nice way of learning about the company before you go work there, if you think about it that way.
Kind of like if you got an interviewer that responds with a blank stare if you talk about version control and says they just make copies of the directory, or something like that.
Some people there on SO are suggesting this could be a "self-confidence testing" question where the interviewer already knows what he's asking is bullshit and expects you to react accordingly. Sort of like a HR-ish kind of question.
I can't fanthom how would one come to the conclusion that there is a difference between the two otherwise.
What a great idea, to test self-confidence in extremely nervous circumstances. What could even go wrong.
Seems like a good time to test it. After all, it's not absurd that you might need it in other nervous circumstances during the job.
It's also potentially a good test for how you approach correcting people, especially when you're in a subordinate position. Some people can be too forceful ("you're wrong!") quite a lot of people will let it slide ("I'll implement this terrible idea because I can't say no").
I hate this thinking (I know it is not yours, it's a hiring meme).
If an interviewer makes some crazy assertion, then I pretty much flip into the mode of "how do I get out of this interview ASAP, as there is no way I'm working with this idiot". Whereas in the office, I'm the guy that sends the really difficult mass email that calls out his boss, if it is really needed. Engineering is not interviewing, and vice versa; why would you expect identical behaviors in both?
And yup, I am self selecting out of the situation where the interviewer is not an idiot and just 'testing' me. I'm fine with that, because I'm also selecting out of a job where people aren't willing to treat me with respect.
Interviewing is largely voodoo; we shouldn't be inflicting cognitive pain on people based on our random selection process. The only measure that has ever been shown to be predictive is past performance. So let's talk about my past performance, and leave this amateur hour psychological testing in the trash bin where it belongs.
It's a psychology test, designed by non-psychologists.
Don't try something because you sit down and think "hey, I am going to create an artificial situation, and then guess at what a good candidate would do[1]." Then see if he does that.
[1] Which is often "what I (imagine I) would do."
Other nervous circumstances that are not the same as interview circumstances. For me at least, test and interview stress is of a nature and effect that I have never experienced in other circumstances in 12+ years as an engineer of various disciplines.
The type of place who needs people who can develop under that type of pressure doesn't sound like a great place to work... That type of pressure sounds a lot like cowboy coding.
TBH if you're nervous about a technical interview, maybe you don't actually have the technical level required for said job.
Or maybe that's just me; nervousity in presentations or interviews or even talking is IMHO an indication of not knowing what you're talking about. And knowledge is confidence.
Ummm... Actually very often the opposite is true.
I've interviewed a number of people who were incredibly confident in their language, voice and body language who clearly had no idea what they were talking about.
Similarly, I've interviewed people who clearly knew way more about the subject matter of the job than I did but who were incredibly nervous during the interview either because they were intimidated by the idea of working outside of academia, real/preceived language limitations, or because they were just incredibly shy and awkward.
I've generally tried to look for people who fit the sweet spot in-between: confident and sociable enough to be reasonably comfortable during the interview and humble enough to not be brash. The more "customer/client" facing the position, the more I care about the confident and sociable part.
Totally depends on the person. I'm shy in interviews, always have been, but I'd happily challenge anyone with my knowledge. (I'm not saying I know everything or even a lot, but I am very confident of what I do know)
Is it normal for an interviewer not to clarify that "actually, I was wrong" on these sorts of self-confidence tests?
Personally at the end of the interview (as the interviewer) I would refer back to any of those sorts of questions and say.. "actually I was trying to catch you out, you did good there", or some such.
This not only stops them doubting themselves, but also clears the air if I was to come back to them and offer them the job. Who knows, maybe the interviewee ran off to SO and categorically proved me wrong.
Could've been a disgruntled developer who told the manager "oh yeah, here's a good question to ask". Spent the evening laughing and feeling good about scaring the interviewee away.
TBH it's developers that should do the technical part of an interview, not a manager - they can do the other stuff.