What counts as "Java software experience" after all? [closed]

Question

I have been working as a Java software engineer for the last 3.5 years. Recently I have decided to leave the company I'm currently employed at in search of new opportunities and a higher salary.

I'm leaving in 2 months but I thought it would be nice to start looking for a new job in advance.

So I started going through job positions on the Internet and as I thought nearly every employer truly expects you to know like a lot, simply knowing Java is not enough. One should also know SQL/Hibernate/Spring/JMS etc etc to make it to the interview process.

Unfortunately, I don't have this experience. In my last job I've had "so-called" hands-on experience with the frameworks and SQL, however it was more of maintenance, not development. If someone asks me to build an application using these from scratch, I'm likely to fail / not understand what I'm doing. It seems to me that I've just wasted 4 years of my professional life gaining irrelevant experience and missed out. Feel like I'm still a junior and learnt nothing.

I can only brag about dozens of REST integrations / Cryptography tasks I implemented. And English (it's foreign for me)

Is there a way to quickly learn what I have no solid knowledge about?

Or should I just get over it and put it down to "experience" ? (no pun intended)

Would you hire a person that has no deep knowledge of modern frameworks?

And finally what counts as "Java software experience" after all?

Answer 1

If someone asks me to build an application using these from scratch, I'm likely to fail...

If they asked you to do that during an interview, yes, you'd fail.

But at work, if they gave you a full week or two to hook up a new application to a database, I'm pretty sure you'd muddle through.

If you don't feel confident about that, maybe you should just prove it to yourself and create a personal project, that involves a connection to a database.

Your personal project wouldn't need to use all the frameworks referenced, but if you can prove to yourself you can use something similar, I'm pretty sure your confidence would skyrocket.

Answer 2

Your job had to do with SQL etc. so you put that under experiences. It is rare to have a job where you design everything including the integration of all external systems from scratch. As long as you had to deal with a technology, it can go under experience with that technology. If you group the technology skills by experience level, you can address it there, e.g. "Java - good", "SQL - basic" etc. If the CV in your region typically has a section for each job you had, you explain there roughly what you did with each technology. If not you answer truthfully at the interview. Some lightweight exposure to the techs people are looking for is better than none. Also understand that job descriptions are typically Christmas wish lists. One rarely gets a developer that meets all criteria.

Answer 3

Know enough about the domain to ask important questions regarding domain specific roles

For your SQL example, ask them "What is your expectation of performing database administrative work?" or "Is there support staff or extra budget available to do database optimization, backup, and maintenance?"

What you're trying to figure out is whether your employer is going for a combo package and make you perform in multiple-roles. 20 years ago, it is possible, but not anymore. Any employer who thinks even just pure front-end (desktop, mobile, accessibility) is a one-man job, they probably have no idea what they're doing.

Once you dive into backend stuff like SQL, you might be on the hook when the system gets hacked (InfoSec is definitely its own role).

You can specify exactly what you have done, but always figure out how these skills fit into the company. If they do not give resources for the role to succeed, then your experience will be unpleasant.

Answer 4

I think if you just told the interviewers what you explained in your OP, you'd be surprised how many employers will appreciate your honesty and humility. Nothing tells me more about a person's character than admitting their faults publicly and expressing a desire to improve.

To answer your question: the definition of "relevant java experience" is subjective to the company you are applying to. Ask them what they require the java experience for (ie. the tasks that you will be doing), and then explore how best you can achieve them. If the company agrees with your assessment, then you either have a job or you don't but either way, the expectations are clear.

Answer 5

The skill lists in job offerings are wish lists.

Companies are well aware that it is unlikely that that they are going to find someone who has years of experience in every single one of those skills.

Rule of thumb is that it makes sense to apply to a job posting when you fulfill at least half of the requirements, and know what the rest of the requirements mean.

Answer 6

I'll approach the question from the other side - what they'll really expect from you. The vast majority of Java projects I've encountered are composed of similar components:

• Spring Framework for the application scaffolding
• Maven or Gradle to build the application, run the tests and deploy it to a compatible repository such as Nexus
• JDBC/Hibernate for database access, because nearly every application uses some kind of database these days
• Some build system to do Continuous Integration (Jenkins, TeamCity, etc.)

If you have at least some experience in these areas, you'll do fine. Does not have to be the specific ones I listed, other technologies in the area are usually similar enough that the experience you have will translate to the new technologies. It does not matter what database back-end you use for example, the general approach you learn for one mostly applies to the other.

If you're unfamiliar with any of these areas, just look at some recently-written tutorials on the subject. These should give you some experience and ability to search for answers. Spring, for example, had a very steep learning curve, but with Spring Boot starters, it's easy to get started and experiment.

It may happen that the stack the company runs is wildly different to what I wrote above, but in that case they will not expect you to know everything from the get go and they'll expect you to learn a lot in the fist few months of your employment.

If you're joining an existing team of people, they will quickly teach you whatever you might be missing. It's worse if you become a "lone gunman", you'll have to be a quick learner if you're not already familiar with the technologies, otherwise your tasks may slip and you may be perceived as unproductive.

Answer 7

I never expect a candidate to know everything listed in a job offer. Technology list in a job offer is a way to let the candidate know what he will be working with. He applies if he's happy with it.

First red flag - candidate doesn't know anything about one of the technologies listed. He had time to look it up before the interview, and now he doesn't even know what I'm talking about - makes me think he doesn't want to learn and is not professionally curious.

Second red flag - he has few years of experience and doesn't know any specific technologies - not only the ones listed, any. What did he do for a few years?

I interviewed people with Spark/Hadoop knowledge who knew very little about Spring, I'm not gonna turn them down because of it. I know everything I need to know:

• why they don't know Spring - they worked with Spark/Hadoop
• they have the skills to learn Spring - they learned Spark/Hadoop before
• they want to learn Spring - it was in a job offer and they applied, then I asked them about it in an interview

You should:

• start looking for more challenging work - you are already doing it, good
• work in your spare with technologies you want to learn - as you should always do, even if you have a stable job you are happy with
• never lie or evade questions about your knowledge, any experienced interviewer will immediatelly see through it, seriously. I say that because of your quick learning question - there is no quick learning

Answer 8

Unfortunately, I don't have this experience. In my last job I've had "so-called" hands-on experience with the frameworks and SQL, however it was more of maintenance, not development. If someone asks me to build an application using these from scratch, I'm likely to fail / not understand what I'm doing.

Maintenance and experience working in other people's existing and legacy code is far more valuable since it's where the vast majority of effort happens.

Initial project setup for any new codebase/repository happens only once and takes a short period of time. Long-term maintenance and evolution of that project can last for decades and involve many people. In your current position, being able to create a new project from scratch isn't particularly important as far as experience is concerned. The other experience you mentioned about REST integrations and Cryptography sounds far more valuable.

Since you're not applying for senior or technical leadership positions, the vast majority of jobs out there won't ask you to build brand new projects from scratch by yourself because those are a significant investment for any employer or client; they'd generally insist on having strong technical leadership and involvement from others in the business to make sure that the fundamentals of the project are strong.

In the unlikely event that you are asked to create a new project by yourself, the company would most likely already have other projects and documentation which define a set of patterns and standards that you'd be expected to mirror, or even a start-up template, in which case you'd follow/copy those, but almost certainly with oversight by a senior engineer.

If you have a new project, then any sensible company would want to make sure there's sufficient technical oversight and leadership from senior engineers to support the people doing the 'real' work, and also acting as reviewers/gatekeepers to ensure quality is up to par and be looking out for potential problems

In a typical New project scenario, there also tend to be a whole myriad of issues to grapple with and a lot of different people involved, with a relatively long 'inception' or 'discovery' period before any deliverable project artefacts are created or any code is written, so this is a significant amount of time that you'd have as a developer to understand what you need to do before creating the project.

Before even thinking about the project's code structure you would be involved in project planning, requirements analysis, big-picture architecture; the initial phase nearly always involves a great deal of learning and de-risking for everyone involved in the project - developers are usually tasked with learning any new tools or technologies that they've never used before.

Overall, it's never in any company's interests for any project to be handled exclusively by a single lone-wolf employee, and any sensible employer will already understand the need for a significant ramp-up time for the project team to learn and figure out what they need to do, as well as the need for that team to get plenty of support before the team can be productive.

Answer 9

I first worked with Java at the beginning, in 1996, when there were no frameworks and you couldn't just Google everything. I did other non-Java things for the next 15 years, but ended up back on Java about 5 years ago. The difference was night and day, and I felt a little like you do at the moment. There was so much to learn and relearn.

These days, I don't think anyone builds a complex Java application that can do REST and SQL from scratch. I'll bet 95% of current Java engineers couldn't do it. Not without spending a good day or two and Googling everything. Today, frameworks have removed all the pain and hassle. To create an application, you run Spring Initializr, and that's that.

So I wouldn't worry about having that level of knowledge. You don't need it. I would spend my time getting familiar with a modern framework. Spring is probably the best one right now. Invest some of your off hours in some homework. Install the free version of MySQL and build a simple multi-tier application that does SQL, REST, and even some MVC for the UI. There are plenty of tutorials available that will walk you through every step. That shouldn't take a lot of time, but it will dramatically increase the breadth of your knowledge and skills. I would even go so far as to write some unit tests using JUnit. If you do that, you should be well prepared to move to the next level.

Answer 10

First, don't leave your current job, keep it until you have a written offer and then leave. Meanwhile, do your homework, literally.

1. build a todo list from scratch. Backend spring boot, database postgres, frontend angular. Just follow a tutorial online, be honest with yourself and try to understand better what you don't get at first sight. An example? How to secure your app (JWT for example with Spring Security), how to scale your app ( try to create docker container for your app) and maybe deploy on heroky/kubernetes or do a performance test (Jmeter) on your backend rest services or profile your memory consumption
2. after first app, start from scratch again and again. Do simple apps, from scratch, maybe change database tecnology, maybe a little bit of frontend, or instead of spring, use Wildfly and JavaEE ( JakartaEE). After ten times, you know what you must know, really.
3. build a showcase/blog for your projects. Put your code on github / public repository this helps a lot !
4. be informed on last ( I mean after Java 8 ) Java releases and what is going on in the space. Companies does not like ( at least most of them) to work with last Java releases, so be sure to know all new features of Java 11 ( last Java LTS ) right now
5. before each interview, be sure to ask which tecnology stack company use, so you can prepare and study on it. Internet is your friend!

After more than a decade on this job, as Java developer I can say that what is important is not knowing the tecnology, but understand the process in your mind:

1. how to stop and think before do anything
2. try to plan and work with other people (communicate is a must, try always to be clear on what you have understood and ask confirmation!)
3. then code ( git/branch etc.. )
4. review process / test / debug
5. how to release / put in production and real use
6. work on bugfixing

Software developers are dealing with code, people, ticketing systems, time management, bosses expetations, your mood and inspiration and a lot of strange bugs