Wasn't sure what else to call this, as I don't really know when/if I am ever looking to go through an interview process again. These are just the typical interview questions that are usually pretty good at showing people how they think about code and solve certain kinds of problems.
I never formally learned any of these concepts and have felt a little bit of that impostor syndrome when it comes to some of my peers that have a very rich computer science background and may have learned these concepts differently. Alongside each solution is my take on how to visualize the problems.
I used to be opposed to these sorts of contrived interview questions, but after coming back to them following a career in software engineering, I can see why they make such great interview questions. They don't show up commonly on the job, but as implementing them tends to have many odd corner cases and gotchas, it really shows a lot about how the interviewee writes code. Common things you see/learn about a candidate from these questions are how they handle decisions between "recursion vs. iteration", "stacks vs. queues", "nested ifs/switch cases vs. maps", "maps vs arrays/arraylists", and many more. But the biggest is around how willing are they able to accept a known non-perfect solution and move on with it.
As a wise man once told me "Pick a direction, and stick with it."
I found an older repo with some good questions, but no solutions, so I started making my own, with little twists since I didn't have anybody to ask disambiguating questions. Hopefully my solutions seem clear enough, but if anything could be done better/made clearer, please keep me honest! I am a fan of learning and working to correct mistakes constructively, but mutual respect is a necessary prerequisite.