Recommended reading: Dreyfus Model of Skill Acquisition. The funny thing is when you learn more, you discover that there is always more. To running company or manage project you need rather business and interpersonal skills, because you would delegate work.

I'll tell you as soon as I get some real programming assignments at my job.

I call myself a C# expert - I know every keyword, I know some IL hacks, I know a lot of the core .NET framework, and I understand the performance implications of pretty much any code you give to me (Database/Web service optimisation notwithstanding). I have written code covering almost every aspect of 'Core C#' including P/Invoke, unsafe, advanced generics, attributes, thread safety, LINQ, parallelization, etc. etc.

But as many guys here already said, part of being an 'expert' or 'senior' programmer, I think, is knowing that you are still very capable of making mistakes and that there is always more to learn. I want to improve my understanding of IL and CLR's execution model, for example (just... Where does the time go?). And every time I start a new project I think I've designed the perfect OO architecture, but it always turns out to have flaws (though I do get better every time).

Also, some people may in fact call me a beginner because I don't know very many .NET libraries and I know almost nothing about the web-sphere (I don't even know what the difference is between ASP.NET and err... The other one). So to finally answer your question, I would say that being an expert is where you feel confident in your abilities, and that they are relevant to your niche, but you understand you will never know everything or be perfect. Then again, ask me in 10 years, I'm only 25 and when I'm 35 I might laugh at what I wrote here. :D I call myself an 'expert' and not a 'senior' because my years of experience are small still (only 3).

Oh and I wouldn't sweat it about keeping up with JS frameworks, just work on your core skills and then you can learn what you need when you have to.

/u/14d2025 mentioned the Dreyfus Model. That identifies a set of categories, but is not without detractors. Of course, there is no One True Way to determine this. If there were, interviews would be much more cut and dry.

That said, here's another way to look at it. If you are a "Senior Programmer" then you should be a source of information for others as opposed to a sink. That doesn't mean you know everything or aren't still learning (even from the more "junior" folks). It just means that, on average, you can provide more information than you need. A slightly different take would be that your focus becomes less just about you and your tasks and more about others and the project/program/company as a whole.

Also, you are definitely right that you are unlikely to "master" programming. That would be a bit like trying to be a "master" at medicine. I was speaking to an honest-to-goodness brain surgeon a few weeks ago. This is a highly regarded professional in his field. However, he readily admitted that there are plenty of things outside his area of expertise even when it comes to the (biological and chemical) workings of the brain.

• Quick edit to add: You are experienced enough to run a development team, manage a project or company when one of two things is true. Either you convince someone to let you, or you are confident enough to try it and accept the consequences of failing. Most folks that I have talked to that run companies have more failures in their past than successes.

The job description asked for an expert, suddenly I was an expert.

It's an almost meaningless term that roughly translates to: "Can safely work without somebody looking over his shoulder."

After I started interviewing candidates with 3x my experience I began to feel comfortable with the progress I was making in my career. Most of my challenges are language agnostic and generally focus on problem solving. Sometimes they are based on concepts like asymmetric encryption but never at the implementation level. There are no right answers just less wrong ones. Most candidates don't even bother taking a shot at a solution despite my urgent pleading to do so. I have never turned down a candidate that has tried to answer all of the questions so far, even if they are just borrowing with popular solutions.

When you take leadership over a project and can envision its design from start to finish, and you can actually code it up in pretty much any language you'd like, you've made it. But then there's so much more to learn. So many sub-domains, so many new technologies.. there's the problem-solving component and the learning component. One should never rest on their laurels in this field unless you're just ready to be obsolete or you're ready for a career change. Any programmer worth their salt can pick up any language in very little time, but it takes discipline and practice to keep these skills relevant and sharp. A senior developer does all of this and has the willingness to learn more, apply fast, and thrive in any environment at a leadership capacity.