Java Interview Questions: Am I Being Too Difficult?

[Chris Uppal]

Re: Java Interview Questions: Am I Being Too Difficult?

Chris Smith wrote:
[color=blue][color=green]
> > An example of how few programmers can pass a "simple" test -- at least
> > in an interview situation. [...][/color]
>
> 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."[/color]

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).
[color=blue]
> If what you're saying is true, I wonder how many correct answers they
> got to *that* question.[/color]

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]

Re: Java Interview Questions: Am I Being Too Difficult?

D Rolfe wrote:
[color=blue]
> 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.[/color]

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

-- chris

[Larry Barowski]

Re: Java Interview Questions: Am I Being Too Difficult?


"Spammay Blockay" <SPAMBLOCKER@BL OCKEDTOAVOIDSPA M.com> wrote in message
news:c8e6ml$me3 $1@bolt.sonic.n et...[color=blue]
> ...
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> ...[/color]

[D Rolfe]

Re: Java Interview Questions: Am I Being Too Difficult?



Chris Uppal wrote:[color=blue]
> D Rolfe wrote:
>
>[color=green]
>>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.[/color]
>
>
> Yes a great question, but then -- oh God -- how do you get 'em to /stop/
> talking...
>[/color]

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

-----------------------------------------------------------------------
OrindaBuild writes your Java access code for you.
www.orindasoft.com.

[kaeli]

Re: Java Interview Questions: Am I Being Too Difficult?

In article <MPG.1b1529cb9b a00dae989af9@ne ws.pop4.net>, cdsmith@twu.net
enlightened us with...[color=blue]
> Chris Uppal wrote:[color=green]
> > 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.[/color]
>
> 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.
>
>[/color]

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

Fun stuff. *g*

--
--
~kaeli~
If a turtle doesn't have a shell, is he homeless or naked?

http://www.ipwebdesign.net/wildAtHeart

http://www.ipwebdesign.net/kaelisSpace

[Chris Uppal]

Re: Java Interview Questions: Am I Being Too Difficult?

kaeli wrote:
[color=blue]
> Fun stuff. *g*[/color]

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

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

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

[kaeli]

Re: Java Interview Questions: Am I Being Too Difficult?

In article <SIednRHBQLmkPj bd4p2dnA@nildra m.net>,
chris.uppal@met agnostic.REMOVE-THIS.org enlightened us with...[color=blue]
> kaeli wrote:
>[color=green]
> > Fun stuff. *g*[/color]
>
> If you don't already know it, you might enjoy:
>
> <http://www.ocf.berkele y.edu/~wwu/riddles/intro.shtml>
>
> -- chris (that's *this* chris, not *that* Chris)
>
>
>[/color]

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

[Eric Sosman]

Re: Java Interview Questions: Am I Being Too Difficult?

Spammay Blockay wrote:[color=blue]
> In article <YcAqc.14561$zO 3.5187@newsread 2.news.atl.eart hlink.net>,
> Dan Nuttle <d_nuttle@hotma il.com> wrote:
>[color=green]
>>My personal opinion about interview questions is that they should be
>>designed to indicate whether the person being interviewed can be a valuable
>>member of your team. So the only relevant criterion to be applied to any
>>given question is, does it help to indicate whether the person being
>>interviewed can be a valuable member of your team?[/color]
>
>
> 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).[/color]

The question you ask, though, is "Demonstrat e 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 ...
[color=blue]
> 2) Have experience in all tiers of common sorts of applications
> (UI, Business Logic/Middleware, Database, Network)[/color]

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?"
[color=blue]
> 3) Be able to quickly come up with relatively clever algorithms
> that solve common (or uncommon) sorts of problems.[/color]

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.
[color=blue]
> 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)[/color]

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.
[color=blue]
> 5) Know that it is important to make your code readable,
> clear, and concise[/color]

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.
[color=blue]
> 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.).[/color]

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 ;-)
[color=blue]
> 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".[/color]

There's really no essential difference between a binary tree
and a forest of general ordered trees. See Knuth, Volume 1.
[color=blue]
> 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.[/color]
[color=blue]
> [...]
> But isn't knowing what a binary tree is, and how to code one,
> something that's kind of Computer Science 101-ish?[/color]

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@sun .com

[Chris Smith]

Re: Java Interview Questions: Am I Being Too Difficult?

kaeli wrote:[color=blue]
> 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.[/color]

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

--

https://www.designacourse.com

The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Liz]

Re: Java Interview Questions: Am I Being Too Difficult?


