> You don't get to see the engineering discipline the same way if you use the whiteboard.
I don't think I agree. There's absolutely something to be said for the comfort of a familiar environment, but I think the interviewer should be able to emulate the compiler/debugger/runtime for the question they're asking. (Many of the most successful interviewees can do this themselves; they write down the program state on the whiteboard and step through it in their head.) Interviewers should be able to say "you get a SIGSEGV" and ask what the candidate would do. If the candidate says "I'd run gdb", they should be able to say "it says the crash was at this line", emulate break/print statements, and such. In some ways, it's slower than the candidate doing things, and more awkward to go through a human. In others, it's faster, because the interviewer can/should speed up the process by forgiving small syntax errors, saying "oh, you're bisecting? it's here", etc.
I do this sometimes when interviewing. I find though that the people who can successfully use a debugger (or me as a debugger) tend to have relatively minor errors in their code anyway[1]. It's pretty rare for someone to have a completely incorrect algorithm and figure that out from debugging.
[1] forgetting a guard on an if for an empty datastructure, forgetting to sort numerically instead of lexicographically, some dumb typo, etc.
> but I think the interviewer should be able to emulate the compiler/debugger/runtime for the question they're asking
How does a human emulate the UI of a debugger? It seems like you would have much lower information-bandwidth and thereby inevitably end up not really presenting all the info at once that a terminal window is able to.
(Sorry, I missed your reply day of, so I'm replying much later.)
Yes, you're right. It's a bit awkward. I certainly wouldn't want to do my regular work by whiteboard + dictation. And if I were designing my company's interview approach I might allow candidates to bring in a laptop to work on a toy problem in their chosen IDE.
But my point is that I don't think debugging skills are completely impossible to test in this way, and the forced interaction allows you to learn what piece of information they're looking for and why. If this is how you have to interview, you might as well find the best aspects of it and use them.
I think a lot of the key of getting useful signal from an interview is to ask a simpler problem. If you ask someone to write and debug really complex code in 45 minutes, you'll just find out if they can write code under pressure really fast. That's a great skill, but I care more about communication: being able to ask good requirements questions, describe the data structure/algorithm so that teammates will understand it, teach people how to work through problems, etc. I think overly complex coding takes away the time I spend examining those things. Likewise, there are a few criteria besides "coding" and "communication" which I also want time to focus on.
When I look through the notes from the full interview panel, my questions often seem to be simpler than others. My feedback appears to correlate more strongly with actual hiring than average, so I think it's persuasive. Of course, I don't know if it correlates well with how people would actually perform if we hired them. I don't even know if the people we did hire are performing well, because I work at a big company and the people I hire generally don't end up on my team.
I don't think I agree. There's absolutely something to be said for the comfort of a familiar environment, but I think the interviewer should be able to emulate the compiler/debugger/runtime for the question they're asking. (Many of the most successful interviewees can do this themselves; they write down the program state on the whiteboard and step through it in their head.) Interviewers should be able to say "you get a SIGSEGV" and ask what the candidate would do. If the candidate says "I'd run gdb", they should be able to say "it says the crash was at this line", emulate break/print statements, and such. In some ways, it's slower than the candidate doing things, and more awkward to go through a human. In others, it's faster, because the interviewer can/should speed up the process by forgiving small syntax errors, saying "oh, you're bisecting? it's here", etc.
I do this sometimes when interviewing. I find though that the people who can successfully use a debugger (or me as a debugger) tend to have relatively minor errors in their code anyway[1]. It's pretty rare for someone to have a completely incorrect algorithm and figure that out from debugging.
[1] forgetting a guard on an if for an empty datastructure, forgetting to sort numerically instead of lexicographically, some dumb typo, etc.