Starting Java Development Career

Starting a Java development career can be a great choice given the number of job openings that pops up day after day. Java has been around for a while and there are a tremendous amount of companies that already have a Java system in place. This only means a lot of development opportunities.

Java is compiled, type-safe, and fast. I mean really fast. I have myself migrated a fairly complex project from Python to Java and another one extremely complex system from .Net to Java. The main reasons were performance improvement and platform independence.

Learning Java in itself is not that difficult, but in order to become job-ready and be able to develop real-world Java applications requires a fair amount of knowledge. In this post, we’re gonna list down the skills required for becoming a job-ready Java developer.

Core Java

Core Java or Java SE is the starting point of your Java development career. Many beginners think that once they learn Java SE, they are ready to develop real-world applications. This is not true. First of all, in order to be a good programmer, learning the syntax is not enough. You should learn how to design an application by using various constructs provided by the programming language. You need to master it by writing a lot of code and developing some projects keeping the design principles in mind.

Next thing is that Java SE itself is not enough. A quite common application would be to develop a command line application which has limited use. To get to the next level, you need to learn Java EE or Advanced Java.

Advanced Java

Java EE or Advanced Java supports the development of server-side backend web applications. While an understanding of Java EE concepts like servlets, JSPs, and EJBs is useful, you need not master this. Just the basic level of knowledge should be sufficient.

The main reason for this is that developing any web application by simply using Java EE is difficult and time-consuming. There are a lot of frameworks available today that help in this development. Some of them are Spring, Spark Java, and Dropwizard.

These frameworks make web application development so easy that you don’t even need to know about JSP and Servlets in order to develop a basic web application.

If you are not sure which framework you should use, go for Spring. Its the most widely used framework and has a very active community.


Testing is an integral part of Software development. Writing automated unit tests helps developer receive instant feedback on the code. Unfortunately, many developers consider tests as second-class citizens.

The de-facto for unit tests in Java is Junit. Junit is widely used and has a great community out there. I can’t stress less on the importance of tests. You just need to master it.


Before you start with any framework, you must be familiar with some build tools and IDE that makes your job easy.

Build Tools

A Java application can consist of lots and lots of files and one big project might be divided into smaller modules where one module is dependent on another. Apart from this, your code might be using some popular libraries like apache commons to solve some well-known problems that come with every project.

These dependencies need to be supplied from your development environment to test environment and then to the production. This can become a daunting task if done manually. To solve this problem, we use build tools like Maven or Gradle.

If you are unsure of what to start with, choose Maven. It’s the older among the two, has wide applications, good community support, and easier to begin with.


An IDE or Integrated Development Environment helps you a lot. It saves you a lot of headache by providing the features like real-time compilation – see the compilation errors as you type, no need to wait till actual compilation happens. An IDE provides type completion among other things.

Code completion
Code completion example

There are a lot of IDEs available but only two of them are really good. My preference is IntelliJ Idea and then Eclipse.

I use Ultimate edition of IntelliJ which is paid, but there is Community edition which is free. Eclipse is also a free IDE. There is another IDE called STS (Spring Tool Suite) which is essentially Eclipse with plugins for Spring development.


Git is a distributed VCS (version control system). Every project uses one or the other VCS for source code management. Git keeps different versions of the source code files as you modify them. Making tracking changes and code history a manageable task.


A web application needs to be deployed on a server. There are several choices like Tomcat, Jetty, GlassFish. A beginner should start with Tomcat. It’s really lightweight and very easy to configure and use. However, if you are going to develop your first web application using Spring Boot, then there is no need to worry about servers for a small project. Spring Boot allows you to use an embedded server.


In essence, if you want to get a job as a Java developer, you need to learn about Java Development along with the most popular frameworks and tools. Using a popular framework will increase your chances of employability as well as it will be easier for you to learn.

So once you get hold of Java SE, develop some small projects to get hold of the language. Then Start learning Spring Boot + Maven and use STS for development. Once you are familiar, develop more and more web applications.

You might want to check out the resume polishing tips before applying for a job. All the best.

