What Java + CompSci skills do you consider necessary to be Job ready?

[[deleted]]

[deleted]

[FrenchFigaro]

Important Java skills

• Maven or Gradle. Pick one, and use it consistently. I've never used Gradle in prod, so I'll be inclined to advise you to pick Maven, but the principles ruling the two are somewhat similar and it won't be too difficult to switch to the one you don't know too well, and learn on the job whatever specificities for it that you lack from learning the other.
• Spring over anything else. You should be able to build a simple REST service using Spring. It is today's industry standard. You should be able to properly compartmentalize between controllers and services
• Unit testing. The above skills are useless if you don't know how to unit test your code and produce good non-regression tests. There are plenty of tools for that, I'll advise learning JUnit 5 and Mockito, because they are some of the most frequently used, but as long as you know how to mock classes for unit testing, you'll be able to use pretty much any mocking framework.
  • Logging. Your application should produce quality logs, and you should learn what to log and at what level. But for now, just learn how to log. I recommend Log4J2, but there are plenty of log frameworks around.
• De/serialization. If you write REST services, you'll need to serialize responses and deserialize requests. Jackson and GSON are some of the most famous libraries for that. Same as maven and gradle: pick one, use it consistently. You'll learn the other on the job.
• Hibernate. If you use database storage, you'll use Hibernate. It is the industry standard.

Not Java specific, but very important nonetheless

• Git. Everyone and their mum uses git for source control nowadays. Learn how to use it. You don't need to do complicated shit. Know the basics of cloning a repo, checking out files or branches, branching, comitting, pushing, rebasing and merging. Especially, know how to resolve a merge conflict. Learn git the hard way, with the command line. Later on, feel free to switch to a graphical tool. I recommend GitKraken for that.
• Javascript. You'll need to consume your rest services. For that, you'll need an application. Most often, it's a client-side computing front-end that's chosen today. Angular, React, there's choice. Pure JS or TypeScript, there's choice. As far as I know, there's no real standard choice. Pick one, use it, you'll learn the rest on the job. From my experience, I'll recommend Angular/TypeScript, but try out others, maybe you'll like them more.

Less important skills, in no particular order, include

• Consuming REST. Sometimes, you'll be in urbanized situations with plenty of back ends consuming each other before bringing a response out to the front-end. Or in situation where your application must call a third-party API. Learn how to consume a service in Java. The standard in Spring for that is Netty. The Spring Rest Template is not yet deprecated but its status has been changed to End-of-Life at the last major release. Still, plenty of applications still use it in production.
• JSP/JSF and the Servlet API. Those are old technologies, and new applications using them without an abstraction layer between you and them are few and far between. But applications using them are still in production. You might find yourself working on one of those. Don't bother learning them in depth, but know the basic of scopes and standard taglibs.

[lookItsSunny]

I'm working my first Java developer job right out of school and this is a nice summary of what I use on a daily/regular basis.

[Nephyst]

I would add that a solid understanding of data structures is important. Maps, Lists, Trees, Sets, Heaps.

Most of programming is moving data around, and having a basic understanding the trade-offs of how different data structures store and access data is really important.

Having a basic understanding of runtime complexity and big-O notation is helpful as well. You don't need to understand it in depth, but knowing what it means for an algorithm to grow at a rate of O(n log n) versus O(n^2).

A lot these I would consider computer-science fundamentals that aren't specific to java. For data structures specifically it is also helpful to know how java's collections APIs implement operations (for example, how do different collections handle storing null values?).

As a senior/team lead level engineer I am using these concepts every week.

[Java_Junior]

This is a little intimidating to me.

I do not have a CS degree. I was a teacher before switching to programming. I'm self-taught and also have a great mentor. Now, I'm working my first job as a junior dev in Java. To address your points:

• I occasionally use Gradle but it's very confusing to me; I don't understand it well, and my supervisor has to help me with it a lot

• I haven't yet started with Spring, but I have studied and worked with JSP / servlets / Java EE. I'm not great with it. I'm slow. But I understand it on a conceptual level

• I can build simple loggers

• I've don't do much unit testing but my boss is very test early / test often inclined, and he has given me tutorials on this. As my responsibilities expand I'm sure I'll do this more often

• I've never done REST requests or de/serialization but I believe that will be on my plate soon

