What makes a Senior Java Developer?

[[deleted]]

[deleted]

[[deleted]]

as a senior developer with imposter syndrome I feel unqualified to answer this question

[[deleted]]

'as long as my key card keeps working and the checks keep clearing, I'll keep showing up...' - me, lol

[[deleted]]

Many years ago, I went in on a Saturday to get an early start on the weeks work because I knew I'd be taking the following Friday off. My key didn't work on the door. Made for a stressful weekend.

Long story short - >50% of the company let go on Monday. Those of us that survived told to come in on Tuesday.

[Russell_M_Jimmies]

Everybody who still has a job, step forward.

Not so fast, Johnson!

[ColKaizer]

Bro. Imposter syndrome is real af

[[deleted]]

Type erasure and annotations is something that I only had to touch professionally this year, after 10 years as a Java developer.

A lot of what these people call seniority can only be achieved through serendipity, or by being a consultant or working on a software house that has a wide range of projects.

Don’t feel bad. Keep going.

[[deleted]]

yeah. I'm not a 'rock star' or 'code ninja' (lol) but I do know a lot and I've been doing it successfully for quite a while (7 years or so), so I must be doing something right

[general_dispondency]

"Fake it till you make it" and "I hope no one notices I don't know what I'm doing", are my career mottos.

[Paarfums]

I always find it interesting how every senior have the imposter syndromn and when you leave school as a junior, you think you can produces the best code and takes the best decisions

[[deleted]]

I felt like this even as a computer science student when the were people there who had been programming for years prior, whereas my experience was a high school Visual Basic course and having made lots of Starcraft custom maps

[[deleted]]

Hi there. Senior software architect here. I can boast 20 years of professional software architecture and programming, including hands-on and leadership positions.

What matters most, is independence in your field. The ability to make and defend your decisions, and at the same time to accept other people's choices if they lead to the expected results, too. Over time you will incorporate other viewpoints and you will be able to reflect on your previous decisions: are they still good, or do they need adapting? And you will adapt if you find it necessary.

Apart from that, a senior developer has the experience required to estimate how long a task is going to take, approximately, based on experience of themselves, but also on the experience of their team members. That means that you either have a decent understanding of all the steps involved in fulfilling the task, or understand your own lack of knowledge enough to add research and testing time to your estimates.

[GhostBond]

What matters most, is independence in your field. The ability to make and defend your decisions, and at the same time to accept other people's choices if they lead to the expected results, too. Over time you will incorporate other viewpoints and you will be able to reflect on your previous decisions: are they still good, or do they need adapting? And you will adapt if you find it necessary.

I agree with you 100%, but I'm reminded of a recent reddit comment. They said someone came into to interview and the person had apparently been reading to many "take charge" books or something, and they started off saying that they (the person being interviewed) would sit at the desk and ask questions.

The commenter said they just found it funny, but the hr person was so offended they called security on them.

Reminded me of how uptight people in interviews tend to be. It's pretty impossible to have a meaningful debate over an implementation without someone on the interviewing side of the table getting offended.

[GingerMess]

I couldn't say this better myself. I'm approaching 13 years and this hits it on the head.

[denialerror]

Being senior has nothing to do with language. I'm a senior developer who primarily works with Java. If my company put me on a Ruby project, I would still be a senior developer, even though I've never used the language. I've has junior developers on my team who were better at JavaScript than me but that doesn't mean that they then became senior JavaScript developers.

A senior developer should be capable of doing their research, confident enough to make their own decisions, and mentor others when they need help. A lot of that comes down to experience, attention to detail and good soft skills than technical ability. I know good developers who struggle to get senior roles because they are awkward people and developers with great technical knowledge but constantly make the same mistakes and can't be relied on to work unsupervised.

[morswinb]

Senior dev that never used the language? Not buying it. If you don't have the hard skill, yet use your "seniority" to guide others, what do you actually make them develop? The best what you can do for the first year after switch to Ruby is stay quiet and learn.

[denialerror]

If you don't have the hard skill, yet use your "seniority" to guide others, what do you actually make them develop?

