I've hired hundreds of developers over three decades, and this is completely wrong:

> It can be months (at a high salary) before you really know whether a hire is likely to work out.

It's only that way if you make it take that long. You should know if you have a good programmer 2-3 weeks after the hire. Here a couple things that make making great hires hard:

* Making it difficult to learn and understand your system.

* Having slow and expensive employee onboarding. I've seen companies spend $3-4K (not including the actual laptop) just getting a laptop to a new employee after IT gets done with it. If it's super-expensive to make a hire, the incentive will be to keep people that aren't getting the job done.

* Not looking at work output for extended periods. In short give new people tickets that can be done in a few days at most so you are able to look at work output in six days instead of measuring at six months.

> I think it makes sense to invest more effort in screening applicants in this case

There's only so much you can really screen before error in your hiring process exceeds 50%. Every step you add to a screening process has an error rate, and some are very subjective and error prone. The more screening you do, the slower you go, and honestly, the worst candidates you have to pick from. Why? Because a good programmer will be on the job market for 1-14 days (I'm not saying you are bad if it takes you longer to get hired, it's just what we're seeing in our recruiting software right now).

Have you built a successful growing software firm?

Does your software systems scale to Millions?

What about counterfactuals?

Without that data, your 3-decade hiring process means nothing.

I'm sure someone working in IBM, TCS, AT&T, Booz can all claim that they have been hiring people for 3-decades and give an opinion

I've done that.

I have a human conversation, make sure the expectations are clear and ask them if they think they can do it. Then I look at some of their work to verify and that's literally all.

No whiteboard, no takehome, no brainteaser, nothing like that.

Go google "how gates hires" or "how jobs hired" ... it's more or less the same. None of this I watch you implement a sliding window in a shared coding environment bullshit.

Let me put it this way. Say your candidates were all award winning scholars with phds and prestigious organizations to their name, then how would you go about it?

With respect but also, you'd still check to make sure it's the right fit, obviously.

Now here's the crazy go-nuts bananas idea - treat everyone with that level of respect. Totally wacky, I know. But hear me out - you can apparently build better teams with trust allocated to trustworthy people as your building block. That starts the day you interview and extends forever, well beyond your time working together.

Not sure why this is downvoted. Considering the parent led with

>I've hired hundreds of developers over three decades, and this is completely wrong

in order to argue from a position of authoritative experience, these questions are entirely fair game.

Because it's self-evident that designing a quick-ramp up process and modular system/good docs makes this a lot easier. It's 2022, you should be able to review checkins on gitlab the first week with a couple of basic tickets.

If folks are too green for that then they can be put thru an internship first. If an obscure language, have them do checkins on a tutorial.

> Have you built a successful growing software firm?

Yes, three times.

> Does your software systems scale to Millions?

Is 8m active users per day enough?

> What about counterfactuals?

A broken clock is correct twice a day. Not sure what you are wanting here.

> I'm sure someone working in IBM, TCS, AT&T, Booz can all claim that they have been hiring people for 3-decades and give an opinion

I don't work for them.

That's an awesome saying -- I'm surprised I've never heard it. It remains true after a LOT of mutation.

The trouble with programmers is that you can never tell what a programmer is doing until it's too late.

The trouble with programmers is that you can never tell what a program is doing until it's too late.

The trouble with programs is that you can never tell what a programmer is doing until it's too late.

The trouble with programs is that you can never tell what a program is doing until it's too late.

The trouble with aphorisms is that you can never tell what an aphorism is saying until it's too late.

I hear it's worse in those languages where the subject comes last.

"The trouble with programmers is that you can never tell what a programmer is doing until it's too late."

the meta-halting problem

But I don't think there is research showing that those strange hiring processes actually do work.

I've seen many variants of the recruiting process from the cute product feature disguised as a take-home to 6 stage interviews with two engineering(!!) interviewers per round that cost the company a few thousand per (un)successful candidate in man-hours.

Which is hilarious in an industry that is pretty binary ("you can build it") || ("you can't build it"). Doubly so when the majority of dev jobs are in web which is easily explored in the candidate's language of choice with basic CRUD / RESTful concepts.

Of course there is. You can generate studies that show roughly anything.

It may not be the majority, but if the research is all done in-house by various firms, there's no way for anyone to know that.

By research I mean of course properly done research.

I know a company that hired a contractor, who (probably) sat on his ass for months, then went AWOL with nothing delivered, and said company had to start over from scratch. Probably a little too much trust there.

I know a contractor who started a gig and it was over a month before he was given a logon, let alone a computer.

That started the contractor looking elsewhere...