Java Interview Questions: Am I Being Too Difficult?

[Chris Smith]

An example of how few programmers can pass a "simple" test -- at least in an
interview situation. A colleague at the same shop was doing the C++
interviewing, and one of his pet "practical" questions was to ask the candidate
to write a *very simple* string class (just simple constructors, a destructor,
and a length() method, iirc). He used that question for a long time, and must
have asked it dozens of times, but he told me later that nearly all
interviewees (who were not beginners) had real trouble with it, and only one
candidate (guess who ;-)) ever answered it completely.

Wow. The last time I interviewed for a job (about three years ago, and
it wasn't even a programming job!) I was asked a much harder question
than that to solve at a whiteboard in the middle of an interview. The
problem was something like "Given an array of integers of length m, and
a target integer n, write an O(m)-time algorithm to find two array
elements whose sum is n." I didn't find one, but on later discussion we
discovered that the interviewer had been assuming the numbers must be
non-negative and that the value of n is negligible in comparison to m...
after which I was able to come up with something that's O(m) time and
O(n) space.

If what you're saying is true, I wonder how many correct answers they
got to *that* question.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[xarax]

/snip/

That's my opinion, too. But I'm finding that most folks that come in to
be interviewed can't do this problem. One guy even went on about how
nobody DOES that kind of thing anymore, and it was a silly question to
ask, etc.

Well, the response is likely correct, because at this
point, such utility classes should be readily available.
Asking someone to re-invent the wheel is a waste of
time (at least at the coding level).

I would suggest easing the question to ask the applicant
to specify only the interface methods for using a binary
tree, and maybe to write a simple piece of client code
that would use the interface for creating, adding, searching,
removing nodes. Writing the implementation code is a waste
of time. Correctly *using* the interface is crucial.

If you really want to see the applicant's coding ability,
then ask them to bring in samples of their code. Writing
code on-the-fly in a stressful interview situation is a
"bad thing". You won't see their best work. Most programmers
fare better when they feel they are part of team and not
competing with each other or being judged on an all-or-nothing
basis ("screw up this interview question and you're history!").

 

[Chris Uppal]

An example of how few programmers can pass a "simple" test -- at least
in an interview situation. [...]

Wow. The last time I interviewed for a job (about three years ago, and
it wasn't even a programming job!) I was asked a much harder question
than that to solve at a whiteboard in the middle of an interview. The
problem was something like "Given an array of integers of length m, and
a target integer n, write an O(m)-time algorithm to find two array
elements whose sum is n."

Ouch. Or maybe not, it depends on the interview situation. It's a nice little
problem for someone sitting happily at home with a glass of wine. But not a
challenge I'd relish in an adversarial interview situation. In a more
friendly, chatty, interview where I felt I could think out loud, and get
"credit" for exploring avenues that turned out to be dead ends, then it'd be a
lot more fun (and, presumably, a lot more informative for the interviewer).

If what you're saying is true, I wonder how many correct answers they
got to *that* question.

Thinking about it, it seems to me that a "difficult" algorithmic question like
that might bring out the best in some people. Maybe we (at the shop I
mentioned) would have got more information about candidates if we'd split the
challenge(s) up, but made them harder.

Step 1: introduce some abstract problem that you hope the candidate can solve
with some thought and discussion.

Step 2: /then/ challenge them to turn their solution into approximately
workable code.

At least it could avoid the mental log-jam caused by trying to work out what
the code should do at the same time as actually writing it.

-- chris

 

[Chris Uppal]

I ask people who claim to know Java what they think should have been
done differently when it was designed.
[...]
Also I've never met a real expert who went all quiet when
asked that question.

Yes a great question, but then -- oh God -- how do you get 'em to /stop/
talking...

-- chris

 

[Larry Barowski]

...
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.

Seems like an excellent question for any CS grad. I would think
it might be too easy since they have all seen this in a data structures
course. I'll accept the responses in this thread that say someone may
fail at this because of nerves, but not those who say it's irrelevant.
Real world projects will often require unique data structures and
algorithms.

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.

You seem to indicate that multiple nodes have the same
value. I think you mean the nodes in the path from the start
node to the node with the matching value, if it exists. If
someone gives you a non-recursive algorithm for that, I
would rank them higher, since students are usually taught
a recursive find in a data structures course. Hopefully they
have picked up somewhere or figured out on their own that
a non-recursive implementation is more efficient and just
as simple.

 

[D Rolfe]

D Rolfe wrote:

I ask people who claim to know Java what they think should have been
done differently when it was designed.
[...]
Also I've never met a real expert who went all quiet when
asked that question.

Yes a great question, but then -- oh God -- how do you get 'em to /stop/
talking...

Wait until they are in mid sentance and then suddenly ask them:

"What's the worst mistake you've ever made and how did you get out of it?"

This stops:

1. People with ego problems, who aren't used to discussing such things.
2. People who have difficulty admitting when they have made a mistake.

Neither of the above two groups of people are desirable as co-workers or
employees.

David Rolfe
Orinda Software

 

[kaeli]

Wow. The last time I interviewed for a job (about three years ago, and
it wasn't even a programming job!) I was asked a much harder question
than that to solve at a whiteboard in the middle of an interview. The
problem was something like "Given an array of integers of length m, and
a target integer n, write an O(m)-time algorithm to find two array
elements whose sum is n." I didn't find one, but on later discussion we
discovered that the interviewer had been assuming the numbers must be
non-negative and that the value of n is negligible in comparison to m...
after which I was able to come up with something that's O(m) time and
O(n) space.

If what you're saying is true, I wonder how many correct answers they
got to *that* question.

This thread is reminding me of all the stuff I haven't had to use since
graduating.

Fun stuff. *g*

--

 

[Chris Uppal]

Fun stuff. *g*

If you don't already know it, you might enjoy:

<http://www.ocf.berkeley.edu/~wwu/riddles/intro.shtml>

-- chris (that's *this* chris, not *that* Chris)

 

[kaeli]

If you don't already know it, you might enjoy:

<http://www.ocf.berkeley.edu/~wwu/riddles/intro.shtml>

-- chris (that's *this* chris, not *that* Chris)

Ooh, I like these sorts of things. I get kind of bored just doing web
apps all the time. It doesn't take much thought process for most of it.
Once you develop the back end, the front end rather builds itself.

Thanks for the link.

--
--
~kaeli~
Kill one man and you are a murderer. Kill millions and you
are a conqueror. Kill everyone and you are God.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

 

[Liz]

/snip/

Well, the response is likely correct, because at this
point, such utility classes should be readily available.
Asking someone to re-invent the wheel is a waste of
time (at least at the coding level).

I would suggest easing the question to ask the applicant
to specify only the interface methods for using a binary
tree, and maybe to write a simple piece of client code
that would use the interface for creating, adding, searching,
removing nodes. Writing the implementation code is a waste
of time. Correctly *using* the interface is crucial.

If you really want to see the applicant's coding ability,
then ask them to bring in samples of their code. Writing
code on-the-fly in a stressful interview situation is a
"bad thing". You won't see their best work. Most programmers
fare better when they feel they are part of team and not
competing with each other or being judged on an all-or-nothing
basis ("screw up this interview question and you're history!").

These are all simple things that can be looked up quickly
by someone after they have the job. If you say, "but I need
them to do it quickly and I can't wait" then you are a
perfect example of why refactoring is so popular.

 

[Eric Sosman]

Well, I can see your point... the thing is, I guess I have
some pretty strong ideas about what "good programmers" *should*
be able to do, and the kinds of things they should know.
Basically, they should:

1) Have a broad knowledge of common data structures, how
they work, and how they are implemented (and be able to
implement them themselves, even if perfectly good, complete
implementations exist in easily-found libraries).

The question you ask, though, is "Demonstrate knowledge of
data structure X." Perhaps a better question might be "Tell me
all about your favorite data structure, and sketch an implementation."
Less coercive, more open-ended -- and you might even learn a thing
or two ...

2) Have experience in all tiers of common sorts of applications
(UI, Business Logic/Middleware, Database, Network)

The binary tree exercise doesn't test this, or not very much
at any rate. Again, I'd put the onus on the interviewee: "Tell me
about some Topic X work you've done. What problems did you encounter?
How did you solve them? What would you do differently if you were
to do the whole thing over again?"

3) Be able to quickly come up with relatively clever algorithms
that solve common (or uncommon) sorts of problems.

A highly structured question about binary trees doesn't seem
to give a lot of scope for cleverness. Also, I question whether
"clever" is an unadulterated Good Thing.

4) Be very comfortable with most uses of boolean logic,
as they appear in programming environments (eg. the
ability to code complex if/then/else's and not lose
track of the logic they're trying to code)

Your question might test this ability, but I think lightly.
There's not a lot of "complex if/then/else's" in most of the
methods I'd imagine for a binary tree implementation.

5) Know that it is important to make your code readable,
clear, and concise

Notice the clash between "clear" and "clever," a few paragraphs
back. Notice, too, the clash between "clear" and "complex" in the
preceding paragraph. These clashes are not unresolvable, but it
requires some discipline on your part to remain open to trade-offs
that you yourself would have made differently.

6) Be able to quickly write code that accomplishes simple tasks
(eg. write a Java Bean, write a Comparator, know how to use
the Java Collections API, etc.).

