Paul C. Williams

Interfacing Technology & Business
View Paul Williams's profile on LinkedIn

Thursday, November 21, 2013

My 4 Favorite Technical Interview Questions

Technical interviewing questions
When I'm interviewing candidates to add to my team of Java engineers, I want to make sure that I hire smart, thoughtful, self-starters.  I don't want to spend much time training them on the basics.  I need to make sure they can write maintainable code, and they have the chops to contribute to designs.

Once I've covered the basics of java coding, like knowing the construction of classes and objects, and other typical syntax, I get into some of the "heavier" lifting.  None of these is particularly difficult to answer, but the depth of answer gives great insight into the overall competency of the individual.

After I ask these technical questions, I usually move on to interpersonal questions.  In addition to being a great technician, I've got to assess how that person is going to fit in to the team. I want the team to challenge each other, but not to the extent of causing friction. There is always room for respectful debate as long as it can be directed to closure by an effective leader.

1. What is the difference between "final", "finally", and "finalize"?

This question, besides having the virtue of a cute alliteration, is what I consider the litmus test for "journeyman" Java experience.  The identifiers seem similar based on the name, but the use is totally different. The depth to which a candidate can discuss these features can be used to infer general Java language knowledge.  This is one of the few language specific questions I ask.

The "final" identifier is used to modify methods or classes to prevent polymorphism, or to modify members or variables to prevent changes to references.  "final" does not prevent changes to content, so if you require immutability of content, there's an additional step required.

"finally" is an often omitted 3rd part of a try..catch..finally block, which is guaranteed to run upon returning from the try.  This is used to release resources (e.g. close database connections).  It is sometimes used after a try block with no catch, to execute statements when control is returned either by an immediate return or an exceptional condition.

"finalize" is a special method in an object.  Similar to a constructor, the "finalize" method is called before the object is garbage collected, and can be used to free resources.  If the Java process terminates (normally or abnormally), the "finalize" method will not be called.  The designer must not rely on the "finalize" method, because there is no guarantee it will be called.

2. What is your favorite design pattern?  What problems does it solve for you?  Under what conditions would you avoid using it?

Design patterns are a great way for software engineers to communicate tested solutions to common problems. Even if the interviewee isn't familiar with the standard design patterns, chances are that if you allow them, they can communicate some kind of typical solution. 

Great answers to this question are surprisingly hard to come by. Most of the time, the interviewee can name a couple, common to the point of cliche, like MVC for which there are already frameworks that coders can hook in with.

A great answer to this question would describe how using a Facade or Adapter pattern allowed a seamless integration between a modern and legacy system with a minimal amount of fuss by adapting the legacy business methods to the new updated APIs, but fails to help when there are processing bugs that need to be resolved, and can complicate debugging processes.

3. What is your least favorite feature of your most favorite language? How do you work around this deficiency?

This tidbit asks the candidate to dig a little deeper and show us how much they've actually done in the language of the day. We can see quickly where the candidate finds a boundary and how the candidate responds to the issue. It also gives us insight into how deep the candidate has delved into the language as a programmer, what kinds of problems the candidate is likely to have been solving, and how skillfully they work around the issues.

My favorite part about this question is that I might get an answer regarding a language that is not on the job spec sheet. When I get answers that refer to a language other than Java, I know that I've got a candidate with real potential.  I can also dig a little deeper by asking about the language they identified.  I don't have to know the language in question, but I learn a lot from their level of confidence in presenting what they know. This can also help "loosen" the conversation, because it gets them talking about something they're passionate about.

4. Tell me about your favorite project.  What makes it your favorite?  What were you most proud of? What would you have done differently?

When I interview a candidate, I look for someone who is introspective and can draw on their experiences to determine what worked well and is worth replicating, and what could be improved. This question helps me to understand the candidate's design process and competency.  It also can give some insight into the complexity of their projects and how they've managed that complexity.

What are your favorite questions, and how do they help you evaluate technical candidates?

I invite you to leave your favorite questions and criteria in the comments below.  Let's have a discussion about identifying the best talent out there for our teams.

Image courtesy of franky242 at

No comments:

Post a Comment