> All of these things are good signals, but past experience can be misleading, and github activity is trivially easy to fake.
And coding challenges... have integrity? If someone goes to the effort to fake GitHub activity (whatever that means?) then why would they not also go to the effort to cheat in a coding challenge?
You can learn more from past experience, job history, hypothetical contextual problems and GitHub repositories than you can from a 45 minute fizzbuzz exercise. If you cannot assess a candidate by having a conversation with them then how on earth do you expect to be able to work with them? If you need a fizzbuzz exercise to trust that they actually know what they're talking about (which, again, proves absolutely nothing other than their ability to do fizzbuzz) how can you trust them in a collaborative setting?
The success of a screener cannot be measured by how many people in screens out, otherwise, the perfect screener for Software Engineering would be the ability to jump 20ft in the air from sitting down.
> its shocking the number of people who have somehow worked in the industry for 20+ years yet only seem to be able to paw ineffectually at eclipse when you ask them to write fizzbuzz.
So either there's an epidemic of people who can wax lyrical and provide meaningful insight into software engineering in a professional context but haven't actually worked in the industry... or you're churning through a dry checklist exercise of common interview questions that anyone who does the bare minimum preparation could answer.
The point I make (to technical and non-technical people alike) when I'm involved in hiring is that if you cannot qualify a software engineer in a conversation then you're asking the wrong questions. Most people interviewing software engineers have no idea how to effectively assess someone, and in my experience end up reading off some list of "software engineer interview questions". The reason supposed experts can pass these interviews and then fail at actually programming is that the interviews are terrible, and they're just being asked questions they've heard a dozen times before because someone half-assed the process and found them via a "software engineer interview questions" blog post.
If you need to know that someone can write code and you cannot confidently assess them in conversation, that's fine, not everyone has that ability, but the solution is to have them tackle a small contextual problem as a project (and pay them for the day of work) and not give them some arbitrary challenge that does not represent the real world.
Coding challenge fans make the mistake of believing that there needs to be some step where you have an applicant do a little dance to prove that they can write code, and so a coding challenge is a natural and necessary part of the interview process and that anybody objecting to coding challenges has to provide an alternative that will have an applicant do a little dance to prove that they can write code.
I've attended lots of interviews in my career, on both sides of the table, and I know exactly why coding challenges are used: because the rest of the process is so bad that someone who couldn't write code could easily get through. If you need coding challenges to prevent that, so be it, but it's because your interviews are bad.
The fact that there's an entire cottage industry of leetcode training and people who spend months "grinding leetcode" should be evidence enough that coding challenges test a candidates ability to... do coding challenges.
And, for the record, when I interview software engineers, I send them the questions I am going to ask in advance so they have time to research and prepare because that's what the real world is like... and I remain confident that even then I can still assess them effectively.