This browser-based-REPL space is getting CROWDED. It also overlaps substantially with the browser-based-IDE space. Let's see the execution competition commence.
So, aside from this, listen, if this tool helps your company run technical interviews, you're doing interviews wrong. (I assume the baseline is using Google Docs for your preliminary phone-screen for technical interviews, which in case you forgot, is free and ubiquitous). Let's go through coderpad's bullet points of User Value Prop, saving the craziest for last:
1) Companies waste less time and money. Tie with Google Docs.
2) Companies observe candidates' actual coding behaviour. If the candidates are IDE-dependant, no, so tie with GDocs. If they're not, tie with GDocs.
4) Interviewers spend less time nudging. Nudging is a FEATURE, not a bug. If you want the candidate to get it for free, give it to them for free. In any case, are syntax mistakes on line 12 REALLY WHAT YOU'RE INTERVIEWING FOR?!?
5) Interviewees demonstrate savviness.... by relying on auto-complete? Tie with GDocs, best-case.
6) Intreviewees look smarter. Well, maybe for some interviewees. I whiteboard flawlessly (such a useless superpower, except when interviewing), so this gives me less chance to show off. Also this highlights all your syntax mistakes, for those of you who make them, which arguably makes you look worse. Overall across all interviewees, I call this one a wash.
7) Candidates solve more problems, by not wasting time asking about API details.
GOD NO. WRONG.
Listen, candidates, when you're at the whiteboard, you should KNOW what methods the object should IDEALLY have, and you should have confidence that if need be you can re-implement those methods, and so you just say "I assume array has a max(), if you need it implemented just tell me." And in the time you took to utter that line, you plan out the next line of good code, and you look smarter. If the interviewer cares, show them. If they don't care, hand-wave past it. The way you figure whether they care or not is you make a reasonable guess whether they care, and tell them you're happy to be corrected.
Interviewers with a basic competence level should be helping their candidates out with this, by the way. Unless what you really care about is whether they know the syntax of max() by heart... in which case you'd better not use coderpad, because it's a cheat sheet! (Note: since I want to fail 100% of interviews that care about whether I know the syntax of some ruby array method, using coderpad works against me too in that situation).
3) Companies unambiguously know if the candidate has solved the problem.
Wow, this one's tough to even start with.
First of all, your interviewer is hopefully competent enough to over-solve the problem, given that they get to think about it in periods of non-stress, with colleagues, and they expect candidates to solve it alone under stress and time pressure. So hopefully they already know all the corner-cases that they care about.
Second, at the risk of repeating myself, if you're grading for precise syntax in an interview, (2a) you're probably grading for the wrong thing (but maybe not), and (2b) you don't want the candidate "cheating" by using coderpad. So who cares if they made minor mistakes that you wouldn't catch by hand?
And third, if the question is interesting enough to be a hard interview question (as contrasted with FizzBuzz, which does have a place in phone screens), then it's probably hard enough that running it is not going to find all the important edge cases. Hard questions are usually hard for one of these reasons: they have crazy corner cases (running it on golden-set data tells you nothing), or they have a naive solution that's too slow and you want a fast solution (how does running it on coderpad help with this?), or both. They're rarely hard in the "can't get it to work AT ALL" sense.
Basically, if your interviewer can't reliably-enough determine, in his or her head, the correctness of the solution, in every dimension that matters to your hire/no-hire decision, you're lost. Hoping for an IDE to help you is... depressing.
With all that in mind, I question the honesty of trying to sell this product. Even if I think the product is pretty.
You could have just said "Why use this when I could use http://collabedit.com/ for free? It's 'good enough'"
I'm personally excited to try this app out though this week on a candidate. There's no way in hell I'd use Google Docs. The lack of auto-indentation just kills it as a tool for writing code for me.
Time to start a comprehensive list, maybe, to make head-to-head comparisons. Some examples: http://c9.io http://pythonanywhere.com
--------
So, aside from this, listen, if this tool helps your company run technical interviews, you're doing interviews wrong. (I assume the baseline is using Google Docs for your preliminary phone-screen for technical interviews, which in case you forgot, is free and ubiquitous). Let's go through coderpad's bullet points of User Value Prop, saving the craziest for last:
1) Companies waste less time and money. Tie with Google Docs.
2) Companies observe candidates' actual coding behaviour. If the candidates are IDE-dependant, no, so tie with GDocs. If they're not, tie with GDocs.
4) Interviewers spend less time nudging. Nudging is a FEATURE, not a bug. If you want the candidate to get it for free, give it to them for free. In any case, are syntax mistakes on line 12 REALLY WHAT YOU'RE INTERVIEWING FOR?!?
5) Interviewees demonstrate savviness.... by relying on auto-complete? Tie with GDocs, best-case.
6) Intreviewees look smarter. Well, maybe for some interviewees. I whiteboard flawlessly (such a useless superpower, except when interviewing), so this gives me less chance to show off. Also this highlights all your syntax mistakes, for those of you who make them, which arguably makes you look worse. Overall across all interviewees, I call this one a wash.
7) Candidates solve more problems, by not wasting time asking about API details.
GOD NO. WRONG.
Listen, candidates, when you're at the whiteboard, you should KNOW what methods the object should IDEALLY have, and you should have confidence that if need be you can re-implement those methods, and so you just say "I assume array has a max(), if you need it implemented just tell me." And in the time you took to utter that line, you plan out the next line of good code, and you look smarter. If the interviewer cares, show them. If they don't care, hand-wave past it. The way you figure whether they care or not is you make a reasonable guess whether they care, and tell them you're happy to be corrected.
Interviewers with a basic competence level should be helping their candidates out with this, by the way. Unless what you really care about is whether they know the syntax of max() by heart... in which case you'd better not use coderpad, because it's a cheat sheet! (Note: since I want to fail 100% of interviews that care about whether I know the syntax of some ruby array method, using coderpad works against me too in that situation).
3) Companies unambiguously know if the candidate has solved the problem.
Wow, this one's tough to even start with.
First of all, your interviewer is hopefully competent enough to over-solve the problem, given that they get to think about it in periods of non-stress, with colleagues, and they expect candidates to solve it alone under stress and time pressure. So hopefully they already know all the corner-cases that they care about.
Second, at the risk of repeating myself, if you're grading for precise syntax in an interview, (2a) you're probably grading for the wrong thing (but maybe not), and (2b) you don't want the candidate "cheating" by using coderpad. So who cares if they made minor mistakes that you wouldn't catch by hand?
And third, if the question is interesting enough to be a hard interview question (as contrasted with FizzBuzz, which does have a place in phone screens), then it's probably hard enough that running it is not going to find all the important edge cases. Hard questions are usually hard for one of these reasons: they have crazy corner cases (running it on golden-set data tells you nothing), or they have a naive solution that's too slow and you want a fast solution (how does running it on coderpad help with this?), or both. They're rarely hard in the "can't get it to work AT ALL" sense.
Basically, if your interviewer can't reliably-enough determine, in his or her head, the correctness of the solution, in every dimension that matters to your hire/no-hire decision, you're lost. Hoping for an IDE to help you is... depressing.
With all that in mind, I question the honesty of trying to sell this product. Even if I think the product is pretty.