If you can’t sit down with someone, have a simple tech conversation with them and be able to tell if they know what they are doing… if you need to “give someone a test”… the problem is likely not the candidate.
"Yes, you are not in fact immune to this even if you think you are, that’s why it’s so dangerous."
I think that I am. I'll think about that a bit more. I don't care for popular people so, in fact, my bias might be the other direction. However, I don't think I have ever met a person who I thought was technical and proficient, but turned out not to be.
I have been forced to hire people I knew were not proficient because they passed a test, but not the other way around.
It's not about someone being popular and you saying it just makes me more certain you don't realize the trap. People can have well honed social skills and not act like your standard popularity contest wining politician.
They can add all the smiles and chuckles and other social niceties they want, but at the end of the day, whether they come up with the right answer or not, their logic will tell you pretty clearly whether they know what they're talking about.
That's the point of a technical interview: to distinguish those who think (or pretend) they can code sufficiently well to do the job, from those who can't.
I get it, your fun language is fun. But if the dev shop is 60% one language and 39% another, I don't really care about the small improvements. You need a strong reason that it actually _helps the business_
It works very well and takes only an extra 10 minutes on top of the conversation.
Sure, there is some correlation between talking and doing, but I've worked with people who talk like geniuses and code like crap. And also the opposite.
For some skills, there is just no substitute for actually have people actually demonstrate using them.
It’s really easy to let the interviewee talk through talk through all of the great things they built from a product and business perspective — and assume they understand the technical perspective. There are candidates who are really good at talking in an impressive way, but manage to talk around any true implementation details or deep technical understanding.
It’s also really easy to come away with a bad impression of someone who has a tendency to give short answers and not elaborate on things, even when it turns out that person is really skilled when you dig in.
I imagine a big part of the reason for the test-style interviews we have today is that it’s easier to train an interviewer on how to give them.
We tried to have a zero coding interview. All behavioral and experiences questions followed up by "how would you design a system to do blah." Got a candidate that did well. Hired. Turned out they could talk the talk but not walk the walk. It was wildly unexpected. They simply couldn't code well. Too long to deliver, too poorly written, usually didn't work right. We insisted on _some_ coding in interviews going forward
My most successful hiring has always been based on a conversation with 3-4 practical questions. I even worked in a company that had testing down to a science with all the psychometric nonsense and in the end, it just hired many sociopath-adjacents.
Skills can be learned. Tools can be provided. But the employee’s personal values are very hard to change. These are core components of performance in some perf management theories.
I think context is important. If a company can hire on potential, I would say it will be a better hire in the long-term. But if employee turnover is high and tenures short, and you need work done now and not 6 months from now, I agree with you more.