Over the past decade I’ve interviewed many many engineers for different roles, for different projects, for different environments and worked with even more.
Here I’d like to share my learnings and takeaways on what are the most important skills you need to be a successful Java Software Engineer.
Skills recruiters are looking for
If you’re here, probably you’ve been through a couple of interviews already. It usually starts with a job description that you apply for or nowadays recruiters could also find you based on your LinkedIn profile.
The job description often includes the following pieces when it comes to the requirements of a Java engineering job:
- Java 11 knowledge
- Advanced Spring Boot knowledge
- JPA and Hibernate
- [..imagine the rest of the specific technologies]
- Ability to work in teams
- Ability to work without supervision
And of course the list could go on.
Anyway, before a recruiter even calls you back, they look at your CV you used for the application (or your LinkedIn profile for that matter). If there’s like 75% match between your hard skills, they’ll reach out and go forward with the process.
You start the series of interviews with the recruiter. You talk a little bit, usually this is the part where they assess if you can speak English (obviously only if you’re not a native speaker) but that’s it.
If everything goes well on this interview, you can proceed to the next step which is most probably when you have a technical interview with some folks from the company. And I know companies could do multiple rounds of technical interviews but let’s just stick with me.
Different set of skills for engineering
First let’s clarify what hard skills are. In short, hard skills are easily teachable abilities that are easy to quantify. For example you can be an expert at Java 11 by taking courses, reading books and whatever learning material you have.
On the other hand soft skills are much harder to quantify. For example we had this requirement up in the list “Ability to work in teams“. Working in teams doesn’t mean sitting down in the cubical next to the team, putting up your headphones and coding non-stop. On the contrary, you gotta be able to communicate your successes, your problems towards the team so you can help each other out when it’s needed. And for this example, communication qualifies as a soft skill, just like emotional intelligence. You can obviously learn about these things but it’s more difficult to apply these learnings in real life. You’ll have a hard time becoming a communicator and getting out of your comfort zone when you’re more on the introvert side of the scale.
Okay okay, we all know how a technical interview goes. You get into a meeting room – yeah, that’s how we used to do it before COVID – and have some warm-up, then you jump into technical discussions.
The first questions often goes from let’s talk about the accessibility modifiers in Java to talking about the equals/hashCode contract.
Then you go deeper and deeper, talking about how a HashMap/TreeMap works in detail, GC internals, OOP, Spring and it’s modules, databases, JPA/Hibernate, microservices. Probably if you’re applying for a cloud developer job, then AWS, GCP, Azure, whatever.
Lots of stuff to cover during an interview session. And after you’re done with the tech questions, usually we arrive to the practical examples. Often I see people starting to ask questions around tree structures, like find this and that in a tree in the most optimal way, or get a subset of an array with some conditions and some of these algorithmic questions. Sounds familiar?
I have bad news. If you think these are the most important things, you’re on the wrong path my friend.
I learned that the only thing that matters in terms of hard skills is the person’s ability to learn new things. It doesn’t matter if you don’t remember how a TreeMap is implemented when you’re in a stressful moment during an interview. You don’t need to know how the GC works in detail to be a awesome engineer.
It’s way more important to be able to learn these things and adapt to the situation. Of course I’m not saying if the job is about low-latency applications and you’re trying to micro-optimize how the GC works, then you gotta know the details but then nobody will ask you about other non-relevant stuff like Spring or whatever.
Generally speaking, somebody capable of learning and absorbing new things into their brain is much valueable to me in terms of ROI than somebody repeating the documentation of Spring. Software engineering is about problem solving. You’re not gonna solve problems on time if you only have the lexical knowledge. And I’d definitely hire the person with problem solving skills.
Think about the practical exercise during an interview. Does it matter if somebody is able to solve a tree-traversal on the spot? In my opinion it doesn’t. Even if the candidate can’t solve it, that doesn’t mean I wouldn’t work with the person. It’s way more important how the candidate thinks during solving the problem because that’s how I can make sure we have a problem solver here or if we have a lazy person here who doesn’t give a s**t about the job or we have somebody who spent the last week solving the most frequent practice questions.
The importance of soft skills
Another aspect I already mentioned, soft skills. This is just as important as being a problem solver.
I remember back in the days when I started my journey in the software engineering industry, I checked a dozen of job descriptions and all of them had this line “Ability to work in teams“.
Back then I was like, what the hell? How can you not work in a team? I mean we are human beings and we just have to talk to each other.
Yet, during the last decade being part of many different teams, now I undestood the importance of this requirement. Let me give you an example.
Assume you’re working in Scrum – cause everybody is Agile nowadays and works in Scrum, right? You have a team of what, 8 people. The sprint is going well so far, the standups are not tense at all, nothing’s on fire, everything is okay, going according to the plan.
The day before the sprint closing, one of the developers bring it up on the standup that he’s been blocked for the past 3 days and couldn’t proceed with a story, jeopardizing the sprint goal and the work of the whole team for the past 2-3 weeks.
If the blocked engineer could bring this up earlier when the first impediment showed up, the team could’ve resolved the issue on time and no problem. Everybody is happy. But that did not happen so the team will not be able to deliver what’s been promised. Tense moments, headaches, difficult conversations with the client, etc.
Or let me give you another example. Same deal, team of 8, Scrum. You’re in the beginning of forming your processes and how you work, what are the quality standards of the project, building your CICD, etc. Pouring the foundation of the project.
One developer loves to complain. He always does it privately, whether it’s about bad quality, wrong CICD setup, or he’s just having a bad day so he’s complaing about anything. You take it as a sign that we need to adjust something so the team can be more effective and happier, so on the next retrospective, you bring it up and you ask the developer to share his thoughts on these things.
What does he do on the retro? Literally nothing, he says it’s not that bad, he can accept it. The next iteration, the same things pop up and it goes around in circles again and again.
The person just doesn’t want to be part of the team and propose solution that’ll make the team’s life better.
And this is one of the hardest things to validate on an interview because it’s not easily quantifiable. How do you check whether somebody is fitting a team?
Conclusion – Skills to look out for
Now, let’s sum up what are the most important skills as any type of Software Engineer in my opinion:
- Problem solving
- Ability to learn new things
- Team worker
These are my key points. As soon as we go up the ladder to senior/lead/manager, the more I add to the list in regards to the specific things that comes with the job.
As I said, for example if you have a heavy event-based microservice system in Java 11 with Micronaut, then it’s crucial to have some experience with those but in my opinion it doesn’t matter if you generally know Micronaut or you know it in a deeper level. If you’re a true problem solver with a positive can-do attitude, you’ll learn whatever you’ll need.
I know this is a contraversial topic so let me know your thoughts in the comments. I’m happy to talk about your experiences and what matters to you.