Hi. I'm the guy that made CoderPad. I bootstrapped the product out of nothing because of terrible candidate experiences older purely textual collaborative environments provided. I sincerely believe CoderPad gives you much more room to breathe than many alternatives. There are a few reasons for this:

1. You get to introspect the environment. I've had lots of candidates forget whether certain objects support simple methods (map, sort, join etc). CoderPad lets you perform quick tests to make sure.

2. You get to debug how you would normally debug. Whiteboard interviews basically rely on the interviewer saying something "Are you suuuuure there's no bugs on, say, lines 10 through 12?". I find this incredibly stressful as both the interviewer and candidate. CoderPad lets you run the damn thing yourself and see if it says what you want it to say.

3. Compared to probably the next most relevant comparison, graded homework assignments, I think CoderPad's free-form format is much more forgiving. As a candidate, I've definitely wasted hours trying to get some hidden automated test suite to pass with no feedback as to what sort of failure was encountered. CoderPad blends code evaluation with live feedback from the interviewer.

Yes, social pressure can be daunting for many candidates. I don't think this is something you can avoid in a live interview in general. I think you can get pretty good signal from project submission from candidates, but at the cost of greatly increased time spent by both candidates and interviewers. For many people this may be a worthwhile trade and I think additional options are good, too.

Regardless of how much your software has made me sweat, I still think it's great software. My comment was more about the interview process, not your software. Good job creating it. I wish it was free... Haha...

I think it's worse than a whiteboard. I have seen very few interviews that expected anything other than psuedo code on a whiteboard.

With a repl I could easily pin myself on some trivial bug that interviewers would ignore on the whiteboard...

I thought I disliked whiteboard coding, until I recently had an interview on a provided laptop running one of those JavaScript IDEs. It was miserable. Extreme unusable OS X mouse acceleration, an awful keyboard, an unfamiliar hotkey setup in the text editor, and a tiny 11 inch monitor split into 4 sections which means my editor was maybe 10 lines tall. I failed miserably at a relatively short and simple challenge that I am confident I could code on a remotely familiar and sane computer setup. Heck, I would have preferred writing valid JavaScript on a whiteboard. At least I'd be able to see a lot more lines at a time, which it turns out is pretty important for my ability to code.

Sounds like a company to avoid if they throw the improper tool for the job at you and expect you to do it with that, even if a pen & paper would be better.

</slightly offtopic>

Some guys I've met, with different occupations and age, sincerely believe that smaller screens are more usable. Like small windows on 14" CRT when everyone had 17/19". Now it's guys that claim that 11-13" ultrabook is enough for them and they don't want more ever. This honestly baffles me every time.

I use only a small part of screen when writing code, because it somehow forces me to write shorter, cleaner functions. Although debugging is terrible experience on small monitors, because I need more windows open at the same time - watches, callstacks, ...

I much prefer a whiteboard to these programs. Half the time I end up typing vim commands and appearing as if I can hardly type.

> unnecessary

I can't think of any way to do an interview without pressure. Pressure is unavoidable when someone's future job is on the line.

It's avoidable. Behavioral questions don't tend to freak engineers out. Neither do questions about their past work.

> Behavioral questions don't tend to freak engineers out.

Speak for yourself. I'm far more relaxed when diving into a technical question than when playing a guessing game about what social signalling I'm supposed to be doing at that moment.

You're not supposed to be trying to be someone you're not. If you have to put in that much effort during your day job then you won't be happy. You just need to relax and be yourself, it not only makes everyone more comfortable but it lets you and the company start to evaluate whether or not you're good cultural fits. You'd be pissed off if they mis-represented the culture there during the interview process, and they have just as much right to be pissed if you act completely differently (in a negative way) when you start working.

> Neither do questions about their past work.

If you feel you didn't accomplish much at your last job(which would be a pretty common reason for quitting), then a question about it would be pretty stressful, since the company is evaluating you based on work you didn't find to be your best.

Then talk about work that you do consider to be your best.

A terminal does not replace a whiteboard. I know some force candidates to code on whiteboard but that's not what it's specifically good for. A person to person discussion with a white board is the best communications platform for conveying technical ideas, IMO. You need the whiteboard, so both of you can define symbols, then discuss the meaning of these symbols by pointing at them, drawing arrows from them, expanding them, etc. The symbols can include fragments of code, of course.

So, yes, if someone wants to force another person to code on a whiteboard then certainly, they can do better, but it's like asking someone to draw with an axe on the stone floor. Waste of good axe and floor.

Well, these code/rpad/lity/rank sites are no different in terms of types of tasks... The problem is not only with a medium (whiteboard or *pad/lity/rank website) but also in what kind of problems you get to solve... Are these problems relevant to job? Is the condition/situation similar to what you'll be doing on the job? etc...

And don't forget interviewer's breathing over skype while you coding online, just to add more drama

XKCD 1168:

- Rob, you use Unix! Come quick!

* To disarm the bomb simply enter a valid "tar" command on your first try. No googling. You have ten seconds. *

- Rob?..

- I'm so sorry.

That's just silly, though. "tar" is pretty easy to use in its basic form, and I have dozens of commands ingrained in my memory.

    tar tf filename.tar
    tar xf filename.tar
    tar xfz filename.tar.gz   # Newer tars don't even require the z
    tar cfz filename.tar.gz directoryname

Heck, surely even

    tar --help

would suffice.

More interesting questions would be like: "which lower-case letters are NOT valid options to GNU ls". :)

I had untarred hundreds of files before I actually needed to start creating tar files on a regular enough basis to remember the syntax.

Defusing a bomb of course~

But yea that analogy fits coderpad well, along with all the other collaborative code editor + webcam websites.