> Guy can't code? Fire him, hire another and take it as a risk of the process.

There's a couple of "problems with this idea in reality" I feel I should point out:

  * The process of firing and hiring someone is often a *very* bureaucratic thing that requires many people to sign off on it.  It can often take weeks or *months*.  That's a lot of wasted time when you actually need someone to fill a role.
  * Some countries just plain don't let you do this (e.g. France).  Once you hire someone you're basically stuck with them unless you can prove they did something really, really bad.
  * It can be downright evil to just up and fire people shortly after hiring them just because they're not as efficient as you'd hoped.  You'd *think* that having a process like you suggest would only get rid of people that lied on their resume (good riddance) but in reality it'll be abused by managers to shape their reports in ways that are beneficial to them but not necessarily the business overall (zero-consequence firing).
  * There's something to be said for letting people through your hiring process that aren't qualified...  It's downright dangerous from an operational stability and information security perspective.

IMHO the real problem is HR: They suck at filtering out IT candidates. They're so bad that you'd be better off throwing darts and sending those resumes off to the hiring managers. They filter out perfectly qualified candidates that could be the best thing that ever happened to your organization and then they let through people who's only useful skill in life seems to be making a good-looking resume.

These are all excuses. You can fire someone whenever you want in the US. It can be the same day you hired them and you can even not give them severance.

I’ve seen this happen plenty enough even in SV. If someone wants you fired - they’ll do it asap.

Sure, but turnover has a strong effect on employee morale and the company’s reputation

So even if it surfaced the best candidates, hiring anyone that applied and then firing 90% of them after a week would result in a depressing work environment and an ever shrinking pool of qualified candidates (who wants to upend their life to take a job they only have a 10% chance of keeping?). Not to mention the cost of onboarding.

This is how we get to the status quo: do as much filtering as you can before you hire.

Just because you are legally allowed to do it, doesn't mean you should do it at the drop of a hat.

Slacking off during the hiring process with the intention of firing a large portion of the people you hire is a violation of the social contract and a huge asshole move.

This is true. Workers in the US have effectively zero rights to employment until they’ve been employed for at least a year, and even then you can still fire them and just make up a reason. Corporations spend a lot of lobbying dollars to make sure the US remains a corporate authoritarian state.

> IMHO the real problem is HR: They suck at filtering out IT candidates.

HR is really only qualified to filter out based on the qualifications on paper. These are sometimes misleading and occasionally outright fabrications. Those can really only be verified by someone with the appropriate technical skill to separate bullshit from an accurate representation of the abilities of the candidate.

Then why putting them in the hiring process?

They are typically the owners of the application tracking software and schedulers of interviews.

If the hiring manager wants the firehose of the "everyone who clicked quick apply" on LinkedIn or Indeed, then fair 'nuff. However, my reading of the comment that I replied to was the issue that HR wasn't filtering out unqualified applicants. Removing HR from the hiring process won't improve on that issue.

It takes time to hire someone and once you do you of course stop interviewing other candidates. Then when the person joins you typically don’t know immediately what the problem is, then once they’re gone you have to start the search all over again.

Much better to get someone qualified in the first place.

I typically use a small coding test, but not even as elaborate as described in this post — more like a 10 or 15 minute discussion/problem just to see if they really do know what std::string is or how to use an op amp or whatever. Some people can really bullshit well. Consider this the simple “do they know which end of the knife to grab when picking one up?” test.

Once that is clear, a conversation (usually just a conversation about a hypothetical problem) works well.

I don’t understand the coding tests that test your tools knowledge btw. If you know how to think and are somewhat familiar with the appropriate language then you can pick up the specific tools and frameworks. We hire for the long term so said tools and frameworks will change anyway.

>and once you do you of course stop interviewing other candidates.

Sadly, I think more and more companies are posting for jobs/positions they don't really have available/open at the moment and are just proactively trying to find potential workers (because this whole hiring process is a mess and take so long).

Hiring is becoming an always on activity.

My company has sort of been doing this, and I (engineer) have been trying to get us to stop. We do have a couple of open slots, but we're doing intake for much much more than we need.

I can offer this bit of perspective on the practice, without justifying it because I do think it's bad. We (again, engineers) spent a long time pushing for hiring to move away from the desperate search because we need someone immediately model to keep our lanes open for whenever someone awesome is looking for a job. Management finally bought into the idea...kinda. Basically, what we're doing is the mixed up interpretation of a that idea, after it passed through the bureaucracy. Instead of keeping just a line open, we're still trawling with big nets, scooping up way too many resumes and letting those people down.

The root of the problem as far as I can see is that screening is atrocious. The people at the front end of the process, the actual recruiters, have no idea what we are looking for, and the output may as well be random. I still don't know how to fix it. :/

> The root of the problem as far as I can see is that screening is atrocious. The people at the front end of the process, the actual recruiters, have no idea what we are looking for, and the output may as well be random. I still don't know how to fix it. :/

One is to have the hiring manager or someone who would be working alongside the new hire write the job description and not allow the recruiter to write it (no “17 years of experience in Airflow”).

Another is to have an engineer do a phone screen after the recruiter has screened them. Having the recruiter listen in is good as they will hopefully learn more about what is wanted.

