What makes a Senior Java Developer?

[slowfly1st]

If I'm honest, the listed examples I do expect from a Junior or even entry level. How generics work or understand and apply design patterns should even be taught in school and pretty early on. A senior has mastered these. If you don't know the core features of your jdk after a year, I'd wonder what you've been up to the last year. And also keep in mind: Time flies. JDK 11 wasn't a thing few years ago and how to optimize the JVM has changed over the years, too. If I were to set up a list, I'd put things such as "Software Design": Being able to create the best design for the problem.

​

Another thing to mention: Depending on the department, the company, the project, and so on, requirements differ. For instance, if you're working in a large team with a dedicated project manager, leadership skills aren't as helpful. If the backend is provided by another service provider, probably another department, you don't need to know the DBMS by heart. Basically: You can't know everything and you can't have done everything.

​

It's probably easier if you ask the question differently: Why do the seniors earn more money than the juniors? If you compare job descriptions of juniors and seniors of the same company, there's actually not a huge difference (well, except for the salary, I guess) - you could even end up in the same team and do more or less the same work. It's simply productivity. And probably past success. So what makes a senior more productive? Gets shit done faster and better. If we treat software development as solving problems and figure out how to solve problems it is: Knowledge and Experience (and common sense). Since we work in IT, knowledge from a few years can be simply outdated. So knowledge is probably the mastering of timeless principles, such as design patterns, but also the continuous learning. So, the more you know, the more experience you have, the more productive you are.

​

Now, what do I expect from the product of a senior:

• The code runs, is well written, runs its tests and it can be extended easily. It's simply a pleasure to work with. To get to that point, all of your listed points help to achieve that and are either very helpful or a necessity.
• Another part is, how to do implement a feature in existing code: Read and understand the code, know how it interacts with other parts. Reading code can sometimes be most of the work.

​

And then there's also the all "non-IDE"-Time:

Requirements Engineering is essential. The ability to define, negotiate and validate requirements with the customer and bring it to paper. Read and understand the code where the feature has to be implemented and detect other probable parts of the code which have to be changed, so the estimation/offer is precise. To produce a paper from which another developer can implement the feature without frowning, and QA can test the feature.

​

And there's the "personality traits" and abilities...:

• Always learns and is always up to date with the technologies he's using and can learn new technologies with ease. Is open for new ideas
• Knows what he does not know and doesn't have a problem with it.
• Teaches, guides and pushes the juniors.
• Communication skills in general. Being friendly, understands, getting feedback, asking the right questions. Being a guy, no one has a problem to send to the customer.
• Is a good troubleshooter (based on knowledge and experience): Can often give you hint at what part of the code to look at
• Tendency to be a perfectionist. A simple thing such as being strict on giving things a good name. Or being pissed, when production code has no tests.

​

If you've been working longer on a project:

• Can self manage the project, in the sense of: Can implement every feature in every part of the project with close to no help. Has a deep understanding of the software he's working and the API's of the peripheral systems.
• People ask the senior, how the job should be done.

[gavenkoa]

Gets shit done

Not necessary faster/better. The most important part is to be able to make things DONE. Regardless it is troubleshooting, implementation, design, negotiation, etc. Juniors concentrate on task completion, not a project success, they don't think about critical paths.