Your question seems a reasonable test of this one. The test is
superficial, of course, but you probably can't have the interview
drag on for six weeks ;-)

In the interview I had today with this guy, he knew what a Binary Tree
was. But then he started coding it as an N-ery tree, with an add(Node myNode)
method. That's not a binary tree. So I clarified it for him "In a binary
tree each node may have at most two child nodes, left and right".

There's really no essential difference between a binary tree
and a forest of general ordered trees. See Knuth, Volume 1.

He continued working, but very slowly, not seeming to understand
what the first thing he might want to do would be.

He showed some knowledge of how to approach the problem (wrote a BTree
interface, then applied it to a class), but didn't seem comfortable
just diving right in and getting his hands dirty, which is what we DO
need for this position.

[...]
But isn't knowing what a binary tree is, and how to code one,
something that's kind of Computer Science 101-ish?

Dunno, as I myself never had the benefit of any CS classes.
(I've taught 'em, but never took one.) Trees are pretty basic,
though. In my own development, trees were the third data structure
I ran into (after arrays and linked lists, and before hash tables).
And Knuth describes them in Volume 1, not in Volume 42 ... I'd
tend to view with some suspicion a programmer who didn't grasp
trees well -- but on the other hand, a programmer who spends his
days dreaming up ways to solve non-linear partial differential
equations in twelve dimensions might be more than a little rusty
on data structures but be a whiz-bang programmer nonetheless. It
all depends on what you (think you) need.

 

