In my long and storied career, well long at least, every single truly heinous, project-killin', crazy person actually interviewed pretty well.
Honestly, I don't have a good solution to the problem.
Honestly, I don't have a good solution to the problem.
There's a quality-distribution of both books and films.
There are only so many good books. And a percentage of films end up poorly made.
Sufficiently low-quality books tend not to get made into films. The ones that succeed are notable --- there's nothing but upside.
A good book can be made into either a good or a bad film. If it's a good film, then yay, but if it's a bad film, people are aware of it (through the book's quality and popularity). This is a perception illusion called Berkson's Paradox. It's an illusion because what awareness fails to account for are all the bad films made from bad books.
Hannah Fry of Numberphile does a much better job than I of explaining this: https://youtube.com/watch?v=FUD8h9JpEVQ
In the interviewing / performance case, you have good vs. bad interviewees, and good vs. bad performers.
Someonehone who interviews poorly but performs well is a positive exception. Someon who interviews well and performs well meets expectations. It's the good interviewer/bad performer who stands out. But it's the poor-interviewer/poor-performer who is missed by this assessment.
In the past I would never have been interested in a contract-to-hire. These days though if the company and role is right, and this an option to short-cut a ridiculous interview process, I might spring for it.
When I was an actuary we used to do “intern to hire” for unemployed recent grads, but I can’t imagine leaving a full time position for a contract-to-hire position. I think for me personally the opportunity would have to be really interesting and the comp upon converting to FTE would need to be at least double my previous comp (meaning the contracted rate would probably be something like 4x my implied hourly).
I've see that work before, but it was some time ago. The company also had a very large test department with separate management and kept to a strongly enforced waterfall-esque design routine.
Of course, it used to be a lot harder to ship out version 1.01 of the software.
I just assume it was a different world as this was in the days of US manufacturing, very limited set of software tools, high importance placed on domain knowledge as opposed to toolset, longer average stays at employer, lower wages for programmers. Probably not applicable to modern times.