[Yoric]

Fully agreed.

I usually don't need complex algorithms in my line of work, but I can't count how many times I've needed to implement topological sorts, for instance, or non-trivial tree traversals, or to rewrite code to increase parallelism, or to be able to quickly spot that a poorly performing algorithm was O(n^2) or O(n^3).

And sometimes, it actually gets complicated. Sometimes, it's about increasing cache hits. Sometimes, it's about making sure that stuff gets allocated in the right order or in the right place in memory. Sometimes, it's about rewriting the IPC layer. Sometimes, it's about reimplementing foreign key logics in a low-level database/file system. Sometimes, it's about writing custom locking data structures or non-blocking algorithms, or a custom memory allocator or GC to match specific performance requirements. Sometimes, you need to do all of this without a debugger or a profiler or even logging.

If you can't handle the simple tasks from the first list, well, how are you going to tackle the issues from the second?

And if you're not curious, how are you going to learn all of this?

[b3morales]

I agree, uses for this kind of knowledge do come up from time to time, but when you're implementing something like this on the job, are you starting from nothing, a blank piece of paper/whiteboard?

Personally I wouldn't start writing a single line without doing some research first. I'd look around on the web for some sample implementations or at least pseudocode. I'd probably get one of my algorithm books down from the shelf to make sure I understand the basics -- and check for "gotcha" edge cases.

So this is still wildly different than Max's interview environment, where the expectation is that you can effectively invent the algorithm.

[Yoric]

I'd argue that, for many problems, researching the issue is hard if you don't have a starting point. For instance, I currently have no clue about the natural language manipulation with machine learning. I would have strictly no idea where to start or where to start looking. I might be lucky and stumble upon some literature that I would understand, but then I might not.

[mancerayder]

Couldn't a good lead suggest an engineer learn this after-the-fact?

Also do most software problems involve optimizations at scale like at Netflix or Google ? It seems mismatched to assume that an esoteric use case is the gold standard.

[Yoric]

I'm talking of my own experience. I've had to do most of these things (or variants thereof) either while working on Firefox or various experiments at Mozilla, or while working at various startups.

I'm sure that not all companies need this kind of skill. But I'm not surprised if Google feels that they do.

[VLM]

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?"

[lordlic]

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.

[saberience]

I'm a VP of Engineering now and I made it here without ever having to do any of the above and most engineers I've worked with haven't had to do any of that either. Your experience isn't the norm and you also sound incredibly arrogant and out of touch.

[Yoric]

Well, thank you very much for the last part.

However, I have needed to do most of the above. Usually as part of a team, thankfully. Happy to learn that you didn't. YMMV.

I'd guess that Google wants to hire engineers who can do that, too.