I still know how to do it, but I’d have to really stop and ask myself why I thought it was a good idea first. Because it probably wouldn’t be.
Conversely if you love algorithms and are sufficiently good at them then you can spend your entire career with that and never ever talk to non-technical people. Some people here thinks those jobs basically don't exist, but they do exist and are really important and well paid. And once you start working there you can just continue forever since there are so few who have experience working with those. Like, maybe Google asks algorithm questions since they want more people to improve their algorithms? I know they had low hanging fruit everywhere, they just lacked people who were competent enough at algorithms to solve them, their hiring bar is way too low to solve their hard problems. But they can't really raise it either, there aren't enough people that could pass them then.
I think there are two types of programmers. Ones that are like you that like algorithms for algorithms sake. And the other that like to solve real world problems. I got into software development because I want to solve problems for people. And not all of us likes algo. We prefer to learn stuff that we do use day to day because that has direct impact. For example, I just spent two months understanding functional programming. I use it in my code almost everyday, but it would be worthless in an interview where you are judge by your algo understanding. It’s frustrating when you realize how this standard is forced on every technical role, on companies that don’t even need algo experts because they are too small.
That is, to one without a hammer, nothing looks like a nail.
They irony of this is that for one with a hammer, everything looks like a nail.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. Donald Knuth.
Knowing when to apply something is just as important as know where
A lack of hammer implies only having a screwdriver.
The point is you should have a tool box (and garage and workshop and spare bedroom) full of tools so you have the exact tool you actually need.
What the Phillips head and pozidrive represent in this metaphor are left as an exercise for the reader. As is the adjustable spanner.
In-memory skiplists, I'm still skeptical of.
for config I used ini files, super simple to parser (and now json so always can use an existing solution)
I've seldom implemented parsing, since we had Lisp, XML, and now YAML. However, I use language translation all the time.
(And I didn’t know about any of the data structures or algos mentioned in the post - I’d never have been hired at a FAANG)
Ever since I became a SWE rather than a researcher, I haven’t found a case to write another one, however. It’s much easier just to embed the DSL in kotlin.