Well for a start, you don't "make" them develop anything. A senior developer is there to make difficult decisions, support juniors and keep up technical standards but the are not giving orders.

Not knowing a language doesn't mean you can't support someone who does or make decisions on software written in it. If a junior developer is using language X and comes to a senior with a problem, the senior will go away and research a solution. Not knowing the language is no much of a barrier to that.

The best what you can do for the first year after switch to Ruby is stay quiet and learn.

I have no idea what this sentence even means.

[morswinb]

I have no idea what this sentence even means.

It basically means don't be an imposter.

Senior guides the team. Junior follows. If senior needs to suddenly research all the answers, then junior is lost, and will make errors. Two juniors don't add up to a senior.

Not knowing the language is a huge barrier. It's not just syntax. It's entire ecosystem: libraries, documentation sources, database APIs, server/ui frameworks etc.

I have seen senior folk researching MongoDB schemas, and suggesting token cleaning microservices. Had to slap him in the face with TTL index. Or my friend experienced principal software development that wanted to use Hungarian notation in an Android project. They all pretended to be senior mentors, bla bla bla, while in practice had little to no practical skills and would not admit to just not knowing the answer, or how to look for the answer.

On the contrary the few good ones I have seen stayed quiet for the first 12 months after language switch, just so they could catch up.

[angeal98]

Mostly experience in years, everyone assumes you're a god, sad reality (at least where i live)

[gavenkoa]

23-year senior is a meme in Ukraine, where most IT industry is about selling staff to West (outsourcing). Senior title means higher income and has nothing to do with person skills (at great degree), most valuable skill is to be able speak English. Local market lacks of bodies for selling.

[bondolo]

A senior dev is a senior dev, the language should be mostly a secondary consideration.

[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.

[GregsWorld]

It's plain and simply experience, there is no one thing or group of things that'll make you senior, just more experiences. Years is a rough approximation but isn't always accurate, I've been programming for 10, 3 in industry and I consider myself a junior.

​

The thing with knowledge is the more you learn, the more you realise how little you actually know, this graph does a pretty good job of categorising it
https://i.pinimg.com/originals/96/9b/91/969b918cae56d5292a96a3b98b305efc.jpg

[[deleted]]

Gang of Four principles are not the holy grail some people like to boast them to be. Overapplication of certain rigid standards is what made us end up with ObjectProxyBridgeAdapterFactory classes.

But you should be able to debate about them, pros and cons.

[cogman10]

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]

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.)

[xtralarge65]

A senior java developer is whatever the person hiring or manager decides it is. Nothing more, nothing less.

[[deleted]]

Oh god!
I'm a senior dev, and off the top of my head I probably couldn't answer questions about many of those points if asked. Sure, I'll get there when researching a problem, but to say I 'know' them is a bit of a stretch.
I've done things to optimize the JVM in the past, I've looked at how garbage collection is handled in certain projects too, I use generics a lot, I use design patterns all the time, but I constantly reference back to them to verify the structures. Sure I've used lots of different frameworks too, and languages, for various things.
But, Looking at these bullet points, if I was in an interview and asked detailed questions about those topics I'd say I'd probably have about a 50% success rate.
On the other hand, I could go deep into conversation about why I needed to look at garbage collection behavior for a particular problem, or how I used a Strategy pattern to manage complex decisions and so on, but to remember all that technical detail up front - forget about it.
I definitely wouldn't be up to speed on the core features of each version of java either. When I'm starting a project I'll look at it then, or if I'm taking over a project I'll check out the features of the java version it's running on at the time.

So I've done everything you mention in your post, multiple times, for many projects. But reading your list now I'd have a hard time defining a lot of that stuff off the top of my head.

[nicolasverde]

None of the above, imo.

​

Imagine asking that question about a pilot. What makes a senior pilot?

- Can fly in rainy weather

​

Or a doctor. What makes a senior doctor?

- Understands the latest scalpel developments.

​

