Ask HN: Is asking obscure algorithms any test of programming ability?

One may argue that a Phd student working in genomics must know the Monotone Queue variant because it MAY come up as a research implementation in his/her work. But this doesn't hold true for general software engineering folks.

I am a Phd student in Computer Graphics and so it is a reasonable expectation that I should know more about linear algebra than my peers. But if you extrapolate it to ask extremely hard research level problem it kills the purpose.

I think these questions usually focus on the wrong part of the equation. Is knowledge of obscure algorithms a good indicator of programming ability? Maybe, maybe not. Is the interviewer expecting you to know the Monotone Priority Queue algorithm, or are they evaluating your ability to approach and solve a problem? That's the question that matters, and there's no information about that here.

"Given an array, and a sliding window within that array, how would you go about finding the max" is a legitimate question with plausible real-world application. The fact that there's an obscure algorithm to optimally solve this doesn't mean it's not a good test of someone's ability to think through an algorithmic problem - as long as you don't make it an algorithm memorization test.

Here's what happened to these companies:

- They started asking algos and datastructs in the 00s because not too many people had the resources to study it. This served as a proxy for intelligence and was vaguely related as compared to other IQ tests or puzzles

- In this decade, more and more CS graduates and bootcampers started studying the same algo and datastruct problems

- Unable to reject anyone (because everyone could solve those problems), they started increasing the difficulty of the problems and started fretting over stupid things like variable names, arcane data structures and solutions, culture fit, ability to handle pressure etc.

- Today, it has devolved into a nerd show off event where the entire goal of interview has become diluted.

The goal of the interview was to open a requisition, find a smart candidate to do the job, close the requisition.

Nowadays, they'll open a req/have a pipeline of candidate, grill them over unnecessary questions and keep interviewing candidates until they get bored/really need to close this req.

The whole point of the interview process is so lost. As a person who is employed in one of these companies, I hate to see what it has become. We regularly reject candidates who are clearly more passionate than their interviewers, have better experience and bring something new to the table.

But because these mediocre interviewers (my peers) interview candidates on some arcane crap (that they obviously can't solve in 30 mins) these smart guys get rejected and I'm relegated to working with these retards.

It is one thing to ask coding questions to filter out the complete losers. It is completely another thing to hire only people who can solve these stupid questions.

Sad!

No, with the sole exception of interviewing for a research position where new algorithm variants on the sliding window might be developed.

What an interviewer focusing on specifics can pick up on is near term familiarity with a topic. But someone who can deliver value is also able to propel knowledge into novel areas, and can explain and debug the solution they came up with. They aren't there to be a student passing an exam.

Familiarity tests are often "weeder" filters that clear out candidates with no knowledge of the domain problem. This is a mixed blessing as it can find senior people if you drill deep enough with the right problems, but it can also make the overall skillset and wisdom of the team brittle if they are overfit.