[Chris Smith]

Ooh, I like these sorts of things. I get kind of bored just doing web
apps all the time. It doesn't take much thought process for most of it.
Once you develop the back end, the front end rather builds itself.

For more interesting programming problems, I find
http://www.topcoder.com to be rather amusing.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Liz]

The question you ask, though, is "Demonstrate knowledge of
data structure X." Perhaps a better question might be "Tell me
all about your favorite data structure, and sketch an implementation."

A doubly linked list that uses only one pointer. Knuth vol 1.

Less coercive, more open-ended -- and you might even learn a thing
or two ...

2) Have experience in all tiers of common sorts of applications
(UI, Business Logic/Middleware, Database, Network)

The binary tree exercise doesn't test this, or not very much
at any rate. Again, I'd put the onus on the interviewee: "Tell me
about some Topic X work you've done. What problems did you encounter?
How did you solve them? What would you do differently if you were
to do the whole thing over again?"

3) Be able to quickly come up with relatively clever algorithms
that solve common (or uncommon) sorts of problems.

A highly structured question about binary trees doesn't seem
to give a lot of scope for cleverness. Also, I question whether
"clever" is an unadulterated Good Thing.

4) Be very comfortable with most uses of boolean logic,
as they appear in programming environments (eg. the
ability to code complex if/then/else's and not lose
track of the logic they're trying to code)

Your question might test this ability, but I think lightly.
There's not a lot of "complex if/then/else's" in most of the
methods I'd imagine for a binary tree implementation.

5) Know that it is important to make your code readable,
clear, and concise

Notice the clash between "clear" and "clever," a few paragraphs
back. Notice, too, the clash between "clear" and "complex" in the
preceding paragraph. These clashes are not unresolvable, but it
requires some discipline on your part to remain open to trade-offs
that you yourself would have made differently.

6) Be able to quickly write code that accomplishes simple tasks
(eg. write a Java Bean, write a Comparator, know how to use
the Java Collections API, etc.).

Your question seems a reasonable test of this one. The test is
superficial, of course, but you probably can't have the interview
drag on for six weeks ;-)

In the interview I had today with this guy, he knew what a Binary Tree
was. But then he started coding it as an N-ery tree, with an add(Node myNode)
method. That's not a binary tree. So I clarified it for him "In a binary
tree each node may have at most two child nodes, left and right".

There's really no essential difference between a binary tree
and a forest of general ordered trees. See Knuth, Volume 1.

He continued working, but very slowly, not seeming to understand
what the first thing he might want to do would be.

He showed some knowledge of how to approach the problem (wrote a BTree
interface, then applied it to a class), but didn't seem comfortable
just diving right in and getting his hands dirty, which is what we DO
need for this position.

[...]
But isn't knowing what a binary tree is, and how to code one,
something that's kind of Computer Science 101-ish?

