> having to prove they know things in an industry where a lot of people don't know things.
The number of people I have interviewed who have been unable to code fibonacci or fizzbuzz, even the number of people with "senior" in their resume, is genuinely remarkable. I can appreciate the tiresome nature of interviews, but someone having to demonstrate that are not simply fakers is, simply, critical to the hiring process.
For people who are "hired by network", that is a different story. But if someone is coming in through the front gate, I will insist on having some kind of technical scrutiny, in technical and documented form, rather than simple conversations.
Work sample tests, according to the literature HN member `tokenadult` has gathered, provide the best predictor of future work.
My druthers today is for senior engineers to provide two work samples: code and design. Neither _particularly_ long or _particularly_ challenging, in a time frame that is not onerous. If the engineer has a portfolio with recent work, that is, IMO, a suitable replacement for code. Again, the point is to elicit fakery and have a demonstration of being able to do good work.
> The number of people I have interviewed who have been unable to code fibonacci or fizzbuzz, even the number of people with "senior" in their resume, is genuinely remarkable.
I believe you; I have met some. Luckily, neither fibonacci nor fizzbuzz requires 4 hours to code.
More like we're tired of having to "prove we know something" to people who have no clue what they're talking about (most recruiters).
Further, there are probably lots of software engineers that have _never touched_ your framework of choice and will be able to learn and become proficient with it in a manner of weeks.
Having just gone through this with yet another developer who couldn't learn the framework in a couple of weeks, I am sick and tired of hiring people I have to coddle for months on end, only to end up having them quit because I didn't screen them correctly.
There are definitely a lot of bad candidates out there these days but I still find that I'm able to filter this by ignoring overly-hyped resumes and giving them a chance to talk about something that excites them as an engineer. If the answer is "learning new tech, becoming a better programmer, getting better at continuous integration", or something similarly encouraging, they're probably good to go in a few weeks to a couple of months. particular if they talk specifics and aren't talking out of their ass. If you can't discern that yourself then I don't know what to tell you ha. I'm aware that lying/cheating during interviews can be really common in enterprise. One approach that might work there is to try to meet candidates out at meetups in the area - this acts as a sort of self-filter and you can chat in person before the interview even gets extended.
I've interviewed multiple people who were really great at talking about tech and work experience, projects, but when we got to the (not so hard) coding challenge they flopped.
...or maybe people in this thread just don't like having to prove they know things in an industry where a lot of people don't know things.