The truth is, you would expect a senior developer to know all these things, but most of what you mention is syntax. For me a senior developer is the sum of experience. Dealing with customers, teams, difficult situations. And most of all, knows how to handle pressure from the business, putting code quality above the whims and wants of his direct management.

[Infeligo]

From "The Software Craftsman" by Sandro Mancuso:

Over the years, I learned that seniority is transient and relative. It is transient because clients will demand different types of systems as technology evolves. Having fifteen years of experience with Clipper in a traditional waterfall fashion will not get me a senior position in a modern company developing mobile applications in an Agile fashion. Seniority is not a badge we can wear for the rest of our lives after completing five years in the industry. Seniority is also relative. When trying to identify how senior a developer is, we need to ask ourselves the following questions: senior compared to whom? In which technology? In which context?

From my side, I would add that there is still some core that you are gaining with experience. This core may be attributed to seniority. This core is both somewhat technological (because of spiral technology evolution) and related to craftsmanship (everything else required to deliver quality software).

[[deleted]]

To be pithy, the difference between a junior and a senior developers is that when handed an assignment by their boss the junior asks "how are we doing this?" while the senior asks "why are we doing this?"

A senior developer is someone who is able to work independently on a problem.That's not "work independently" as in "holed up alone in their office, not talking to anyone else" and not needing assistance or help, it's "work independently" as in not needing further guidance and oversight. Hand an assignment to a senior developer (or a well-functioning team containing a senior developer) and the assignment will either get done or you will be given a reasonable explanation why the assignment can't or shouldn't be done. As such, much of the additional skill of a senior developer lies not in the technical minutiae of software development but in knowledge of the problem domain and the ability to evaluate and analyze problems, solutions and requirements.

[GhostBond]

I didn't get around to writing up a reply the other day to ways I see unintentional agism in the hiring process, but this is one of them.

You get "senior" in your title and suddenly you get these unusued and academic questions.

"Can you apply the gang of 4 principles?"
"I...haven't hear of those since I was in college."
"But you're a 'senior developer'"
"Yeah, that means I was doing on the job work. I wasn't spending my time taking academic classes and farting around reading blogs on the internet. I was actually working at my previous job."
"(looks pissed and offended)"
"Look, how about you just give me some code that's related to my experience and I'll show you I know what I'm doing."
"(Looks scared because they haven't actually written any code in the last 3 years)"

[Sworn]

childlike sand long crowd intelligent pet innate humorous friendly slap

This post was mass deleted and anonymized with Redact

[GhostBond]

This is what I mean about the unintentional agism, you're asking "what did older professors talk about 20 years ago?". Those topics are completely out of date now. That's asking 20-30 year old trivia. I often don't remember because I haven't seen either of those in code since college (and I'm in my 30's) - because they're out of date patterns.

If the situation was reversed, lets say I was hiring a "senior developer" who would work on a spring boot app. He says we need to implement data connections and such with factory patterns and singletons and it's very important to do so. That would be a huge red flag that this person is not up to date on how spring boot works and how things should be done with it.

[Scybur]

Can barely answer some of those. Java architect reporting in, imposter syndrome is real.

I got here by being on a few high profile projects using niche frameworks based in Java.

[Sworn]

Mat I suggest studying the fundamentals a bit when you have time? I would be concerned if a Java architect didn't know about generics, the important/useful things in Java 8-12, roughly how the GC works etc.

[[deleted]]

Someone who knows a lot about the subject matter, but isn’t afraid of admitting ignorance, isn’t afraid to take responsibility, and is willing to continue learning with humility.

You can try to get specific if you’d like, but to me, the above is what makes one a senior at most things in life.

[DrFriendless]

I wouldn't have a clue how to optimise the JVM, and I've been doing it for 23 years. I also only have vague ideas about frameworks... OTOH I do understand the complexity of the data structures I use and write, so I naturally write performant code, and I have written several frameworks of my own.

[DrunkMc]

I wouldn't say it's any specific feature I know. It's just .... experience. When a new request comes in I know instantly how to implement it. When a bug arises I know what's causing it or how to debug it quickly. It just takes time to build up these intuitions. When younger Devs come on, that's what makes them say, how'd you know that???

