Interview Zen, tool for asynchronous coding interviews

So now, we are supposed to be evaluated on our "thought process"? Based on what we type in the middle of programming? Talk about a completely ridiculous notion.

First off, what is the point? What matters is the finished product. When I code, I try a bunch of different ideas, get to a working prototype to make sure that the idea can actually work, and then I start to whittle down to what I believe is the best solution.

What does it matter what intermediate steps I come up with? All that matters is the code that I present for code review to my co-workers, and the code that I ultimately check-in. Trying to divine someone's "thought process" (which other people are completely unqualified to do, just based on what you see them type on the screen) is more stupid hoops to jump through in what is already becoming an increasing ridiculous hiring process for programmers.

Perhaps it was the fault of the interviewer and the way he framed his questions (they were slightly involved questions -- "write a command line utility that converts an image file, include unit tests, etc.)? I would often have to write my code in the online editor... (so the interviewer could observe my "style") and then bounce out of the browser, throw it into iPython or sublimetext, run the code, debug in my editor... go back to the browser... write my updated code out... rinse repeat.

Code interviews are a bit nerve racking to begin with -- and interrupting my workflow so jarringly doesn't really help. I prefer when hiring managers have me branch a git repo on git hub, encourage me to commit my changes to a project frequently and discuss my thought process on the commits. I think that process works better for both sides.

However, as a candidate, the coding process is pretty painful. I tried it out for C# and there is no intellisense, no compilation, no type checking, etc. This means that I'm more likely to just write it in VS, then cut and paste the solution into the webform, which reduces the value for me as an interviewer because I can't see the process. Even for languages like Python and Ruby, I would see most devs using the editor they are used to and cut and pasting since it would be faster / easier. This makes it hard for me as an interviewer to distinguish between someone that's just good and someone that cut and pasted a solution off the web.

Not sure the best way to fix it. A plugin to popular IDEs for the languages that use them. Improved coding experience on the webpage itself. Some plugins for something like vim, emacs, textmate, sublime or something that can be used for most languages. All those options are tough. Good luck :)

Also a small note. I would decrease the default tab size. When coding in the web window, it is quite large by default.

Another small note. I would remove the dead space from the video. You could note you are doing it, but if someone is thinking / using another editor, you're just going to have a 1/2 hour of nothing, then one block of text.

The only problem that I have with things like this is the way they throw me off by whatever rules they have for indentation - the auto-indentation rules may well not match those that I'm used to, and it increases the cognitive burden. And not having access to the full power of Vim! How can you analyse an applicant's capabilities if you tear him away from Vim? ;-)

That issue is one that I guess you can't really get around.

Oh yes - one other gripe. The hunt-and-peck style is apparent in your leading demo submission. Shudder. If you hit ones like that, 5x just doesn't seem fast enough.

Good job.

This isn't appropriate for every company, but we simply give programmers we are trying out a project, something we expect can be done in less than a day. We pay for the project, and we're always asking them to build things we actually put into production.

If you make it to a phone screen with me, 80-90% of the time, I'm going to be willing to pay you 200-1000 to show me what you can do. I have to let go most of the candidates after this trial, but it's cheap, and the people we keep are all really outstanding.

Writing code in this doesn't really give you anything beyond watching how long it takes them to type something, which isn't a good indicator of anything (perhaps they have the phone up to their ear instead of a headset and it is hard to type). Also, since there is no way to test your code you may as well do the same thing in a skype chat window.

<?php

$x = 1;

while($x <= 100) {

if((($x % 5) == 0) && (($x % 3) != 0)){ print("Buzz"); }else{ if(($x % 3) == 0){ if(($x % 5) == 0) { print("FizzBuzz"); } else { print("Fizz"); } }else{ print($x); }} ++$x; }

?>

Dont believe me?

Checkout https://etherpad.mozilla.org/ep/pad/view/wvxaz6MPyt/latest

After researching other coding interview tools, I stumbled upon this one (that I'll probably use next week), and wanted to share it with HN.

If the discussion here is interesting (as usually), I'll send the link to the author.

I think a conversation with someone as they code, rather than a reply of what they did, is an easier way to evaluate skill.

What's your revenue model?