"Eric Sosman" <Eric.Sosman@su n.com> wrote in message
news:40ABBEAC.9 050707@sun.com. ..[color=blue]
> Spammay Blockay wrote:[color=green]
> > In article <YcAqc.14561$zO 3.5187@newsread 2.news.atl.eart hlink.net>,
> > Dan Nuttle <d_nuttle@hotma il.com> wrote:
> >[color=darkred]
> >>My personal opinion about interview questions is that they should be
> >>designed to indicate whether the person being interviewed can be a[/color][/color][/color]
valuable[color=blue][color=green][color=darkred]
> >>member of your team. So the only relevant criterion to be applied to[/color][/color][/color]
any[color=blue][color=green][color=darkred]
> >>given question is, does it help to indicate whether the person being
> >>interviewed can be a valuable member of your team?[/color]
> >
> >
> > 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).[/color]
>
> The question you ask, though, is "Demonstrat e knowledge of
> data structure X." Perhaps a better question might be "Tell me
> all about your favorite data structure, and sketch an implementation. "[/color]

A doubly linked list that uses only one pointer. Knuth vol 1.
[color=blue]
> Less coercive, more open-ended -- and you might even learn a thing
> or two ...
>[color=green]
> > 2) Have experience in all tiers of common sorts of applications
> > (UI, Business Logic/Middleware, Database, Network)[/color]
>
> 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?"
>[color=green]
> > 3) Be able to quickly come up with relatively clever algorithms
> > that solve common (or uncommon) sorts of problems.[/color]
>
> 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.
>[color=green]
> > 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)[/color]
>
> 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.
>[color=green]
> > 5) Know that it is important to make your code readable,
> > clear, and concise[/color]
>
> 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.
>[color=green]
> > 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.).[/color]
>
> 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 ;-)
>[color=green]
> > 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[/color][/color]
myNode)[color=blue][color=green]
> > method. That's not a binary tree. So I clarified it for him "In a[/color][/color]
binary[color=blue][color=green]
> > tree each node may have at most two child nodes, left and right".[/color]
>
> There's really no essential difference between a binary tree
> and a forest of general ordered trees. See Knuth, Volume 1.
>[color=green]
> > 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.[/color]
>[color=green]
> > [...]
> > But isn't knowing what a binary tree is, and how to code one,
> > something that's kind of Computer Science 101-ish?[/color]
>
> 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@sun .com
>[/color]

[Eric Sosman]

Re: Java Interview Questions: Am I Being Too Difficult?

Liz wrote:[color=blue]
> "Eric Sosman" <Eric.Sosman@su n.com> wrote in message
> news:40ABBEAC.9 050707@sun.com. ..[color=green]
>>
>> The question you ask, though, is "Demonstrat e knowledge of
>>data structure X." Perhaps a better question might be "Tell me
>>all about your favorite data structure, and sketch an implementation. "[/color]
>
>
> A doubly linked list that uses only one pointer. Knuth vol 1.[/color]

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

--
Eric.Sosman@sun .com

[Alex99 Kay]

Re: Java Interview Questions: Am I Being Too Difficult?

SPAMBLOCKER@BLO CKEDTOAVOIDSPAM .com (Spammay Blockay) wrote in message news:<c8e6ml$me 3$1@bolt.sonic. net>...[color=blue]
> 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???
>[/color]

In a work enviornment no, in a uni assignment no but in an interview ?
[color=blue]
> - Tim
>
> --[/color]


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]

Re: Java Interview Questions: Am I Being Too Difficult?

I believe it was Gawnsoft who said...[color=blue]
>
> 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.[/color]

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]

Re: Java Interview Questions: Am I Being Too Difficult?

"Chris Uppal" <chris.uppal@me tagnostic.REMOV E-THIS.org> wrote in message news:<j4udndLxs tvmFDbdRVn-hw@nildram.net> ...[color=blue]
> Chris Smith wrote:
>[color=green][color=darkred]
> > > An example of how few programmers can pass a "simple" test -- at least
> > > in an interview situation. [...][/color]
> >
> > 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."[/color]
>
> 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).
>[color=green]
> > If what you're saying is true, I wonder how many correct answers they
> > got to *that* question.[/color]
> 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[/color]

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]

Re: Java Interview Questions: Am I Being Too Difficult?

Eric Sosman wrote:[color=blue]
> The question you ask, though, is "Demonstrat e 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 ...[/color]

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

--

https://www.designacourse.com

The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation