Interview Questions I Hate (part 1 of a possible series)
I've been interviewing lately, and as you might expect, some questions get repeated by many questioners. Some make sense, if you're trying to give the candidate a softball question to put them at ease. "Describe the difference between Java's public, private, protected, and default access levels" is one.
Others are just laziness: "What's the difference between an ArrayList and a Vector"
But some questions I really hate getting.
One question I really hate being asked is: "Java's parameter passing: by value or by reference?"
It's not that I don't know the answer. I do. The problem is that most people who ask the question don't know the answer. It's one of those things that everybody knows, but what most people know is wrong.
You see, the standard, everybody-knows answer is: "primitives by value, objects by reference". Clear, simple, and brief. Altogether an admirable answer, except that it's wrong.
Not completely wrong, but subtly and importantly.
Here's why: in reality, all parameter passing in Java is by value.
That answer confuses people who quite rightly notice that given an object as parameter, a method can make changes in that object which are available to caller once the method has returned. Which proves that the method has a reference to the object. True, but it's a copy of the calling method's reference, which is very important.
You see, pass-by-reference is not the same as passing a reference.
That's why I said it was a subtle difference. The reason I said it was important is that the fact that it's a copy means that although the method can make changes to the state of the object by use of its public methods, it cannot replace or delete the object.
I don't mean that you can't write the code - it's not a compiler-enforced constant value. It's quite valid to write: thisObjectParam = null or thisObjectParam = new ParamObject()
But having written that code, though thisObjectParam will thenceforth be null or replaced within the method, on return, the change has magically disappeared... because the method was operating on a copy of the reference.
It's why you can't write a swap(obj a, obj b) method in Java. Or rather, you can write it, but it fails: on return, a is still a, and b is still b.
In the end, it's almost a no-win question. I obviously can't give the wrong answer, but it's all too common that when I give the right, complete answer, the interviewer hears the "wrong" answer and stops listening or can't comprehend the explanation.
You might think that's not very likely, but sadly, this is more likely than you'd like to hope: I know for a fact that at least once I failed to get a position because the interviewer didn't like my answer. The feedback I got through a former colleague was short and pungent: "He seemed sharp, but then it turned out that he doesn't even know how Java passes parameters - guys without CompSci degrees are hacks".
Others are just laziness: "What's the difference between an ArrayList and a Vector"
But some questions I really hate getting.
One question I really hate being asked is: "Java's parameter passing: by value or by reference?"
It's not that I don't know the answer. I do. The problem is that most people who ask the question don't know the answer. It's one of those things that everybody knows, but what most people know is wrong.
You see, the standard, everybody-knows answer is: "primitives by value, objects by reference". Clear, simple, and brief. Altogether an admirable answer, except that it's wrong.
Not completely wrong, but subtly and importantly.
Here's why: in reality, all parameter passing in Java is by value.
That answer confuses people who quite rightly notice that given an object as parameter, a method can make changes in that object which are available to caller once the method has returned. Which proves that the method has a reference to the object. True, but it's a copy of the calling method's reference, which is very important.
You see, pass-by-reference is not the same as passing a reference.
That's why I said it was a subtle difference. The reason I said it was important is that the fact that it's a copy means that although the method can make changes to the state of the object by use of its public methods, it cannot replace or delete the object.
I don't mean that you can't write the code - it's not a compiler-enforced constant value. It's quite valid to write: thisObjectParam = null or thisObjectParam = new ParamObject()
But having written that code, though thisObjectParam will thenceforth be null or replaced within the method, on return, the change has magically disappeared... because the method was operating on a copy of the reference.
It's why you can't write a swap(obj a, obj b) method in Java. Or rather, you can write it, but it fails: on return, a is still a, and b is still b.
In the end, it's almost a no-win question. I obviously can't give the wrong answer, but it's all too common that when I give the right, complete answer, the interviewer hears the "wrong" answer and stops listening or can't comprehend the explanation.
You might think that's not very likely, but sadly, this is more likely than you'd like to hope: I know for a fact that at least once I failed to get a position because the interviewer didn't like my answer. The feedback I got through a former colleague was short and pungent: "He seemed sharp, but then it turned out that he doesn't even know how Java passes parameters - guys without CompSci degrees are hacks".