7 ms·

So here's the problem: 1) A great way to assess your technical chops is to watch you code. 2) A great way to see if you can do the actual work that you'll be

by jawns 13y ago

So here's the problem: 1) A great way to assess your technical chops is to watch you code. 2) A great way to see if you can do the actual work that you'll be expected to do on a day-to-day basis is to work on a real-world task on the team's actual codebase. 3) If you have what it takes, then it's crappy to have you "work for free" for a day. But if, after the day's over, it's clear that you don't have what it takes ... then have you really "worked for free"? (Remember, freelancers don't get paid unless they deliver.) Here are some ways to address this problem: 1) Do paired programming on the actual codebase -- but on an old problem, the solution to which has already been implemented in production. This makes it clearer that the exercise is merely to assess your skills and not to get free labor out of you. 2) Pay all in-person interviews for their time. Once they've passed the phone screen and whatever other preliminary hurdles you've set up, you should feel pretty good that they're not just wasting your time. So compensate them. 3) If you don't have the budget to do #2, which -- let's face it -- is uncommon, then perhaps you could offer a signing bonus to anyone you end up hiring that essentially repays them for their time.

josephlord 13y ago
Regarding solution (2) it is probably that you should offer to pay for their time. Many people can't accept paid work under their current contracts. Also whatever the plan if the interview is going to be for more than a couple of hours let the interviewee know the rough plan in advance.
iamthepieman 13y ago
4) Do paired programming on an actual feature or problem for an hour or two. Work with your potential team members and discuss the feature, do some rapid prototyping etc. The assumption isn't that your code will be deployed at the end of the day, but that both side will get to see how the other works and you don't waste too much of anyone's time if it's not a good fit.
VLM 13y ago
"perhaps you could offer a signing bonus" Comp time. You wasted a vacation day at your previous employer by "working" here so your official start date is Friday but don't bother coming in until Monday morning. Seems simple enough. Or you come into work on your start date but I'm not giving you any work assignments of any sort for n+1 days where n is whatever is normal (zero?) Or start on Monday but don't bother coming in the following Friday.
ijk 13y ago
> (Remember, freelancers don't get paid unless they deliver.) Not if the freelancing contract has a kill-fee or partial payments upfront. Both of which are really good ideas, because they prevent clients from taking advantage of freelancers.
- raverbashing 13y ago
  I had to look up the definition of a kill-fee http://freelancewrite.about.com/od/glossary/g/KillFee.htm http://freelancewrite.about.com/od/glossary/g/KillFee.htm
raverbashing 13y ago
Pay the people for their time "freelancers don't get paid unless they deliver" Well, depends. If you're having a clear deliverable I agree, if you're getting them for staying there and following the team, pay the person.
antjanus 13y ago
So here's MY opinion on the problem: 1. I totally agree with that. Yeah, watch someone code. Do a short hackathon. But not a day's worth. Seriously. 2. Using the actual codebase is fine but the interview starts to stink when the interviewer says "I gotta get this pushed live by the end of the day so let's get 'working'". It's not about "is he genuine?", it's about "that's a little weird, does he even want to interview?" 3. Here's an issue. What if you have 10 great people. I've been in a hiring process where it was DIFFICULT to find a person. So you get 10 days worth of free work and have to hire someone based on OTHER metrics. Be it budget, their demeanor, or whatever else. Also, freelancers (same as contractors) get by the HOUR unless contractually provided otherwise. Meaning that it's not just about the deliverables. If I was doing freelance work on a big project, had a scope, I'd get paid by the hour. If the company cut me off (didn't let me finish), they would pay for that hourly work, not for what I delivered. Same with scope revisions and other stuff like that. Sometimes you even work for a company HOURLY, doing random work that they need done. Again, it's HOURLY.
bane 13y ago
This topic comes up here all the time and I'm always shocked to see that this is even considered as a hiring practice and I'm surprised it's not outright illegal. This problem exists in every field and for every kind of job. Nobody takes seriously the notion that a book-keeper candidate should do your accounting for a day to see if they should be hired, or have a contract manager negotiate a contract for a day for free, or a designer design for you for a day. So why are developers freed from this? Because it's feasible for a developer to sit down in front of a terminal for a few hours and start hacking away? Here's part of the problem from the candidate PoV 1) It's slave labor (obvious) and opens you up for a never ending series of small, but annoying lawsuits if you don't hire the candidates. 2) Candidate doesn't know if you're serious about hiring, or just doing a cattle call. There's a lot of reasons companies do this, but it's a practice used by some very well funded startups that wastes unbelievable amounts of people's time and is like a cancer in the industry. 3) Candidate likely has plenty of other irons in the fire, and your company isn't a special snowflake. If they're currently employed it's even worse as they have to figure out how to take time off of work to waste doing free work for somebody else. Now let's say they have to do this for the 20 companies they applied to, that's a month off of work! 4) Development on complex codebases is hard, most engineering companies don't really expect a new hire to be very productive on their codebase for a few months at best. It doesn't actually test them on their day-to-day as much as anybody might think, because their day-to-day job function will rapidly change over their first six months as they start to wrap their brains around the work. What is appropriate? 1) Ask for a portfolio, open source projects, other work they've done, etc. Hopefully they have some kind of work history they can show off. 2) Irritating, but ask them to complete basic development tasks -- fizzbuzz is a good example. Surprisingly, most bad engineers will be stumped by surprisingly simple questions like "write a for loop" or "write a basic SQL query". If they pass that, ask more and more complex questions until they're at the level you need. You can usually figure out a candidate's skillset within 10 questions. But please, don't waste anybody's time with brain teasers and puzzles and other nonsense. Keep it focused and keep it real. 3) Actually have a conversation with the candidate. Plumb their knowledge. Ask them about various frameworks they've used, or languages they've experimented with or whatever. People who know their stuff can usually talk endlessly about their past experiences, people who don't can't and you end up with "well....C++ is nice, but Lisp is a great language!". Too many hiring processes forget this part of interviewing because it takes practice to get good at "interrogating". But it gets you so much soft information about a person as well. 4) With questionable candidates that you're 50-50 on, be open to offering probationary employment. 30-days, or 90-days or something. It must be well structured (weekly check-points, options to leave after the first 30 days, etc.), and you have to take it seriously. It's up-to the candidate if they want to take this or move on to other opportunities. If they move on, nobody's time was wasted. If they really need something right now and they take it, you have some exit valves if they stink, and if they're promising you can adjust final employment one-way or the other. 5) Something I hated at first, but have come around to a bit is the idea of a take-home problem they can work on at their leisure. Perhaps a problem that wouldn't take more than 2-4 hours to work on. Why is this different then having them hack on your code? Because you can make it not-your actual code, and can use it to concisely test exactly what you're looking for. Plus they're not taking time off of work to do this. They can spit-shine and polish their response as much as possible and really show off if they want.
cs02rm0 13y ago
Remember, freelancers don't get paid unless they deliver. Contract developers on a day rate very much do get paid time (and materials). If they can't afford a day of his time to figure out if they want him they shouldn't be interviewing him.
witek 13y ago
One of the common interview questions for a non-technical management/marketing person is: "having researched our market, company and competitive position, what strategies do you think we should pursue?" Imagine if I were an experienced exec or strategy/marketing consultant, came up with a few interesting ideas and demanded to be paid for them on the spot? I'd get laughed out of the room. Similarly, when you sell a consulting project, you're expected to do a certain amount of analysis in your pitch, with no guarantee of being chosen for paid work.
- Ensorceled 13y ago
  But none of them will do 8 hours of analysis and put it into a report.
  - antjanus 13y ago
    I was going to add that. It's one thing where a developer gets asked, "Well, if you could rearchitect (or create) our application, what would you do?" and then discuss what frameworks, where to focus on caching and optimization, discuss technology, paradigm etc. And I've been asked this before, "We serve a million visitors a day, what kind of caching and optimizations would you implement to handle that type of traffic?" Completely fair question. It's another to do that work.
