Knowing the existence of, and understanding the performance characteristics of a broad range of algorithms is, to my mind, a much more useful set of working knowledge than the details of any individual algorithm. The latter can always be looked up. It is harder to find out the former and much better to say “yes, there is an algorithm such-and-such that may be applicable here, let me spend 5 minutes checking that.” In my experience, anyway.

Broadly speaking, that used to be how design patterns were often treated in interviews. Could you recognise, describe, code, discuss pros, cons and applicability for pattern X in given circumstance. Pretty easy stuff to cram unfortunately, which may be why they may have fallen out of favour in recent times as proxy measure for brains, but depending on the role in question that sort of material was often more likely to be useful in the job than a similarly broad knowledge of algorithms

>testing whether someone is willing to prepare for a thing is a relevant work skill test too.

Is it, though? I could understand if algo questions had some relation to the work you're doing, but your comment on why they're good is independent of the actual material. If we replaced the algorithm question interview with an interview testing obscure presidential facts, would it really be a useful test to have devs take? I guess it is a relevant work skill test in that you get people willing to put the work in/game the system, but it doesn't seem to be much of (if at all) an improvement from ad hoc conversations.

There’s a vast difference between, say, preparing for a school exam and preparing for a job interview. In the former, you know in advance what material will be tested. Job interviews are more like PhD comprehensive exams, or professional licensing exams. I know a lot of working professionals who are good at their jobs, yet admit they wouldn’t be able to pass the license exam today.

Go search for "Knights on a Keypad" (a formerly-common Google interview question). Trying to imagine any situation in which the solution would be useful is harder than the problem itself.

If you're trying to find a situation where that exact solution is going to be useful, you're not thinking about the problem from the right perspective.

Handled correctly, a problem like this answers several questions:

1) Can you correctly break down a problem like this into its components parts? 2) Can you recognize the overall class of problems that this falls into? 3) Can you transform this specific problem into the more general class so that you can solve it in a known fashion? 4) Can you think about and implement the movement? 5) Can you communicate while you're doing the above?

No one cares about solving that particular problem. But the answers to the above really are relevant. Being able to map novel problems onto known solutions is absolutely a skill that any competent software engineer needs to have. "Oh, you want me to do X? That looks a lot like Y, this thing we've already solved; maybe I can just implement it in the same fashion (or re-use our existing system!)"

I'm not saying that this particular problem is a wonderful example, or that I'd use it in my own interviews. But this overall class of problems really does have a place in interviewing when it's handled well by the interviewers, and arguments against it on the basis of the specific problem being irrelevant are really rather missing the point.

If it's true that this type of problem is relevant (I doubt it), then why not ask about a specific problem you've actually had to solve?

I don't do many interviews anymore, but I used to, and I had no short supply of problems that I actually had to solve in the course of my work that I could ask about. I don't think whiteboard interviewing is great in general, but if you're going to do it you can at least try to keep it relevant.

As a matter of fact, I did have to do memoization of graph traversals at least once for work (most programmers never have to do this), and I find that problem a lot more interesting (trait matching for Rust). I could easily give a talk about that problem. As for that interview question, though? I don't always do well with time pressure, and so I can't guarantee I'd be able to answer it to your satisfaction.

Setting up the same problem in terms of trait matching for Rust is quite a bit more difficult than this toy problem when you're in a limited-duration interview setting. All of the time that you spend laying out the problem is time the candidate doesn't spend solving it, and time you spend not getting a signal. The simpler the problem setup the better, in my experience.

I've done the "ask a real problem that I've solved before" thing, and I find that it usually gets hung up on details and context around the problem to the detriment of actually solving the problem at hand. That's not to say that such a conversation isn't itself very valuable, but that's a different interview conversation, at least on my team. We find it important to maintain some level of focus just to ensure that we're covering the various signals that we'd like to get from the candidate.