Polishing Your Resume Before Applying For a New Job

A resume is your first impression on your prospective employer. You better spend quality time on polishing your resume before applying for a new job. In this article, we will discuss some of the tips and tricks that I have found to be extremely useful in getting your resume shortlisted.

Avoid Walk-ins and Bulk Hiring Processes

I know, it might sound a bit counter-intuitive. But once I have got some experience, I apply for jobs that have some specific and clear requirements. In that case, I will be able to know the type of project and the future team that I will work on during the interview process.

Generally, walk-ins do not tend to better judge the potential candidate and usually do not give the candidates a better chance to evaluate the job. The hiring companies do not generally have a clear vision about the deployment of resources. And most importantly, you lose bargaining power in terms of salary negotiations.

Of course, all this is true for service-based organizations. If its the (rare) case of a product based company, things change. Product based companies generally have a single product or a fixed set of products on which the new talent will be deployed. You will most likely end up in the team of the interviewer. And product based companies usually pay better than their service-based counterparts.

Now all this is just my general observation and experience. The real world is filled with randomness and nothing can be confined to a set of well-written rules. So expect the unexpected.

Target a Company and Do Some Research

Whenever I am looking for a job change, I select a specific company where I will apply and do some research to understand the work culture and type of job that I might get.

I don’t apply for every job opening that I find on job search sites. Instead, I take time to learn about the company and shortlist a few of them that fits my parameters. Then, I apply to one or two of the top companies that I have shortlisted and I give everything I have to get in.

My research starts with the job description itself. The type of tools and technologies that are required, the roles and responsibilities listed, etc. Then I do a general google search to see what people are talking about the company. Sometimes you might also get to know if the customers are happy with it. Then comes glassdoor, where you can find the salary range and the reviews from the current and past employees. I read a lot of reviews. Then I head towards the interview section where you can have a peek inside the interview process and what types of questions you might face and what are the experiences of the past interviewers.

Then lastly, visit the company’s official website to learn about the management and the type of work they are in to. All this helps in shortlisting the company. I look for negative points like frustrated customers/employees, technological skillset mismatch, extremely lower salaries/increments. If I find more of such negative flags, I become cautious.

Polish Your Resume, For Every Job That You Apply

Yes, that’s right. I don’t use a common resume for all the jobs. The reason is simple, not all jobs have the same requirement.

Circles of knowledge

The left circle is the circle of your knowledge that you have built up based on your research. This circle tells you about the types of requirements and qualities that are most important to this particular job. This could be anything ranging from experience with a specific tool or technology, experience working on a certain type of project, leadership skills, or anything else.

The right circle is the current skill set that you have. This is fixed and can’t be changed over a very short time.

The intersection of these two circles makes you a better or worse fit for any given job. I highlight the portion of my resume that falls at the intersection point.

For example, at one of the jobs that I applied, I got to know that they put a lot of emphasis on knowledge of design patterns and also testing.

I highlighted the part that talked about unit testing and described how I created a base testing framework in one of the projects in the past. Also, in the project description section, I included a row mentioning the design patterns that we had used.

Result? The recruiter said that I am a “great fit” for the job.

Now it should be obvious that why I don’t use the same resume for all the applications. The right circle changes depending on the job. Hence, the section of intersection also keeps on changing.

High-level Structure of a Resume

Even though the contents of my resume keeps on changing, I have designed a concrete high-level structure that remains the same. This allows me to do quick edits and customize the resume quickly.

The first section consists of an introduction and a profile summary. The introduction is usually 2-3 sentences and the profile summary consists of 7-10 bullet points that highlight what I have achieved in my past jobs. Note this, “highlight what I have achieved” and not “what I have done”. I like to represent myself as an “achiever” rather than a “doer”.

Achievements could be anything from helping clients meet a deadline in a highly ambitious timeframe, achieving performance improvements, improving quality among others.

Next comes the experience section that describes in detail my roles and responsibilities in past organizations along with the project details.

Then come the section for academics and professional certificates. A really short section that does not take much of space. Only consist of the highest educational degree.

