5 ms·
If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire. Anything less is a guess. Every team is
by coldcode 13y ago
If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire. Anything less is a guess. Every team is different, every need is different and every candidate's experience is different. Assuming you can ask a magical question or two and know is the realm of psychics.
- zszugyi 13y agoYou can't do this with someone on a work visa in the US, so this could reduce your pool quite a bit (depending on where you are located).
- chollida1 13y ago> If you really want to know if a (otherwise qualified) developer will fit into your team you should do contract-to-hire The difficulty here is that no one who is even mediocre would ever do a "contract to hire". If they are good they have options and there just isn't any upside to doing a contract for hire when you can take another full time job. Contract for hire is a big red flag!
- beachstartup 13y ago> The difficulty here is that no one who is even mediocre would ever do a "contract to hire". this is absolutely not true. good people will simply demand a high hourly billing rate during the contract phase to compensate for the opportunity cost, which you have to be prepared to pay. sure if you're dicking around with $20/hr "contracts" everyone decent will tell you to kick rocks. have you ever worked with people who are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it.
- chollida1 13y agoI think we're going to have to disagree here. > have you ever worked with people who are used to getting paid $100+/hr? i.e. top people? it doesn't sound like it. I saw this and wondered if you were trolling. It's certainly a rude and undeserved comment, but I'll be charitable and bite:) My main point is that "good" developers, always have options. My assumptions: 1) the developer wants full time work, otherwise they would just do contracting and not contract for hire. 2) jobs are plentiful for good developers. Why would the developer assume all the risk with contract for hire, unless they had no other options? Why not just take the full time job instead? Basically my point boils down to two points... 1) How would a company convince me to do contract for hire work when I can work somewhere else without that risk? What's my upside to doing this? 2) As long as most companies don't' do contract for hire, a company is putting themselves in a position that excludes most talented developers. ie if you aren't facebook, twitter, dropbox, etc. my contention is that the top developers will laugh at your contract to hire request.
- phlo 13y agoDone right, contract-to-hire seems like a great solution to me. It's actually a chance for the employer and employee to get to know each other and make sure their mutual expectations match. Assuming the position were to be salaried at $104k, a sensible agreement might be: - The employee is hired temporarily for a period of one to three months. - Their wage is paid weekly, at a rate of $2k per week (i.e. 1/52 of their expected salary) - The contract may be cancelled by either party with seven days' notice. - At its end, the contract automatically converts to a permanent position. If a signing bonus is called for, it should be due early during the probationary period. A separate bonus for the transition from temporary to permanent employment may not be a great idea as it may incentivize the employer to terminate the agreement.
- rdouble 13y agoThat's the issue. A job explicitly labeled "contract to hire" is never done right. No good developer is going to do contract to hire at 1/52 of the salary, because they already either make an equivalent salary or far more as a contractor. The company isn't going to pay an actual contracting rate, because they are either cheap or can't afford it. Contract to hire is almost exclusively done in places where it's hard for a developer to find a good job and it's used to take advantage of this situation.
- beachstartup 13y ago> A job explicitly labeled "contract to hire" is never done right i don't understand how you and the other guy can make these blanket black and white statements like this. have you guys ever had to hire people based on advertised solicitation only? contract to hire is mainly done in situations where a new employee can not be vouched for by an existing one, or a large number of new employees must be brought on at once. the reason why it's so rare among elite silicon valley firms is because everyone knows each other and recruiting is usually a personal process between existing employees and prospective ones. THIS IS NOT HOW IT IS EVERYWHERE. outside of the echo chamber it's very common and good people can be hired this way.
- gaustin 13y agoIt is actually a good way for some employees to go from proven track record with tech X to building a proven track record with tech Y. Especially for those that don't dedicate a lot of free time to building demos/products.
- MrBuddyCasino 13y agoI don't agree. This is an opportunity for both parties to check each other out, a top dev might want to check the employers claims, too. Too often they are just lying, especially if the market is drained.
- BillyMaize 13y agoTotally agree, I never even touch job openings that are looking for contract to hire. Some companies just want you for a short time and this is a way to get better talent without having to keep them, and I definitely don't want to relocate with the risk they won't need me in six months.
- changdizzle 13y agoNot necessarily true, automattic (makers of wordpress) does this[1] [1] http://automattic.com/work-with-us/ http://automattic.com/work-with-us/
- deleted 13y ago[deleted]
- coldcode 13y agoMaybe in SV it is, but out here in the regular world it's not the uncommon. My current job was contract to hire at a slightly higher rate. I was converted after 4 months. This way both sides were happy with the work environment. In SV there are too many jobs and not enough people so it might be harder to get anyone to do this. But contract works both ways - the prospective employee gets to see if they like the team too. I've taken jobs before direct where the team turned out to be completely evil but it wasn't obvious in the interview.
- michaelochurch 13y agoThe difficulty here is that no one who is even mediocre would ever do a "contract to hire". I would, but at a real consulting rate (over $150 per hour) and not at a salary rate, since it comes with none of the benefits of being salaried. That kind of arrangement is going to lead to adverse selection in the end. At typical tech salaries, you'd be asking me to take a 50% pay cut for (not much) additional job security. The main upshot of being FT (aside from benefits but those don't merit a 50% pay cut) is that it takes ~30-60 days to fire someone without severance. For contractors, they don't have to do that PIP bullshit. But I prefer to plan my career based on upside, not job security/what happens if I'm fired. The rate at which I'd take a contract-to-hire gig is one at which I wouldn't happily convert to full-time, unless there were a huge promotion in the mix. The people who would convert without a big promotion are the ones you don't want, because they plan on coasting.
- gaustin 13y agoI was skeptical of contract-to-hire situations until I did one myself. I got a significant increase my salary in the contract phase (even including what I paid for benefits) and got an increase on top of that at the time of hire (not counting benefits). I was toward the top end of what I could make being traditionally employed locally (Helena, Montana). The remote contract-to-hire opportunity put me on par with folks living in cities, save places like NY and SF, or those working for huge companies. Definitely a good deal for some of us that don't have professional networks that would support consulting. And whatever you might think, I'm not a coaster or I wouldn't have been offered full-time employment.
- mkramlich 13y agoI strongly agree that something like that is the best approach. I'm developing a process I'll call YRR (for Yes, Real and Reciprocal) to define one particular take on this idea. I'm going to try to enforce using it on others, as much as I can, going forward. So tired of people making guesses. So tired of "tell me your life story", so tired of being told I'm under-qualified or over-qualified for things I know I can do and clearly have a track record of doing, etc. So much time wasted on meta instead of doing the real things itself we want. And too many formal/bureaucratic hoops, unpaid, people expect you to jump through. The traditional recruiting/applying/hiring process, at least as its done in the more formal parts of the software development field is badly broken, almost a circus not to be taken seriously. Can it work sometimes? Of course. Could it be done much much better? Hell yes.