Month: September 2009

Does Java Puzzlers make Good Interview Questions?

Intent of my Blog

Recently i wrote an blog entry on one of the java puzzlers that was asked to me in an interview.I received some of the comments which said this is unfair to ask java puzzlers in an interview.So i thought of writing an blog which discusses whether java puzzlers make good interview questions or not.

Does Java Puzzlers make Good Interview Questions?

I think before answering this question that should we ask java puzzlers in an interview or not we need to define some guidelines about what makes a good interview question. And if java puzzlers fit within those guidelines then we can ask the them in an interview.I am giving my personal point of view please add in your comments if you think something different.

Guideline for a Good Technical Interview Question

  1. Question should be How not what = Should be Practical which means that Interviewer should not ask the definition of some term or concept the interview question should be such that it discusses  practical application of concept.Asking how has the advantage that interviewer gets the correct feedback about interviewee that interviewee actually understand the concept.
  2. Question should be on simpler concepts = Asking a difficult question doesn’t make an interview question good.In my personal opinion interview question should be about the concepts which a developer normally use. You can vary the difficulty level of question depending upon position you are hiring but the concept should be simple.For example you can ask questions on overriding which can be simple or difficult but the concept of overriding is such that every java developer should know.
  3. Question can be Extended =  A good interview question should be such that you can build your interview on that question which means that if you ask a question on overriding you can start with the easier question and then build your interview by asking questions that increases in difficulty.
  4. Question should not be specific to API = The question that i mentioned in my post was good but it was specific to the HashSet remove method arguments. Let me explain, when you create an hashset  like HashSet<Short> s = new HashSet<Short>() you might expect that when you are doing s.remove(i-1) should remove only short objects but when you take a look at the remove method it takes Object .This is something specific to api which  most of the developers might not know. So asking such a question becomes useless.
  5. Question should provide a learning point = A good interview question should provide a value add to the interviewee. It might be possible that interviewee knows everything which is great and you can hire him/her. But even if he/she doesn’t know the answer they can at least  learn a good technical point.

Does java puzzlers fit these guidelines?

In my view java puzzler fit some of the guidelines:-

  1. All Java Puzzler are about How not What so java puzzlers can provide interviewer the practical understanding of the interviewee.
  2. Java Puzzlers are about simpler concepts but the Puzzlers are not simple because they discuss the trap or corner cases of the API. You can use these concepts for interviews but the questions are very specific to api and most of the times should not be asked in interview.
  3. Java Puzzlers can be extended but again because they are not easy most of the times you will not get the correct answer.
  4. Java Puzzlers are specific to API and they require very good understanding of java api.
  5. Java Puzzlers definitely provide a learning value to interviewee because these questions touches the corner cases  of the api which normally developers doesn’t know.

Conclusion

In my view you can ask some of the java puzzlers in an interview as java puzzlers definetly provide a value. Sometimes you should only take a concept and build you question on that and sometime take the whole question. If you think the java puzzler you are asking is difficult and a normal developer who hasn’t read java puzzlers book can’t answer please dont make that question a decider question means your decision to hire a person should not be based only on  java puzzler. Java Puzzlers are definetly very good questions and you should use them wisely in interview.

These are some of my view points. Please share your also.

Java Puzzlers are asked in interviews

Intent of my Blog

This blog is about one of the question that i was asked in an interview two years back. I forgot this question but yesterday i again faced this question and this is a “java puzzler”.

Question

Yesterday while looking for videos on “java puzzlers” i found out link on youtube by Joshua Bloch.When i started viewing this video one of the puzzle reminded of a question i was asked in an interview two years back. Although this question is not in Java(TM) Puzzlers: Traps, Pitfalls, and Corner Cases but it is one of the question i thought worth sharing.Try this question and have fun.

public class JavaPuzzler{
    public static void main(String[] args) {
        HashSet<Short> s = new HashSet<Short>();//1
        for(short i = 0; i<100;i++){//2
            s.add(i);//3
            s.remove(i-1);//4
        }
        System.out.println(s.size());//5
    }
}

Before viewing the answer of this question please try guessing the answer to this question and then run code in eclipse to check whether you what you were thinking matches the answer.If the answer amaze you it is a java puzzler.

Answer

Answer of this puzzler is 100.

To understand why we get 100 as answer lets try to understand the code line by line.

