My office is a satellite of a larger one in Austin; we provide laptops for candidates to use for the "remote" part of the interview, when they interview with someone in Austin.

But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. Getting a chunk of source code in an email isn't representative of that. (At worst, they paid someone to do it for them; at best, you have no idea what their approach was. Somewhere in the middle is copying and pasting most of it from SO.)

> But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem.

So thinking out loud while coding is a job requirement now? I have been an engineer for over 14 years, and a software engineer for 10, and I can count on one hand the number of times I have done that outside of an interview. I collaborate all the time, but almost never synchronously while actually writing code.

Reasoning about problems is a very essential job requirement. And doing that out loud is the one of the few ways people can see how/if you do that.

>>Reasoning about problems is a very essential job requirement.

Sure.

>>And doing that out loud is the one of the few ways people can see how/if you do that.

Strongly disagree. I would posit that written explanations are a much better indicator of someone's ability to reason about problems, because:

a) They can provide hyperlinks, images and other supporting materials to aid their explanation

b) You also get to see if they are a competent writer, which is also a very important skill for an engineer

> At worst, they paid someone to do it for them

Which would easily come out at the interview when they fail to answer basic questions about their code.

> at best, you have no idea what their approach was

So? Did you get code that would pass a code review? Did you get code with good commits/history?

Not really.

It is much easier to talk about a solution, when the solution is right there in front of you, and you read an explanation of the solution online.

Regurgitating someone else's solution is fairly easy.

> But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem.

This is exactly why I do this kind of stuff as well when interviewing. It's not about syntax or the ability to recall (regurgitate?) a function, but how does someone approach a problem and where can the conversation go from there. If you sent someone pre-work to write an array matcher, you'll see a final result, but not how they think through it, and you'll miss potential queues to further the conversation.

I have used both ways, and i would say the candidates in general respond better to using the whiteboard. I do ofcource not require syntacitly correct code or anything like that. Im looking for ideas not if they are a compiler.

Using their own computer way to many struggle with creating a new project or other basic things. And that dont make them comfortable either. It also takes much longer then using the whiteboard.