In my experience there's a big difference between an interview and talking/communicating/collaborating with coworkers. I don't think that you can use one as a reliable predictor of the other.

> I don't think that you can use one as a reliable predictor of the other.

It's pretty hard to claim that there's no signal from this kind of interview.

Candidate A: was able to have a conversation with me, asked good questions, explained their thinking well, was easy to follow, etc.

Candidate B: seemed to not understand what I was saying/asking, his answers were rambling and incoherent, and unless I led the conversation he just sat there in awkward silence.

You can't make a prediction about which of these is more likely to communicate well at the office?

All else being equal on paper, the better their social skills the worse all their other skills will be since otherwise the guy with social skills would have had a way stronger career than the guy without and then they wouldn't be equal on paper.

The problem is the halo effect here. Candidate A has likely gotten preferential treatment throughout their entire life thanks to his social skills, possibly all the achievements they listed were just because they were good at talking and never had to perform in previous jobs? While if candidate B has similar achievements but acts like that then you know he earned them, since nobody would give such a guy a pass unless they knew their shit.

On average a new employer will rate the persons work the same as the persons old employers, since these are the same set. So if both the socially savy person and the socially inept person got the same rating at previous employers, then you should expect to rate these two the same as well. If in these cases your process prefers the first over the second then you will over select for social savviness and under select for technical acumen.

> gotten preferential treatment throughout their entire life thanks to his social skills

First, I am talking about communication skills, the ability to receive and present information.

Second, this skills can be practiced and developed, it's not something you have or don't have. I assume that the person who is presenting well, does it because they put effort into it.

Third, I don't get this "all else equal" thing. I don't have access to their rankings from their old boss, nor do I have reason to expect their old jobs required the same thing my role does. Maybe their boss "did their talking" for them. Maybe someone gave them a spec and they just implemented it without any back and forth. But that wouldn't fly here.

I think that's the point of TFA. You can never predict perfectly but it might be a closer approximation than a traditional interview.

At least you're talking about programming, something you should know about. In the actual job you'll have to talk about the subject domain, which you aren't always an expert in.

This right here is the kind of company any self-respecting engineer shouldn't join unless they are transparent about the fact that they have issues with their processes/don't have people to deal with these issues that they need your help.

If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.

And btw, requirement gathering and writing technical specifications are taught in school.

At least in SV, not having the support staff to fully insulate engineers from these kinds of conversations is the norm, not the exception. If you are a run of the mill senior engineer at the highest paying companies in the the area you're expected to be able to have these conversations. My experience is that exceptions are only made for people who are true technical wizards.

Project managers, product managers, etc. are still human beings. They can insulate you from the users themselves, but they still rarely turn everything into formally specified requirements. The job still involves a lot of discussions with co-workers, managers, etc. about exactly what it is that needs to be done.

It even shows up in the code. Code will one day be read by another human being, for maintenance, and maintainable code is often more important than mere correctness.

To the contrary, I avoid any company that has an arsenal of project managers insulating me from the problems I'm solving. I don't want to be trapped in a cubicle churning out code. We all have preferences about the types of teams we like to work with.