Java Interview Questions: Am I Being Too Difficult?

[MCheu]

I've been tasked with doing technical interviews at my company,
and I have generally ask a range of OO, Java, and "good programming
technique" concepts.

However, one of my favorite exercises I give interviewees seems
to trip them up all the time, and I wonder if I'm being too much
of a hardass... it seems easy enough to ME, but these guys, when
I get them up to the whiteboard, seem to get really confused.

The exercise is this:

Create one or more classes that represent a binary tree.

This class(es) must be able to do standard sorts of operations
one would do on a binary tree in a good, OO sort of way.

A node in this tree holds only a single, String, value.

Now write for me a method named 'find' that takes an argument
of a String (or a String and a Node, depending upon your
implementation) and returns a java.util.List of all nodes,
from the node it's called upon and all descendent nodes, inclusive,
who's value matches that of the String argument.

The code must be syntactically correct, and would compile.

As an added exercise, how would you make this code thread-safe?

Seems pretty simple, huh? But most guys we've brought in just sit there
staring at the board, and have trouble even writing the basic
Node class... they get all confused, don't know how to traverse a
tree, etc.

Am I unreasonable in expecting someone to be able to do this???

- Tim

The only two points I have a problem with are:

This class(es) must be able to do standard sorts of operations
one would do on a binary tree in a good, OO sort of way.

You might want to specify the tree type and operations you want
implemented, because my idea of "standard" might be different than
yours. The basics might be search, insert, delete. Other functions
that may or may not make it into someone's idea of "standard"
functions might be the order traversals, finding the level of an
entry, rebalancing (if required by the requested tree type), and
likely others that you've thought of, but I've not.

Also a generic BT only specifies a nodes with data and two node-links,
with no specific insertion organization. This may be the source of
the traversal confusion, because the output from the order traversals
will be different depending on how the BT was implemented (though I
guess the code would be the same).

The code must be syntactically correct, and would compile.

This is another bone of contention. Unless you give the applicant a
computer, with a compiler installed on it, this isn't terribly fair.
Typos and other small error can arise in hand written code, making
impossible to compile, and yet would be easily catchable under normal
conditions.

 

[Paul Schmidt]

I've been tasked with doing technical interviews at my company,
and I have generally ask a range of OO, Java, and "good programming
technique" concepts.

However, one of my favorite exercises I give interviewees seems
to trip them up all the time, and I wonder if I'm being too much
of a hardass... it seems easy enough to ME, but these guys, when
I get them up to the whiteboard, seem to get really confused.

The problem with this, is two-fold:

First this is good for "performers", but just because you can play
programmer on TV by hauling concepts out of a recendly completed
programming class, doesn't mean you will be good in other situations.

Second, Java isn't the perfect language, in 4 or 5 years, your company
may be moving to something else, do you want Java experts, or people who
can learn the company methodology, and can apply it, in Java, or some
other newer language.

A better excercise, would be to draw up a case study that you know has
major issues, then ask candidates how they would deal with the issue, if
they tell you the major issues or at least some of them, you have a good
candidate, if they don't raise some issues, then they are a clueless
Microserf, even though they could be a great performer.

Paul

 

[Liz]

The problem with this, is two-fold:

First this is good for "performers", but just because you can play
programmer on TV by hauling concepts out of a recendly completed
programming class, doesn't mean you will be good in other situations.

Second, Java isn't the perfect language, in 4 or 5 years, your company
may be moving to something else, do you want Java experts, or people who
can learn the company methodology, and can apply it, in Java, or some
other newer language.

A better excercise, would be to draw up a case study that you know has
major issues, then ask candidates how they would deal with the issue, if
they tell you the major issues or at least some of them, you have a good
candidate, if they don't raise some issues, then they are a clueless
Microserf, even though they could be a great performer.

Paul

Maybe if you are hiring a code monkey you can ask s/him to jump through
hoops like this, but if you want someone to do more you can't get a
good indication of their merit this way.

 

[xarax]

Maybe if you are hiring a code monkey you can ask s/him to jump through
hoops like this, but if you want someone to do more you can't get a
good indication of their merit this way.

A similar situation when I would interview assembler
language applicants: I would explain how a compare-and-swap
machine instruction worked, how the registers are specified
and the memory location, condition code result, etc. Then I
would ask the applicant to write a small code fragment that
uses the compare-and-swap to update a linked-list. The intent
was to determine how the applicant *thinks* about problem
solving, not whether he can cough up some canned code he
memorized from a book.

