Personally, I find the algos interview to be the bullshit one. I've lost track of the number of people we've interviewed and hired that do well on it and then o

Personally, I find the algos interview to be the bullshit one. I've lost track of the number of people we've interviewed and hired that do well on it and then once they are working for us go ahead and design unnecessarily distributed systems (i.e. split some functionality across two or more services when there wasn't a scaling requirement that necessitated splitting things up) and thought nothing of all the extra CPU and memory that was now going to be used on serialization/deserialization between those two services and that's before you consider to all the added incidental complexity from (1) separate deploys, (2) separate on-call shifts, (3) separate logs and metrics, (4) more complicated migrations of interfaces between them, (5) increased complexity in testing that the services work correctly together, etc. In the last 7.5 years in my current role, I have yet to apply much if anything I needed to study for the algos interview for this role. I get that some adjacent roles in the company might occasionally need this stuff, but it's used rarely enough that it's a better skillset to be able to find the algo you need when you need it then study to be able to conjure one on demand only to have that knowledge atrophy while on the job.