I really liked LeetCode style interviews at big companies, and I loved that my colleagues also understood the importance of run time of complex algorithms. I al

I really liked LeetCode style interviews at big companies, and I loved that my colleagues also understood the importance of run time of complex algorithms. I also interviewed at startups where algorithmic knowledge is more of a disadvantage, as I may optimize things too early. As an example of why for some (especially big) companies need deep algorithmic knowledge is that at Google I was working on adding new features to an ads prediction model, and even without changing the code base the new (slightly more complex) model increased the ads 99%-ile latency by 0.1ms (millions of dollars loss because of the RPC timeouts), which required director level exception there if I wanted to ramp up the experiment to total user traffic (the usual thing that people do is to optimize something else in the code base to stay in the latency budget). The small problems that LeetCode provides for interviews are great filter for people in these companies when they are faced with much more complex optimization problems. The problem is when a small company with lots of user facing features uses the same type of interview (they shouldn't).