Nursie 13y ago
>> (Remember, freelancers don't get paid unless they deliver.) That depends on the freelancer. I charge a day rate.
badman_ting 13y ago
> Do paired programming on the actual codebase -- but on an old problem That's what I was thinking. Which is why I thought "uh oh" when the interviewer said they needed the features live later that day. So, not only does the coder get to do free work for the interviewer, there's time pressure as well. Sweet!
- ijk 13y ago
  Not to mention shipping a new feature on a codebase you are, by definition, not familiar with. I'd at least want to budget time for testing the thing. Not to mention I have severe doubts in the competence of someone who lets random interviewees edit their live code.

by jawns 13y ago

josephlord 13y ago

Regarding solution (2) it is probably that you should offer to pay for their time. Many people can't accept paid work under their current contracts. Also whatever the plan if the interview is going to be for more than a couple of hours let the interviewee know the rough plan in advance.

iamthepieman 13y ago

4) Do paired programming on an actual feature or problem for an hour or two. Work with your potential team members and discuss the feature, do some rapid prototyping etc. The assumption isn't that your code will be deployed at the end of the day, but that both side will get to see how the other works and you don't waste too much of anyone's time if it's not a good fit.

VLM 13y ago

"perhaps you could offer a signing bonus" Comp time. You wasted a vacation day at your previous employer by "working" here so your official start date is Friday but don't bother coming in until Monday morning. Seems simple enough. Or you come into work on your start date but I'm not giving you any work assignments of any sort for n+1 days where n is whatever is normal (zero?) Or start on Monday but don't bother coming in the following Friday.

