5 ms·

Exactly. It's not uncommon for design firms (interactive and motion) to conduct a probation period with potential employees by paying them a freelance rate for

by colmvp 13y ago

Exactly. It's not uncommon for design firms (interactive and motion) to conduct a probation period with potential employees by paying them a freelance rate for a few months prior to writing an offer. That's also why I balk at companies that give take home tests to screen applicants.

tptacek 13y ago
FWIW: the practice of having prospective employees do a probation period as a contractor is (take your pick) unreasonable and/or counterproductive.
- gruseom 13y ago
  It does seem like the mechanisms people have come up with for this so far are counterproductive. But the underlying problem seems to me a real one, and a hard one: how can you tell whether someone will be good to work with? The only way to know is to actually work with them. So (the argument goes) rather than relying on bogus predictors, let's just test the hypothesis "this person will be a good addition to our team" directly. Since you think about hiring a lot, I'm curious: do you think the above is accurate? If no, how would you phrase it differently? If yes, how would you recommend testing that hypothesis instead?
  - tptacek 13y ago
    I think it's very accurate, and I think the idea of temp- to- perm hiring is seductive for exactly that reason. In addition to the argument that the economics of temp- to- perm don't work out in this market for tech talent, there are also fundamental problems with the approach. Most importantly: lots of people can perform well for short periods of time, especially if they don't have to deal with interpersonal conflicts (which take time to develop) or technical design disagreements (which only happen at inflection points in product/service design; ie, it might take 8 months to discover whether someone can "disagree and commit" to work on a team where they disapprove of some technical decision). Also, lots of people can work well on a project for a couple weeks before they get bored, and some of those people lack the ability to kickstart their engagement back up again once they feel "burned out" by a problem domain. I think those are some of the most likely failure modes of new employees, and they also happen to be different from the failure modes that classic interviewing and work-sample testing are likely to suss out; ie, you can cover the non-psychological non-work-ethic concerns about new candidates with a relatively straightforward hiring process, so temp- to- perm might not even buy you much even if you don't assume that the approach is costing you the best candidates.
    - deleted 13y ago
      [deleted]
- andrewflnr 13y ago
  I'm not sure I see the difference between the freelancer->fulltime and contractor/probation->fulltime progressions. Is is just because in the latter case they weren't already a freelancer/contractor? Is there a big terminological issue I'm missing?
  - tptacek 13y ago
    The two issues (unfairness and inefficiency) are somewhat orthogonal. So let me just guess that you're referring to the "inefficiency" side of the problem. The problem is that companies looking to fill full-time slots are looking to fill full-time slots, not to engage a succession of contractors. By requiring candidates to perform in a contractor role prior to signing on full-time, companies are effectively disqualifying most candidates that are currently employed. That's because very few people sniffing around for a better job than the one they have now can afford to drop out of the market for months or even weeks delivering work as a contractor. That's not how most people switch jobs; instead, most people search for their new job from the comfort and security of their current job, knowing that if (say) interviews don't work out, they can take their time looking for the next lead, knowing that they can continue to execute on their current job. This is a problem for employers because virtually everybody you'd want to hire in this market is already employed.
    - mechanical_fish 13y ago
      And those who aren't full-time employed may not bite on the contract-to-perm offer either. Because in my limited experience "here's our contract-to-perm offer" usually translates to: "Please freelance for us at sub-market rates, under our poorly-thought-out non-negotiable boilerplate contract with unclear deliverables." Typically they offer to take a slightly-low full-time weekly salary+benefits number, divide it by 40, and pay that as an hourly rate. Oh, goody. No company wants to pay a contractor the going rate for contractors, and then face the unenviable task of talking that contractor's rate back down again when making them a full-time offer. Nor do they want the bother of haggling over the details of a contract deal that will almost always prove, one way or the other, to have been a wasted opportunity. (If the worker proves to be competent, the contract will be replaced by a full-time offer as quickly as possible. If the worker is incompetent, the contract will be terminated at the earliest practical date. In no case does anyone care much about the contract. It is a consolation prize for everyone involved.) My personal philosophy is to treat contracting and employment like oil and water. Both can be tasty. But they are different things and one does not merge seamlessly into the other.
- ghempton 13y ago
  Calling it a "probation" period is creating a loaded discussion. It can be in the developer's interest to find a job that really interests her rather than give a full-time commitment based off of an interview.
