[BurningFrog]

> How is providing a code editor or text editor different than writing it out on the whiteboard?

At least for me, it's vastly better. In an editor, I'm in my element, I have autocomplete, things work they way they usually do and everything is much more comfortable.

I could even throw together some quick tests and test drive my code!

[grogenaut]

That's if your used to using your laptop not your desktop, you didn't forget to charge it, the WiFi is working, you aren't missing your mouse keyboard montitor, etc. Ive had candidates many fuck all that up and spend 15 minutes fixing the ergonomics. Guess what it's a 25 minute coding exercise, good luck. If I give them a laptop, same deal.

After it all I still give them the option. Their computer ours or whiteboard.

Statistically ive found that the in ide ones don't get as far because they get hung up on syntax or project setup.

Interviewer and candidate tend to let things like missing curlys slide on whiteboard or just text editor. I don't even care if you get the size function name correct on a collection (I can't remember between the 7 languages I use) or similar.

This is data pulled from 500 interviews.

I don't think places would stop you if you wanted to use your laptop but I do think you're actually optimizing for the wrong thing.

[BurningFrog]

I'll admit this mostly comes from frustration standing by a whiteboard. If I did the same thing on a computer, I'd maybe just have a different set of frustrations.

As someone who does a lot of TDD, I is quite frustrating that a whiteboard can't run tests though...

What I have seen work well, from both sides, is interviewing by pair programming. Not for everyone, for sure.

[grogenaut]

Just write the test cases as bullet points and actually run through the algorithm with them when done coding. Don't declare success the instant you wirte that last curly.

Doing that gets a big plus from me (I'm 100% tdd personally).

Remember I know the answer to the question. The instant I can tell you do and for reasoning is good, I'm going to stop waisting time getting fro 95% sure to 100% sure on that part of the question and get another piece of data.

Usually that for me is to add some system design, speed consideration or other area of investigation and try to get another overall compentency covered. And just keep doing that till we run out of time.

It's very often other interviewers aren't able to hit things so backup signals are great.

And interviews are risk mitigation really. The more 80% certainties I can get on the more areas of coverage the Better if the interview team is doing a good job.

[pfranz]

As an interviewer I'd prefer a whiteboard and an open discussion. With a computer I have to deal with pedantic reality instead of discussing the concepts or approach. You also need a projector or a large screen if it's more than one other person in the room.

At one interview I was given a coding test (this was alone and timed). I was put into a separate room and pointed to a computer. It was a Windows box and Notepad.exe was the only thing I saw. I may have found Nodepad++, but I'm pretty sure it didn't have a Python interpreter. I hadn't used a Windows box in 10 years and my preferred environment is Vim. After the test they pulled me into a different room with the interviewers and discussed the code. This test was terrible for multiple reasons. I was asked to interview by a senior person who was working there who admitted that part of the process sucked and was pushing to improve it.

Even at large places that invest heavily in hiring, I don't see them developing/maintaining a test candidate environment, they're not likely going to hand you someone else's account in a production environment, and if they have a generic PC with a guest account, things are going to be missing or out of date. It'd be preferable for me to bring in my own laptop (but that discriminates against people with desktops or who don't have home computers).

[lazyasciiart]

I agree with the 'easier discussion' aspect of a whiteboard, but I feel that any whiteboard test should therefore be asking for pseudocode and explicitly disregarding the pedantic reality of syntax.

[pfranz]

Yes. I do think there's a benefit in having a reference language--just don't be pedantic. For example, certain design patterns might be needed for C++ that are built into a language like Python. Knowing which libraries the candidate (or the company) leans on is a good topic to discuss. Pure pseudocode might be too generic to suss this out. It depends what you're evaluating them for. There's little to no value in testing them on things like mismatching parens or typos in variable names (I've heard stories about people getting called out on those things using a whiteboard).