Show HN: CoderPad, an etherpad + REPL for coding interviews
coderpad.io
coderpad.io
300 pads/month - clear makes sense
Unlimited pads under 15min - This shows up for every tier but I'm not really sure what it means.
Save pads for later review - Just "Save Pads" gets the point across.
Custom pad branding - Just "Custom Branding" gets the point across.
24/7 support availability - Just "24/7 Support" gets the point across.
Just my two cents. Don't get me wrong, I think you did a great job with the design and execution.
PS. Upvoted anyway, because this is a nice tool and idea, and because your demo process was slick!
ruby and python can also be shitty in the wild as php, please stop such foolish statements once and for all.
It just so happens that PHP is shitty by default.
But remember, the best way to avoid dealing with this dogma in the workforce is to use some other language. It's a win/win... not only do you not have to deal with silly PHP shame, but you ALSO don't have to deal with PHP, which isn't as bad as the haters say, but is still pretty bad!
https://github.com/d11wtq/boris
Discussed last week on HN here: https://news.ycombinator.com/item?id=5673032
Also, I'd love to see how saving pads for later review actually works before buying - even screenshots would go a long way in deciding if I want to pay.
Have you considered offering trial plans?
JSRepl is super cool, I can't believe people are just now starting to use it in their own projects.
I'm hoping the tech screen income covers the costs of the site so I can make the applications for online tutoring and possibly classroom demonstrations free. The reason I made coderang was to help me teach my little sister how to code over the Internet without making her set up a dev environment (she's 12), so the potential educational applications are something I really care about.
As far as I know, things like Emscripten (https://github.com/kripken/emscripten/wiki) can compile C/C++ to JS, but the compilation itself doesn't happen in JS.
I want to see him, in his own environment, how he solves problem. With spaces I can observe via shared screen how the guy codes, how proficient he is with his tools, which references he uses, etc. This reduces any barriers. More importantly, I can interact with him as he codes a solution via microphone.
Google Spaces is free.
Furthermore, as a candidate, I'd be leary of someone on the other end, not paying attention, trying to multi-task, etc...
AND, this would make me feel like someplace is trying to hire a MONKEY if they sent this to me as a first step in the hiring process.
Say I am stuck on a particularly sticky problem. I'd love to be able to load up some code and work through it with someone more experienced.
I know you can do this via Tmux but what if I don't want to setup Tmux and SSH keys?
There's also another startup that's a shared code editor with video chat on the right, but I can't find the link to that right now.
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.
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.