A couple of years ago I’ve published an online article with a list of 30 Java questions that can be used during job interviews.

This article has been re-posted a couple of times, and it became my most readable article ever: the read counter will reach 300000 in a month or two. Also, you should not miss the feedbacks to this article, which is a good read on its own.

It does not take a rocket scientist to figure out that the vast majority of the people who are seriously getting ready for Java are located in India. The typical feedback is this “Give me the job interview questions for J2EE for a person with 1 year of experience “.

But today I’ve received a different post, and this blog is my answer to it. This is the feedback:

“Don’t you think people should already know the answers to those questions before applying for a job?
You’ve given kids with no experience but a faked resume a prime source to cram questions and answers to trick themselves into jobs by writing this, thank you very much for making programmers as a group look bad (by making it possible for even more unqualified people to get programming jobs). ”

It’s refreshing to receive such a feedback after a couple of years of demands for more questions on servlets and EJBs. It also raises a broader question: is publishing of the technical job interview questions a bad thing to do in general? My short answer is: no it’s not a bad thing and here’s my reasoning :

For most questions I “ve provided only short answers to encourage further research. Any decent interviewer can ask some further drill-down questions to find out if the candidate understands what s/he is talking about.

There is a bunch of web sites and even books that list hundreds of questions, which in my opinion are not too practical and are more useful for certification exams then for the real-world work. So the goal of these questions was to give people guidance in learning Java when preparing for the job interviews. When a person is getting ready for an enterprise job interview, s/he should not spend days trying to figure out how the byte shifting in Java works and what the difference between gt; gt; and gt; gt; gt;. The chances are very slim that you’ll need to use this knowledge while working on an order processing application. Besides, these kinds of questions are easily googlable when needed.

If a job candidate can trick the interviewer by simply repeating the answers that I offerred, it’s clear that the only person who does not qualify for the job is the interviewer. I’m sure there are some vocational schools that bake Java programmers in 2-3 months by forcing them to memorize technical questions for the job interviews. And it’s the employer’s responsibility to weed out the applicants that know just this. If a hiring manager does not have people who can interview Java applicants, they should outsource (not offshore though) the interviewing process. For example, some time ago I’ve been moonlighting by conducting technical interviews over the phone for several consulting firms.

Figuring out if a resume is fake is completely another story and has nothing to do with the questions/answers I’ve provided.