The specific questions don't have a hold in real life but the patterns behind them do. Most problems to be solved in computer science, with enough abstraction, have already been solved. I joined a new software development scrum at work and have been helping optimize how long our application takes (it can be thought of as an encoding engine) we've seen huge leaps in improvement with very simple solutions, 75% of the time the way we're seeing that the best way to solve a problem is via a hash table. That's also an incredibly common core solution to most interview problems.

The patterns _can_ have a hold. It's always fun to optimize slow engines, but it always feel more to me like rote/busy work than actually building the system from scratch and engaging in product engineering. But, I guess that's kinda your point -- very simple solutions that revolve around simple, common core structures can lead to huge leaps in improvement. But this kind of real world optimization has medium breadth and depth. It's got a lot more breadth than many algo interviews I've gotten, and yet less depth. I've found that's been the real structural weakness in weak algo interviews I've had -- they just overindex on deep knowledge of algo optimization and underindex on communication, reading and design ability. I'm drawing from a pretty small and outdated sample, though; the last time I had the patience to interview with a BigCo was more than five years ago.

> The specific questions don't have a hold in real life but the patterns behind them do.

At many companies, successfully recognizing the pattern isn't going to be enough to pass the interview. You have to implement a working solution.

Did you solve the problem using a list of words you needed to find in a long string like "cowsgoformoosomethingelse"?

Change your mindset, instead think of it as convenient way to get a job for a multiple different company using basically the one generic approach. It doesn't really matter whether it has no hold in real life, in fact well I argue it does have a hold in real life, which is to get you that job.

Do you have any resources or suggestions for better types of questions to ask, especially for individual interviewers without control over the overall process?

I try to avoid those sorts of questions, but it's hard for me to come up with better alternatives.

I don't have anything written up in a blog post.

I try to work on soft skills during the interview, I found those to be way more important than knowing to invert a tree.

How does one converse through a problem? How would you go about solving this bug.

I usually do something really simple like

logMessage(from, to, content) {} searchMessageBySender(senderName) {} getMessages() {}

Have the candidate fill in the interface and walk through what the choices are and what are the ups/downs of their solution.

Even among textbook questions from the infamous leetcode and the likes, there are a few good ones. For instance I was once asked this one: https://leetcode.com/problems/flatten-nested-list-iterator/

- it's not too short or too long

- there's no trick, it's just a matter of being thorough

- it's pretty concrete (modern languages have that in their standard lib) and/or might actually come up someday in your day-to-day job

And in my opinion, what matters even more is that your full round of interviews shouldn't be just 5 slots of algo questions. One or two should be enough. I like combinations of a take-home challenge (keep it short!), pair programming sessions and architecture / systems design discussions.

That's because you don't work at FANG where most engineers are expected to ask these types of questions.

Getting a computer science degree from a fancy university would prepare you for these types of questions.

They are a ( maybe unintentional ) dog-whistle for coming a wealthy background which means you will fit right into the cultures at these sorts of places.

Learning to program takes a lot of privilege. Look up the stats for how many google SWE's do not have degrees / where they come from.

>Learning to program takes a lot of privilege.

Whaa? It takes a computer. Beyond that hurdle, I dunno what privilege is involved. It'd say it takes persistence more than privilege. I grew up quite poor, bad family, dropped out of college (due to bad family), learned cs on the internet, now work at a FANG corp.

Thinking there's some wealthy background bias is bizarre to me. When you've got 300k+ people in an organization, you acquire people from all walks of life / countries / backgrounds.

But doesn't this article specifically disprove that point? The author came from a non-fancy university and non-fancy internships. He prepared only using free or low cost materials (leetcode and books) and was able to meet the hiring bar.

To me this reads that the questions are intended to narrow the candidate pool down to people with an abundance of time to devote to studying, which is certainly one type of privilege, but is not necessarily the same as a wealthy background.