Lastly, there are public artefacts that contain links to my blog, GitHub profile, and other things that I find relevant.

And yes, all this fits really well in two pages. The interviewer immediately loses interests if the resume has more than two pages. Extra pages should be included only when it is absolutely required and when you have a lot of experience. I never went beyond two.

Things that I avoid in resume are the team size in project details and my hobbies. Its just a matter of personal preference. No one ever asked me why hobbies are missing in my resume.

How to Love Your Code

1. Introduction

In this article, I am going to present my strong personal opinions on various aspects of the code, legacy applications, and why that existing ugly looking method does not use generics? Feel free to agree, disagree, and provide any constructive feedback.

2. The Problem With Legacy Code

The main problem with the legacy code is that it isn’t the problem at all. That ugly looking method that heavily relies on HashMap was written in Java 1.4, when no had heard about the fancy word Generics. Before cursing the existing code for not being readable and not doing what we want, try to understand the circumstances under which it was written.The code might not do what we want, but hey, this the exact code that is running on production and earning $$ for the company. It is doing exactly what it’s supposed to do. It is the code that the customers are using day in day out. This is the code that generating the revenue and even our salaries.

The code might not do what we want, but hey, this the exact code that is running on production and earning $$ for the company. It is doing exactly what it’s supposed to do. It is the code that the customers are using day in day out. This is the code that generating the revenue and even our salaries.

Now, don’t think I am promoting spaghetti and unstructured code in any way. My point is, if we have a problem, then we should carefully look at it, observe it, and then try to think of ways to resolve it. We can’t just curse it and sit with hand on our hand.

Many times it happens that when I look at the code that I wrote six months back, I immediately think, did I write this crap? I am sure there will be many who agrees to this. If we can’t appreciate our own code that was written a few months back, how can we blame the code that was written 2, 5, or even 10 years back. Believe me, that code was “as per the current industry standards” while it was written.

3. Stop Complaining, Start Acting

So, what should be done in this case? Improve the code. But how?

Utmost care should be taken while refactoring the legacy code. And, by the way, there is a reason it’s called “legacy code”, because it has written a legacy (I think this one is from  Joel Spolsky).

Completely rewriting the entire code base is almost never a good idea. However, refactoring it bit-by-bit is the approach that we should embrace.

In our team, first, all of the team members agreed that we need to improve the existing code. Then, we identified some of the ways that we can achieve this, some automated, some manual. We took several pledges to reach our goal.

Pledge 1: Clean the Surroundings

First, we decided to start cleaning the surrounding area of code where are working. Remove the dead code and commented code, add generics to that ugly looking method, extract common code in separate methods to make it DRY, and many other small things. This started building the confidence in our team. Such things are very easy to master if you can make good use of your IDE.

Pledge 2: Strict Code Reviews

We decided that we will commit the code without peer reviews. This helped us to stay on track and avoid the temptation of “cheating”. This also made sure that everyone on the team is committed towards our common goal. This went for a while until everyone developed confidence in everyone else.

Pledge 3: More and More Junits

This is the best thing that we decided to do. Writing Junits, mocking, spying, stubbing, these quickly became the buzz words. Writing automated test cases gave us tremendous confidence to refactor the existing code with even more speed. I personally decided to never compromise on automated tests after this experience.

Pledge 4: No Sonar Criticals/Blockers

We integrated SonarQube with our project. The results of the first scan were really disappointing, but we didn’t lose hope. We worked hard to resolve the Blockers and Criticals until there were zero occurrences. Later, we started our nightly builds and integrated SonarQube with it. Every morning, we use to verify if the code committed yesterday is having any high priority issues. Gradually, we started focusing the Major issues.

This helped us reduce code smells and code complexity.

4. Well Done Is Better Than Well Said

I admit that it’s not as easy as it might sound. It took us almost a year before everyone started appreciating the code. Our clients thanked us, our managers appreciated us, and everyone was more confident than ever. But this has not yet stopped. This has to continue. There are still several areas of improvements. This is a “legacy”.