Big O is a useful vocabulary for comparing efficiency between different approaches. Binary trees are abstract, yes, but I prefer them to spending an extra 5-10

Big O is a useful vocabulary for comparing efficiency between different approaches. Binary trees are abstract, yes, but I prefer them to spending an extra 5-10 minutes listening to an interviewer describe a scenario that ultimately still boils down to a binary tree. From the other side of the table, when I’ve interviewed candidates without a solid understanding of runtimes I’ve seen some very unique code. One candidate wrote a triple-nested for loop and couldn’t understand why it wasn’t an answer we were hoping for. i.e. O(n^3) instead of O(nlgn). Running that code in production honestly would have been a disaster for our oncall. Interviews being such a hot button topic always struck me as odd. On HN we love evaluating new frameworks of the month, or discussing the intricacies of Elixir fundamentals - all of which also require time investment to learn. Why draw the line at learning Big O? Try looking at it through the lens of a useful skill rather than something to memorize for interviews. Even if you never learned it in school, you can still learn it now and it has real life practical value.