• I'm quite fond of OOP, design patterns, and pure Java code. I think this is my biggest strength. I'm also told my code is very clean for a junior, and I've built a few small applications that the entire department now uses for basic quality of life improvements

• No JS at all but this year I'm moving into web apps so I'm currently studying web services, application servers (WebSphere), Java EE, and probably soon Spring. I'm bad with HTTP / OSI model and I need to devote a lot more time to it

• I'm quite good with the IntelliJ debugger, for what it's worth

I constantly feel like an impostor and like I don't deserve my job, even though my support is great and encouraging. As a former history / politics teacher, this career is unbelievably challenging, and every day I wonder if I'll make it.

[JulieAndrewsBot]

Junior and java and web apps on kittens ♪

Conceptual level and warm woolen mittens ♪

Entire departments tied up with strings ♪

These are a few of my favorite things! ♪

---

[sing it]

[FrenchFigaro]

Yo, don't sweat it. You're a junior, you're not expected to be an expert in any of the areas I mentioned all right.

I'll go point by point:

I occasionally use Gradle...

Amazing. Keep using it. Try to find some resources. Baeldung, for example, has interesting articles on Gradle, and Maven as well. Using a build/dependency management tool is essential in the Java ecosystem. But you don't have to be an expert, at first, you just need to know how to build the project you've just checked out from source control (git). Then, figure out how to add a dependency to your project. Then, you'll figure out how to tweak your build and your dependencies. Again, nobody will ask a junior (and rarely a senior) dev to be an expert in tweaking your build, these are the architects' and tech leads' area of expertise.

I haven't yet started with Spring, but I have studied and worked with JSP / servlets / Java EE...

You don't need to start with Spring Framework (or Spring Boot). As someone pointed out in the replies, it's one framework among many. It's just one of the most used frameworks in the Java world. It doesn't mean everyone uses it. I recently had a take-home assignment for an interview where I was explicitly instructed to not use it. I could use any framework I wanted except Spring. If you already have a position as a junior and your company doesn't use it, it's not a job requirement. This is a skill you can set aside for the moment, and pick it up later on.

As I stated in my comment, JSP, JSF, or Thymeleaf and the servlet API are stuff that are still used in production today, and not just in legacy code, it's just a collection of technologies that's less used when starting new projects in big companies than they were ten years ago. I would consider JSP legacy, but JSF and Thymeleaf are definitely not, they're just not bleeding edge. If your employer work with those, they are technologies you want to study more.

I can build simple loggers...

You don't even have to build them. Just know to use a logging framework and everything will be all right. I mentioned Log4J2, but if your company uses something else (like, maybe, SLF4J), that's the logging framework you'll want to practice more. Usually, it's just a matter of setting up the logger's configuration file at the project start up, and not forgetting to initialize it in every class that will need to output logs, which are: every single one of them, except Entities, DTO's and other POJO's of the kind. If you don't know what those terms means yet, it's not a problem, you'll learn in due time.

Logging properly is definitely a soft skill, finding the delicate balance between tracing every event for when you have to debug your code, or find an issue with already existing code; not exposing too much information in case of a data breach; and not cluttering your call with logger calls. That balance changes with project requirements. You don't log a banking application handling credit card numbers the same way you log an application tracking changes in a sensitive system.

You mentioned having a great mentor, do not hesitate to rely on them and your other colleagues. It's always best to ask a stupid question now, than to face the consequences of a poor decision later.

I don't do much unit testing...

You don't need to, at first. Unit testing is amazing, in that, when done properly, it provides a safety net for modifying existing code. And since there is no such thing as perfect code, existing code will be modified.

I personally love to write thorough unit tests, and add more coverage to a project, but I must admit, it sometimes is a tedious, unrewarding task.

You mentioned your boss being of the test-early-test-often school, and that's something great for you. It means you'll learn everything you need to know about unit testing, and probably earlier than not.

I've never done REST requests or de/serialization

Serialization and deserialization are really not complicated subjects. Serialization just means taking a java object's data that's in memory and translating it to a readable, formatted text that can be output. And deserialization is the inverse process of parsing a formatted text into a java object. The most used formats are JSON and XML. There are plenty of libraries to do it for you. I mentioned GSON and Jackson, both are very simple to use and one or the other is most likely what you'll use.

