I would go a slightly different track after seeing comments on OPs linked article making fun of people who know what ACID compliance means WRT databases.
The point of interviewing about algos or ACID or SOLID is fast inter-team communication and less wasted effort.
So you have two sysadmins talking about some database's filesystem options and they talk about sync-writes vs non-sync writes and they immediately see a problem they need to research WRT ACID's "D" and sync writes and there are of course many solutions historically and workarounds and on the whiteboard they just look at each other and say "ACID's D" and the other nods knowingly and they know what to research and are on the same page and it took about 30 seconds total interaction. I mean two people who know about durability and sync writes are going to like "wink and nod" and they're on the same page and they're both productive in minutes.
Then you meet some joker who don't wanna learn nothing about nothing he just does stuff that seems to work and googles for how to fix it later, and the guy doesn't even know the concept of what the "D" in ACID means and when the tickets start rolling in, tries to reinvent the wheel all himself and its just awful to see and he can't explain it was well as a textbook or wikipedia and you try to point out this is all old stuff "Everybody doing DBMS stuff should know" and "eh its just some trivia thing from the old days nobody knows like back when you wrote Perl for money" and its just a train wreck watching the guy. OR he doesn't get hired for the position because only 50 bazillion social media posts explain this employer loves "useless trivia stuff" and if you know anything about DBMS the concept of the ACID acronym makes so much obvious sense you can learn it well enough to BS past an interview in like two minutes, if you're a DBA worth anything. But nah they're too lazy, which is how its gonna be day to day if they get hired accidentally and nobody wants to deal with laziness either.
The guy who invented homebrew and famously couldn't get hired at google wasn't not-hired because he couldn't flip a binary tree, but was not-hired because he couldn't talk like a programmer with programmers about programmer stuff quickly in a standard documentable format in the trivial and non-commercial sense of flipping a binary tree. So he could have memorized every algo just in case, or he could have learned to talk like a programmer with programmers about programmer stuff but he never did either, so ... that didn't work out well for him.
As a terrible car analogy you wanna hire two car mechanics to change tires at a tire shop and one guy knows all the names for all the tools and parts and can at least BS plausibly at the interview how to fix something obscure like a malfunctioning TPMS, at least his answer sounded believable or rational if not perfect. The other guy doesn't know the names of any of the parts "This is the growly thing that twists the shiny things off the side of the heavy bouncy circles" and you ask him how he'd troubleshoot a broken TPMS in a general sense and he fires back about he don't know no fancy words but he's been changing tires for years and it'll probably be OK eventually. And you're like "Dude, you interviewed at a F-ing tire shop and read online that we'd ask about TPMS systems but couldn't be arsed to bother even looking up what the acronym means?"
That is a big part of it I think, and just being able to provide meaningful names for code/documentation/discussions makes a huge difference, though I'd say communication problems alone don't tell the whole story.
Even when you're just working alone, having seen something before and knowing the theory/literature means you can build on it instead of wasting time thinking about how to reinvent the wheel. Like you can imagine someone who knows nothing about ACID or transaction isolation being frustrated by apparent concurrency bugs in their database and hand-rolling some abomination of a locking mechanism to manually serialize database transactions. They're going to waste a ton of time on that, and it'll be fragile and have terrible performance. Or if you're working on some task tracking application and wondering about how you can untangle dependency relationships for users, you should have a basic suite of graph algorithms in your head so that you can use them effortlessly and focus on the actual problem instead of being mired down in retreading basics that every CS graduate already knows.
Also it doesn't seem like an issue of communication in the case of the homebrew guy; he was just stumped.
The point of interviewing about algos or ACID or SOLID is fast inter-team communication and less wasted effort.
So you have two sysadmins talking about some database's filesystem options and they talk about sync-writes vs non-sync writes and they immediately see a problem they need to research WRT ACID's "D" and sync writes and there are of course many solutions historically and workarounds and on the whiteboard they just look at each other and say "ACID's D" and the other nods knowingly and they know what to research and are on the same page and it took about 30 seconds total interaction. I mean two people who know about durability and sync writes are going to like "wink and nod" and they're on the same page and they're both productive in minutes.
Then you meet some joker who don't wanna learn nothing about nothing he just does stuff that seems to work and googles for how to fix it later, and the guy doesn't even know the concept of what the "D" in ACID means and when the tickets start rolling in, tries to reinvent the wheel all himself and its just awful to see and he can't explain it was well as a textbook or wikipedia and you try to point out this is all old stuff "Everybody doing DBMS stuff should know" and "eh its just some trivia thing from the old days nobody knows like back when you wrote Perl for money" and its just a train wreck watching the guy. OR he doesn't get hired for the position because only 50 bazillion social media posts explain this employer loves "useless trivia stuff" and if you know anything about DBMS the concept of the ACID acronym makes so much obvious sense you can learn it well enough to BS past an interview in like two minutes, if you're a DBA worth anything. But nah they're too lazy, which is how its gonna be day to day if they get hired accidentally and nobody wants to deal with laziness either.
The guy who invented homebrew and famously couldn't get hired at google wasn't not-hired because he couldn't flip a binary tree, but was not-hired because he couldn't talk like a programmer with programmers about programmer stuff quickly in a standard documentable format in the trivial and non-commercial sense of flipping a binary tree. So he could have memorized every algo just in case, or he could have learned to talk like a programmer with programmers about programmer stuff but he never did either, so ... that didn't work out well for him.
As a terrible car analogy you wanna hire two car mechanics to change tires at a tire shop and one guy knows all the names for all the tools and parts and can at least BS plausibly at the interview how to fix something obscure like a malfunctioning TPMS, at least his answer sounded believable or rational if not perfect. The other guy doesn't know the names of any of the parts "This is the growly thing that twists the shiny things off the side of the heavy bouncy circles" and you ask him how he'd troubleshoot a broken TPMS in a general sense and he fires back about he don't know no fancy words but he's been changing tires for years and it'll probably be OK eventually. And you're like "Dude, you interviewed at a F-ing tire shop and read online that we'd ask about TPMS systems but couldn't be arsed to bother even looking up what the acronym means?"