Software Developer’s Maturity Matrix

Hi all, this is a good matrix to keep track of your skill set as you advance in your field.

Software Engineer Maturity Matrix


Ace the Software Engineering Interview: An Interview Preparation Framework to Land the Job You Will Love Kindle Edition:

Copyright Notice:

“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”


Arulkumaran Kumaraswamipillai’s job search ideas.

Tip #1: Java is very accessible and all the following are available for free.

The steps you take may slightly vary depending on your familiarity with Java and its tools.

  1. A computer — desk top or lap top.
  2. Download latest version of Java (JDK and JRE).
  3. Download latest version of eclipse IDE.
  4. Dowload Tomcat or JBoss to deploy your applications.
  5. Download and install MySQL database. All non trivial applications need information to be persisted to a database.
  6. Set up Maven as a build and dependency management tool so that you can download sought after frameworks like Spring and Hibernate.

Google search, good blogs and online tutorials are your friends in setting up the above 6 items. Even with 13+ year experience in Java, researching on is integral part of getting my job done as a Java developer. As an experienced Java developer, I can research things much faster. You will improve your researching skills with time. You will know what key words to search on. If you are stuck, ask your mentor or go to popular forums like to ask your fellow Java developers.

Tip #2: Start with the basics first.

Enterprise Java has hundreds of frameworks and libraries and it is easy for the beginners to get confused. Once you get to a certain point, you will get a better handle on them, but to get started, stick to the following basic steps. Feel free to make changes as you see fit.

  1. Core Java fundamentals. Write simple stand alone Java programs using OO concepts. Write unit tests with JUnit.
  2. Learn SQL and write stand alone Java programs that connect to MySQL database via JDBC.
  3. Write simple web applications using Servlets and JSPs using enterprise Java. The application needs to persist data to the MySQL database. Deploy your application to Tomcat or JBoss server and run them as an enterprise application. Use Maven for build and dependency management.
  4. Expand your project created with JSPs, Servlets, and JDBC to use sought after frameworks. Learn the concept of “dependency injection”. Start wiring up sought after frameworks like Spring. Spring is very vast, and start with spring core and spring jdbc. Spring core is used for dependency injection and Spring jdbc is to connect to databases and to execute SQL queries.
  5. Learn the MVC (Model View Controller) design pattern for web development. Convert your JSPs and Servlets to Spring-mvc based web application.
  6. Write RESTFul web services using Spring MVC.
  7. Get a working knowledge in HTML, JavaScript/jQuery/JSON, ajax, and CSS. This is imperative as more and more organizations are moving towards JavaScript based MVC frameworks like angularjs or backbone. These frameworks make RESTFul web service calls to get data in JSON format and populate the front end. It will be handy to learn node.js as well if time permits.
  8. Make sure that you write unit tests for your code with JUnit and mocking frameworks like Mockito.

Tip #3: Once you have some familiarity and experience with developing enterprise applications with Java, try contributing to open source projects or if your self-taught project is non trivial, try to open source your self-taught project. You can learn a lot by looking at others’ code.

Tip #4: Look for volunteer work to enhance your hands-on experience. Don’t over commit yourself. Allocate say 2 to 3 days to build a website for a charity or community organization.

Tip #5: Share your hands-on experience gained via tips 1-4 in your resume and through blogging (can be kept private initially). It is vital to capture your experience via blogging.  Improve your resume writing and interviewing skills via many handy posts found in this blog or elsewhere on the internet. It is essential that while you are working on the tips 1-5, keep applying for the paid jobs as well.

Tip #6: Voluntary work and other networking opportunities via Java User Groups (JUGs) and graduate trade fairs can put you in touch with the professionals in the industry and open more doors for you. The tips 1-5 will also differentiate you from the other entry level developers. My books and blog has covered lots of Java interview questions and answers. Practice those questions and answers as many employers have initial phone screening and technical tests to ascertain your Java knowledge, mainly in core Java and web development (e.g. stateless HTTP protocol, sessions, cookies, etc). All it takes is to learn 10 Q&A each day while gaining hands-on experience and applying for entry level jobs.

