Ask HN: Why are hiring processes flawed and testing random standards?
In the end I found what I was looking for. It just seems the hiring processes overall is flawed in many ways.
Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out.
Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner.
There is a fear to pull the trigger compared to local companies. Afraid to take a chance on obvious candidates. Someone with x amount of years in a language but not with a specific framework version. It's like the ability to learn even the smallest thing isn't considered.
Multiple unnecessary rounds of interviews/tests/assignments/group hiring. The long the process ensures the best candidates go elsewhere or are filtered out.
The random unrelated tests.
The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.
Why are the processes so bad?
69 comments
[ 2.6 ms ] story [ 50.7 ms ] threadSecondly, and following up on my first critique, an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires” that should have been sifted out by the hiring process.
There's no truly bulletproof solution to interviewing, because the needs of every org are different, and the skills of interviewers are rarely nurtured to the point of usefulness. Sometimes you just have to luck out and get a good interview.
Whoa, what triggered and justified that response? I don’t know if the parent was edited, but it seems pretty reasonable to me.
> Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs.
What do you mean? Why do companies hire then?
> an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires”
This hasn’t been true in my experience. Why would someone who’s good at the work not tend to be good at interviews?
I’ve interviewed hundreds of people and hired dozens. The number one reason for a candidate not getting a position is that there was another better candidate. More often than not, it has nothing to do with how good the candidate is, nor does it have anything to do with how good the company’s interview process is. After that, there is usually a large number of candidates that are young and shooting above their weight, hoping to get in somewhere with almost enough qualification. Occasionally, that works. I haven’t bumped into anyone yet that was great at interviewing but not good at the work, but like many companies, I’m using the interviews to try and find out if they’ll fit it, and if they’re truly interested, and if they’re good at work.
Nope, no edits. I'm not sure where the bitterness is coming from either, aside from the obvious that they aren't pleased with how recent interviews have gone.
>> What do you mean? Why do companies hire then?
Sadly this is very common -- the bigger and more profitable the company the more common it is. Companies often hire for non-business related reasons for several major reasons:
1. Bench strength -- Hire top talent before you need it so you are ready to fire when you have a strategic project. Ideally, hire away talent your competitors might hire. In many ways, this is a good thing.
2. "Burn the Budget" - Divisions will often lose budget if they dont spend it, and they may lose it in future years when they need it ("well you got it last year and you didnt use it, so this year you dont get it...") -- so many divisions will hire to burn the budget and use it just so they dont lose budget when they really really need it.
3. HR - It is common for HR to institute Crazy-8s policies or some variant of it -- where you only get promoted if you have 8 (or N) people working for you. Naturally all sorts of non business related tasks suddenly pop up and people hire just enough to get promoted. This is very common in organizations where promotion and pay is linked to non business metrics (how much budget you control, how many people report to you) rather than business metrics (revenue delivered, revenue enabled, churn reduced, traffic increased, etc.) Often your boss themselves wants to be promoted and needs 8 middle-managers 8 under them to get promoted. And so on up the chain. Almost half the HR departments in my ~20yr career institute such a policy, whether it is internally known or not. It is of course more common in organizations which are not metrics driven.
#2 is a gray area.
#3 is business burn -- when an organization "needs" to hire loads of people to work on useless projects just to align to rigid HR rules, the business has stopped to drive operations and instead operations are driving the business.
1) Why pay someone to learn? In both terms of money and other devs time being sunk into helping you learn.
2) If you do know "tool X" and its a primary tool then its a lot easier to quickly evaluate whether or not standards will align.
Personally I don't mind hiring Jr Developers that cost less, are mold-able, and are willing to put in extra effort. Could any experienced dev lean it? Sure... but its more costly and often ends up in a "I have now studied X for Y weeks, we do X wrong I refuse to do X your way."
I would say that one of the most important qualities a developer can have is the ability to learn.
Perhaps, you expect all the learning to be done outside of work?
I never claimed learning is not important, if anything I supported that in my comment in hiring eager jr's.
My point being is if I am hiring someone "experienced" I need someone who can mentor others, own projects, and help drive our current products forward. If that person will need to come in and learn the job... I might as well hire a JR and train them up instead or hold our the X months the "experienced" person will need to learn to bypass that whole ordeal.
http://www.mooreds.com/wordpress/archives/2812
Usually when a job candidate is not selected they aren't given any information about why.
https://www.youtube.com/watch?v=v1WiCGq-PcY
I work partial remote and every day I go to the office I wish I was fully remote... not because I hate the office (I love it, and really enjoy my co-workers) but because I hate commuting.
However, it seems like you're exchanging any future/potential at a company for the convenience of working remote which why i was asking if he was retired.
I set out attempting to get a remote position and if that failed I would look locally.
It took almost two months where locally I usually could land a position in a month or less.
Locally is a lot easier for sure.
First, most companies will look for a remote person only after exhausting their local labor pool. If someone remote has to devote their initial months to learning with no advantage over someone local learning the same content, why not go with the added benefit of hiring someone local.
Second, many companies have a fallback person in place who can almost meet the need - maybe they have x amount of years in a language, right attitude, etc. This process is only to see if you are better than their fallback option. The distressing answer sounds to be rarely.
It started with algorithmic interviews. Then, we tried take home assignments. Now, lots of companies are doing pair programming type scenarios including a code review for a more accurate representation of a day on the job. Still, there hasn't been this silver bullet companies are looking for to solve their hiring woes.
I don't know the solve. There's also a large problem with those doing the interviewing being either untrained or unempathetic to the candidates.
For ex my company does hire remote but only senior and more exceptional candidates.
Then you start talking and they ask you a bunch of really stupid questions. The voice in your head starts telling you something is off.
Then they start testing you and giving you the run around. In dating this is known as playing games.
Just like in dating it's time to wake up and realize they are showing you who they truly are. Ignore at your own peril!
* Hiring is a marketplace, and supply/demand is not always balanced, so most issues related to job search/hiring is due to this.
* When a company posts an ad for a job, they usually receive about 150-200 applicants within 2 weeks, thanks to job boards, LinkedIn etc. Unless it is for specific high-skilled jobs, in which case, they receive hardly any applicants at all.
* Most of the applicants are usually not a match for the job, but given the number of applicants, recruiters rely on resumes, social profiles etc to shortlist about 20 applicants.
* Tests and assignments are quick means to filter, hence their popularity.
* Not much of an incentive to keep applicants posted at every step, plus, managing communication with a few hundred applicants for multiple positions is hard - so you're most likely to receive only automated communication from the hiring team.
I believe that having a clear specification of the job, that can be checked/validated with applicants is critical to ensuring a smooth, fast interviewing process.
[1] - Shameless plug to my startup (in beta) - https://www.interviewpass.co. If any of you are interested in using InterviewPass in your hiring, drop me an email at suresh@interviewpass.co - happy to help set it up for you.
But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
It's not just the initial screening. They actively go out and find candidates who otherwise wouldn't be looking for jobs directly. And as I said before, those tend to be prime candidates since they get so many recruiters they have little need to apply directly.
>But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
Again, recruiters are a solution to this because their paycheck is based on closing the deal. They will hound the company and the candidate to get the process finalized.
In my experience this rings true for senior roles and less so for new college grads.
Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner.
I can see why perhaps a candidate receiving a rejection may think this, but in the companies I’ve worked at this has never been the case. It’s always been “it’s really tough finding talent, not paying talent”.
The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.
A fair reviewer recognizes the limitations of these take home exercises. While there are many ways to perform a take-home successfully, there are more ways to show that you aren’t qualified for the role. Not all that pass will be right for the job, but most who fail aren’t.
> In my experience this rings true for senior roles and less so for new college grads.
I agree that I've seen this to be true for senior roles, but what I've noticed on many job descriptions is the reluctance to say they are looking for a senior engineer. I've gone through quite a few phone screens where it becomes immediately apparent that the company is looking only for a senior but the job title and sometimes description looks like it was written for a mid or even junior position. So I can completely understand where OP's view of the hiring process comes from - you go through the initial test round, get to speak to them, then find out that they have extremely specific requirements. If you happen to be unlucky enough to go through many of these, it can really mess with your perspective on the hiring process.
The economics of it are that in many places in the world, it is extremely difficult to fire an employee. Getting rid of an underperformer can take time, effort, and exposes the company to liability if the termination can be construed as relating to the employee being in a protected class (e.g. can't fire someone because she's a woman). Let's assume that it's a SF startup willing to play a little fast and loose and they aren't concerned with severance packages or the legal issues. They still put time and effort into training a new engineer. That's months of work that is potentially wasted.
All of that means that companies are incredibly risk-averse when it comes to hiring, and will pass on someone who looks even slightly wrong to them. It also means that the process is inherently random as a company will pass on someone they aren't sure of _even if they would have been a good hire_ just because they aren't certain. However, this also means that a lot of companies rely on self-selection in their hiring pool. Look for people they already know, from the same backgrounds, or are willing to pass through a series of arbitrary tests.
In short, it's like democracy. It's the worst form of government, except for all the others we've tried.
For a newly hired, you have a probation period, before your contract becomes permanent, usually between a month and a year, where you can be fired on the spot. After that, your contract becomes permanent and you can get fired, no questions asked, with a notice period of usually between one and 3 months.
In theory, before letting you go, the company has to set up a performance improvement plan for you but companies never bother as it's considered wasted effort to invest in under performers so they just warn you at your performance review that your performance is lacking and that this is strike one. After 3 months of performance monitoring you are let go because your performance hasn't improved so that was strike two and you're out.
Sure, you can sue them if you know you've been wronged, and win a few thousand euros, but nobody's gonna hire you knowing you're in a lawsuit with your ex-employer so nobody bothers to sue and prefers to just find another job instead.
So unless you're a protected category, usually over 50 years old, woman or not, doesn't matter or part of some big-corp with strong unions, the hard-to-fire is not an argument that holds water here.
First, in jurisdictions like Ontario, there is a probation period during which a new employee can be fired for no reason at all. They can be a top performer and still get fired, and they have no recourse.
There are Ontario Human Rights exceptions to this, you can’t have a “Cowboys and Squaws Dress Day” and then fire the newly hired First Nations person who objects.
But I have been to a number of management training programs put on by HR consulting firms, and zero of them have said, “Be 100% certain about your new hired, because firing them is difficult and expensive if they don't work out.”
It’s true that after they’ve been around for a while, firing someone without cause entails some costs. But here in Ontario, they are surprisingly low. It’s possible to get sued, and win or lose that costs money and time, so most employers either go through a PIP process before letting someone go, or write a decent but not outrageously large cheque in exchange for agreement.
On the whole, “Avoid all but the most insanely qualified candidate because firing people is hard” is not anything I’ve heard from a professional. At least, not in my jurisdiction.
——-
The above is my recounting my factual experience. And now to my conjectures:
What I have heard from fellow managers has more to do with team morale. Hiring and firing people on a regular basis destabilizes the teams they join.
Hiring people without ensuring they're a decent fit sends a message that the company doesn't value competence.
When such things were in vogue, using bullshit a-hair-to-the-right-of-astrology tests like “How many weights do you need to use a balancing scale to...” acted as a signal to existing employees that they are super smart elite braniacs, and the company values that.
I suspect that a lot of risk-aversion with hiring is a combination of “apocraphyl stories going around the intrnet, but nobody is quoting actual research and case law,” combined with cultural signalling.
At my current employer, there are lots of people who don’t pass our interview system, but when we review a candidate, we are often less concerned with how capable they are today than with our estimate of how amenable they are to growing on the job.
That obviously applies a lot more to people coming in at a lower level, but I assure you that we value great people, but we aren’t insanely risk-averse. Being too risk-averse with hiring is a failure mode, just as being too risk-averse with engineering and product development.
Ah, you're lucky to be living in such an enlightened society. In Switzerland you can still find employers who require handwritten applications because they have them evaluated by professional graphologists!
BTW, don’t scratch your head. It throws off the phrenological screen.
I've only had to fire one person, but it was as a part time homework checker. I've only been personally responsible for 3 FTE hires in my career (beyond CV screen). I'm not the most qualified person to talk about actual hard data points on the importance of success in the hiring/firing process.
However, I do screen CVs and I've seen several thousand of those so we can imply some data from other companies experiences. I'd say maybe 5% pop out as truly problematic people who jump jobs more than once a year. There's another 10% who have been at their current job for less than a year. The overwhelming majority of those 10% are leaving because the role isn't what they were told it would be (they are pure backend dev's being forced into a frontend role, different tech stack, QA job advertised as devops, etc). The next 60% work at each job between 2 to 4 years and leave because they got bored, or weren't allowed to grow, or they were asked to work harder than they feel they should have to. The rest leave because the business closed or similar circumstances. While some of these people may be lying about the reason they're leaving, I don't think they'd lie about the amount of time they worked somewhere.
So what makes someone a bad hire? The obvious ones you can easily filter for in your hiring process. The ones that cause the conventional wisdom of "firing is hard" are the ones who just barely scrape by, draining the team with extra training, extra work, extra bugfixes, extra "oops" moments for the longest time. They're the ones who go on a PIP and improve enough that it's difficult to justify firing them with cause. The reason "firing someone is hard" isn't because the process itself is hard. It's because the ones you need to fire, the ones you're warned against, they're just a bad fit. They take up an extra desk and shorten your runway (or budget) while providing just barely more than what they cost. It's the opportunity cost of hiring someone who's not great but not horrible. The actual cost of firing an underperfomer is 2 or 3 months salary equivalent depending on contract/jurisdiction.
So we're stuck with "a-hair-to-the-right-of-astrology" because it's really difficult to filter reliably, and an amazing worker on the right team could be "meh" on the wrong one (for him/her). It may be bullshit but at least it's bullshit the entire team believes in.
Something must be done.
This is something.
Therefore we must do it.
There’s lots of that in business: Long explanation for why something must be done, then a short explanation for what “this” is, and we just have to take it on faith that “this” will do anything to fix the problem that makes us feel like something must be done.
But as long as “everyone else is doing it,” we all believe in this something that we must do, and as long as we all believe it, we’ll all back “this something” we must do.
Whether it works, doesn’t work, or even makes it worse.
e.g. If you ask people how many golf balls fit in an airplane, word gets around and the next thing you know, people who can game PIPs to not get fired will game your interview to get hired in the first place.
And by hiring them, you don’t hire someone else who can actually do the job but doesn’t solve recreational puzzles for a hobby, nor do they spend any time learning how to game interviews.
This is the thinking that also brought us, “Nobody ever got fired for buying IBM,” and so forth: An emphasis on doing the thing people believe must be done, rather than looking for something that works whether it’s popular or not.
My experience of quite a lot of jobs has been that people, even managers, struggle to articulate what exactly they do, let alone what is required to do it well. If you can't clearly articulate that it's pretty meaningless to have any sort of rigorous hiring process to begin with.
Maybe that sounds over cynical, but I've watched as people from outside the tech industry encountered the concept of asking people to actually do a work sample in an interview for the first time. They thought it was the most crazy demanding and professional thing they ever heard of and immediately came to regard the team that was hired through that process as incredibly elite. Very few professions really challenge candidates in any meaningful way.
checking at Asia now, not because they're slightly cheaper(they still are, though to a less degree), but at least the labor law seems more reasonable, so yes, outsourcing not for just saving some money but mainly because of the employment rules are more reasonable for both sides.
If you are a senior/staff with some success at previous startups, you are likely to get vetoed by developers who see you as a threat in the promotions tournament.
Here are some thoughts: - When the new position opens, the team (say the scrum team) collaboratively writes a job description based on the current backlog. Let's not leave it to a manager or recruiter who is writing the job description. Use the company/team's mission and values as guidance to see who an ideal candidate would be. This is like writing your stories.
- Then write the filtering criteria based on the typical day to day skills - what are must haves, what are good to have, what is ok to not have. This is like write your test cases.
- What are the areas where the team is lacking. Try to get skills/qualities that will, for lack of a better expression, raise the bar of the team. This is like your retrospectives - and if you have notes from your recent retrospectives, they should help you identify what you are looking for.
- This better spec should help the recruiters, and also give the candidates an honest look into the team.
- For the interview, go back to your previous sprints etc. and build questions that are simplified models of what a typical story would look like. Instead of asking to invert a tree, may be it would be better to talk about how a particular problem you solved and see the approach the candidate would take. Give the candidate all the tools - their favorite editor/ide or whiteboard, whatever they prefer.
And as somebody with a past in technical recruiting, I really like your thinking. Indeed you're right: many recruiters are poorly equipped to actually understand the roles. We have non-coders as the first or second tier gatekeepers for development roles, which does not seem ideal.
Sometimes I'd get different signals from the job descriptions than the senior recruiters or hiring managers, which was frustrating. Other times, the requirements in descriptions were way too broad: like the team had an idea of what they wanted, but couldn't get it down on paper in a concise way.
Resumes can be a challenge, too: many engineers don't always give full details of their work. Perhaps because they're tired of getting recruiters reaching out for irrelevant roles (that happen to have a keyword match somewhere). Perhaps they don't have the time to always be updating and polishing.
A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier.
And then, of course - build the interview process around the shared skills / technologies / etc.
Hopefully I'll have something to share here soon, or perhaps do an ask HN to chat more about making hiring developers easier for everyone
"A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier." - 100%! This is the market place that Linkedin has been trying to create - but hasn't worked very well, right? They have largely solved the problem of structuring the resume data - which is definitely useful, but I don't see much of that on the job description side. The matching algorithms can only rise up to the level of quality of the input data - the resume data, and the job description.
There are similar problems in the dating industry, but mostly you can be sure both parties are putting their best efforts for creating better input.
I think honesty is also a critical part of the equation. And if the Linkedin or indeed could encourage both sides to reveal what they value deeply - that would things more useful. May be a few why questions rather than just checkboxes and drop downs that can be filled quickly. Candidate: Why is remote working important for you? Job poster: Why is a self-starter important for you? That would help bring out the uniqueness for the candidates and helped the matching algorithms.
Will look forward to seeing your product on Show HN - best wishes!
For anyone who may be interested, https://www.rocketship.jobs/
If it can help even one person land a job, we'll be happy with having built something new and different!
I ran for political office. Endorsement interviews can be either awesome or brutal. One key difference is whether the interview is recorded, and then shared publicly.
It will surprise no one that my worst interviews (in both politics and tech) were behind closed doors.
Worst of all are the 1:1 interviews with inexperienced interviewers. Zero accountability, zero transparency, no feedback loops. They just report whatever they want, are not even expected to explain themselves.
I've since decided that any future job interviews will be recorded and posted. I will definitely embarrass myself. But until someone starts, no improvement can occur.
I think if there was a standard for recruiting that the industry followed, then people would just be thinking of ways to "hack" the standard, so I don't think that would be helpful.
Remote working is desirable and rare but also a lot of companies that recruit for remote workers are very new ones and they often have no clue what they're doing. I think they feel that so long as they make it really hard and unpleasant, they'll be like the other massive internet companies.
To be honest, I also have no real clue what I'm doing but I am trying. Perhaps you could give me some feedback on our process while we're here:
1. A written test where we ask a few questions around the candidate's experience - what's the most interesting thing they've worked on, what recent tech are they most interested in, and we ask them to do a code review of a poorly written method. We have a strong culture of documentation so if the candidate can't write well then it's not going to be a good fit.
2. An online interview where we talk about the company, discuss the test, answer questions and write some code together via screen sharing. This latter part takes the longest part - firstly we write a simple string reverse method, write some unit tests for it, debug another method and design a history API for a browser (which has more edge cases than you'd think). What we're looking for: confidence in programming, code, design and communication.
3. An online or in-person (depending on where the candidate lives) interview with me and our CEO. This part has about a 95% success rate for the candidate, our CEO's just a people person and likes to get to know people.
4. The candidate is hired, and we start assigning work in increasing levels of difficulty. This is a probation period of 3 months.
Stage 4 is still part of the interview, we're able to take advantage of UK labour laws that allow us to let someone go inside 2 years without having too much trouble.
This way we can see them working for real and even if they aren't that good, get some sort of benefit from it. Of course, we might waste some money but it's an opportunity to learn what we need to do better during the interview phase.
For better or worse, capitalism rewards those who take risks. I think the companies with their multi-month long recruitment cycles are putting too much effort into risk minimisation. I'm happy when I hear about my competitors' "brutal" interview processes. It means they're moving slower than me.
1. We haven't yet figured out a way to get enough signal from two hours or so of work.
2. There are multiple ways to be a good programmer, but companies need a standardized way to assess skill. There's an inherent mismatch.
3. Most teams don't even know how to gauge their own employees' skill/value.
4. Teams rarely have their own employees retake their hiring tests to calibrate effectively.
5. Unpopular opinion: they aren't. Skills like algorithms are vital, and people who argue that they don't matter simply don't want to do the work.
I can't imagine that would end well in most cases.
I've recently landed an on-site job (I had to relocate) that pays pretty well in an R&D type environment that's actually all right -- in fact, this is one of the few jobs I've had that I've not hated -- so I may stay here more than my usual 1-2 years :)
Plus, it's much better for the environment. If you can do you work from home, why not?
Most want to hire you as a contractor. Contracting I'd have to at least double my salary to take home the same amount of salary and insurances and out of germany it's basically illegal to be a full-time contractor for just one company.
Having a remote interview with really bad audio, no word on their product, no small talk, just questions without discourse or feedback on my answers? - No thanks.
I'm a bit torn on assignments and trial days. I think they should simply be paid.
I just finished a take-home assignment that I considered roughly "not completely sadistic", and it took me about 10 hours.
And there is some level of trust I have for the hiring company, etc., so I was comfortable doing the 10+ hours. Not happy, necessarily, but decided I wasn't going to try to change the hiring process while I was trying to be busy getting hired.
I could easily see someone spending 20-40+ hours on it, and still not completing it successfully. I was offered proactive help by the existing staff, which was super-nice of them, and it probably helped.
I'm not sure how long it was supposed to take.
I would generally guess that hiring companies think their take-home tests/assignments take about one-fifth/tenth of the actual time they take. They often are simple if you're an expert in the company's proprietary software platform.
I don't know what the difference is for remote vs. local hiring -- I'd guess the hiring is generally more tedious for remote positions -- they require more trust.
I'm generally in the sales engineer/tech acct mgr/tech support/other-type space. If I don't love the company, and I get a homework assignment that is 20+ hours, I usually bail.
I had another position I was working on that required a codility (?) test. I took the sample test and 'passed' it, or thought i did, but then the eval said i got a zero. So, not sure what that was about.
I ended up bailing on that position, or telling the company i'd do any other type of tech screen, including live coding, whiteboarding, etc., but they weren't for it. I said I'm not down with that tool, but it was over. Fine. I know better than to try to justifying my objection to these types of tests.
Lots of companies have been asking for recorded video interviews. I try not to voluntarily talk to robots. Again, I try not to object on 'dignity' or any other grounds -- it's not a language that 'we' commonly understand yet -- it's too sci-fi.
So "let the robots do it" is one strategy for hiring.
I think there are lots of sane things we can do to improve the hiring process, but one thing I'd generally like to see is an easier try/buy process (like traveling nurses seem to have).
In theory, contracting or contract-to-hire can make everyone's experience better, but...it just doesn't seem widespread in my experience.
For example, I would love the opportunity to work for some company for 2 or 3 months, at some percentage of my normal rate, and then if we both like, we agree to the full-time hire. But it seems everyone is deathly afraid of having to pay unemployment. That's the best guess I have for as to why this is not a more common practice. This arrangement or something like it would seem to offer a good mix of risk/reward for everyone involved.