[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.