I've had interviews that take months, but I don't really see the value of this. Why do you need 6 people to make a decision? Why do you need to ask them technical questions when you can ask for their college results? Why do you need to test them for skills they'll use maybe once a year?

What about non-CS degree folks? What about people who graduated 20 years ago?

2. For the most part, you just need someone who can do the job. Most people applying for seniors could; it's just a question of how fast/accurate/stable. For the most part, expected salaries tends to correlate with their ability.

Many of the bad hires I've seen were "cheap hires"; they applied for senior positions but were often paid half as much as a senior just because they were from a poorer country.

One guy had more ability as a researcher, less as a developer (he'd get things done very, very slowly, but produced well crafted code and was able to tackle the hardest problems). One guy was a great programmer but had personality issues, often getting into fights. Another scored highest on all the tests, but worked 12 hours/day and got nothing done. So I'm not sure assessments help in filtering most of these problems.

> Why do you need to ask them technical questions when you can ask for their college results?

Genuinely no offence, but this one hurt to read!

However I've found that the few places that do say they supposedly have a "fire fast" policy, also have an egregious and lengthy interview pipeline also.

Unfortunately, college results are not the most reliable. A in Algorithms class from a world-class CS university means something very different than the same A from some completely no-name Uni where teaching standards are very low and cheating is widespread and accepted. What's worse, even the people from top uni could be cheaters (it's just less likely) or rode on the backs of their colleagues in group projects.

Also, some people are like me and are not motivated to do well in school just for arbitrary and meaningless grades (I once got a grade corrected by the prof from C+ to A and didn't bother to go collect it, because what's the point of grades anyway?), while they will be very motivated in a job where they're paid good money.

To get a good job :p

This argument applies for every other field, but you don't see civil engineers doing interviews past a week, and even with substandard hires, building are built just fine.

About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.

That's the thing - in my country (Poland) nobody looks at grades anyway. The only exceptions are American companies that have offices there. Everybody else cares very much about the kind of University you graduated from (I think they mostly treat it as a proxy for general IQ and work ethic - best Polish schools for CS have admission rate of 7-10%), but don't care about grades.

> About 20 years ago, it was also common sense that a CS degree from Caltech means more than a 3 month Rails bootcamp, but now they're all treated the same.

Maybe because coding just got easier? I have a junior guy on my team that barely comprehends how computers work under the hood. However, he's still quite productive in an advanced/esoteric functional programming language. He just needs a little guidance by a senior to debug some less obvious issues or to review his designs to make sure they're not a performance catastrophe. Meanwhile, 20 years ago he'd just add a ton of segfaults to a C++ codebase and be fired...

I'm not talking about rock stars.

When I do a technical interview, I'm mostly looking for basic skills: from a brief description of the problem with example input, ask any questions and describe the output and show what the output would be. Then write code that does what you described; any language is fine as long as it's consistent on the board. My problem is reversable, so if we have time, I ask them to write the code to go the other way.

The problem itself isn't hard, the biggest issue people have is being consistent; even after we spent a good portion of time coming up with an example output, some people do something totally different. Very ocassionally, I get someone who has real trouble with a basic for loop. Sometimes, people are having a bad day and you can tell, which is unfortunate. If they're local, you can try to get them rescheduled, but if they were flown in, that's kind of their one shot for a while.

Anyway, what takes more time is actually getting the interview, and this depends on the value your company adds to collaborators. For example, if you're a company with great reputation, salaries, good benefits, interesting projects, you will get good candidates in line. But if your company isn't really "outstanding", finding someone that's truly good will take a lot of effort. Bear in mind software developers have many job offers, in a weekly basis.

This is why it's so important to build an employers brand!!

* specificity of targeting

* commonality of targeted skills in the market place

* competition for such candidates

Confusing something good for those factors is half the reason many companies stop reading resumes and make poor hiring decisions. A poor hiring decision is not just someone unqualified but also people who are well qualified yet not what you expect or need.

In my case as a JavaScript developer many companies knowingly ship the same kinds of crappy software over and over because they leverage their hiring risks away from writing software to tooling popular tools/frameworks.

Whenever I hear companies struggle with hiring at least a lot of the time the reason is that there are better jobs available in the same city for more money.

Whenever I've been between jobs I've just googled "Sysadmin $location", and tend to find a new position within 2-4 weeks. But if there are five adverts and two of them have low salaries I ignore them.

In ~4h total time interview you can have a very strong feeling if someone will be a fit culturally and if they aren't incompetent. Give them a chance.

Or you can spend months and many more hours to roll a dice with a bit higher chance of making a better hire...

Shift the deadline

Pay contractors

Sacrifice quality by either working overtime or reducing standards

Depending on organization the hiring process can be fast and effective.