OT: Java interview questions
Dec 6, 2004 at 2:40 PM Thread Starter Post #1 of 12

jatinder

100+ Head-Fier
Joined
Jun 28, 2001
Posts
375
Likes
25
Hi,

I'm interviewing a number of people next week for software development jobs in Java.

Does anybody out there have some Java related questions which would be a good test for weeding out the men from the boys during an interview?

Thanks,
--Jatinder
 
Dec 6, 2004 at 3:02 PM Post #2 of 12
You want questions that specificly depend on Java? What level of developer are you looking at, and what type of programming (i.e. client-side, ecommerce, etc...)?
 
Dec 6, 2004 at 3:10 PM Post #3 of 12
Quote:

Originally Posted by dhwilkin
You want questions that specificly depend on Java? What level of developer are you looking at, and what type of programming (i.e. client-side, ecommerce, etc...)?


Hi,

Yes - sorry for the omission.

I'm looking for a number of senior software developers, primarily working in a client-server environment with thick java clients (Swing) and custom java processes as servers. The client side is very very deep swing.

Other server technologies are Postgres & Linux.

We will also be looking for some e-commerce type developers (simple website, maybe a forum or two, most importantly highly secure). Here I suspect it'll be Apache & PHP. (I have no experience with these.)

--Jatinder
 
Dec 6, 2004 at 4:34 PM Post #4 of 12
There are some thoughts on this at Joel on Software that are pretty good. In particular I agree with what he says about people who don't "get" pointers, and identifying those who do.

A lot of Java programmers seem to get by on builder tools alone, and can't really write code freehand. I don't want those people. I would ask lots of "write me a little snippet to do the following" kinds of questions to test their mastery of the language, especially things like exception handling.

