So here's something I've been thinking about recently. I'm 2.5 years into my first job out of college and I think I'm starting to pick up on things like "oh let me guard against something that could return null" or "let me guard against calling .at() out of bounds". I'm starting to feel really thankful that my work has me thinking like this, because I can actually see it as a sign of getting better as a developer.
So -- instead of wondering what kinds of problems will get me through interviews, do you think some way I can train myself to be able to see things like that more often? "Defensive programming" or something?
I'm not that far ahead of you years-wise (5 years post graduation though I had a combined 3.5 or so years of paid work during/before that) and while I think defensive programming is great and keep it in mind I also have recently been thinking we need more champions of pure reason. Instead of "let me guard against this possibly being null", go and actually look: can it really ever be null? Or, can you make it not ever be null? Or "do I even care if it's null?" In many cases, the guarding is just paranoia or a band-aid against spending a little effort to go look and maybe change. In the worst cases the guarding becomes itself a failed guard. One piece of advice is know your programming language pretty well. e.g. in Java I've caught a few people "guarding" against null by wrapping the thing in Optional.of(), except that throws if the thing is null. They need Optional.ofNullable().
Similarly while I think unit tests (and other tests) are great, there's a notion of "I can't refactor without tests" that I don't agree with. You can use pure reason! And other tools. Michael Feathers has a whole book showing how to refactor legacy code without tests in order to make it possible to get it covered by tests at all.
Try starting or joining a book club at work (and even better if you can get the company to pay for copies, and maybe lunches for weekly or every-other-week meetings :)) since working with other coworkers (might not even be on your team!) who want to improve will be pretty stimulating and you can learn things from each other. There are lots of great technical books written by programmers with many years of industry experience. Don't take books dogmatically, but many usually have something worthwhile in them.
Writing good code from the software engineering standpoint is something that seems largely missing from the interviewing processes, but it's pretty important for lots of jobs...
Run your code in as many sanitizers and UB detectors as you can (ubsan, ASAN, valgrind, ...). Send code reviews to smart and detail-oriented people on your team.
So -- instead of wondering what kinds of problems will get me through interviews, do you think some way I can train myself to be able to see things like that more often? "Defensive programming" or something?