I asked this question, because I see often in books: "You need to have an intermediate level of programming knowledge"
Well, that is a very different question than the answers above are aimed at.
From that perspective, I'd say that it sounds as if you are at a stage where books aimed at "intermediate" programmers will be useful to you.
Agreed. For books, "intermediate programmer" seems to most-often mean "has basic programming competency, or more", the books say this because they aren't going to expend pages teaching you how to program from the ground up. The book is a 200 or 300-level course, not Programming 101. In the end, all you need to tackle most subjects is a willingness and drive to learn, to self-identify gaps in your knowledge and fill them on your own if needs be.
In a separate rant not solely directed at OP here -- What's with all the permission-seeking anyways? This forum is over-run with questions of this stripe in every topic. Permission to use this language or that language. Permission to use this library or that library. Permission to make this game or that game. Permission to read this book or that book. Permission, Permission, Permission.
Stop asking for permission and just go do stuff! Ask for advice, direction, opinions, help -- but enough with the permission already. Based on that advice, direction, opinions, help, and most importantly your own honest self-assessment, do what you think is best for you. By definition, you have to over-reach to learn just about anything at all that's worth learning -- no one ever got smart by being satisfied that they were already smart enough. Comfort is the enemy of progress, Challenge is its ally.
What's the worst thing that could happen by picking the 'wrong' book? You might have to read it more slowly? You might have to read it twice? You might have to put it back on the shelf for awhile, and go learn about the things attempting the book made you realize you don't know? I don't see anything resembling a failure here.
A junior programmer has learned the core syntactical constructs of (usually) one language, and has performed enough exercises to be able to use their knowledge to write simple solutions to simple problems. To do anything moderately complex, they'll generally still need a lot of guidance, though, with sufficient help from a senior developer and constant review of their code, they can still be a useful member of a larger team. A mentor can make a lot of difference in helping a junior programmer reach competency (intermediate level?) sooner rather than later.
An intermediate programmer knows at least one language pretty well, has generally used it consistently for at least a few years, and may have dabbled in at least one or two other languages along the way. They've probably gotten used to using one or more libraries and frameworks too. As Sean was saying, they can use what they already know to do a reasonable job of solving problems that they are presented with, and even though the result may not be the most efficient, or most optimal, way of doing a thing, they can generally get it done without supervision. Intermediate programmers generally don't have enough experience to architect elegant solutions to complex problems. The term "architecture astronaut" is common at this level.
A senior developer usually knows more than one language pretty well, is very good at debugging, and more than that, is very good at writing code defensively, or in other words, knows how to write code and foresee potential errors and issues of efficiency that are likely to arise, this avoiding many bugs altogether. At this level, such a developer probably understands at least their core language in great depth and has a good working knowledge of several others. They can probably architect elegant solutions to relatively complex problems, though the actual level of competency in this regard can be vary, because the term "senior" can be somewhat amorphous. If I hire a senior developer, I expect to be able to provide them with a task and not have to worry about whether their code is going to negatively impact the codebase as a whole. I expect them to have a pretty good idea of what they don't know, and be proactive enough to fill in their own knowledge gaps as needed.
The upper end of senior developer crosses into areas like "lead developer" and "software architect", which I generally don't see from developers with less than at least 10-15 years of real-world development experience. One thing I find interesting is that I come across developers who have "10 years of experience", but almost all of it is at the same job, doing the same thing. Those developers, I would say, probably stagnated after 2-3 years and, having not been exposed to new ideas, new challenges and alternate approaches to problems, have not risen above the level of junior-intermediate developer, which can be quite a shock to them when they finally end up back on the job market, claim that they are a senior developer and then fail miserably in interviews when they are asked standard senior-level questions and have no idea how to answer.
---
If you want to go from junior to intermediate and beyond, always assume that your code is probably crap and can be improved. Retain an insatiable need to get better at what you do, read articles and books written by those in your field that you look up to, never be afraid to ask a lot of questions and risk looking stupid. Above all, be genuinely passionate about writing code, solving problems, building things and doing the best job you can do.
I honestly think the whole idea of beginner, intermediate, master, and expert are pointless, but that is just my opinion. Just keep learning and pushing yourself.
I wouldn't really classify anybody as an intermediate until they have been doing it full time for at least a year. You can spend years just researching and learning stuff but, until you use it in anger you're a beginner.
This is also the same way that most companies I have worked at calculate it too. If it is your first job you are a beginner or junior developer. After a couples of years you are intermediate or associate developer and so on.
Seniority doesn't just come from learning the basics of a language, it also comes from actually completing software development projects. Notice that I said "completed" and not something like "unfinished projects" or "projects in progress"? I have certainly learned the most from completed project, either solo or part of a team, and when you have a few of these completed projects under your belt professionally then that is when you can start ranking yourself as intermediate or whatever.
Until you have completed projects you cannot be anything more that junior/novice. Others here have made excellent points that I don't need to reiterate.
"vectors" is a subject in physics not computer science, nor programming, the way i know it. But they are useful in game design, so wth.
about your question; it really seems to depend on what you mean by intermediate. I'd call you an advanced programmer, in comparison to a novice programmer who's still messing around with basics.