So, I think that giving an applicant the basic problem
solving *tools* and seeing how that applicant applies those
tools to solve a problem is more important than coding.

2 cents worth. Your mileage may vary.

 

[Sudsy]

xarax wrote:

So, I think that giving an applicant the basic problem
solving *tools* and seeing how that applicant applies those
tools to solve a problem is more important than coding.

Hey, I'd be happy enough to GET an interview. My applications seem
to drop into a black hole these days. Companies often don't even
send you an e-mail acknowledgment of receipt. Then again, Forrester
is predicting the loss of 830,000 IT positions by 2005...
<http://news.com.com/Study+supports+controversial+offshore+numbers/2100-1022_3-5213391.html>

 

[Joe]

So, I think that giving an applicant the basic problem
solving *tools* and seeing how that applicant applies those
tools to solve a problem is more important than coding.

Even better is to ask an applicant how they solved a similar problem in
the past. Past behavior is far and away the best predictor of future
behavior. Additionaly, a question like that gives you insights into how
a person sees themselves, how they work in teams and how they
communicate.

 

[Herman]

At one of the companies I worked for, they hired people straight out
of college, and sometimes people who came from non-IT backgrounds who
had studied IT on their own or at night. Therefore, they gave tests
to everyone as part of the interview process. But after we got bought
out by a bigger company, they changed the policy to only hire
experienced candidates with appropriate academic degrees, so as a
result, giving tests at interviews was deemed unnecessary. So it
depends on the rest of the person's qualifications. If they've got
PhDs from Cambridge or Imperial College with experience developing
safety kernels for BAE or the like, then I wouldn't feel the need to
test them. If I didn't see evidence of their skill in programming,
it's a reasonable test. Also, are you expecting to see fully
compileable code from them, or will pseudocode suffice?

 

[Tony Morris]

I'd tell you that I'd prefer to design it properly.
I'd write the Tree and TreeNode (package scope interfaces.
I'd use Object parameter and return types on the Tree interface (since this
fully meets the requirement of being abot hold String types and operator on
them in the way specified).
I'd return an array, not a List, since it is a fixed length, and an array
gives you type safety - granted, an array is mutable, and a List is easily
made immutable with the Collections API.
I'd provide thread safety by calling a static method that returns a
thread-safe Tree implementation - the same way the Collections API does it.

Of course, this all runs the risk of sounding like a "know-it-all", but I've
always believed that honesty in interviews is the key, and I'd be honest
about how I'd go about it.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Guest]

The only two points I have a problem with are:


You might want to specify the tree type and operations you want
implemented, because my idea of "standard" might be different than
yours. The basics might be search, insert, delete. Other functions
that may or may not make it into someone's idea of "standard"
functions might be the order traversals, finding the level of an
entry, rebalancing (if required by the requested tree type), and
likely others that you've thought of, but I've not.

The reason I don't specify these things is to see what
ideas the interviewee *has* of "standard". That is,
what kinds of things might one want to do to a binary
tree that seem like useful, utility sort of methods.

Also a generic BT only specifies a nodes with data and two node-links,
with no specific insertion organization. This may be the source of
the traversal confusion, because the output from the order traversals
will be different depending on how the BT was implemented (though I
guess the code would be the same).

The manner of traversal isn't that important to me, so long as
they traverse it SOMEHOW... the output of the 'find' method is
a java.util.List, and I don't care about the order of the found
nodes in the List.

This is another bone of contention. Unless you give the applicant a
computer, with a compiler installed on it, this isn't terribly fair.
Typos and other small error can arise in hand written code, making
impossible to compile, and yet would be easily catchable under normal
conditions.

Pretty true... but, well, *I* can write syntactically correct code
on a whiteboard, so I'm using myself as a benchmark. I write code
using 'vim', don't depend on IDE's... although IDE's are really useful,
I tend to think that a "good programmer" should be able to code
without one. A little help is allright (syntax highlighting, brace
matching, etc.), but needing an IDE to know Java syntax, or even well-known
API's, is using a crutch (in my opinion, anyway).

- Tim

--

 

[Guest]

The problem with this, is two-fold:

First this is good for "performers", but just because you can play
programmer on TV by hauling concepts out of a recendly completed
programming class, doesn't mean you will be good in other situations.

Second, Java isn't the perfect language, in 4 or 5 years, your company
may be moving to something else, do you want Java experts, or people who
can learn the company methodology, and can apply it, in Java, or some
other newer language.

