8 ms·

> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off

> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option. Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense.

jlees 13y ago
I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company.
- anonymoushn 13y ago
  My current company does this. It seems to work pretty well, but it has some of the same problems as other methods. In particular, the standards applied to the solution vary greatly from "Does it work and run at most 40x slower than expected?" to "It heap-allocates things that could be stack-allocated, so we should pass".
  - jlees 13y ago
    Hmm, how about applying the same standards to the solution as you would to internally-committed code (peer reviews, etc)?
- ataggart 13y ago
  In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.
  - zecho 13y ago
    We do this at my job. We try to come up with projects that are good fits for the candidate, usually a small version of a problem we've recently dealt with. It's not a first line, though. We tend to start by actively recruiting/headhunting. We cherish recommendations from current or past employees, but we'll also open the position to all on the off chance we get a good application through traditional routes. HR only becomes involved with the process after an offer has been accepted or if the hiring manager has questions/concerns. After an informal lunch with the hiring manager, you'll be invited to meet with some senior developers for about an hour. These meetings are mostly to figure out what the candidate thinks their strengths and weaknesses are and gives us a chance to talk about the stuff we plan to work on in the near and not-so-near future. Once we have a fairly basic understanding of each other, we'll come up with a project. Think your strength is on the front end? Here's an API we wrote. Build a widget with the data. Think you're strongest at databases? Great, here's a database project. We don't care if you have a lot of questions or if you fill in the blanks. We give as little direction as possible at first on purpose. Write it in whatever language you want to write it in. We want to see how the candidate works. If they ask questions, great. If they don't, great. Do they ship something? We make sure to stress there's no wrong answers. At all. The projects are designed around your perceived strengths because we'll figure out your weaknesses and will compensate for those during the 90-day trial period all new hires have to go through anyway. The point is to see something we can discuss in a later, final round. Even failure to complete is acceptable, so long as you can articulate why. None of this is hard and fast. We have had candidates who, for whatever reason, can't or won't write code outside of their current position. We'll adjust. Our process isn't rigid at all. We try our best to take a holistic approach. It's only bit us in the ass twice, mostly due to culture issues because the hiring manager made his decisions unilaterally. Since then, all senior devs and a few others on the team meet all candidates before hire and can give management input.
- scrabble 13y ago
  This is the way the company I work for currently does it. They provide the candidate with a piece of terrible code, ask for a code review of as many issues as the candidate can find, and also for a refactored copy of the code. Both of which are completed remotely on the dev's own time. This is before even meeting the candidate in person. Once we meet in person for the first time, another terrible piece of code is provided -- in this case a basic data structure -- and another code review is requested. The candidate is given 15 minutes to complete it. It's interesting what comes back. Some people comment only stylistic issues, others only logical or architectural issues. One person got up and left during their alone time. Other than these, no coding is required. So far, it's worked out pretty well. And when I was going through it, I enjoyed it.
  - BrandonM 13y ago
    I think that a lot of companies forget that they are also being interviewed during their interviews. Were I to interview at your company, I would think that your employees spend most of their time performing code review. I would probably walk out, too.
    - scrabble 13y ago
      I can understand that take on it. Our take is more that if you can recognize what is wrong with the code on multiple levels then you can most likely write good code. This is easier to check on non-trivial code when done through a code review then by getting the interviewee to write the same kind of code that every other interview looks for. The submitted code sample does this as well. I'd also want people on my team to be able to successfully refactor legacy code just by looking at it and being able to identify where things can be better cleaned up and tested.
      - BrandonM 13y ago
        I am completely behind code review and refactoring. I am our company's Chief Refactorer (a title I just made up, but it's accurate), and after instituting code review a few months ago, it has made our development process so much better. At this point, I hate merging in a feature that I've written without having someone else review it. So that's not my issue. I was pointing out that your interview process seems to involve only code review, based on your comment above. Put yourself in an interviewer's shoes: in two different instances, you've been presented with bad code and asked to code review it. Personally, I would be concerned that (1) your company writes bad code, and (2) I'm going to be expected to spend all my time reviewing and fixing other people's bad code instead of writing code myself. Now I doubt that's actually the reality of working at your company (at least I hope so!), but first impressions are very important, and that's what your interview process would tell me if I were interviewing there.