Create your Own Company as a means to gain experience

Here’s an excerpt I found very interesting from John Sonmez’s newly released book, ‘the Complete Software Developer’s Career Guide’. It is a good read and I recommend it.

I think I might try this option, and I think you guys might want to give this some thought too.


Many people laugh when I tell them this idea of gaining experience when you don’t have any, but it’s perfectly legitimate.

Way more companies than you probably realize are actually run by a single person or a skeleton staff of part-time workers or contractors.

There is absolutely no reason why you cannot create your own software development company, develop an application, sell or distribute that app, and call yourself a software developer working for that company.

You can do this at the same time you are building your portfolio and learning to code.

If I were starting out today, I’d form a small company by filing for an LLC, or even just a DBA (Doing Business As) form (you don’t even need a legal entity), and I’d build an app or two that would be part of my portfolio. Then, I’d publish that app or apps in an app store or sell it online in some way.

I’d set up a small website for my software development company to make it look even more legit.

Then, on my resume, I’d list the company and I’d put my role as software developer.

I want to stress to you that this is in no way lying and it is perfectly legitimate. Too many people think too narrowly and don’t realize how viable and perfectly reasonable of an option this is.

I would not advocate lying in any way.

If you build an application and create your own software development company, there is no reason why you can’t call yourself a software developerfor that company and put that experience on your resume—I don’t care what anyone says.

Now, if you are asked about the company in an interview, you do need to be honest and say it is your own company and that you formed it yourself.

However, you do not need to volunteer this information.

I don’t think being the sole developer of your own software company is a detriment either.

I’d much rather hire a self-starter who formed their own software company, built an app, and put it up for sale than someone who just worked for someone else in their career.

I realize not all employers will think this way, but many will. You’d probably be surprised how many.

Copyright Notice:

“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

What?! Oh hell no! Hold up. Huh?? Oh okay.

This blog is about so many different things. It’s about things that make you go ‘What’! And then when you don’t want to except those things that’s the part of the blog that’s in the second page it’s called “Oh hell no”! Then it’s like “Hold up”, because maybe I didn’t think that through, maybe I do want to know about it. And then it’s like “huh?? Oh okay.” You know what I mean?

I took that from the show Impractical Jokers

I think that that’s the kind of conversations developers have in their day-to-day life.

For example, developers have to learn new tools everyday in order to keep up with the changing field. Some ideas may make you have the first part of the conversation, “what! I have to learn this stuff!.” Then you hear how complex it is and it makes you say, “Oh hell no!” But then you realize that it actually makes sense and that it is not as complex, and that makes you go, “Hold up.” But then as you try to learn the tool you get into some obstacles, making you say “huh?” Then you realize how cool the new tool is and how much it simplifies your job more, and that makes you say “oh okay.”

For example, I just learnt a new tool for testing called the JMockit. JMockit is primarily used to mock objects, not an instance of an object, but objects themselves like classes and interfaces. But the problem is that it is not as simple as you would like it to be. It does not conform to object-oriented rules, and thus it feels so unnatural for a developer to use. This is the part where you have the “what! oh hell no!!” conversation with yourself. One thing that I find annoying is that debugging a JMockit unit test can be very difficult, because the internals of how mock object results are returned are not well documented. For example, if arguments to a mock object invocation do not properly implement “equals(Object other)” then your invocation may not match any expected invocation and will return null instead of your intended result. It is very difficult to step through the mock object framework matching code to find the particular argument that is failing to match. But then there’s so many other pros of using it, so you give JMockIt  an open mind. That’s when you go “Hold up.” Sure enough JMockit provides well documentation for other functionalities.

In my opinion JMockit is definitely worth learning. However, the author of, Richard, advises that a simpler framework be used if available. But he also says that “JMockit is probably the simplest mock framework to use after you master its unusual API.” So the conversation would end in ” Huh? ? Oh okay.”


Best Operating System for Developers?

This is a frequent question among newbies to the tech industry.

