4 ms·

My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. I don't do challenges any

My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. I don't do challenges any more, life is too short to waste solving problems that don't exist for someone else without getting paid.

MarkMc 8y ago
All the coding challenges I ask of my candidates have been real-world problems I had to solve in the past where I though, "huh, this would probably be a good interview question". I also pay candidates for their time, except for the initial screening test.
navinsylvester 8y ago
Second that. I was hired via this model. Have also used this approach to hire and this has paid off more than any other approach. A simple 100 line code can be curated and taught by a friend/relative in a very elaborate way. This approach can negate that issue in someway.
maccard 8y ago
> My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. That excludes anyone with a no moonlighting agreement in their current contract, though.
matthewmacleod 8y ago
While I appreciate that it can be a waste of time, the way I tended to look at this was that if the coding test / task was minimal, it was an acceptable trade-off for both company and candidate. Like, that task should take an hour or so. The problem it's trying to solve is just the surprising number of bad candidates that apply. We're talking about people with decent CVs, a bit of work experience at different companies, some open-source work etc., and who had a good chat on the phone – sometimes they just completely mess it up when faced with a task like "combine these JSON files to make output that looks like this sample". Things like code that literally doesn't work, or code that uses totally inappropriate tools. We want to avoid wasting both their time and our time by bringing them onsite for an interview that isn't going to go anywhere. The risk with being "hired to do real, paid work remotely" is that it relies on finding people who are in a position to do that, and this ends up excluding a bunch of good candidates. Not everybody is in an employment situation that will allow them to do external work, and it disincentives people with families or other commitments. The process of applying for a position shouldn't be over-burdening on a candidate. I agree that it's unfair to expect lots of stupid work, multiple-day interview processes and so on. But I don't think it's unreasonable to expect that a candidate who wants to work with a company can afford to spend a few hours in total as part of that process.

MarkMc 8y ago

All the coding challenges I ask of my candidates have been real-world problems I had to solve in the past where I though, "huh, this would probably be a good interview question". I also pay candidates for their time, except for the initial screening test.

navinsylvester 8y ago

Second that. I was hired via this model. Have also used this approach to hire and this has paid off more than any other approach. A simple 100 line code can be curated and taught by a friend/relative in a very elaborate way. This approach can negate that issue in someway.

maccard 8y ago

> My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. That excludes anyone with a no moonlighting agreement in their current contract, though.

matthewmacleod 8y ago

While I appreciate that it can be a waste of time, the way I tended to look at this was that if the coding test / task was minimal, it was an acceptable trade-off for both company and candidate. Like, that task should take an hour or so. The problem it's trying to solve is just the surprising number of bad candidates that apply. We're talking about people with decent CVs, a bit of work experience at different companies, some open-source work etc., and who had a good chat on the phone – sometimes they just completely mess it up when faced with a task like "combine these JSON files to make output that looks like this sample". Things like code that literally doesn't work, or code that uses totally inappropriate tools. We want to avoid wasting both their time and our time by bringing them onsite for an interview that isn't going to go anywhere. The risk with being "hired to do real, paid work remotely" is that it relies on finding people who are in a position to do that, and this ends up excluding a bunch of good candidates. Not everybody is in an employment situation that will allow them to do external work, and it disincentives people with families or other commitments. The process of applying for a position shouldn't be over-burdening on a candidate. I agree that it's unfair to expect lots of stupid work, multiple-day interview processes and so on. But I don't think it's unreasonable to expect that a candidate who wants to work with a company can afford to spend a few hours in total as part of that process.