ijk 13y ago

> (Remember, freelancers don't get paid unless they deliver.) Not if the freelancing contract has a kill-fee or partial payments upfront. Both of which are really good ideas, because they prevent clients from taking advantage of freelancers.

raverbashing 13y ago
I had to look up the definition of a kill-fee http://freelancewrite.about.com/od/glossary/g/KillFee.htm http://freelancewrite.about.com/od/glossary/g/KillFee.htm

raverbashing 13y ago

Pay the people for their time "freelancers don't get paid unless they deliver" Well, depends. If you're having a clear deliverable I agree, if you're getting them for staying there and following the team, pay the person.

antjanus 13y ago

So here's MY opinion on the problem: 1. I totally agree with that. Yeah, watch someone code. Do a short hackathon. But not a day's worth. Seriously. 2. Using the actual codebase is fine but the interview starts to stink when the interviewer says "I gotta get this pushed live by the end of the day so let's get 'working'". It's not about "is he genuine?", it's about "that's a little weird, does he even want to interview?" 3. Here's an issue. What if you have 10 great people. I've been in a hiring process where it was DIFFICULT to find a person. So you get 10 days worth of free work and have to hire someone based on OTHER metrics. Be it budget, their demeanor, or whatever else. Also, freelancers (same as contractors) get by the HOUR unless contractually provided otherwise. Meaning that it's not just about the deliverables. If I was doing freelance work on a big project, had a scope, I'd get paid by the hour. If the company cut me off (didn't let me finish), they would pay for that hourly work, not for what I delivered. Same with scope revisions and other stuff like that. Sometimes you even work for a company HOURLY, doing random work that they need done. Again, it's HOURLY.

bane 13y ago

This topic comes up here all the time and I'm always shocked to see that this is even considered as a hiring practice and I'm surprised it's not outright illegal. This problem exists in every field and for every kind of job. Nobody takes seriously the notion that a book-keeper candidate should do your accounting for a day to see if they should be hired, or have a contract manager negotiate a contract for a day for free, or a designer design for you for a day. So why are developers freed from this? Because it's feasible for a developer to sit down in front of a terminal for a few hours and start hacking away? Here's part of the problem from the candidate PoV 1) It's slave labor (obvious) and opens you up for a never ending series of small, but annoying lawsuits if you don't hire the candidates. 2) Candidate doesn't know if you're serious about hiring, or just doing a cattle call. There's a lot of reasons companies do this, but it's a practice used by some very well funded startups that wastes unbelievable amounts of people's time and is like a cancer in the industry. 3) Candidate likely has plenty of other irons in the fire, and your company isn't a special snowflake. If they're currently employed it's even worse as they have to figure out how to take time off of work to waste doing free work for somebody else. Now let's say they have to do this for the 20 companies they applied to, that's a month off of work! 4) Development on complex codebases is hard, most engineering companies don't really expect a new hire to be very productive on their codebase for a few months at best. It doesn't actually test them on their day-to-day as much as anybody might think, because their day-to-day job function will rapidly change over their first six months as they start to wrap their brains around the work. What is appropriate? 1) Ask for a portfolio, open source projects, other work they've done, etc. Hopefully they have some kind of work history they can show off. 2) Irritating, but ask them to complete basic development tasks -- fizzbuzz is a good example. Surprisingly, most bad engineers will be stumped by surprisingly simple questions like "write a for loop" or "write a basic SQL query". If they pass that, ask more and more complex questions until they're at the level you need. You can usually figure out a candidate's skillset within 10 questions. But please, don't waste anybody's time with brain teasers and puzzles and other nonsense. Keep it focused and keep it real. 3) Actually have a conversation with the candidate. Plumb their knowledge. Ask them about various frameworks they've used, or languages they've experimented with or whatever. People who know their stuff can usually talk endlessly about their past experiences, people who don't can't and you end up with "well....C++ is nice, but Lisp is a great language!". Too many hiring processes forget this part of interviewing because it takes practice to get good at "interrogating". But it gets you so much soft information about a person as well. 4) With questionable candidates that you're 50-50 on, be open to offering probationary employment. 30-days, or 90-days or something. It must be well structured (weekly check-points, options to leave after the first 30 days, etc.), and you have to take it seriously. It's up-to the candidate if they want to take this or move on to other opportunities. If they move on, nobody's time was wasted. If they really need something right now and they take it, you have some exit valves if they stink, and if they're promising you can adjust final employment one-way or the other. 5) Something I hated at first, but have come around to a bit is the idea of a take-home problem they can work on at their leisure. Perhaps a problem that wouldn't take more than 2-4 hours to work on. Why is this different then having them hack on your code? Because you can make it not-your actual code, and can use it to concisely test exactly what you're looking for. Plus they're not taking time off of work to do this. They can spit-shine and polish their response as much as possible and really show off if they want.