I am not at all confident that I would be able to answer Knights on a Keypad to your satisfaction, due to some combination of nervousness and time pressure. I probably could if I did many hours of interviewing practice, though. Absent that, I think there would be a good chance you would reject me on the grounds that I don't know how to do memoized graph traversals, despite the fact that I'm in a small minority of programmers that have shipped memoized graph traversals to production (and in fact a few teams at Google rely on my implementation of memoized graph traversals, ironically enough).

My view is that Google's interview process seems to work because Google gets so many applicants that they can afford to randomly reject most of them. It's not because it's a good process.

Using an actual problem you solved can also work against the candidate because most problems we encounter in our daily jobs require a lot more time than the standard 45 minutes reserved for an interview (actually only 35 minutes out of 45 because there's 5 minutes of intro/icebreaker and 5 minutes reserved at the end to answer any of the candidate's questions).

So it isn't fair to ask the candidate to solve a real bug or implement a real feature in only 35 minutes unless they've seen something similar before.

This is why big companies like Google are limited to whiteboarding interviews because they need to have an interview process efficient enough to properly vet and filter >1 million applicants Google receives each year.

Personally, I think a better interview process is a pair-programming or work audition for a day. But that is not even close to matching the scale of Google.

Let's say out of a million applications, maybe only 25% are qualified. That is still almost 1000 candidates to interview per day (number of U.S. business days in 2019 is 261; 250,000 candidates / 261 business days = ~957 candidates per business day). Pair-programming or full day work audition will not be able to accommodate 957 candidates every day.

Why can't it be done using Permutation and Combination formula? I am bad at dynamic programming so can't really get into the solution right now?

You mean that you can't imagine when a memorized graph traversal would be useful?

I find that hard to believe.

I have actually implemented memoized graph traversals for work (unlike most programmers). To begin with, I see no point in asking this when I could ask how to implement trait checking in Rust (what I had to use memoized graph traversals for), which a practitioner will find much more intuitive.

Moreover, memoized graph traversals don't get you full credit on this question. There's a dynamic programming solution, and in fact the ideal solution is one using matrix math, which is ludicrously divorced from anything most programmers would ever see.

So you are saying that companies are hiring people that are willing to prove that they can put "a lot of work" into preparing for interviews that have no relevance to the actual work? I can see that as a valid point, as a way to filter lazy individuals. (In the same way that a college degree is more a way to prove that you can sustain X years of learning things without dropping out).

But it will also filter out everyone that is opinionated enough to not do that stupid preparation work, and you will end up with sheep coders that will always follow the rules. Looking at Google, Facebook etc, this might already be the case. I will even go so far to say that they prefer those type of obedient coders than the ones that ask too many questions and get too creative.

No relevance would be like when I took the GRE for grad school. I studied things that had zero relevance to the CS program I ended up attending.

Reviewing algorithms for interview prep at least has some relevance to programming. While a candidate may not use that exact algorithm in their day to day job, they are creating ad hoc algorithms all day long. With that said, I don't think time pressure, white boarding algorithms is a very good job performance predictor.

There seems to be an assumption in these discussions that everyone has to prepare for these things in equal amount. But that's not the case.

(The counter to that is that if people can relatively-easily (single-digit days) cram for your interview, you're still not going to be effectively screening for at-hand pre-existing familiarity/knowledge.)

What about using a real job related task. If they can do that they probably can do the job.

The elephant in the room is that it's a surrogate for an IQ test, since those are illegal.

It is not illegal to use IQ tests as part of a job screening (in the US). It is illegal to screen in a way that is both discriminatory and not proven to correlate with job performance, but that applies equally to both IQ tests and algorithms questions.

IQ is proven to correlate with performance in virtually everything, so I'm not sure where you're going with that.

If I require all prospective engineering hires to prove explicitly that they have an IQ of at least 135, I will get sued. Do you think this is false?

Obviously I do not think that is false; you can get sued for literally anything. Do I think you would lose? Depends on whether you've done the research showing that 135 is an important cut-off.

To turn this around, can you point at the law that makes IQ a protected class or whatever you're claiming it is? I'm not going to have much luck proving a negative - Russell's teapot and all that.