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.
Showing the mistakes I made while coding was actually something I liked about it. I would hope that after I write the code, I can justify some of the backspaces I used. Even when writing the fizzbuzz implementation in Ruby I found that I used the wrong conditional logic at first (puts "fizz" if i % 3 == 0) and then decided to change it to a more traditional if-else block format. Sure, that meant I took 2m10s to finish the test, but now I have proof why it took the extra 30 seconds. That's something I have no problem showing to a potential employer, because I can show how I'm constantly trying to improve my code even as I write it.
I would probably do okay at this. But I know some good people who would not. One of them is nearly blind, and is one of the best systems programmers I know.
Since I use Emacs nearly exclusively (Visual Studio for debugging, and other tools for writing documentation), I would revert to "I have to type code in a dumb editor" mode, and my fingers would be stupid. You'd see some stumbling around. I'm not sure it's useful knowledge for the interviewer.
I've used this in an interview and was very frustrated.
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.
I think the problem lies in the interviewer in this case. This tool seems to be a substitute for being in an interview room and having a whiteboard to write code on in front of the interviewer, rather than an IDE with a "record-mode". As such, I think the interview question should be posed as if that were the case.
In regards to its effectiveness, I think if you take the above into consideration, this tool works very well as advertised. If I were being interviewed with it I suppose I'd just be thankful it has syntax highlighting.
Questions for this should be to discover a person's thinking and problem-solving style, not the correctness of syntax/libraries/etc. Things like writing idiomatic code, etc. are much more appropriate to test for.
Okay. Tried it out. This has some promise, but I think there might be some issues in actual use. One of the major bonuses of this for me as an interviewer is to see how the candidate solves the problem over time (as opposed to just seeing the finished product).
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.
It's definitely far from comfortable if you compare to your favorite editor/IDE. In my case, I'm fine with it because I just want to assess the overall coding and design skills of the candidate.
For instance, I'm well aware that when you take Eclipse/IntelliJ away from a Java developer, we feel hopelessly lost, so I wouldn't be picky when seeing the candidate answers.
This really depends on the applicant and the coding question being asked. Writing a fizzbuzz implementation shouldn't require any IDE, intellisense, or any tools for that matter. I wouldn't expect a coding interview using this tool to be asking anything more than a simple coding question, or else this gets unweildy quickly, but not because of a lack of an IDE, but because I'm typing in a small textarea.
You should try writing out some code on paper some time and see how you do. Without any of the fancy tools to act as a crutch, you'll find that your memory gets better and you are able to crunch more logic in your head.
Looks like a good tool. You don't show all the functionality from the homepage; would I be correct in imagining that you'll have a way of exporting results for execution, or executing them, so that the correctness of a solution can be verified?
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.
I've been hiring programmers recently, mostly contract, then on to full-time for the best fits. One thing I've never asked is to see them code, and I'm not sure I'd want to. I might skip a candidate who fumbled around, who was actually really good.
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.
It is a good idea but I'll stick with using join.me (or skype, vnc, or teamviewer) so the candidate can have their own development environment.
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.
It's certainly not perfect, but I came up with it under pressure in less than 90 seconds without checking online for the modulo return values, so I'm rather proud of it.
I am a bit lost on the syntax, but its always good to check for division by 15 first. You have sort of caught that I think in 5 and not 3, but that just seems an odd idiom.
The homepage shows a simple example in C.
Oh, I used to use this on coding tests, the first guy who asked can I do it recursively in Scheme - I could have kissed him !
Doesnt etherpad have a similar functionality to record and replay entered text? In fact it allows for unlimited editors and far more customisable. Best of all, its free!
yeah.. that's true. I have been using etherpad in interviews and it has worked out quite well.
Please give me a reason to not choose an open source solution and instead go with your proprietary solution. I would be glad to be your customer if you come up with a good one.
In Internet Explorer 9, the code editor is unusable because you can't change previously entered lines. When you try to move the cursor by up arrow key or mouse click, the cursor jumps back to the last line. Maybe it's a feature to exclude candidates who don't run a modern browser. :-)
But, as a candidate, once you try it once, and see what the interviewer will see, you become very self-aware of those minor details. It perhaps adds a bit of unnecessary pressure for some.
This is cool, but I am more interested in the javascript component that does the playback. Is there anything similar open source? Having actually seen the implementation that downloads a set of linear commands in JSON it doesnt seem too hard to implement though.
However, you can't do asynchronous interviews to a bunch of candidates with seemikecode. (A different business is whether that is a good practice or not.)
When I clicked on the play button on the homepage under Chrome (latest) on Macbook i7/8gb, my fans popped on and I thought I was going into outer space. Is that just me?
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.