ig1 13y ago
It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).
- thedufer 13y ago
  This is the root of the problem with contract-as-interview, as far as I can tell. It wouldn't be completely unreasonable for someone to take a few days off from their job to interview (although I wouldn't do it). But both of the points you mention are standard for creatives, at least in the US, so I don't know how many people you'd legally be able to interview.
- nrivadeneira 13y ago
  You could make it a short take-home assignment where the code doesn't get used by the interviewing company and the assignment is short enough that the interviewee doesn't feel like they need to get paid for it. It would basically be the same as doing it in-person but removes the added stress of the over-the-shoulder scrutiny, leading to a more realistic scenario where a developer has resources such as Google and Stack Overflow at their disposal. In my engineering days, a company I interviewed for had me prototype some stuff in SolidWorks but gave me the courtesy of working alone. I just had to tell them when I was done. Even this was much more preferable to an in-person on-the-spot tech interview. I got an offer for that job, but if I had to perform the same task with someone watching, I don't think it would have gone as well.
- pkinsky 13y ago
  How would this be enforced? I suppose it could end up being more of a problem for the hiring company after this practice became more widely known.
- driverdan 13y ago
  You're a fool if you'd sign away copyrights to all work you do outside of your place of employment. Actually, that shouldn't even be legal.
- 13y ago
comrade_ogilvy 13y ago
"I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option." I wonder that, too. The very best people usually have a job that they like well enough, but might change jobs for a real offer. "Quit your job and we will probably hire you" is not so attractive to experience people, who are usually no longer in their 20s. Even if a developer were inclined to give it a go on his or her vacation time, most employment contracts require notification for taking on additional employment -- it is rather awkward and annoying to the candidate to jump around these hoops.
bmj 13y ago
Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense. Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at least 10 hours preparing for it (with perhaps only a bit of assurance that I had prepared properly). If I were given a ~10 hour contract project, I would know the problem up front, and be free to complete it without the stress of a whiteboard session.
- Bartweiss 13y ago
  For me this part about preparation is the hidden value of this approach. For most interviewees the interview isn't a 2 hour process, it's far more time spent in potentially-irrelevant preparation. It seems like companies might as well turn that time into a more direct skills evaluation.
  - bmj 13y ago
    And, if I'm reading you correctly, it may end up being a benefit to the interviewee, too. At the end of the process, whether I got the job or not, I have additional "implemented X in Y" experience.
    - Bartweiss 13y ago
      I'm slightly embarrassed to say that didn't even occur to me, but yes. It makes the interview experience helpful for something other than more interviews.
justincormack 13y ago
Given the average success rate of interviews is relatively low this is probably a complete waste of time. If I am expected to do projects like that I am going to do some open source code I care about not stupid interview questions extended to a week...
hox 13y ago
If I were looking for a job, I would really only consider a 10+ hour "take-home" interview if I already had extensive dialog with the employer, met their team, and determined proper fit given my background. I also don't know if I would be willing to put in the time if I was still competing with others for the same position. I know that I would not be able to put in as much free time as others, and devoting that much time to something that might only be used as a measure for comparison is a waste of my time.
enraged_camel 13y ago
What do you think will be the quality of work produced by someone who works all day at their regular job, and then after putting the kids to bed at 10pm, works for another 2-3 hours on the contract project you assign them as part of the interview process, and does this for a week straight? Personally, my brain is completely fried by the time I get home in the evening.
skittles 13y ago
I've always assumed those companies are weeding out older applicants. They are going after fresh graduates who are smart. That's all they want.
fieldforceapp 13y ago
Left a comment above, but thought I'd ask again... anyone have any experience with GroupTalent [1] which seems to enable this type of small-contract-as-an-interview process? [1] https://grouptalent.com/welcome/ https://grouptalent.com/welcome/
- thestoic 13y ago
  Hi - I am the founder of GroupTalent. Mahmoud above has had experience on the hiring side of our platform. I can put you in contact with other devs (with their approval of course) who are doing try-outs and they will relate their experience directly.
roycoding 13y ago
I agree that it seems unrealistic to expect someone who is currently employed to put everything down for a few weeks to do a trial project. I've only agreed to them when I was already between jobs. Of course the prospect of multiple weeks-long projects before finding a good position doesn't sound very thrilling. Not sure there is a perfect solution.

jlees 13y ago

I've seen companies do a "challenge" style interview, where it's less of a contract and more of a "take this problem home, code something up to solve it, push to github and let us know when you're done". Then the interview portion is discussing the solution. It means you can calibrate across candidates better, but I think the advantage of an onsite contract job is the two-way feedback, especially in a smaller company.

