Maybe it's different in other parts of the world and other industries, but I've been in the tech industry in the US for almost 20 years and I've never really known anyone who I could say ever had a mentor or mentored anyone else. I have heard people make references to mentors and mentoring in the software world, but I just haven't seen it in practice.

I've learned lots of stuff from more experienced developers I've worked with, and passed on that knowledge to less experienced developers who needed it, but none of that was in the context of anything resembling a special relationship like mentoring.

IMO, once you have the basics that people usually get from a CS education (meaning the more abstract stuff like algorithms and data structures, not the stuff that's tied to a particular platform or language), there really isn't any more common or universal knowledge to be had. Quite a bit of what most people learn after graduating tends to be technical minutiae- the specifics of how to use various languages, libraries, and tools.

It's also the nature of the game that this technical minutiae changes all the time, and has an expiration date that's frequently only a few years away. So, one aspect of being a professional programmer is that you never stop learning throughout your career, and quite often you're just spending time learning how to do something in some language that you already knew how to do in 10 other languages. That's why I called it minutiae: it's critical stuff to know, but it's ephemeral knowledge that will someday be irrelevant, and you'll find yourself learning how to do the same stuff all over again in some other language in a few years.

I guess the whole point of this is that you've already got the somewhat universal basics of being a professional software developer, and all a mentor would do for you at this stage is help you learn the technical minutiae of a particular set of tools. But really, you will be having to do this learning on your own throughout your entire career, and you won't have a mentor to help you with it. So the very best skill you can have is the ability to learn things on your own with minimal help from others. Having a mentor might even be an impediment to gaining that skill, because it'd just be postponing you becoming self-sufficient.

The main thing to remember is that no matter how experienced you get, it will always feel like the set of things you don't know is growing faster than the set of things you know. It's not like you just get a certain amount of experience and all of a sudden you know most or all of the things- it's the exact opposite in fact. The more you know, the more you realize how much you don't know. So try not to feel bad about your lack of experience, but do try to become a lifelong learner if you aren't already.

I feel dirty quoting Eric Raymond but he's written a lot of things that can be insightful when taken in isolation. One of them was that the best way to get better is to alternate between reading books and hacking on code. It's easy to spend lots of time reading tech books and then never applying that knowledge to writing actual code. It's also easy to spend lots of time hacking on code and never reading anything, but this can drastically reduce how much new stuff you get exposed to. He suggested people get into a pattern of reading a book, write some code, read a book, write some code... When it comes to personal projects, just do stuff you want to do even if you have no idea how to do it.

The key to being a great programmer (IMO) is to never allow yourself to flounder or feel lost. If you are successful in your career, you may frequently be expected to complete a project using a language you haven't learned yet with some libraries you never even heard of. It's easy to get frustrated, but the way to get out of it is always to just put one foot in front of the other. Don't waste time feeling bad for not knowing how to do something, just always think about what the next step is and take it. Take everything one step at a time. You may not know how to get to where you want to go, but you can almost always figure out the next step you should take to get there.