[pfp]

> I've been a professional software interviewer (600+ interviews) and have seen most very experienced software developers do quite poorly during interviews.

So... you've 1) realized you're dealing with experienced people and 2) yet discarded them based on irrelevant "interview skills"?

How does this serve the company trying to hire someone?

FWIW, the couple of times I've interviewed someone -- I've always given the guy a 2nd chance if I've seen he's obviously nervous or just not on a good day, but has the material. Even an autistic nerd like myself can spot that and have the common decency to look past trivial human weaknesses.

Besides, I'd rather pick a genuine human being as a colleague rather than some overbearing, over-social, potentially arrogant prick whose competitive urges are liable to disrupt technical decision making down the line. Those types belong in the suite & tie department, not in tech.

[ratorx]

Interviews at FAANG don’t really work like that. The typical interviewer has very little say in metrics used to evaluate the candidate. Their job is to evaluate the candidate based only on those metrics, with little room for anything else.

Part of the reason is standardisation. There is lots of training given to avoid bias. I think you’ve misunderstood what the parent meant by interview skills. The criteria don’t select for social skills (beyond the basic), but rather for algorithmic skill. However, most day-to-day development will not require as much of it, which is the parent’s point.

I think most people are aware that the system is not perfect, but the process of determining the metrics (as far as I understand it; I’m a fairly new interviewer) is pretty data based. It’s been optimised to hire people without relying heavily on the interviewers all being very experienced (because that doesn’t scale enough for FAANG).

[therealdavesky]

Also the 'metrics' being used to make the final decision are secret, most likely not known even by the interviewer. This prevents gaming the system but the lack of transparency makes it easy to imagine that MANGA companies choose new hires the same way that South Park depicted the FED making economic decisions: with a headless chicken running around and finally falling down on a big diagram.

[icsa]

> How does this serve the company trying to hire someone?

The interviews are designed to evaluate algorithm & data structure knowledge and proficiency. Most experienced software engineers have not kept up to speed with such knowledge since they were in school. It is not their fault, as most jobs/projects don't require maintaining such knowledge in order to be effective on a day-to-day basis.

N.B. The interview firm I worked provided the option for a second interview if the candidate believed that the first interview did not provide an accurate assessment of their skills.

In any STEM profession, one's academic knowledge "expires" in 5 years or so. Continual learning & practice (incl. interviewing skills) is a requirement to maintain employability in a field.

[pfp]

Like you said,

> most jobs/projects don't require maintaining such knowledge in order to be effective on a day-to-day basis.

This is common knowledge to any developer - you really don't need the academic angle most of the time.

So... how does rejecting on that basis serve the company trying to hire someone?

[icsa]

> So... how does rejecting on that basis serve the company trying to hire someone?

One way to describe the rationale is that the hiring firm is hiring for 2-sigma capabilities versus 0-sigma or 1-sigma capabilities.

The ability of a software engineer to "shift gears" to the 2-sigma skill set when outlier conditions (e.g. debugging rare events, performance issues et cetera) occur is a form of insurance against having to contract outside resources.

N.B. I am one of those outside resources that gets called in when none of the FTE staff can resolve a difficult (aka "burning platform") problem.