Zimahl 13y ago
Ugh, the take-home test/coding assignment. I've done two of these and I will never do another. Bottom line, if a company can't be bothered to respect that the time the interview process eats up for both parties, they probably aren't going to be worth spending their time with long-term.
- tptacek 13y ago
  Interesting. Why do you feel this way? We rely on "take-home" (they're set up in advance of the f2f interview) work-sample tests pretty extensively, and I feel like they're probably more humane; for instance, you can look things up on the Internet, do them in a comfortable setting, &c.
  - ciclista 13y ago
    How long do you usually expect these tests to take? Do you pay for the interviewees time?
    - tptacek 13y ago
      No, we don't. And, a couple hours. The time commitment we demand from candidates is calibrated to be about the same as you'd demand from a (rigorous) day of on-site interviews. Our on-sites are a half-day thing, not a full-day.
  - ardit33 13y ago
    Good developers have always a project that they are working on. Be either an open source project, app, game, little library, whatever. Working on a take home assignment is just a waste of time, where that person could be working on something useful. Or they could be spending that time with their kids, friends, or just relaxing. The only time it is ok to ask for a take home assignment is when the person is at most a couple of years out of school, and they haven't proven themselves yet. I personally refuse doing to do take home assignment as I have enough projects in my belt that I can show. It is usually a sign that the other party is not mature enough, and they don't know what they are looking for, and once you join that company they will treat like a junior engineer, when you might be past that.

by colmvp 13y ago

tptacek 13y ago

FWIW: the practice of having prospective employees do a probation period as a contractor is (take your pick) unreasonable and/or counterproductive.

gruseom 13y ago
It does seem like the mechanisms people have come up with for this so far are counterproductive. But the underlying problem seems to me a real one, and a hard one: how can you tell whether someone will be good to work with? The only way to know is to actually work with them. So (the argument goes) rather than relying on bogus predictors, let's just test the hypothesis "this person will be a good addition to our team" directly. Since you think about hiring a lot, I'm curious: do you think the above is accurate? If no, how would you phrase it differently? If yes, how would you recommend testing that hypothesis instead?
- tptacek 13y ago
  I think it's very accurate, and I think the idea of temp- to- perm hiring is seductive for exactly that reason. In addition to the argument that the economics of temp- to- perm don't work out in this market for tech talent, there are also fundamental problems with the approach. Most importantly: lots of people can perform well for short periods of time, especially if they don't have to deal with interpersonal conflicts (which take time to develop) or technical design disagreements (which only happen at inflection points in product/service design; ie, it might take 8 months to discover whether someone can "disagree and commit" to work on a team where they disapprove of some technical decision). Also, lots of people can work well on a project for a couple weeks before they get bored, and some of those people lack the ability to kickstart their engagement back up again once they feel "burned out" by a problem domain. I think those are some of the most likely failure modes of new employees, and they also happen to be different from the failure modes that classic interviewing and work-sample testing are likely to suss out; ie, you can cover the non-psychological non-work-ethic concerns about new candidates with a relatively straightforward hiring process, so temp- to- perm might not even buy you much even if you don't assume that the approach is costing you the best candidates.
  - deleted 13y ago
    [deleted]
andrewflnr 13y ago
I'm not sure I see the difference between the freelancer->fulltime and contractor/probation->fulltime progressions. Is is just because in the latter case they weren't already a freelancer/contractor? Is there a big terminological issue I'm missing?
- tptacek 13y ago
  The two issues (unfairness and inefficiency) are somewhat orthogonal. So let me just guess that you're referring to the "inefficiency" side of the problem. The problem is that companies looking to fill full-time slots are looking to fill full-time slots, not to engage a succession of contractors. By requiring candidates to perform in a contractor role prior to signing on full-time, companies are effectively disqualifying most candidates that are currently employed. That's because very few people sniffing around for a better job than the one they have now can afford to drop out of the market for months or even weeks delivering work as a contractor. That's not how most people switch jobs; instead, most people search for their new job from the comfort and security of their current job, knowing that if (say) interviews don't work out, they can take their time looking for the next lead, knowing that they can continue to execute on their current job. This is a problem for employers because virtually everybody you'd want to hire in this market is already employed.
  - mechanical_fish 13y ago
    And those who aren't full-time employed may not bite on the contract-to-perm offer either. Because in my limited experience "here's our contract-to-perm offer" usually translates to: "Please freelance for us at sub-market rates, under our poorly-thought-out non-negotiable boilerplate contract with unclear deliverables." Typically they offer to take a slightly-low full-time weekly salary+benefits number, divide it by 40, and pay that as an hourly rate. Oh, goody. No company wants to pay a contractor the going rate for contractors, and then face the unenviable task of talking that contractor's rate back down again when making them a full-time offer. Nor do they want the bother of haggling over the details of a contract deal that will almost always prove, one way or the other, to have been a wasted opportunity. (If the worker proves to be competent, the contract will be replaced by a full-time offer as quickly as possible. If the worker is incompetent, the contract will be terminated at the earliest practical date. In no case does anyone care much about the contract. It is a consolation prize for everyone involved.) My personal philosophy is to treat contracting and employment like oil and water. Both can be tasty. But they are different things and one does not merge seamlessly into the other.
ghempton 13y ago
Calling it a "probation" period is creating a loaded discussion. It can be in the developer's interest to find a job that really interests her rather than give a full-time commitment based off of an interview.

Zimahl 13y ago

Ugh, the take-home test/coding assignment. I've done two of these and I will never do another. Bottom line, if a company can't be bothered to respect that the time the interview process eats up for both parties, they probably aren't going to be worth spending their time with long-term.

tptacek 13y ago
Interesting. Why do you feel this way? We rely on "take-home" (they're set up in advance of the f2f interview) work-sample tests pretty extensively, and I feel like they're probably more humane; for instance, you can look things up on the Internet, do them in a comfortable setting, &c.
- ciclista 13y ago
  How long do you usually expect these tests to take? Do you pay for the interviewees time?
  - tptacek 13y ago
    No, we don't. And, a couple hours. The time commitment we demand from candidates is calibrated to be about the same as you'd demand from a (rigorous) day of on-site interviews. Our on-sites are a half-day thing, not a full-day.
- ardit33 13y ago
  Good developers have always a project that they are working on. Be either an open source project, app, game, little library, whatever. Working on a take home assignment is just a waste of time, where that person could be working on something useful. Or they could be spending that time with their kids, friends, or just relaxing. The only time it is ok to ask for a take home assignment is when the person is at most a couple of years out of school, and they haven't proven themselves yet. I personally refuse doing to do take home assignment as I have enough projects in my belt that I can show. It is usually a sign that the other party is not mature enough, and they don't know what they are looking for, and once you join that company they will treat like a junior engineer, when you might be past that.