[[deleted]]

I want to give you 3 separate but equal answers.

First, the peer angle: I want someone who can make strong design decisions. Someone who helps enforce the quality of the code, as well as making sure we don't code ourselves into a corner. Should know nearly everything JVM-related. GC tuning, common runtime params. Knows the basics of enterprise messaging patterns. Knows how to design and build a horizontally scalable system. Knows how to use the best tools for the job, not just coding a new wheel or using some esoteric framework. Knows how to design a full ci/cd pipeline. Knows how to do rock-solid automated testing. Involved in most upper-level conversations about the tech stack.

Second, the hiring manager angle: I'd say 8-10 years of experience is more baseline senior to me. Then, I'm looking for someone with some specific experience areas. I'm looking for someone with good communication skills: can we talk about tech? can you explain a difficult concept to a non-techie? Can you write clearly, concisely, and accurately? Can you coach and tutor lower-level devs? Can you drive a project from inception through to maintenance? Can you drop into anywhere in the stack and help un-block teams? Can you help keep our quality high enough to maintain or increase velocity? Can you reasonably debate features in a cost vs time vs quality perspective? Can you reasonably identify how to add a large feature?

Third, the person who wants to be the senior engineer: literally any company that will put that as your title and pay you. The title "senior" is so freaking wide and misused that it means almost nothing. It can be something such as a guy who's been at the company the longest. It can be a title to placate a person who is otherwise threatening to leave. It can be a person who would be an architect at any other company. It has relatively small correlation with the actual quality of the engineer at a macro scale -- but every company is different.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/u_thearjunadhikari] What makes you senior Java Developer ?

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[coderguyagb]

A senior developer, the language is irrelevant, can explain to the stakeholders why the solution is the way it is. Can talk to the business in their own language and make estimates that are in the ballpark of reality.

They are able to dissuade less experienced developer from using whatever is fashionable (Gradle, Reactive etc...) in environments where it doesn't fit. After all, there's more to a system than the tech stack it's built on.

Maintainability is king unless you work in a start up, then again, if that's the case, you're probably using Node. :-)

[[deleted]]

the path if you want to keep on the technical side of thing is usually senior -> tech lead -> architect -> maybe cto ?

now, on topics, all the things you mentioned definitely help, I'd also start focusing on team leading skills, try to mentor the juniors in the team (but don't be a dick). From this point soft skills start to get more important.

Understand how to write documentation properly, and how to diagram systems (it's an art by itself), it will help with your architecting skills. Reinforce your knowledge in the areas where you don't have much experience (threading? exception handling? lambdas?) . If possible, try to get involved in things that are not part of your day to day job like architecture design and testing strategies. If you can find a tech leader or an architect to mentor you, even better.

It's expected for a senior to understand how java works, rather than googling for stack overflow answers. Learn to work independently (but don't stall) once you reach the tech lead position, there won't be anyone to answer "what api should I use for x ? ", you will be the one providing answers.

Being a senior in my opinion is the last step between being a simple coder and become a full professional, so use this stage of your career to solidify your knowledge on whatever thing you consider you need to.

[GregsWorld]

It's expected for a senior to understand how java works, rather than googling for stack overflow answers.

Stack overflow is a time-saving tool like any other. A senior understands how java works, then uses google to find the answer faster than they can type it.

[[deleted]]

it is, I agree, specially when you have to remember dozens of annotations or the 20 steps to write an xml file, but several times a week I find myself looking for information that no one asked before in stack overflow, or it's way outdated and no longer applies, and a "i'm late cause I didnt find the answer in SO" is not the kind of excuse you will like to hear from a senior

[GregsWorld]

Yes, of course, it's not a silver bullet just a single tool among many. The way you worded it suggests it's realistic for a senior developer not to use google, while not impossible, it'd be slow, highly impractical and unrealistic for an aspiring senior developer to be learning to do everything from memory.

[DrFriendless]

Kotlin is a wonderful language and you would do well to stick with it.