Java interview questions and answers on code quality

Open-ended interview questions can tell a lot about a candidate.Code quality starts when you interview someone. You need the right people with the right skills and most importantly the right attitude. If you don't know how to achieve good code quality or don't care about it then your chances of job interview success will be very slim if not zero. The open-ended job interview questions give you a great opportunity to sell not only your technical skills, but also your soft-skills and personal traits. Impressive answers in open-ended questions can motivate your prospective interviewers to overlook any short-comings in your resume like not knowing a particular framework or tool or not having any experience with a particular application server. The following questions are very frequently asked, and your answers will be drilled down. So, don't just rely only on memorizing the answers given below, but apply it.

Q. How do you ensure code quality in your application?
A. code quality means writing readable and robust code, that conforms as much as possible to the style-guideline that is used, and that has as little as possible defects. It also means writing maintainable code with proper automated and manual tests.

1. Write a number of automated tests

• Unit tests  using JUnit or TestNG. For unit tests use mock objects to ensure that your tests don't fail due to volatility of the data changes. There are mocking frameworks like EasyMock, Mockito, and PowerMock.

• Integration testing of your services with JUnit or TestNG. Your integration tests are only as good as the quality of the data. You could either use dedicated test databases or use frameworks like DBUnit to manage extraction and insertion of data.

• Web testing  using Selenium + WebDriver. Selenium + WebDriver ( Selenium interview questions and answers) allows you to reenact web user experience and run it as an automated unit test using JUnit or TestNG.Your tests are only as good as the quality of the data. You could either use dedicated system test databases or use frameworks like DBUnit. DBUnit allows you to extract the data from databases into flat XML files, and then refresh (i.e. insert or update) the data into the database during setup phase of running the unit tests. There are handy proxy JDBC driver tool called P6SPY, which logs the SQL queries that are executed against the database by the DBUnit. This P6SPY also very handy in debugging Hibernate’s generated SQL  by acting as a proxy driver between JDBC and the real driver so that all generated SQL will be logged. There are other Web testing tools like Badboy.

• Load testing your application with tools like JMeter, OpenSTA, etc.  The Badboy compliments JMeter by allowing you to record scripts and then exporting the scripts as a JMeter file to be used in JMeter.JMeter Interview Questions and Answers

2. Have regular code reviews. There are tools like Crucible from Atlassian that gives your team an efficient way to benefit from the power of constant code review with features like inline commenting, simple workflow, asynchronous reviews, email and RSS notifications, JIRA integration and much more.

3. Using a number of code quality tools.

• Checkstyle ensures the style of your Java code is standardized and "nice". It checks white spaces, new lines, formatting, etc. (i.e. it looks on the code line by line).  This only ensure style of your code.
• On the other hand there is PMD which not necessarily checks the style of your code but it checks the structure of the whole code. PMD scans Java source code and looks for potential problems like possible bugs, dead code, suboptimal code, overcomplicated expressions, duplicate code, etc.
• FindBugs is a static analysis tool to look for bugs in Java code. It discovers possible NullPointerExceptions and a lot more bugs.
• Sonar is a very powerful tool covering 7 axes of code quality as shown below.

(The diagram is from the Sonar website)

4. Using continuous integration servers (on a clean separate machine) like Bamboo, Hudson, CruiseControl, etc to continuously integrate and test your code.

5. Not stopping to code once the code works. Too many developers feel their job stops at making something happen. It is a best practice to constantly refactor code with proper unit tests in place.


Q. Do you use test driven development? Why / Why not?
A. [Hint] Yes.

• Gives you a better understanding of what you're going to write.  Gets you to clearly think what the inputs are and what the output is.  Helps you separate the concerns by getting you to think about the single responsibility principle (SRP).
• Enforces a better test coverage. This gives you the confidence to refactor your code in the future, since you have a good coverage.
• You won't waste time writing features you don't need.

Q. How do you keep your knowledge up to date about writing quality code?
A. Mainly through good books and online resources.

