Algorithms Interviews: Theory vs. Practice (2020)

If I can see these issues hit at multiple separate FAANG companies famed for their algorithm interviewing then we still don't have enough safety measures. As long as a spectrum of individual algorithm skill goes as low as X, there's always a non-zero probability you'll have a whole team around that level X. A larger institution just creates more opportunities for random teams to be low outliers just like you'd hope some would be high outliers.

Sure, these situations shouldn't last forever, sooner or later the problem will be bad enough that someone has to come in and rescue the project. I've been that person multiple times [1], so some might say maybe I've just seen the worst of it and my experience isn't universal, but ask yourself how likely it is that I've had to save multiple large projects across multiple large companies if there isn't enough of this in the industry to go around.

It's always a total disaster when you get to a project like that. There'll be one "worst" algorithm but there'll also be many other terrible algorithms. I wish I could say they were only inefficient; people who don't understand algorithms usually produce plainly incorrect algorithms, not just inefficient ones, because algorithm knowledge is required for both. Even if they bother to write tests, which is far from a given, they won't think of the algorithmic edge cases most deserving of tests.

If you're very lucky, you can find a way to regenerate production data to fix whatever errors were introduced by the incorrect algorithms. Often this is impossible because the original inputs were not saved because of the assumption that the algorithm was correct even if inefficient. We can talk all we want about how there should be safety nets for these things, but there's no denying incorrect code does sometimes end up in production even at a large scale.

[1] I'm really not even that good at algorithms. I can do every day in Advent of Code without spoilers, but nowhere near a competitive level, and not always the most efficient algorithm for a given day. It turns out that's still far more algorithm knowledge than the average senior FAANG engineer who doesn't even attempt AoC because they're too busy step-debugging their last dumpster fire.

What you wind up with is someone designing a giant system from parts they have read about that, honestly would probably work. However, it would also require retouching pretty much every system in the company to get things aligned. Which, isn't likely to ever happen.

Put a different way, the longer a project spends in design phase, the higher the chance it will not get completed. And all too often people will spend a ton of time in design looking for ways to make sure what they are building will scale to success level loads.

I never said trivia. By definition, trivia is stuff that is not important. I interview for things that are important to the work we do, and I give plenty of hints along the way to give a candidate a chance to show their reasoning abilities even if they have gaps in their knowledge or memory. This is what critics of algorithm interviewing conveniently ignore to make the interview seem unfair and unreasonable.

If you had a bad interviewer I'm sorry to hear that. Formal interview training in places like Google explicitly includes how to hint and unblock people effectively, and hiring committee feedback-on-feedback can instruct interviewers how to be more fair and better reflect the candidate's potential. Maybe your interviewer did a bad job and later received that feedback, but it had already soured your perception of algorithm interviews.

It's also a total myth that candidates are completely rejected because of one bad algorithm interview. If you have a day of five interviews, your success is not an AND() of the five, but it's also not an OR(). Whoever looks at the feedback weighs the various positive and negative signals to determine if it's a fit for the role. Skills in some areas can outweigh skills in other areas. Algorithms are one of those areas for a reason but it's still only one area and probably only one or two of the five or more interviews people will do.

If you know a better way to interview for these skills before hiring someone, please tell the rest of us and change the industry for the better. Until then, this seems to be the best we can do.

If your organization has very different needs, you can interview your candidates however best meets those needs. I know my organization needs algorithms and data structure skills, not just trivia but actual fundamental skills that generalize to novel problems we encounter along the way, and I'm going to keep interviewing for those skills. It's still just one interview out of several, and we've hired people that totally flunked my interview, so I'm not even gatekeeping, I'm giving the hiring team the signal they asked me to give them and the rest is up to them.

Here's the problem with this blend of specious reasoning. Even without questioning your claims, your example is based on a scenario consisting of a niche of niches whose relevance is limited to rare corner cases which have virtually no expression on the real world.

It's like trying to extrapolate optimization details from Formula 1 as something relevant for the design of a Volkswagen hatchback.

I mean, I worked at a FAANG on flagship services that virtually the whole world used, and I can tell you as a matter of fact that the vast majority of real-world FAANG services do not qualify as your hypothetical FAANG scale.

That's where you're basing your anecdotal example.