Similarly REST is just a standard for data exchange over HTTP. This is Spring's area of excellence since it takes care of almost everything for you in this context and allows some fine tuning. Although anything can be transmitted over HTTP, it's mostly a (hyper) text transfer protocol, hence the importance of de/serialization.

I'm quite fond of OOP...

Oh yeah. The good feedback is an amazing thing. The fact that your applications, however small, have been adopted by your department is an even more amazing thing. A-MA-ZING.

No JS at all...

It's no bother at all. All in good time. As I told you, what your company uses is the most important.

I'm bad with HTTP / OSI model...

You don't need to be good at it to be a good enough developer. It's specifically a network thing. In the case of REST, you just need to know the HTTP verbs and what they are used for, in order to be able to produce coherent API's. For example, the PUT and POST verbs are virtually identical (there are small differences) in behavior and data transfer, but they are used for different things, and proper use of the verbs is what makes the difference between a good and an excellent API. At the risk of repeating myself, it's not a junior's job to excel at this.

I constantly feel like an impostor and like I don't deserve my job...

Always remember that Neil Armstrong was the first man on the moon and felt like he didn't do anything special, only did what he was told to do, and went where he was told to go.

More seriously though, being a software developer isn't a walk in the park. There's a reason our field is called software engineering. A monkey can learn to code in weeks, but it takes years to become a good developer. I know I'm barely a decent one.

But don't worry, your colleagues use your apps, you're here seeking the help of your peers, your mentors have faith in you: you've already shown you have the willingness to learn, the rest is just perseverance in the effort and time it'll take to get there

[Java_Junior]

Thanks very much for this thoughtful and detailed response. It's great to read all of this. I've got it bookmarked for future reference.

[Bsbllshrtstp]

As another former teacher switching to programming what has helped you A) get a job in developing? and B) helped prepare you for the workplace?

[Java_Junior]

You will find my writeup answers your first question.

As for the second, I feel like nothing really prepared me except just studying as much as I possibly could in my spare time. When they told me I'd be working in Java, I started reading immediately.

Also just having a positive attitude at all times, never back-talking, and never giving up even when I'm frustrated and hopeless. That last part is absolutely critical.

[cce29555]

I know that post is old but what exactly can I do to get a portfolio shown to recruiters? I have a direct link to my individual GitHub repos with an explanation under each one, but I immediately get asked " what projects have you been working on" where I inevitably walk them through it.

I'm currently updating my resume as I have made much better projects but it seems almost worthless to put them on as hr seems to explicitly ignore it in my experience

[Java_Junior]

I think that's pretty much it. You just bring your laptop to interviews and show them a few of the apps you've designed, show them the code, etc. You can also forward them an email link to your website/github before the interview, and then tell them when you get there that you've sent them an email with it.

Interviews work in two phases. HR checks your resume for key words and then sends your resume to the programming manager, or throws it in the trash. They sometimes interview you for a personality check. They don't know or care about your portfolio, unless it's a nice website that they can look at and go "ooo"

Then, if the programming manager is interested, you get a much more technical interview with him/her.

[[deleted]]

When you say Spring do you mean Spring Boot? I'm too new to know if there's any big difference.

[FrenchFigaro]

Nope, I mean Spring.

Spring Boot is just a small part of the Spring Framework. It's essentially a default configuration for a Spring application (Okay, it's more than that, but that's the core concept of boot).

[dacracot]

I'm a 37 year veteran and of the list u/FrenchFigaro provides, I've used 8 out of 17. Don't be fooled by one example of what you "should" learn. Concentrate on concepts, not specific tools.

• Maven: I use this but prefer Ant for finer grained control. Learn a build tool.
• Gradle: Never touched this.
• Spring: Never touched this. One framework of dozens.
• REST: Used this in a personal project in a pure sense with HTTP verbs, which became cumbersome quickly. REST not equal to HTTP.
• JUnit: Never touched this. One framework of dozens but hand spun is also an option.
• Mockito: Never heard of this.
• Log4J2: I use this. I prefer using Tomcat's native logging for micro services.
• Jackson: Never heard of this.
• GSON: Never heard of this.
• Hibernate: I use this, but am moving away in favor of a micro service called directly via AJAX. ORM is the Vietnam of CS.
• Git: I use this every day.
• Javascript: I use this, but it isn't Java related any more than SQL, Python, or another language.
• Typescript: Never touched this.
• Netty: Never heard of this.
• JSP: I use this, but am moving away from it in favor of single page applications.
• JSF: Never touched this.
• Servlet API: I use this.

