> if yes then offer a year contract with 1-3 months of evaluation period
Contract work is a great way to find good talent, but it's a different candidate pool. Lots of good candidates can't or won't give up their full time jobs to take a time-limited contract job.
Those who can take contract work are often more talented and more in demand, meaning they're less worried about finding another job if the contract isn't renewed. Contract work (without benefits) is not an option for a large number of developers.
"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.
I initially applied for shorter contract gigs, but I found they had the same interview process as full-time salaried gigs. In the future I'll push back on some of the interview requirements for contract work.
That's an unacceptable offer for a lot of higher-tier developers. Literally un-acceptable - I'd never get poached by a contract-to-hire, especially one with no benefits. And even if I was forced to accept such a situation, I'd continue to send out resumes and take interviews while on contract-to-hire.
The contract to hire contracts I've worked as a developer the past 30 years were either 3 month or 6 month periods and 40 hours per week.
No offense but I'd be highly suspicious of someone offering contract to hire only 10 hours per week, it doesn't sound like the company has much skin in the game.
Many employment contracts prohibit doing additional contract dev work. I agree the spirit of contract to hire is great, but worth noting it won't work for everyone.
The contract to hire approach is great for the company if the applicant accepts it, but any good applicant would not because the applicant would simply take another full time job with benefits instead. Especially in today's market.
Totally agree with your points here. I think it's also great to start with a short-term contract before deciding if you want to become a full-time employee. Just like how people usually date for a while before getting married. Becoming an employee is a big commitment, especially at early-stage startups.
(I'm currently looking for a 1-2 month contract if anyone is looking for a full-stack web/mobile developer. Experience with Rails, React, React Native, TypeScript, AWS.)
Different strokes for different folks, but I immediately dismiss any job posting that mentions contract to hire. Even if it's a 2 week trial. I have a mortgage to pay and regular expenses, and given I've had secure full-time development work for over a decade, I would never jump from a secure job to a contract position where a company does not have to offer benefits or even the courtesy of actually firing me so I can collect unemployment. If a company wants me to have wizard of oz style interviews, sure, I'll jump those hoops until I have an offer from a company I like. But I'm not going to sit in financial limbo while a company decides if I'm worth keeping or not.
Of course for someone just starting in the industry, or comfortable with contract work, this might be fine. But I imagine many SWEs have no interest in contract to hire for similar reasons.
All of you guys are imagining some sort of 6 month junky contract to hire situation. All I'm talking about is a 3-10 day contract like the article mentions.
An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in.
An employed candidate can do the work in off-hours.
I agree with your approach. As a junior developer I got my big break by agreeing to join as an hourly contractor while I proved myself, with the hope of being brought on full time should my performance be sufficient. Lucky for me, the company was not lying and they brought me on and the rest is history. We all have heard those horror stories about companies who claim to do the contract-to-hire thing but have no intention to make good on the promise, so this is a risky path for the candidate.
"Have the candidate come in to work with you for a day. "
I'd only agree to this if I got paid for it. Interviewing is one thing, but actively contributing to a company's codebase is another. I don't think it's asking too much to get paid for what I do.
Plus, it would be difficult for me to shake the impression that such a company is cheap and is trying to get free labor. If they're not going to pay me a day's pay, how can I trust them to pay me a yearly salary or provide me the tools I need? How likely are they to be in business a year from now?
In the 2004-2007 timeframe, the company I worked for hired software engineers via a staffing company for three-month contracts. We interviewed the candidates with the intention of making a full-time hire. As the contract term approached, the management team did a 360 review, the decided to offer a full-time position or just not-renew the contract. This had some downsides, but overall I found it to be better that alternate approaches I've tried before or since. It stopped being viable once software engineering became a sellers market.
I am tired of being offered $120k for a 3month contract without things like parking, vacation, and health benefits. I am lucky to be employed full time currently. I always ignore recruiter calls of that kind because what it really means is $30k for 3 months, which creates a "mercenary" job environment out of what should really be a more full time/stable developer job environment. I can do that by marketing my own skills. Employers need to end the short-term hiring practices, they're artificially boosting the economic outlook and creating shoddy work that is a piecemeal result of several developers that work on DEV projects temporarily.
> Which of those 5 do I give the short term contract gig to? So you're back to the same problem.
Ideally, all of them. It's not hard to find a couple one-off tasks that you'd like to see done in a day. Or could could proceed sequentially until you find one whose work you like.
Nobody said you needed to give contract work to everyone and their dog, or that it was specifically a great idea if you get a million applications (proverbially or literally).
If it's clearly not a good fit then this wouldn't be offered. If you are doubting then this could be a good way to make a decision with the most information you could possibly have, low risk for the company, the applicant gets paid when they might otherwise be between jobs... there are the caveats mentioned in sibling threads, but in some cases, yeah I can see this being a good idea.
We recently rejected someone and I still think that was the right decision, but there is still a chance it wasn't. I wouldn't have minded giving them some contract work to find out if they were competent and just terrible at showing it in an interview. I didn't realise this was even an option. Though in this case it probably wouldn't have worked out due to them currently having a job.
Unless I'm currently unemployed, if someone asked me to do this I would politely say, "thank you, but no thank you." It has been my experience that there are oodles of development and operations jobs out there and not enough candidates to fill the positions. As a prospective employee, if I have multiple companies interested in hiring me, I'm not going to take days off of work in the off-chance that I might get an offer from you. And giving that time up for free is a non-starter. At least pay me a market-rate contracting fee.
I keep hearing this advice repeated. Maybe I live in Crazytown, but I doubt it's realistic at any scale and likely self-selects for young, inexperienced, or presently unemployed candidates.
It doesn't have to be for free. I know someone who would "hire" potential candidates for a 2-week contract, and based their skill on the code they write during that time. If the candidate doesn't end up getting hired afterwards, he still gets paid for his time. It's a win-win.
It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.
I think that's why a lot of companies are now doing contract-to-hire. First they let the contracting agency do the pre-screening, and if the employee doesn't work out the contract just doesn't get renewed.
Only problem is for the employee -- it is difficult during the contract phase, if they don't get any feedback if they will be converted to an FTE, and the lack of benefits. So for the hiring company, they will no be able to steal away any good developers who are currently fully employed.
Contract work is a great way to find good talent, but it's a different candidate pool. Lots of good candidates can't or won't give up their full time jobs to take a time-limited contract job.
Those who can take contract work are often more talented and more in demand, meaning they're less worried about finding another job if the contract isn't renewed. Contract work (without benefits) is not an option for a large number of developers.
reply