anonymoushn 13y ago
My current company does this. It seems to work pretty well, but it has some of the same problems as other methods. In particular, the standards applied to the solution vary greatly from "Does it work and run at most 40x slower than expected?" to "It heap-allocates things that could be stack-allocated, so we should pass".
- jlees 13y ago
  Hmm, how about applying the same standards to the solution as you would to internally-committed code (peer reviews, etc)?
ataggart 13y ago
In my experience, these take home projects are woefully underspecified. Do they know this and expect me to email them with "good questions"? Or want me to not email them and "fill in the blanks" on my own? Do they want something that "just works"? Or something that is "reusable"? And so on. There's a reason we don't write production code by just throwing a document over the wall.
- zecho 13y ago
  We do this at my job. We try to come up with projects that are good fits for the candidate, usually a small version of a problem we've recently dealt with. It's not a first line, though. We tend to start by actively recruiting/headhunting. We cherish recommendations from current or past employees, but we'll also open the position to all on the off chance we get a good application through traditional routes. HR only becomes involved with the process after an offer has been accepted or if the hiring manager has questions/concerns. After an informal lunch with the hiring manager, you'll be invited to meet with some senior developers for about an hour. These meetings are mostly to figure out what the candidate thinks their strengths and weaknesses are and gives us a chance to talk about the stuff we plan to work on in the near and not-so-near future. Once we have a fairly basic understanding of each other, we'll come up with a project. Think your strength is on the front end? Here's an API we wrote. Build a widget with the data. Think you're strongest at databases? Great, here's a database project. We don't care if you have a lot of questions or if you fill in the blanks. We give as little direction as possible at first on purpose. Write it in whatever language you want to write it in. We want to see how the candidate works. If they ask questions, great. If they don't, great. Do they ship something? We make sure to stress there's no wrong answers. At all. The projects are designed around your perceived strengths because we'll figure out your weaknesses and will compensate for those during the 90-day trial period all new hires have to go through anyway. The point is to see something we can discuss in a later, final round. Even failure to complete is acceptable, so long as you can articulate why. None of this is hard and fast. We have had candidates who, for whatever reason, can't or won't write code outside of their current position. We'll adjust. Our process isn't rigid at all. We try our best to take a holistic approach. It's only bit us in the ass twice, mostly due to culture issues because the hiring manager made his decisions unilaterally. Since then, all senior devs and a few others on the team meet all candidates before hire and can give management input.
scrabble 13y ago
This is the way the company I work for currently does it. They provide the candidate with a piece of terrible code, ask for a code review of as many issues as the candidate can find, and also for a refactored copy of the code. Both of which are completed remotely on the dev's own time. This is before even meeting the candidate in person. Once we meet in person for the first time, another terrible piece of code is provided -- in this case a basic data structure -- and another code review is requested. The candidate is given 15 minutes to complete it. It's interesting what comes back. Some people comment only stylistic issues, others only logical or architectural issues. One person got up and left during their alone time. Other than these, no coding is required. So far, it's worked out pretty well. And when I was going through it, I enjoyed it.
- BrandonM 13y ago
  I think that a lot of companies forget that they are also being interviewed during their interviews. Were I to interview at your company, I would think that your employees spend most of their time performing code review. I would probably walk out, too.
  - scrabble 13y ago
    I can understand that take on it. Our take is more that if you can recognize what is wrong with the code on multiple levels then you can most likely write good code. This is easier to check on non-trivial code when done through a code review then by getting the interviewee to write the same kind of code that every other interview looks for. The submitted code sample does this as well. I'd also want people on my team to be able to successfully refactor legacy code just by looking at it and being able to identify where things can be better cleaned up and tested.
    - BrandonM 13y ago
      I am completely behind code review and refactoring. I am our company's Chief Refactorer (a title I just made up, but it's accurate), and after instituting code review a few months ago, it has made our development process so much better. At this point, I hate merging in a feature that I've written without having someone else review it. So that's not my issue. I was pointing out that your interview process seems to involve only code review, based on your comment above. Put yourself in an interviewer's shoes: in two different instances, you've been presented with bad code and asked to code review it. Personally, I would be concerned that (1) your company writes bad code, and (2) I'm going to be expected to spend all my time reviewing and fixing other people's bad code instead of writing code myself. Now I doubt that's actually the reality of working at your company (at least I hope so!), but first impressions are very important, and that's what your interview process would tell me if I were interviewing there.