Through good books

• Code Complete: A Practical Handbook of Software Construction by Steve McConnel
• Clean Code:  A Handbook of Agile Software Craftsmanship by Robert. C. Martin

Through good articles and  quick tips at online resources like

•   JavaLobby (java.dzone.com)
•   TheServerside.com
•   InfoQ.com
•   handy blogs on Mockito, PowerMock, Easy mock, DBUnit, Selenium, JUnit, TestNG, etc. 

Q. What do you look for when you are reviewing others' code?
A. Firstly, and most importantly look to see if the following key areas are properly adhered to avoid any potential issues relating to thread-safety, performance, memory leak, scalability, transaction management, exception handling, etc. Also, look for the key areas like best practices, design concepts, and design patterns. Key Areas.

Secondly, ensure that proper test cases are written. Also, ensure that it has a good code coverage.

Here are a few finer points:

• Naming conventions.
• Existence of unused code and commenting code out. Delete unused code. Source control is there for maintaining the history of your code.
• Unnecessary comments.  The method and variable names must be self explanatory without cluttering the code with excessive comments. The methods should do only one thing with fewer lines of code. More than 15-20 lines of code is questionable. The number of parameters passed in must also be small. The public methods must fail fast with proper validations.
• Repeated code due to copy-paste. For example, same logic or hard coded values repeated in a number of places.
• Favoring trivial performance optimization over readability and maintainability. 
• Tightly copuled code. For example, not coding to interfaces, favoring inheritance over composition, etc.
• Badly defined variable scopes or variable types. For example, using a data type double to represent monetary values instead of BigDecimal. The variable scopes must be as narrow as possible.
• Using mutable objects and read only varaibles where immutable objects make more sense.
• Proper implementation of language contracts. For example, not properly implemented equals and hashCode methods.
• Deeply nested loops or conditionals. Nested loops can be replaced with changing the logic or through recursion. Nested if-else conditionals are a good candidate for applying polymorphism.
• Not properly handling exceptions. For example, burying exceptions, exposing internal exception details to the users without proper friendly messages at the Web  layer, etc.
• Badly written unit tests.
• Not designing the classes and interfaces with proper design concepts and principles. For example, strongly coupled classes, classes trying to do more things than it should, modelling it as a class when it should be an attribute, etc.
• Not handling and testing non-functional scenarios. For example, not properly handling service timeouts or using incorrect timeout values.
• Reinventing the wheel by writing your own implementation, when there is already a proven and tested  implementation provided by the API.
  

Note: The Core Java Career Essentials cover all the above in detail with examples.