A better excercise, would be to draw up a case study that you know has
major issues, then ask candidates how they would deal with the issue, if
they tell you the major issues or at least some of them, you have a good
candidate, if they don't raise some issues, then they are a clueless
Microserf, even though they could be a great performer.

Good points... I don't usually think in "who would be a good
problem-solver in general" but "who would be a good programming-problem
solver, and who knows general syntactical concepts and rules
like the back of their hand". Your suggestion is a good'n.

- Tim

--

 

[Guest]

At one of the companies I worked for, they hired people straight out
of college, and sometimes people who came from non-IT backgrounds who
had studied IT on their own or at night. Therefore, they gave tests
to everyone as part of the interview process. But after we got bought
out by a bigger company, they changed the policy to only hire
experienced candidates with appropriate academic degrees, so as a
result, giving tests at interviews was deemed unnecessary. So it
depends on the rest of the person's qualifications. If they've got
PhDs from Cambridge or Imperial College with experience developing
safety kernels for BAE or the like, then I wouldn't feel the need to
test them. If I didn't see evidence of their skill in programming,
it's a reasonable test. Also, are you expecting to see fully
compileable code from them, or will pseudocode suffice?

If they said "I'm kind of dependent on my IDE, so do you mind
if I use pseudocode?" then I'd accept it.

A guy I interviewed was very demeaning of my desire to have him
write syntactically correct (or even close to it) code, which
made me wonder about how well he actually knew Java.

- Tim

--

 

[Guest]

I'd tell you that I'd prefer to design it properly.
I'd write the Tree and TreeNode (package scope interfaces.
I'd use Object parameter and return types on the Tree interface (since this
fully meets the requirement of being abot hold String types and operator on
them in the way specified).
I'd return an array, not a List, since it is a fixed length, and an array
gives you type safety - granted, an array is mutable, and a List is easily
made immutable with the Collections API.
I'd provide thread safety by calling a static method that returns a
thread-safe Tree implementation - the same way the Collections API does it.

Of course, this all runs the risk of sounding like a "know-it-all", but I've
always believed that honesty in interviews is the key, and I'd be honest
about how I'd go about it.

You're HIRED!

All kidding aside, that's the kind of answer I'd LOVE to get in an
interview. I rarely do.

- Tim

--

 

[perry]

Spammy...

YOU ARE NOT and i do mean NOT being difficult at all....

If more interviewers were like you companies would hire people that knew
that they were talking about get a whole lot more done. I'll give you a
real example.... I have a cousin who has never been around a computer in
his life except for looking over my shoulder, couldn't write a program
to save his life. Much less did he spend 10 to 15 years as a programmer
and systems analyst with a variety of high tech firms with numerous
projects and numerous technologies.... yet HE is in NEW YORK as a
"COmputer Consultant" and I'm waiting for John Kerry to get in office....

What he does know how to do is tell people what they want to hear. A
most valuable skill in of itself but that has nothing to do with a
technical background. How did he manage to get a past the border guard?
well, at that time when Bill Clinton was in office, the demand for
computer people was so huge that if you could even spell computer you
were hired. This is NOT the case with George Fucking Bush. I don't know
precisely why the economy tightens it's belt when a Replican gets into
office, but thats what happens.

Anyway, getting back to your question, I simple love it when I get an
interviewer who knows what he is talking about and you can have a 1/2
decent interview and not walk away like you were either giving a lecture
on basic algoritms or talking to a gawd damn wall....

I would dearly love to have someone like yourself as an interviewer!

- perry

 

[perry]

Spammy,

Not the least one bit are you being too difficult. Many people think
that just because you are an interviewer that you automatically know
your stuff. Quite often this is not the case. I think one of my most
frustrating interviews came as a result as someone not asking me a
question like this... a question that's relative and shows intelligence
on the side of the people looking for help. Once i was asked a question
"How many bits does it require to store the number 1000?" Normally that
wouldn't be a problem but they way he asked it just caught me completely
off guard.

Instead had I realized the level of non-technical knowledge that this
fellow possessed I wouldn't have raised an eye brow....

1 2 4 8 16 32 64 128 256 512 (1024) = 2^10 bits