Dunno, as I myself never had the benefit of any CS classes.
(I've taught 'em, but never took one.) Trees are pretty basic,
though. In my own development, trees were the third data structure
I ran into (after arrays and linked lists, and before hash tables).
And Knuth describes them in Volume 1, not in Volume 42 ... I'd
tend to view with some suspicion a programmer who didn't grasp
trees well -- but on the other hand, a programmer who spends his
days dreaming up ways to solve non-linear partial differential
equations in twelve dimensions might be more than a little rusty
on data structures but be a whiz-bang programmer nonetheless. It
all depends on what you (think you) need.

 

[Eric Sosman]

A doubly linked list that uses only one pointer. Knuth vol 1.

If you're referring to the XOR trick, I think this would be
a risky choice because of the "sketch an implementation" piece.
As an interviewer, I'd be all over you about how you're going
to swizzle a Java reference variable ...

THEN if you pointed out that links need not be references,
and sketched an implementation using array indices in an arena
consisting of a LinkedListNode[], I'd have confidence that you
knew whereof you spoke.

Of course, if you were to choose something too simple ("My
favorite data structure is the free-standing `int' variable"),
I'd exercise my interviewer's prerogative and request another
nominee ;-)

The important thing, I think, is to avoid trying to assess
someone's ability based on a small "hit list" of pre-selected
topics. That's why I prefer to let the interviewee come up with
the knowledge to be demonstrated: not "Do you know X?" but "Tell
me something you know." I'm usually able to ask enough awkward
questions to separate those who actually do know from the mere
parrots. So far, anyhow ...

 

[Alex99 Kay]

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???

In a work enviornment no, in a uni assignment no but in an interview ?

- Tim

--

Hi Tim,

I've done heaps of interviews so I share your pain. I also found most
didn't understand the basics.

Mind you my basics were even more basic than yours. I just had a base
class, a derived classed and a polymorphic show() ... and we just
talked through various things.

Questions like how would you do this, why would you do that... when to
use inheritence vs containment. What do you think is important?
Why/why not?

I focused on depth of understanding, experience, design, their ability
to reason and make intelligent tradeoffs ... I didn't care about
syntax errors, compilers easily catches those.

So I agree, tests are a great idea.

But on OTOH personally I wouldn't test using a BinaryTree.

I have 19 years experience, all my performance reviews have been
excellent, my solutions just keep on running, I've done really well at
uni and in the field, I've implemented way too many BinaryTrees in C,
Pascal, C++ (none in Java I use TreeMap/TreeSet) ... yet I would
probably fail your BinaryTree test!

Not that I don't know BinaryTree's but an interview environment is
radically different to a work enviornment. It makes people nervous. It
would take me by surprise, I'd have to context-switch and that takes
time.

But put a keyboard under my fingers and I'll thump a BT out no
problem. Let me use my references or my past code and it's all so
easy!

But would I recall it all in an interview on a whiteboard? NO.

It's a dilicate matter of balance. Interviews ain't easy, I do
sympathize with you ;-|

OTOH not all get nervous some really shine in interviews yet they
can't program for peanuts! They present extremely well, they've got
all the lingo down, design patterns, OO-speak, buzz words, charm
galore but ... they can't program!

Another big factor are they burnt out? They may really need a big
holiday and not a new job.

Tim, above all the most important thing for me is
how-well-would-they-get-on-with-everyone?

I've worked with very clever guys but some were savages to get on
with, I hated it. I'm considered by most as easy going, I don't want
to have wars at work! Nightmares about work at home.

....
Some ideas: Maybe an 80% completed BinaryTree, they could talk about
what's missing ... or a poorly designed tree and they can suggest how
to make it good. Oh I dunno ...

Best wishes ;-)
Alex

 

[Panama Red]

I believe it was Gawnsoft who said...

Test for /ability to pick up new stuff/.

Currently your test does not test for this. It primarily tests for
existing knowledge of tree structures.

In other words, he's acting like most companies hiring programmers,
they are looking for people who know how problems were solved rather
than people who can solve problems.

 

[Sam]

An example of how few programmers can pass a "simple" test -- at least
in an interview situation. [...]

Wow. The last time I interviewed for a job (about three years ago, and
it wasn't even a programming job!) I was asked a much harder question
than that to solve at a whiteboard in the middle of an interview. The
problem was something like "Given an array of integers of length m, and
a target integer n, write an O(m)-time algorithm to find two array
elements whose sum is n."

Ouch. Or maybe not, it depends on the interview situation. It's a nice little
problem for someone sitting happily at home with a glass of wine. But not a
challenge I'd relish in an adversarial interview situation. In a more
friendly, chatty, interview where I felt I could think out loud, and get
"credit" for exploring avenues that turned out to be dead ends, then it'd be a
lot more fun (and, presumably, a lot more informative for the interviewer).

If what you're saying is true, I wonder how many correct answers they
got to *that* question.

might bring out the best in some people. Maybe we (at the shop I
mentioned) would have got more information about candidates if we'd split the
challenge(s) up, but made them harder.

Step 1: introduce some abstract problem that you hope the candidate can solve
with some thought and discussion.

Step 2: /then/ challenge them to turn their solution into approximately
workable code.

Thinking about it, it seems to me that a "difficult" algorithmic question like
that
At least it could avoid the mental log-jam caused by trying to work out what
the code should do at the same time as actually writing it.

-- chris

Agree completely. Interviews should focus on the candidates ability to
develop solutions to a problem in the context of discussion between
professionals. For example, I very much enjoy bouncing ideas off of a
colleague, and letting the chemistry take hold. This is more effective
than ivory-tower, genius programming for a variety reasons, such as:

1) Creates social interaction and a sense of shared goals.
2) Reduces isolation in an inherently anti-social profession.
3) Speeds up the development process by allowing ideas and solutions
to stew to the surface more quickly than the "lone genius" appoach.
4) Allows project personal to know very precicesly what you're working
on, where you're at, and how you're progressing, thus obviating the
intrusive and often demoralizing status reporting so favored by
un-enlightened managers.
5) Sharing information not only generates solutions, but spreads
knowledge which can be used later for the "general good".

My belief is that someone who is stubborn, arrogant, egotistical,
argumentative, etc., regardless of skill level, is usually usually a
major detriment to a project. Otoh, (and this is rare), someone who
knows how to listen, is flexible and supple in thier thinking, who has
a good feel for the "critical path", a willingness, even a desire to
explore and learn new stuff, has a strong record of delivering "rocks"
and involvement in succesfull projects, and who has demonstrated and
ability to think "out of the box", is someone whose candidacy should
be strongly considered.

Computing is by definition a creative and ongoing learning process.
Tying a candidate's success or lack thereof to his or her ability to
produce some code relating to a technique he may not be familiar with
while under the pressure of an interview is not only rather silly, but
is probably depriving the company of some very capable employees.

Regards,
Sam Hunt

 

[Chris Smith]

The question you ask, though, is "Demonstrate knowledge of
data structure X." Perhaps a better question might be "Tell me
all about your favorite data structure, and sketch an implementation."
Less coercive, more open-ended -- and you might even learn a thing
or two ...

Eric,

I get your point here, but I'm just imagining being in an interview and
being asked that question. I suppose I'd feel very awkward and wonder
what kind of an answer is desired. "Well, I've always felt a special
bond of friendship with the red-black tree..."

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Eric Sosman]

Eric,

I get your point here, but I'm just imagining being in an interview and
being asked that question. I suppose I'd feel very awkward and wonder
what kind of an answer is desired. "Well, I've always felt a special
bond of friendship with the red-black tree..."

Aside from the "special bond" part, this is exactly the
sort of response I'd hope to get. I'd ask you to explain what
a red-black tree is, what it's good for, and what makes it good
for those purposes. I'd ask you to show how to perform some
operation like deleting a node -- I'd probably settle for
diagrams on a whiteboard rather than insisting on compilable
code, but might require the latter in unusual circumstances
(e.g., if the job required knowledge of an uncommon language
and I felt the need to probe some of your resume's claims).
I'd ask you if there were any circumstances in which you'd
abandon your beloved R-B tree in favor of something else.

The point of all this isn't really to test your knowledge
of R-B trees, but to tell whether you actually know something
or are merely blowing smoke, to get an idea of how you deal
with trade-offs, to find out how well you understand your
chosen tools. After all, once I've hired you (big bonus in
your case, I'd think) I'm not going to ask you to write new
R-B implementations! That would be a shameful betrayal of
*my* favorite data structure, the skip list, and you better
not say anything mean about her ;-)

 

[Dimitri Maziuk]

Eric Sosman sez:

Aside from the "special bond" part, this is exactly the
sort of response I'd hope to get.

If I were asked about my favourite data structure, "special bond"
part is exactly what'd be going through my mind, followed by "do
I want to work with people who have _favourite_ _data_ _structures_,
ffs?!!"

Besides, any competent programmer should answer "char(0)" because
it has small memory footprint, is well understood, easy to implement,
debug, etc.

Dima