Another is to carefully set the recruiter comp to take into account not only hires but percent that fail a phone screen.

Your recruiters aren’t your enemy but they are recruiting, not programming (you probably couldn’t do their job either) so there will always be a mismatch to some degree.

These are some really interesting ideas! Have you implemented them at one company or another? What were the results?

That seems odd to me because it’s very expensive to interview people (time spent interviewing is time not spent doing something else).

There are also people interviewing just for practice or to find a way to negotiate a raise with their management.

It is probably different where you are but what would actually happen is that it would take you at least 3 months to work out they can't do the job (they are probably not terrible just not good enough) by which time you have lost 3 months and perhaps $20K recruiters fee and now have to start the search again.

Of the people I have interviewed in the UK for "Senior .Net Developer", I would say that 75% did not meet the grade and that was with face-to-face interviews that took a lot of my time. An exam isn't perfect but if someone can't answer a reasonable spread of questions to a half-decent degree, then I don't want to hire them and it saves me hours of my time. Sorry.

"they are probably not terrible just not good enough"

Odds are, you're getting not good enough because you're using programming puzzles. Instead, why not quiz them on the work that they'll be doing, so you know that they can do it?

If you need 3 months to figure out whether the person you hired to do something can't do it then it's because you didn't really need that thing done

It’s not the actions of a few when compared to the positive hire result. Typical ratios are 1 in 100 to 400 for an SDE position. If 2% of people lie, in both cases that’s a significant number of people relative to a positive hire event.

Firing people is not as easy as you think in many places. Also, managers are human. Accusing someone of lying and going through the termination process is mentally taxing!

If a simple screen takes twenty minutes of time, it’s rational to do. If people get offended and aren’t empathetic to why you’d do this, would you really want to be on a team with them?

Yes but there are regulatory, legal and potential lawsuit issues why just firing people is not like snapping your fingers. It's an exercise with significant friction

In which country firing someone on probation would result in any legal issues? I had no problem firing people in Germany where labor laws are quite strict.

Silicon Valley, the birthplace of this type of interview, is in an at-will state, which makes the regulatory concerns quite puzzling.

And they can find an attorney to say that they were discriminated against, or that the company somehow did something improper, etc. As America is (to my knowledge) the only developed country where the losing party does not pay attorney's fees, 'winning' such a case may cost the company mid-five to six figures- or higher! Executives may be subject to invasive depositions, all company communications read by the opposing attorneys, other minor violations of our gigantic unknowable legal code found during this process, etc.

Where would a person who's looking for a job have the time and the financial resources to embark on a legal wild goose chase in search of a hypothetical payout? What kind of termination of an individual contributor for performance results in dragging in execs? This is a complete snowball effect of a scenario.

Litigators frequently work on contingency- so they work for 'free' for the litigant, in exchange for a healthy percentage (a third or higher) of any settlement. This is without including the actual government, where an employee may say that they were discriminated against somehow, and then the relevant government agency investigates everything under the sun looking for violations. For example they could allege that they were not provided their California-required lunch break, so then a nosy, hostile agency launches a huge investigation starting with lunch policies, and including anything else they find.

I agree it's a complete snowball! It's absurd :) And, it's reality- this is how litigation & workplace regulation in America works. For example depositions are so crazy, not only can you be deposed as a party in a lawsuit, you could be deposed for extra information even if you're not the one being sued (i.e. you're in a related industry as someone in a lawsuit, so the court compels you to a deposition just to talk about the industry, what's standard there, etc.)

Firing someone is much more expensive than it is to just give someone a shitty coding test and losing out on a few good devs

How do you calculate this „much more expensive“? I do not think this is correct estimate.

Just a few of the things you have to do when you have a bad hire that you fire (In the US and specifically California)

* Pay off any accrued time off

* COBRA insurance

* Unemployment

* Opening up the hiring pipeline (ads on job boards, recruiter, flights for potential candidates, training for new new employee)

* Potentially pulling other employees to fill the role while hiring again (Overtime and stress to existing employees)

Versus

Sending an email and saying no.

> Sending an email and saying no.

This is not that simple. Your hiring process is a funnel with certain conversion rates at wach step. If you overcomplicate it, your hiring timeline extends, increasing time to market for your projects and having some impact on the revenue. If you oversimplify it, risk of bad hire increases, but it may still worth it, if funnel gets much better.

Hiring someone isn't free, if only due to the opportunity cost of filling a role in your business with someone unsuitable.

I'd imagine the opportunity cost is offset by filtering out good devs with programming puzzles.

Consider that recruiters charge around 25% of 1 year of salary for helping to hire a developer, and the person-hour costs of hiring one person can easily exceed the recruiter cost for a small organization.

Firing also requires a fair amount of person-hours to do, and if you fire someone and need to replace them those costs stack.

Recruiting costs vary from one country to another. For me 25% is ridiculously high. Even considering cost of doing business, a recruiter would need to close just 5-6 open positions per year to earn as much as an engineer. If they work full time to achieve that, this is extremely inefficient for those money. Besides that, some recruiters actually offer warranty period that will cover thus specific case - you should not pay twice.

> How do you calculate this „much more expensive“?

By having actually done it, and understanding what processes are involved.

.

> I do not think this is correct estimate

It is.