In line 1 we created an HashSet which is of type java.lang.Short .

In line 2 we are doing a for loop

In line3 we are adding short primitive which will be autoboxed to Short object  to the HashSet Collection.

In line 4, we are trying to remove an element from HashSet, which we added just before the current element. But there is a small gotcha (can you guess what is it?), the gotcha is when we do s.remove(i-1),  first of all expression (i -1) is evaluated in which short is widened to int and then int is converted to Integer object. This is due to autoboxing in java 1.5 version.If you look into the javadoc of remove method of HashSet, you will find that it takes an Object, so you can remove Integer objects  from HashSet of Short objects, but this will not work as a result none of the Short objects will get removed.

So in line 5 we get output as 100.

Hope you find this puzzle interesting, i will strongly recommend viewing this presentation.

You can share any of yours interview question which you think is a “java puzzler”.

Interim build to testing team worked for us

Intent of my blog

This blog is about my personal experience of giving interim build to QA team. So far now it has worked great for us.

Content

Few months back my team decided that we will be following some agile practices. So we decided to list down the practices that we will follow.We tried tdd but it failed. The only practice from that list which we have successfully followed is giving interim build to testing team during an iteration.
We follow 1 month iteration of which 3 weeks is for development and 1 week for testing. Till few months we give build to QA team only when we have done all development which means 3 weeks they were not doing any testing but were creating test scenarios and understanding user stories.As we were not following tdd ,during the testing lot of bugs were raised which were programmatic error like NullPointerException or sometimes the understanding of user story was different which leads to QA week to be  a very tiring week(fixing lot of defects).Also this also leads to lot of tension and pressure on the team.

Interim Build became the SilverBullet

From the last few iterations we have started giving interim build to QA usually one or two between the development cycle.This has helped our team a lot:-

  1. Programmatic errors are resolved during the development cycle so cost of fixing the defect is quite low.
  2. Testing Team is doing testing during the development cycle.It helps testing team in understanding the application better rather than just reading documentation.
  3. Quality of defects raised by QA team during the QA week increased because they were able to do more functional testing rather than finding NullPointerException or validation issues.
  4. Pressure on developers and QA team reduced during the QA cycle.
  5. High Quality of Application

These are some of the benifits which we got by giving interim builds to QA team.

Please share your thoughts also.

Java Puzzlers are found in day to day work

Intent of my Blog

Today i was writing a piece of code and found one java puzzle. When i debugged it, i remembered that i read it something like this when i was reading  Java(TM) Puzzlers: Traps, Pitfalls, and Corner Cases .

Java Puzzle

Today while doing my day to day office work i found one java puzzle which i thought was worth writing.

Can you guess what is the output of following  java code:-

public class Test {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		String[] arr = {"java ","puzzlers ","is ","a ","good ","book"};
		String message = null;
		for(String str : arr){
			message += str;
		}
		System.out.println(message);
	}

}

I am posting the answer as well as the solution to overcome this problem.But first try this java puzzler yourself.Run this piece of code in eclipse and see what you guessed is correct.

Answer
If you ran this code you will get nulljava puzzlers is a good book
but you might be thinking that it should print java puzzlers is a good book If you don’t know that when you are concatenating the string null is taken as a string and was appended to the result . + operator is overridden for string so it does the concatenation for you.

The Easiest Solution to this problem can be initializing message with empty string rather than null.

public class Test {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		String[] arr = {"java ","puzzlers ","is ","a ","good ","book"};
		String message = "";// replacing null with empty string
		for(String str : arr){
			message += str;
		}
		System.out.println(message);
	}

}

But this solution also has a problem and that problem is related to performance because when you are iterating over array you are doing String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String.This can lead to decrease in performance of your program.
The best solution is the use of StringBuilder class.

public class Test {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		String[] arr = {"java ","puzzlers ","is ","a ","good ","book"};
		StringBuilder message =  new StringBuilder();
		for(String str : arr){
			message.append(str);
		}
		System.out.println(message.toString());
	}

}

If you think there is anyother better solution please put that in comment.

Does Google Search limits the developer ability to solve problems?

Intent of my blog

I am trying to express my views on the problem which i think google search pose to developers in terms of limiting the ability of software developer to solve problems.May be my point of view is totally irrelevant to many of you but i think getting every answer at the click of just one google search button leads to under-utilized brain.

