[_xhok]

CoderPad is really, really good. I've interviewed using a bunch of alternatives, and CoderPad is far and away the only one that works reliably all the time. It always cheers me up when a company tells me they're using it, because I know it won't lag, the vi keybindings will work, the built-in terminal will work, there won't be weird interface glitches, every language I need will be there, etc.

This sounds hyperbolic, but I've never wanted a feature during an interview and found CoderPad to lack it.

[akanet]

This is perhaps the highest praise from a candidate we have ever received. Thank you, that means a lot to us.

[nightsd01]

CoderPad seems like an excellent product and I’m very impressed

I’m also impressed by your YIMBY project and that you mentioned it!

[gaius]

It always cheers me up when a company tells me they're using it

But how often in real life does a manager come to your desk and say, implement this feature RIGHT NOW and by the way I'll be standing over your shoulder the whole time? Would your first thought be, damn, I hope my key bindings work?

It doesn't matter how technically good a thing is if it shouldn't even be a thing in the first place...

[akanet]

An interview isn't a surprise attack, they're usually scheduled days in advance. Good interviewers will usually characterize what kind of questions you can expect to receive ahead of time. I'm sorry that you've had bad experiences during interviews, but the process is difficult for both parties. It can be very difficult to assess both candidates and companies without spending an inordinate amount of time in the process. CoderPad offers a particular cost-benefit tradeoff, and longer take-home assignments offer another. Onsite projects offer yet another, etc.

[fragmede]

In real life, my manager tasks me with doing something, and then it's up to me to figure out how to do it.

Sometimes, there's already a library or SaaS product that I could use, but the catch is we have to pay for the product.

For something that isn't a core business expertise, I could take an afternoon, implement it myself, and then spend all of my time maintaining that instead of working on our company's product, which is ultimately penny wise but pound foolish.

Smarter companies will realize some things are worth paying for, and seeing a company that has picked coderpad demonstrates that they are willing to pay for quality software that works.

> It doesn't matter how technically good a thing is if it shouldn't even be a thing in the first place...

We should have universal basic income and I shouldn't need to have a job not to be destitute, but until then, I'm going to keep going in to the office.

[bovermyer]

I think you missed the point there.

The point is that coding during an interview, whether digitally or physically, is a stupid practice that solves nothing and needs to stop.

[barrkel]

If the job has a large coding component, the candidate must code at some point in the hiring process. Take-home problems work out worse than interviews, primarily because coding isn't a solitary practice.

Discussing a problem, getting a shared understanding and outline of the solution, and then seeing how the candidate turns that solution into code - that's the kernel of a coding-heavy job, and it needs to be observed during the interview process to make even an approximate evaluation of their ability.

Other forms of observation can substitute: strong personal recommendations from previous co-workers, or famous accomplishments visible from afar, where there's no doubt as to who exactly accomplished them. But observation must be made.

[recursive]

Let's agree to disagree.

The job I'm recruiting for requires someone to be able to write code. Also, there are a lot of bullshitters in the world. Given these facts, I conclude that writing code in a an interview for a position where you'll be writing code is necessary.