I learned algorithms and data structures at university. That was the last contact I had with most of them.
For most of the companies in existence, as a software pro you will be working on the worst code ever written. It is all the worst code ever written out there, except the rare unicorn company that was co-founded by a software pro, and developed by best practices from the very start. You will never have the time, nor the opportunity, to design something that might work better than what is already there. Your tools are a spool of baling wire, a roll of duct tape, a tub of spackle, locking pliers, and a #2 Philips screwdriver. You know other tools exist, but you are not allowed to use them. They are too slow. And also expensive.
Nobody cares about big-O out in the real world. They care about alignment, margins, font sizes, and button clicks. They have all the money in the world for fixing something that's broken, but never a single penny for building things that don't break. You will never, ever be asked to traverse a binary tree. You will have a hard time even finding a binary tree. It's either an invisible part of the framework you're using, in which case traversal is already handled, or the data are not even organized well enough to shoehorn into any recognizable data structure.
So what usually happens is that some guy once made a spreadsheet. This becomes the nucleation site for all the business computation. But it doesn't scale. So the business gets a software amateur to port the spreadsheet into a "real" software solution. It might have been written in Delphi if you're lucky, or Visual Basic 6 if you're not. That scales past the four guys previously using the spreadsheet, but it doesn't scale with company growth. So then the business hires software professionals, but those guys are expensive, so all they are allowed to do is weld in a new support and slap a new coat of paint on the amateur solution, so that more hardware can be thrown at the problem. This last step is usually repeated until the company exits.
Sure, you can select in your interviews for people who know how to construct ivory-tower software under academically ideal conditions, but you're intrinsically selecting against all the people who can tell when your dumbshit software development process is wasting colossal piles of money, because the developers are effectively working with both hands and one foot nailed to the floor. If you hire someone fresh from the ivory tower, they are going to see the lovely pile of filth you live in, and recommend that you throw it out and start from scratch. Replacing it from scratch never goes well, but the new guys don't know that until after they have tried it at least once.
You're not going to get that guy who speeds up your existing software by x% just by walking the entire codebase and replacing every instance of the string '+' operator with buffer concatenations and string formatting statements. You're not going to get that guy who saves you 6 months of development time because he or she walked down the hallway and asked someone how they actually use some feature and heard "we don't use that anymore." You're not going to get the guy who solves problems before you knew you had them, not for promotions or recognition, but because it keeps you from running into his or her office in a panic at 4:45 PM on a Friday.
In the real world, you just link the binary tree library that has already been in existence for 20 years, and forget about it. Unless your company is the one maintaining that library, at most only one of your employees will ever need to know anything about how it works, most only need to know which specific business problem it solves. And no one will ever look at it again, until the profiler says it's a performance bottleneck.