I find that a lot of Java programmers, including self-proclaimed senior architects, are very weak on basic computer science. If I am hiring for a decently senior position, I'll send them up to the whiteboard and ask things like this:
  1. Show me a linked list (if they don't ask what kind, have them show you both single and double)
  2. Show me a tree
  3. If I asked you to write code to traverse the tree, what question would you ask me before beginning?
  4. Show me a directed acyclic graph (if they are a wiseass (which is OK with me) they will just point at the tree; then I'd ask them to alter the tree so it's a DAG but not a tree)
  5. Show me a generalized graph that is not a DAG.
I also find that a lot of Java programmers are helpless in SQL - they know how to use ORM tools to build database objects for them, but they can't write a query themselves. That's important to me, though it may not be so important to you. So I diagram a mini-database (manufacturer, product, invoice, invoice-line-item) and ask them to write me a query that lists all the manufacturers whose items appeared on invoices last week. Someone with SQL skills can rattle this off, but a surprising number take a very long time or can't do it at all. (Bonus brownie points to those who have the added insight that it probably should be a SELECT DISTINCT query.)

I really want to see a code sample. In my experience, 90% of good programming is good taste, so I want to see that their code is thoughtfully designed, has clearly and intelligently designed interfaces to the other code that it works with, that it's readable and shows some sort of consistency around naming conventions, and so forth. Code that isn't like that is not stuff I like putting into production and having to support.

I like people who can function pretty independently, so near the end I usually ask a question along these lines: "it's your first day, you arrive here and there's an email from me saying I'm out and unreachable and asking you to investigate, right away, the following type of bug that's been reported by the customer. Walk me through what you're going to do next." Poor answers are vague: "I guess I'd start trying to figure out the code." The best answers are very proactive and specific: "well, today I'm interviewing with 3 other people in your group, so by the time I come in I know 3 people here who understand the application, and I probably have an idea which one to start with for this particular problem; I'll talk to her. I'll also ask how the customer complaints come in to our group, so I can go through that channel and find out all the details of exactly what went wrong so I can reproduce it locally. Once I understand the problem and reproduce it, I'll..." and so forth. In my experience people who ace THAT test are rare, and are outstanding contributors.
 
Dec 6, 2004 at 5:25 PM Post #5 of 12
That was an awesome link. I'll finish reading it when I get home, but I just loved the descriptions of Smart but don't Get Things Done, and Get Things Done but not Smart. It described folks I used to work with to the T.
 
Dec 6, 2004 at 6:22 PM Post #6 of 12
I would also ask how they would break up a certain program. What objects would be needed, how many layers, if they can foresee what interactions will be needed with other functions etc...
 
Dec 6, 2004 at 7:04 PM Post #7 of 12
Some Java-specific questions (a senior developer who understands fundamental concepts behind Java should get all of these w/o much trouble):
- If you are modifying a Swing GUI, what are two ways to ensure your code is executing in the Event-Dispatching thread, and why is this important? Answer: Either run code from an event listener or create a new thread and send it to SwingUtilities::invokeLater(). If not, you risk thread deadlocks and the GUI may freeze or have unexpected behavior.
- Ask about design and performance tradeoffs between different layout managers.
Answer: Could include things like null layout being fast and great placement control, but must be carefully coded or will look horrible if window is allowed to be re-sized, etc...
- Show some code taking a String object and doing a whole bunch of add operations to it. ex. String talk = "Hi"; talk += "hi"; //repeat 50 times. Ask if there's a better way to do this.
Answer: Ignoring the pointlessness of this code, obvious but inadequate answer is put code in a loop. Adequate answer is put in loop and use StringBuffer::append instead of wasting memory w/ all the String operations. Best answer is same as adequate answer, but also put comment //shut-up, already! in loop.
wink.gif

- Ask about different ways to keep track of specific user information when visiting websites, between visits.
Answer: Could include session tracking, cookies, etc...
 
Dec 6, 2004 at 11:24 PM Post #9 of 12
Is this project is http based protocal?
If so are you going to use Servlet or SOAP?
What server? Apache Tomcat AXIS ?
I thought that the advantage of StringBuffer is that you don't have to create a new instance of String object, not saving memory.
 
Dec 7, 2004 at 4:54 AM Post #10 of 12
Quote:

wit said...

I thought that the advantage of StringBuffer is that you don't have to create a new instance of String object, not saving memory.


Both are valid. Java has built-in garbage collection, but it doesn't happen every time referenced memory loses its reference. So, until the GC decides to clean up memory or you ask it to (which it doesn't have to do immediately), all those times you allocated a new String object, the old String objects are still hanging around, tying up memory. Work w/ big strings, and it can add up. Though, I should have also emphasized using a StringBuffer is just plain much faster as well, since all that memory allocation and copying data takes time.
 
Dec 7, 2004 at 8:47 AM Post #11 of 12
Quote:

Originally Posted by wit
Is this project is http based protocal?
If so are you going to use Servlet or SOAP?
What server? Apache Tomcat AXIS ?
I thought that the advantage of StringBuffer is that you don't have to create a new instance of String object, not saving memory.



The major project is a thick-client swing-based app running behind corporate firewalls handling very sensitive data. Hence, we'll be communicating to the server processes via SSL (port 443) BUT NOT using HTTPS.

The "minor" project is a website for the "general public" to use. This is at a very very early stage - and I expect that we'll be using Tomcat & servlets.

--Jatinder
 
Dec 7, 2004 at 10:53 PM Post #12 of 12
Quote:

Originally Posted by jatinder
The major project is a thick-client swing-based app running behind corporate firewalls handling very sensitive data. Hence, we'll be communicating to the server processes via SSL (port 443) BUT NOT using HTTPS.

The "minor" project is a website for the "general public" to use. This is at a very very early stage - and I expect that we'll be using Tomcat & servlets.

--Jatinder



Sounds interesting.
We have a few Tomcat servers setup here at work. I personally don't handle them. I'm more of a microsoft (da devil) solution developer.....
smily_headphones1.gif

Hmm... Not too sure why would you need a servlet for a "minor" project if it's a browser-app. shouldn't jsp be enough?
Thick-client on the other hand, probably going to requie servlet or SOAP.
I think nowaday SOAP seems to be a better solution, especially since AXIS is coming along quite well and prove to be quite stable as well.
 

Users who are viewing this thread

Back
Top