cs02rm0 13y ago

Remember, freelancers don't get paid unless they deliver. Contract developers on a day rate very much do get paid time (and materials). If they can't afford a day of his time to figure out if they want him they shouldn't be interviewing him.

witek 13y ago

One of the common interview questions for a non-technical management/marketing person is: "having researched our market, company and competitive position, what strategies do you think we should pursue?" Imagine if I were an experienced exec or strategy/marketing consultant, came up with a few interesting ideas and demanded to be paid for them on the spot? I'd get laughed out of the room. Similarly, when you sell a consulting project, you're expected to do a certain amount of analysis in your pitch, with no guarantee of being chosen for paid work.

Ensorceled 13y ago
But none of them will do 8 hours of analysis and put it into a report.
- antjanus 13y ago
  I was going to add that. It's one thing where a developer gets asked, "Well, if you could rearchitect (or create) our application, what would you do?" and then discuss what frameworks, where to focus on caching and optimization, discuss technology, paradigm etc. And I've been asked this before, "We serve a million visitors a day, what kind of caching and optimizations would you implement to handle that type of traffic?" Completely fair question. It's another to do that work.

Nursie 13y ago

>> (Remember, freelancers don't get paid unless they deliver.) That depends on the freelancer. I charge a day rate.

badman_ting 13y ago

> Do paired programming on the actual codebase -- but on an old problem That's what I was thinking. Which is why I thought "uh oh" when the interviewer said they needed the features live later that day. So, not only does the coder get to do free work for the interviewer, there's time pressure as well. Sweet!

ijk 13y ago
Not to mention shipping a new feature on a codebase you are, by definition, not familiar with. I'd at least want to budget time for testing the thing. Not to mention I have severe doubts in the competence of someone who lets random interviewees edit their live code.