now thats how a programmer would have answered the question but what was
funny is that he didn't explain his answer like that at all... instead
he simple reworded his question and then used "math" to show what he was
talking about (which showed no real technical expertise on his part,
much less any knowledge of formal algoritms that you've demonstrated).

And I also remember telling a fellow later i knew about the inicident
and asking him the same question. little did i not realize that i was
speaking with a pathalogical liar who... proceeded to spend 10 minutes
explaining to me how 45000 zenon-atoms and 17 electrons conspired to
require just 2 bits to store the number 1000.... yes, i soon learned
what M.P.D. stands for. And on top of that, I have a cousin who is also
a complete newbie when it comes to computers and in fact, when it comes
to brain power he'll never be able to answer any of your questions but
boy.... does he ever know how to tell people what they want to hear....
he managed to hook in in the midst of the dot-com boom and makes a
living in the jungles of New York, he's still there today yet he can't
turn a computer on, never worked for a computer company in his life, but
he's considered a "computer consultant".... so much for 20 years of IT
experience and 50+ projects...

i'm not sure why the economy goes bust when ever a Republican gets into
office but boy let me tell you, I'm never complaining when a Democrat
gets in there.... bring me back the problems like 850,000 unfilled High
Tech jobs averaging $50 to $125 per hour each....

- perry

 

[MCheu]

This is another bone of contention. Unless you give the applicant a
computer, with a compiler installed on it, this isn't terribly fair.
Typos and other small error can arise in hand written code, making
impossible to compile, and yet would be easily catchable under normal
conditions.

Pretty true... but, well, *I* can write syntactically correct code
on a whiteboard, so I'm using myself as a benchmark. I write code
using 'vim', don't depend on IDE's... although IDE's are really useful,
I tend to think that a "good programmer" should be able to code
without one. A little help is allright (syntax highlighting, brace
matching, etc.), but needing an IDE to know Java syntax, or even well-known
API's, is using a crutch (in my opinion, anyway).

- Tim
[/QUOTE]

So, I guess you're saying that you're a bit more lenient than the
wording suggests. A misplaced semicolon, a missing brace, or
brainfreeze on a necessary import line can make hand written code
uncompileable. As for IDEs, I didn't say anything about those. In
fact, because of the differences in IDE designs, plunking someone in
front of an unfamiliar IDE might be a bit sadistic.

 

[Alex99 Kay]

Pretty true... but, well, *I* can write syntactically correct code
on a whiteboard, so I'm using myself as a benchmark. I write code
using 'vim', don't depend on IDE's... although IDE's are really useful,
I tend to think that a "good programmer" should be able to code
without one. A little help is allright (syntax highlighting, brace
matching, etc.), but needing an IDE to know Java syntax, or even well-known
API's, is using a crutch (in my opinion, anyway).

Tim,

Let's turn the tables a little, if I interview you and ask you to
write perfect Java code on a whiteboard to implement a Hashtable or
someother ADT you haven't implement for a while how would you go?

Cheers
Alex

 

[Christopher Browne]

i'm not sure why the economy goes bust when ever a Republican gets
into office but boy let me tell you, I'm never complaining when a
Democrat gets in there.... bring me back the problems like 850,000
unfilled High Tech jobs averaging $50 to $125 per hour each....

You'll have to recreate the Y2K problem, where there is a need for a
vast phalanx of programmers to repair some massive problem. That's
what "President Bill" was able to benefit from...
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/languages.html
Rules of the Evil Overlord #89. "After I captures the hero's
superweapon, I will not immediately disband my legions and relax my
guard because I believe whoever holds the weapon is unstoppable. After
all, the hero held the weapon and I took it from him."
<http://www.eviloverlord.com/>

 

[Tim Ward]

"How many bits does it require to store the number 1000?" Normally that
wouldn't be a problem but they way he asked it just caught me completely
off guard.

"Insufficient data" is the only really sensible answer.

If the requirement is to be able to distinguish between 1000 and 12312834,
those being the only two possible values for the parameter, then the answer
is one bit. If the parameter is *always* 1000, then then answer is no bits.
And so on.

 

[Chris Uppal]

If the requirement is to be able to distinguish between 1000 and 12312834,
those being the only two possible values for the parameter, then the
answer is one bit.

Or indeed, if the potential values range between 0 and 1023, but 1000 comes up
a million times more often than any other...

(Assuming variable-length encoding, of course)

-- chris

 

[kaeli]

Pretty true... but, well, *I* can write syntactically correct code
on a whiteboard, so I'm using myself as a benchmark. I write code
using 'vim', don't depend on IDE's... although IDE's are really useful,
I tend to think that a "good programmer" should be able to code
without one.

So those of us who code in multiple languages and don't memorize the
syntax aren't "good programmers"?

In any given day, I might code in the following languages:
C, C++, Java, Unix KSH, ASP (JScript/VBScript), Javascript/HTML, PHP,
and/or Perl.
Forgive me for mixing up the different syntax sometimes.

--