I've interviewed SWE candidates, discussed others' interviews, and been interviewed myself. By now, I've noticed what kinds of imbalances exist in interviews and can list things to study that come up more than they should in general SWE coding interviews.
1. DFS/BFS, both recursive and iterative form. Iterative version is usually better because it's easier to incorporate the Q's gimmick into it, plus they might grill you on Python's max call depth. Honestly, these are important in real work, but I've had an interview day where every single algo question was basically DFS.
2. Trie. It's niche, but I've seen a silly number of questions that are super easy with a trie and super hard without one. Should be banned IMO cause it almost purely tests textbook knowledge.
3. Dynamic programming (DP), and its cousin memoized recursion. The harder interview questions will require this. Memoization is usually easier, but I've seen some interviewers insist on DP.
4. Text parsing. Use a finite state machine, or it'll get ugly quickly. Say you're parsing XML like <tag>value</tag>, make an enum of states OPENING_TAG, READING_VALUE, CLOSING_TAG, loop through one char at a time, and add an entirely separate branch for each state in the loop.
5. Java OOP memes. They'll especially ask what an abstract class is for some reason.
6. If you're given a list as input, half the time, sorting it is half the answer.
7. Distributed hashmaps. If the interview involves concurrent or distributed algos, it will probably be a modified hashmap of some kind.
8. Different from all the above, I've been interviewed for many "reliability/production engineer" type roles (and taken none of them). Every single place has asked me to recite the entire TCP/IP stack. "I pledge allegiance to the SYN flag, of the finite states of TCP..."