Approach

In my personal day to day work whenever i am struck with some problem and i think i just can’t think more i just do a google search and try to find the solution to my problem. If the solution which i get by viewing the first few links(which we all normally do 🙂 ) on google search page are relevant to my problem i will integrate(after understanding the solution) that piece of solution in my code and move to the next step/task.

Problem with this Approach

  1. Easy way to get solution :- Once you know that you can find every solution to your problem by googling it becomes a habit and most of the time without giving proper thought or applying your mind you just do google search.
  2. Brain not optimally used:- Because more than often we are relying on search results to give us the solution to our problems we tend to let search engine become our brain and leaving the brain we have do nothing.
  3. Lazy Developers :- This also leads to developers becoming lazy in solving there problems themselves.
  4. Solution doesn’t work as expected:- Because you are not giving your 100% in finding the solution to your problem leads to the another problem that you have not fully understood your problem  and the solution you found by googling was just a partial or incomplete or even wrong solution.
  5. Time Waste :- It happens that you try to put time on solution which are not the actual solution to the problem leading you to tweaking the piece of code to work the way you want and finally if it doesn’t work you just delete the whole piece of code and start thinking in a better way.

Above mentioned are few of my concerns that i can think right now but i think there will be many.

Please share your thoughts also even if you think what i am saying is totally rubbish 🙂

Why my attempt to apply tdd failed?

Intent of my Blog

The intent of this blog is to write down the reasons for my failure to apply test driven development in my current project. Uncle Bob Martin in his interview on infoq said that “Developer is not professional if he does not practice test driven development”. We tried following tdd but failed (are we not professionals 😦 )!!

Brief Background

We had a major release few months back and till that time we were not following Test Driven Development so when the talks for the subsequent releases started we thought that we should follow tdd.I was given the responsibility to come up with strategy on how we will be applying tdd in our project. So i started with reading kent beck book Test Driven Development: By Example. I also read lots of articles  on infoq and testdriven.com to get a good and thorough understanding of tdd and was convinced that we should apply “TDD”.I gave a presentation-cum-coding demo to my team and after my demo we all were convinced that we will be applying TDD.

Ist Iteration using TDD :-Whenever you start some new thing you are excited, the same was the case with us.So before writing any class or any piece of code we used to write a test for the same. We were developing our code in an incremental manner, letting the design evolve as tdd gurus says and we were seeing small benefits like fixing programming errors like NullPointerException were caught in the early stages before the code goes to the QA team for testing.
For the next two weeks i was on leave and when i came Iteration 2 had started and tdd was no where…. So what went wrong………………

I asked my team why now we are not using tdd and the answer was that client changed the contract of one the web service that we published in iteration 1 although we had taken the feedback from him on the previous contract but somehow later he felt that this was not correct and we have to re-implement the web service with new contract and because of pressure of time we commented out all the tests and wrote the code without tests.

I started thinking about our failure to apply tdd because i think time pressure is not the only reason why teams fail to apply tdd there are many reasons. So i am writing down some reasons(in no particular order) which i think led to us not apply tdd:-

  1. Time:- Developers think that writing test cases before writing code requires more time and most often under pressure circumstances time is more important than writing test cases.
  2. Boring to write test cases first:– Its very difficult to get into the habit of writing test first than code so developers are reluctant to write test first.
  3. Client Support:- When we told our client that we will be applying tdd in our code, the response was that tdd doesn’t provide better results and in a longer run developers don’t maintain the test and they become irrelevant after some iteration.Client cares about money not test cases.
  4. Writing Exhaustive test cases :- I think tdd will make sense when you are able to cover most of the scenarios in your test class. More often what happens is that developers just write the basic test and test class doesnt evolve to incorporate all the test cases as a result developer thinks that when the number of bugs getting raised is not decreasing why should i write test.
  5. Patience :- I think it is very important that we should not expect everything to go fine and everyone to become tdd guru in one iteration. So we should give tdd few iterations before we can judge whether its useful or not.
  6. Poor Examples :- The example with which tdd is often taught are very simple as compared to the one you face in real life scenarios.So it becomes difficult to follow tdd when there is some real complex problem come.
  7. Legacy Code

In short, i can say that applying tdd requires a complete change in mindset you have start fresh.These are some of the reasons that i could think of at this point of time why applying tdd failed.
Please share your views also.