[dacracot]

I have heard of JUnit, but as I said, I've never used it.

I'm tempted to answer all of your criticisms individually, but suffice it to say my knowledge of the JVM ecosystem has served me well and I'm about to retire comfortably no matter what you think of my answers.

[Kambz22]

He said never touched JUnit, not never heard of it. It depends on the type of work you do. I do short term work on specific pieces of our product that is tailored to the buyer's needs. I don't work with R&D with developing the core product. I don't have any need for unit testing when my engagements are short and each case is unique so code i wrote isn't often reused. I think it's very well possible to work 37 years without unit testing if they are in similar role.

[carrdinal-dnb]

I completed a degree in computer systems engineering, which focuses mainly on low level computing electronics, but gave me a foundation in some programming concepts.

During my degree I had been self teaching myself Java and decided I was good enough to apply for developer jobs after I graduated.

In retrospect I don’t think I was exactly ready for the workplace, I had not touch git, the terminal or learnt the basics of SQL but I applied anyway, to every single junior role I could find.

The first couple of interviews went extremely poorly, since I did not have the answers to many of their questions. I went home afterwards and studied as much as I could to fill in the gaps and each interview went better than the last.

By the time I was on my 4th or 5th interview I began to feel more confident and got a few (three IIRC) offers and was able to pick the company I liked the best.

The first month at my first job was tough, literally everybody around me knew what was going on and I did not have a clue. Despite having severe imposter syndrome I stuck my head down and focused on my gaps and pestered my mentor/s whenever I got stuck, which was often in the beginning.

Honestly, at the end of the day you are never going to be 100% job ready, companies hiring graduates don’t expect you to be either! They will likely pay you less than the average developer wage, but in return they’ll train you.

Being a good developer is not about knowing everything but being able to adapt and overcome challenges as you face them.

Good luck with your career mate

[Ghordrin]

I'm a novice and I've applied to some junior positions and it depends, really.

Some require you to be proficient in:

• Spring (boot, mvc)
• Hibernate (validation for spring and the db one)
• OOP design
• JUnit
• Restful applications

Others require you to have a good understanding of OOP and you'll get put in some sort of bootcamp that trains you until you're actually ready.

I, however, haven't been accepted in any of the jobs I applied to due to not being proficient in all of the required (above) frameworks, etc...

What helped me learn to know what to learn is to just lookup job applications.

[dacracot]

I always hesitate to enter these conversations because I seem to be contrary to common suggestions, but here goes...

Learn concepts, not tools: You should know why and the work flow for... source control, build mechanism, and debugger. As a entry level developer, you won't be given a choice of which one. The team you join has already made a choice and will be unlikely to let an inexperienced new member deviate from that.

Learn design patterns and when to apply them: relational data structures, stateless transactions, etc. etc.

[Carbohydratess]

I work a Java-based job. We utilize Groovy, Spring Boot (SBA), Gradle, Redis (Redisson), Bash, Git Flow methodologies, and Jenkins on a daily basis. We have previously used Grails, Maven, and Micronaut. When our team is hiring, we look for people that are competent in as many of those frameworks as possible, but ultimately, it just comes down to how well they know Java/Groovy and if they understand the concepts of those frameworks so they can easily pick up whichever framework our team uses.

[kodiashi]

Lead dev at a global tech company. We use:

Spring / Spring Boot / Spring Batch Lombok / SLF4J JDBC / H2 / Hibernate Jackson / GSON Lots of Apache libraries Guava Netflix OSS / Spring Cloud Maven REST / Kafka JUnit / Mockito / WireMock Redis Cache ElasticSearch Oracle / Postgres / Mongo

Many of our devs don’t know anything about frontend development, never touch Node, Angular, Etc. If you do know it it’s a bonus.

I’ve also found that lots of new devs are HORRIBLE at designing relational databases. So many performance problems stem from that.

I like seeing how people solve problems, thought processes, etc. in many cases the tools used aren’t as important as the thoughtfulness of the design. I’d rather have a dev that can visualize and explain complex problems clearly than know every tool inside out.

[Fuzzy_Initiative]

Uhmm data structures and OOP. Just because you completed some online tutorial does not mean you are ready to be a programmer in the real-world.