I read about three paragraphs in and then stopped.
Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point?
We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the coderpad, then a panel interview; the author is right in that it's about a 5-6 hour process overall (for the candidate). The coderpad is as much about watching how you go about solving a problem as it is you getting the right answer, although that certainly counts. We want to see if you pay attention to the question and implement what we asked for (not brain teaser 'gotcha!' stuff, simple stuff like "write a function that does ... and returns a boolean" - a lot of people will have their function print an answer and return nothing, or won't write a function at all, or will ignore other key requirements), that you can explain your approach, that you can think of some test cases, and that you can accept help/coaching if you're clearly stuck. We want people to do it in a language they are comfortable with, and looking up syntax is OK.
Overall I'm not sure how much value we get out of coderpad. It's manufactured pressure, just like a whiteboard exercise in an in-person interview. You can tell candidates what I wrote above, and try to convince them that it's not about getting the right answer as much as how you get at the answer, but that doesn't really work. Some people are not going to do well in those interviews regardless of their ability.
> Overall I'm not sure how much value we get out of coderpad
Well so you're pretty much in agreement with the author it seems. He's just more convinvced than you that coderpad is actually more bad than good that's all, you have a bit more doubts.
Maybe. I know we've hired people who did objectively poorly on our coderpad and they've been effective - although in one case not as an IC, IMO - while other people who did objectively great were just not.
I think my feedback is that the coderpad is not about whether you can solve tricky brain teasers correctly. It's just one signal along with several others: can you understand directions, can you demonstrate familiarity with a coding environment, and does it seem like you can think through (again: simple) problems in a way that we can compare to more real-world stuff.
Personally, my favorite challenge stuff when I was last interviewing were take-home problems that were more representative of the type of work the position would be doing. I could take my time, and idk I felt like I was doing something meaningful and holistic instead of implementing an algorithm. I've brought this up enough to realize that it's a controversial idea though; a lot of people either want that scheduled hour coderpad because they are taking their personal time for it and that's what fits in their schedule, or I've also heard people say that if they are going to do work then they expect to get paid for it, so a take-home assignment doesn't work for them. Of course there's also the possibility that someone will just copy an answer from somewhere and submit it.
Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point?
We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the coderpad, then a panel interview; the author is right in that it's about a 5-6 hour process overall (for the candidate). The coderpad is as much about watching how you go about solving a problem as it is you getting the right answer, although that certainly counts. We want to see if you pay attention to the question and implement what we asked for (not brain teaser 'gotcha!' stuff, simple stuff like "write a function that does ... and returns a boolean" - a lot of people will have their function print an answer and return nothing, or won't write a function at all, or will ignore other key requirements), that you can explain your approach, that you can think of some test cases, and that you can accept help/coaching if you're clearly stuck. We want people to do it in a language they are comfortable with, and looking up syntax is OK.
Overall I'm not sure how much value we get out of coderpad. It's manufactured pressure, just like a whiteboard exercise in an in-person interview. You can tell candidates what I wrote above, and try to convince them that it's not about getting the right answer as much as how you get at the answer, but that doesn't really work. Some people are not going to do well in those interviews regardless of their ability.