ig1 13y ago

It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).

thedufer 13y ago
This is the root of the problem with contract-as-interview, as far as I can tell. It wouldn't be completely unreasonable for someone to take a few days off from their job to interview (although I wouldn't do it). But both of the points you mention are standard for creatives, at least in the US, so I don't know how many people you'd legally be able to interview.
nrivadeneira 13y ago
You could make it a short take-home assignment where the code doesn't get used by the interviewing company and the assignment is short enough that the interviewee doesn't feel like they need to get paid for it. It would basically be the same as doing it in-person but removes the added stress of the over-the-shoulder scrutiny, leading to a more realistic scenario where a developer has resources such as Google and Stack Overflow at their disposal. In my engineering days, a company I interviewed for had me prototype some stuff in SolidWorks but gave me the courtesy of working alone. I just had to tell them when I was done. Even this was much more preferable to an in-person on-the-spot tech interview. I got an offer for that job, but if I had to perform the same task with someone watching, I don't think it would have gone as well.
pkinsky 13y ago
How would this be enforced? I suppose it could end up being more of a problem for the hiring company after this practice became more widely known.
driverdan 13y ago
You're a fool if you'd sign away copyrights to all work you do outside of your place of employment. Actually, that shouldn't even be legal.
13y ago

comrade_ogilvy 13y ago

"I often wonder about the quality of the people they hire as I have yet to run into a talented dev who would quit their current job to do this one week contract for hire option." I wonder that, too. The very best people usually have a job that they like well enough, but might change jobs for a real offer. "Quit your job and we will probably hire you" is not so attractive to experience people, who are usually no longer in their 20s. Even if a developer were inclined to give it a go on his or her vacation time, most employment contracts require notification for taking on additional employment -- it is rather awkward and annoying to the candidate to jump around these hoops.

bmj 13y ago

Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense. Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at least 10 hours preparing for it (with perhaps only a bit of assurance that I had prepared properly). If I were given a ~10 hour contract project, I would know the problem up front, and be free to complete it without the stress of a whiteboard session.

Bartweiss 13y ago
For me this part about preparation is the hidden value of this approach. For most interviewees the interview isn't a 2 hour process, it's far more time spent in potentially-irrelevant preparation. It seems like companies might as well turn that time into a more direct skills evaluation.
- bmj 13y ago
  And, if I'm reading you correctly, it may end up being a benefit to the interviewee, too. At the end of the process, whether I got the job or not, I have additional "implemented X in Y" experience.
  - Bartweiss 13y ago
    I'm slightly embarrassed to say that didn't even occur to me, but yes. It makes the interview experience helpful for something other than more interviews.

justincormack 13y ago

Given the average success rate of interviews is relatively low this is probably a complete waste of time. If I am expected to do projects like that I am going to do some open source code I care about not stupid interview questions extended to a week...

hox 13y ago

If I were looking for a job, I would really only consider a 10+ hour "take-home" interview if I already had extensive dialog with the employer, met their team, and determined proper fit given my background. I also don't know if I would be willing to put in the time if I was still competing with others for the same position. I know that I would not be able to put in as much free time as others, and devoting that much time to something that might only be used as a measure for comparison is a waste of my time.

enraged_camel 13y ago

What do you think will be the quality of work produced by someone who works all day at their regular job, and then after putting the kids to bed at 10pm, works for another 2-3 hours on the contract project you assign them as part of the interview process, and does this for a week straight? Personally, my brain is completely fried by the time I get home in the evening.

skittles 13y ago

I've always assumed those companies are weeding out older applicants. They are going after fresh graduates who are smart. That's all they want.

fieldforceapp 13y ago

Left a comment above, but thought I'd ask again... anyone have any experience with GroupTalent [1] which seems to enable this type of small-contract-as-an-interview process? [1] https://grouptalent.com/welcome/ https://grouptalent.com/welcome/

thestoic 13y ago
Hi - I am the founder of GroupTalent. Mahmoud above has had experience on the hiring side of our platform. I can put you in contact with other devs (with their approval of course) who are doing try-outs and they will relate their experience directly.

roycoding 13y ago

I agree that it seems unrealistic to expect someone who is currently employed to put everything down for a few weeks to do a trial project. I've only agreed to them when I was already between jobs. Of course the prospect of multiple weeks-long projects before finding a good position doesn't sound very thrilling. Not sure there is a perfect solution.