Q. There are lots of advantages in writing tests, but in your experience, are there any disadvantages?
A. [Hint: Everything has pros and cons. Discussing the cons demonstrates your experience, but make it a point to mention how you overcome the cons to exemplify your problem solving, researching, and analytical skills.

Tests need to be maintained. If a particular method signature or logic is changed, then all the relevant tests need to be fixed. Many developers don't put lots of thoughts into writing quality test cases through proper what if analysis. For example, what if new records are added to the database? What if the data is missing?, etc. So, this continuous tweaking of test cases will require time. Writing quality tests require experience and lots of  analysis.you need to have an enthusiastic team and at least one experienced developer who knows how to write good tests, and also knows a few thing about good architecture

Requires some initial upfront investment in time and cost. But, this initial up front investment will pay-off  significantly in a long run through quality code and robust application.

Q. What is the difference between fake objects, mock objects, and stubs?
A.

• Fake objects build a very lightweight implementation of the same functionality as provided by a component that you are faking. Since they take some shortcut, they are not suitable for production.

• Mocks are objects pre-programmed with expectations which form a specification of the calls they are expected to receive. You can use mocking frameworks like EasyMock, Mockito, PowerMock, etc to achieve this.When an actual service is invoked, a mock object is executed with a known outcome instead of the actual service. With mock objects, you can verify if expected method calls were made and how many times. The verify(mockOrderDao) shown below tells EasyMock to validate that all of the expected method calls were executed and in the correct order.

public void testOrderService() {
          
        //....
         
        expect(mockOrderDao.getOrders(...)) .andReturn(mockResults);
        replay(mockDao);
        assertTrue(service.login(userName, password));
        verify(mockDao);  //expected method calls were executed 
     }

• Stubs are like a mock class, except that they don't provide the ability to verify that methods have been called or not called. Generally services that are not ready or currently not stable are stubbed to make the test code more stable.

You use a Mock when it's an object that returns values that you set to the tested class. You use a Stub to mimic an Interface or Abstract class to be tested. In fact, the difference is very subtle and it doesn't really matter what you call it, fake, mock, or stub, they are all objects that aren't used in production, and used for managing complexity to write quality tests.


Q. Can you list some of the key principles to remember while designing your classes?
A. Use design principles and patterns, but use them judiciously. Design for current requirements without anticipating future requirements, and over complicating things. A well designed (i.e. loosely coupled and  more cohesive) system can easily lend itself to future changes, whilst keeping the system less complex.

• Favor composition over inheritance.
• Don't Repeat Yourself (DRY principle). Code once and only once.
• Find what varies and encapsulate it.
• Code to an interface, and not to an implementation.
• Strive for loose coupling and high cohesion.

Q. In your experience, what are some of the common dilemmas you face when writing unit tests?
A. [Hint: provide the dilemma and the tips to overcome the dilemma]

• Whether to fix the code or the test. When you write unit tests, sometimes you feel compelled to change your code just to facilitate the test. For example, when you need to test a private method or attribute. Doing so is a bad idea. If you ever feel tempted to make a private method public purely for testing purposes, don't do it. Testing is meant to improve the quality of your code, not decrease it. Having said this, in most cases, thinking about the test first in a TDD (.i.e. Test Driven Development) will help you refactor and write better code. Also, mock frameworks like PowerMock, let you mock private methods, static methods, constructors, final classes and methods, etc. Care must be taken in testing private methods. Inside a class you can end up with a lot of private methods manipulating instance or class variables without having them passed as parameters. This leads to high method coupling, and something not recommended. Instead use private methods that take explicit parameters and provide explicit return values.

• Whether to use mocks or not. The quality unit tests need to be repeatable. Some non-deterministic or environmental conditions can make your code fragile. Mocking these scenarios can make your code more robust. For example, a CircusService class can use a mock CircusDao to avoid test cases failing due to data related issues. Alternatively, the test cases can use frameworks like DBUnit to insert data  during test set up and  remove data during the test tear down to provide stable data for the test cases. Some test cases rely on Web service calls, and availability of these services are non-deterministic, and it makes more sense to mock those services.

• How to test non-functional requirements? For example, a non-functional requirement like 95 percent of all Web-based transactions should complete within 2 seconds. Your approach here would be to simply run the test code many times in a loop and compare the transaction times with target time, and keeping track of the number of passes and fails. If at the end of the test less than 95 percent of the transactions fail, then fail the test too. There are scenarios where @Test(timeout=5)  becomes handy to fail a test case that takes longer than 5 seconds to execute.

• Testing multi-thread code. This can be quite challenging  and sometimes an impossible task. If the tests are too complex, then review your code and design. There are ways to program for multi-threading that are more conducive for testing. For example, making  your objects immutable where possible, reducing the number of instances where multiple threads interact with the same instance, and using the ExecutorService (e.g. having a SerialExecutorService which is part of the jconch framework to execute the threads serially)  instead of the Thread class, etc. There are frameworks like GroboUtils and MultithreadedTC aiming to expand the testing possibilities of Java with support for multi-threading and hierarchical unit testing. The goal of  jconch project is to provide safe set of implementations for common tasks in multi-threaded Java applications. The SerialExecutorService class is one of them.

Related links:

• Selenium interview questions and answers
• JMeter interview questions and answers
• unit testing with mocking interview questions and answers