Obviously it is going to depend on what kind of development you are up to. If you are making a Linux application, you’ll need a Linux OS; if you’re making a windows application, you’ll need a windows OS; if you’re making a mac application, you’ll need a mac OS.

But then the question becomes, what is the best OS overall?

I’ll try and compare the different OS’s using a benchmark. Let’s get to it.

In my personal opinion I’d say that that is you are into web developing, probably Windows is the best to go with as you can check on all reasonable common web browsers that you can’t on a Linux, including Mac which is a version of Linux.

For Linux, it’s good to learn the command line interface because it is very powerful without all the GUI. People underestimate the GUI and how it lowers productivity with higher response times. But that is not a good reason to switch to Linux as Windows has a command line too, and an advanced PowerShell which is on par with Bash.

For Mac users it is the best if you are into android development. You can write your code in Objective C which is good for android devices. I recently heard on a presentation that Java is a battery drainer for android applications. Thus people prefer to use Mac.

And even yet, Linux differs from the different distributions there is. For example, Solaris, which is a UNIX, performs very well Java compared to other Linux’s. It’s probably due to the fact that SOLARIS is made by Sun microsystems, but now owned by Oracle.


Diagram taken from:

But in the real world it all comes down to economics. You can make a lot of money selling software for Windows, and when people give away open source on Linux, there’s hardly any monetary gain in making Linux application. The only time Linux is used in the real world is to as a large server warehouse, where they want to be cheap and avoid paying for licenses.

Works cited.

Decision Table-Based Testing: the setbacks & the benefits

Decision tables are one of the more powerful functional testing methods, partly due to their logical decision-making structure. Here is how they work:

  • Conditions are identified as inputs; actions are identified as outputs.
  • In certain cases, the conditions are equivalence classes.
  • For every possible combination of inputs, the output is identified and marked.

The size of a decision table is greatly impacted by the choice of conditions. Thus, the conditions have to be identified wisely.

Pretty straight-forward thus far. Decision tables involving equivalence classes have a characteristic appearance.

But people often make mistakes when the conditions refer to equivalence classes. Particularly when the equivalence classes are mutually exclusive, and are disjoint sets. As such, it is not possible to have a rule where two entries are true. For a particular rule if one equivalence class is marked true, it doesn’t matter what the other classes are marked – don’t care entries. Thus, the number of rule count increases.

This creates a problem.

Let’s say we have a decision table as shown below, where c1, c2, c3 refer to conditions and a1, a2, a3 refer to the actions. And we have Rule 1-4 identical to that of rule 9. Let’s say we have two versions of this table. Although version 1 is redundant, it does not have a problem. In the second table there is a problem. Because, in addition to being redundant, the two redundant rules (1-4) and 9 are not identical – their action portion differs.

   Frist Version.                                                   Second Version


This problem of redundancy and inconsistency creates tremendous strain on the part of a developer. In cases such as that of version two, two observations can be made:

  1. Rules 1-4 are inconsistent with that of rule 9.
  2. The decision table is nondeterministic.

Here is the bottom line: Care Should Be Taken When Do-Not-Care-Entries Are Used in A Decision Table.

This is the drawback of decision-table based testing, because of the dependencies in input domain. On the other hand, the benefits of decision-based testing are that indiscriminate selection of input values from equivalence classes as done in other testing methods such as boundary-value testing (this is done when the variables are assumed to be independent) are not made here. In a decision table, impossible rules are emphasized with the use of don’t-care-entries and the use of impossible-actions.

In summation, decision-table based testing should be used for applications that indicate these characteristics:

  1. Prominent if-then-else logic.
  2. Logical relationship among input variables.
  3. Calculations involving subsets of the input variables.
  4. Cause-and-effect relationships between inputs and outputs.


Works Cited

Jorgensen, Paul C. “Decision Table Based Testing.” Software Testing: A Craftsmen’s Approach, 4Th Edition. New York: Auerbach Publications, 2013. Safari Books Online. Web. 7 Mar. 2016.