Don't use Java for Coding Interviews

Mohammad Faisal - Jan 5 - - Dev Community

To read more articles like this, visit my blog

The main goal of a technical interview is to test a candidate’s problem-solving skills.

But choosing the right language is very, very critical. Sometimes, it becomes the most crucial factor in a high-pressure 45-minute interview.

And, in my experience, Java is probably the worst language to be used in a live coding round.

But first, Let me explain.

Who am I to judge?

I take technical interviews in my spare time, and to this point, I have taken around 630 interviews. So I am literally the judge :P

Candidates use many languages, but Java, Python, and C++ are the most common ones.

The interview lasts for 45 minutes, with as many problems to solve as possible.

The hiring bar is different for various companies, but solving two problems is generally enough in most cases.

The first problem

The first one is straightforward. For this problem

The expected output was a hashmap where the key would be a user id, and the value would be an array.

Something like this.

{
  user1: [1,2],
  user2: [3,4]
}
Enter fullscreen mode Exit fullscreen mode

For simplicity, I will only show you two very simple parts of this implementation.

  • Building the result array

  • Printing the result array.

Inserting values into a map

For Java, the code looks like this.

Map<String, List<Integer>> map = new HashMap<>();

if(map.containsKey(user)){
     map.get(user).add(time);
}else{
 map.put(user, new ArrayList<>());
     map.get(user).add(time);
}
Enter fullscreen mode Exit fullscreen mode

What is happening here?

  • We are checking if a value already exists in the hashmap or not.

  • Then based on that, we initialize an array and insert it.

There is nothing wrong here. To my knowledge, this is how we do it in Java.

But let’s look at how the code would look if the candidate used Python.

map = defaultdict(list)
map[user].append(time)
Enter fullscreen mode Exit fullscreen mode

Do you see how simple it is?

  • We don’t need to think about declaring the complex type Map<String, List<Integer>>

  • We can use defaultdict of Python to avoid checking for a key existence.

  • We don’t need to initialize an empty array as defaultdict already did that for us.

The bottom line is you already saved at least a minute here. Both in terms of the number of characters typed and the overhead of thinking about everything.

Printing the result

Now, this is the most frustrating thing I have experienced.

Printing something in Java is so unnecessarily complicated that I scream inside my head during these interviews when I see candidates writing the following code to print out the hashmap.

Again, This is the actual code that the candidate wrote,

Map<String, int[]> result = new HashMap<>();

result = user_sessions(logs1);

for(String key : result.keySet()){
   System.out.print(key + " " + result.get(key)[0] + " " + result.get(key)[1]);
}
Enter fullscreen mode Exit fullscreen mode

But the same thing in python would be

print(user_sessions(logs1))
Enter fullscreen mode Exit fullscreen mode

Now, to be honest, I am not a java expert.

So, probably some of you will show me a better way to print the values easily and tell me it’s the candidate's fault that he didn’t know how to do that.

But that’s exactly my point.

If there are easier ways to do these things, then why most java developers don’t know them?

I can only imagine the amount of time wasted on this kind of thing in so many coding interviews.

On average, coding rounds are 45 minutes, so losing even 2–3 minutes does add up.

And when you need to debug

You are probably human, so naturally, you will make some mistakes.

Imagine debugging your code and putting out these System.out.println() every time you want to print something.

System.out.println("Something")
Enter fullscreen mode Exit fullscreen mode

vs

print("something")
Enter fullscreen mode Exit fullscreen mode

And trying to print an array is another story. It will straight up print out the memory locations for you :P

But….

But I have seen good candidates just easing through these coding exercises using Java as well.

But why are there so few of them?

That’s probably because Java was built for a separate use case. On the other hand, Python is a scripting language. So it makes more sense.

So if you are one of those candidates who just write Java code like it's nothing, then kudos to you!

So What Did I Learn?

If you are using Java for your job, then that’s fine. Be awesome.

But for coding interviews,

Please. please.. please… learn Python

It will save so much time for you that I can’t even describe it. Seeing so many good candidates fall short because of these little things hurt me so much.

And it's a Win-Win

Python is a great language anyway, right? So there is nothing wrong with learning this.

I have seen too many good candidates fall short just because of this.

So much so that I have started refreshing my knowledge of Python even though I am a Javascript developer.

What happened to our guy?

He was cruising in terms of concept and clearly described the intended solution.

I think he was clearly within 5 minutes of solving the problem but couldn’t finish it in time.

I am not saying he failed just because of using Java. He could have finished the problem in time if he knew Java better.

But my point is that gaining that proficiency in Java is significantly harder than the other languages.

My Advice

We all know the economy is not good, and to get a job these days, you have to be on top of your game.

So if you are preparing for your first job or planning to switch, take the plunge and have the best tool available.

Love it or hate it, Java is not going anywhere. But using Java for coding interviews is probably not a good idea.

That was my view on this topic. Let me know what you think about it in the comments.

Have a wonderful day!

Have something to say? Get in touch with me via LinkedIn or Personal Website

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .