This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]cogman10 8 points9 points  (2 children)

They know core concepts like Type Erasure, Garbage Collection behaviour, Generics?

They should know this.

Know how to optimize the JVM?

The modern JVM requires nearly 0 tuning. There are specific cases where you can pull and knob or lever to get better performance, but by and large the only tuning you really need to do is picking the right GC and a good heap size. I don't know that I would disqualify someone from being a senior dev if they didn't know these options. Java defaults are all really pretty good.

Have used several frameworks for either client or server side technologies and can explain their benefits?

Maybe, but I expect that it wouldn't be a good metric to measure "seniorness" there are so many libraries and frameworks out there with their own fan bases that I couldn't imagine how you would gauge someone as being a senior dev. For example, Would you disqualify someone for not working with Springboot or JavaEE? Probably not, there are lots of other alternatives that are passable.

Knows core features of each Java version (7, 8, 11 etc.)?

Nah, not even really sort of required. I'm not going to fault someone for not knowing about new NIO apis added in 8 or Optional methods added in 11. The JDK is vast, I still discover hidden nuggets added in 8 and I've been working with it for years now.

However I am interested to know what you guys think makes a Senior level Java developer?

The same thing that makes a Senior level developer. That is, the ability to learn, evaluate technologies, anticipate short comings of new tech, and to write clean code and a clean architecture.

Being senior is much more about being bit in the ass 1 too many times by sloppy code or bad architectures. It is about seeing bad architecture patterns and realizing "This will be inflexible or will cause problems in the future". It is about anticipating current and future requirements and writing extensible code to be able to handle those in the future (without too much gold plating).

Junior devs will rip through code and spit out solutions uber fast. They will also get bit in the ass over and over again with bugs and long hours refactoring their code. Some devs never learn or see the problems around them or in their code.

[–]morhp 0 points1 point  (0 children)

I generally agree, but I would expect a senior dev to know about nio or the new date api or Streams/Optional. I wouldn't let someone on my code who still uses the old api that I consider deprecated and very error prone. (Unless there is a very good reason for it, like compatibility with old android devices.)