By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,605 Members | 2,012 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,605 IT Pros & Developers. It's quick & easy.

Java Interview Questions: Am I Being Too Difficult?

P: n/a
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

--

Jul 17 '05 #1
Share this Question
Share on Google+
54 Replies


P: n/a

"Spammay Blockay" <SP*********@BLOCKEDTOAVOIDSPAM.com> wrote in message
news:c8**********@bolt.sonic.net...
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

--


Seems reasonable to me, but Ive never used List, and is that not an
interface anyway?
So without the api do you allow them to say can I return it anyway I like
for now, and implement the list when they can look it up?

Probably stump me in the interview, but as I do not know how list works, I
would ask to return it as an array or vector because I do not know how list
works.

Would this fail me?
Give me 5 minutes with a compiler and api and you could have your list
:)
Jul 17 '05 #2

P: n/a
In article <40**********************@news.optusnet.com.au>,
Marty <ma***@sorry.com> wrote:

"Spammay Blockay" <SP*********@BLOCKEDTOAVOIDSPAM.com> wrote in message
news:c8**********@bolt.sonic.net...
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

--


Seems reasonable to me, but Ive never used List, and is that not an
interface anyway?
So without the api do you allow them to say can I return it anyway I like
for now, and implement the list when they can look it up?

Probably stump me in the interview, but as I do not know how list works, I
would ask to return it as an array or vector because I do not know how list
works.

Would this fail me?
Give me 5 minutes with a compiler and api and you could have your list
:)


Oh no, of course not... if you told me you weren't familiar
with the List interface, I'd let you use whatever you wanted.

- Tim

--

Jul 17 '05 #3

P: n/a
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?

E.g.:

1. Will the person need to write code that represents a binary tree? Or do
you already have an existing library that provides that functionality?

2. Does the coding a representation of a binary tree represent the common
type of programming task your team members face?

3. What other kinds of coding do team members need to do? Can you list
categories, and prioritize them? Where does coding a binary tree fit in?

Only you can determine the answers to these kinds of questions. Now, I will
say that from my own personal experience, I believe that being able to code
a binary tree probably isn't that important. First, it's been done; you
can find implementations already coded for you. Second, it's the kind of
thing that throw coders for a loop if they're not familiar with it, but once
you understand what a binary tree is, it's not terribly difficult to code
it. Are you perhaps indulging yourself in trying to make interviewees jump
through a hoop that you once had to jump through yourself? Don't think I'm
trying to be insulting; I know I can be prone to just that kind of
indulgence myself.

Personally, I think the most important attributes of coders are 1) the
ability to "get things done", however nebulous that sounds, 2) the ability
to work as part of a team, and 3) the ability not to annoy the living hell
out of me with bizarre personal habits and mannerisms. A good coder can
quickly learn what a binary tree is, and code it, even if he's never heard
of the concept before. I'd concentrate more on best practices (for example,
emphasizing the uses of interfaces rather than inheritance whenever
possible) rather than something like the ability to code a particular
concept or algorithm. But even then, best practices can be learned.
Jul 17 '05 #4

P: n/a
In article <Yc******************@newsread2.news.atl.earthlink .net>,
Dan Nuttle <d_******@hotmail.com> wrote:
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?
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).

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

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

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)

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

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

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

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.

E.g.:

1. Will the person need to write code that represents a binary tree? Or do
you already have an existing library that provides that functionality?

2. Does the coding a representation of a binary tree represent the common
type of programming task your team members face?

3. What other kinds of coding do team members need to do? Can you list
categories, and prioritize them? Where does coding a binary tree fit in?
I can say that coding a binary tree won't be a requirement for the job,
no; but understand what one is, how one might code one, how one might
write the kinds of methods needed to maintain one, etc. to me are
the _kind_ of skills that show how well-versed somebody is.

I want someone who doesn't have to be taught any programming skills
on the job; they may need to learn a new API, or how existing code works,
but they're knowledge of patterns, data structures, algorithms, and
Java syntax is rock-solid.
Only you can determine the answers to these kinds of questions. Now, I will
say that from my own personal experience, I believe that being able to code
a binary tree probably isn't that important. First, it's been done; you
can find implementations already coded for you. Second, it's the kind of
thing that throw coders for a loop if they're not familiar with it, but once
you understand what a binary tree is, it's not terribly difficult to code
it.
But isn't knowing what a binary tree is, and how to code one,
something that's kind of Computer Science 101-ish?
Are you perhaps indulging yourself in trying to make interviewees jump
through a hoop that you once had to jump through yourself? Don't think I'm
trying to be insulting; I know I can be prone to just that kind of
indulgence myself.
I may be, but they're also hoops I WANTED to learn to jump through.
I have read my Knuth. I have read my Dragon Book. I currently read
the Javasoft website and these newsgroups. I expect no less of someone
I'd want to hire.

Is that unreasonable?

I also grew up playing on the Arpanet machines, reading stuff by
all the old MIT hackers, and developed a strong idea that any programmer
worth his salt spent TIME to LEARN all these minutiae of programming.
They could code in their sleep. That kind of thing.
Personally, I think the most important attributes of coders are 1) the
ability to "get things done", however nebulous that sounds, 2) the ability
to work as part of a team, and 3) the ability not to annoy the living hell
out of me with bizarre personal habits and mannerisms. A good coder can
quickly learn what a binary tree is, and code it, even if he's never heard
of the concept before. I'd concentrate more on best practices (for example,
emphasizing the uses of interfaces rather than inheritance whenever
possible) rather than something like the ability to code a particular
concept or algorithm. But even then, best practices can be learned.


Quite true... I just want a big background in these "basics of programming"
kinds of things. Doesn't anybody keep up with that stuff these days?

- Tim

--

Jul 17 '05 #5

P: n/a
On Tue, 18 May 2004 23:36:53 GMT, Spammay Blockay
<SP*********@BLOCKEDTOAVOIDSPAM.com> wrote:
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

You say you are responsible for "technical interviews". But the
applicability of your exercise depends to a large extent on the particular
job for which the person is interviewing. For a software architect your
question is way too detailed, for a web developer a bit off-base, but for a
nuts-and-bolts programmer quite relevant. I got my degree in applied
physics and have been architecting scientific simulations and writing core
algorithm code for for nearly 10 years, but have never had to implement a
binary tree. I freely admit that I would struggle with your test - not
because I am an incompetent Java developer, but because it is not
applicable to my particular expertise.
Jul 17 '05 #6

P: n/a
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message news:<c8**********@bolt.sonic.net>...
Am I unreasonable in expecting someone to be able to do this???


I don't think so. I wouldn't hire a programmer that can't solve your
problem. It's a good problem because it emphasizes on the ability to
understand data structures, algorithms and how to solve problems,
rather than just knowing the Java API and how to use it. I think the
former is MUCH more important for a good programmer. The latter is
what Javadoc is for. :-)

/Jesper Nordenberg
Jul 17 '05 #7

P: n/a
"Spammay Blockay" <SP*********@BLOCKEDTOAVOIDSPAM.com> wrote in message
news:c8**********@bolt.sonic.net...

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


Possibly. Depends what you're after. A perfectly competent Java application
level programmer (who knows all about, say, multi-tier web applications)
could well not have a clue how to do this sort of stuff - because a Java
application level programmer never has to do anything like this, they just
use the stuff in the library that already does it for them.

If on the other hand you're after someone to do low level computer-sciency
library type work then maybe you should do the test in some other language.

--
Tim Ward
Brett Ward Limited - www.brettward.co.uk
Jul 17 '05 #8

P: n/a

"Jesper Nordenberg" <me*******@yahoo.com> wrote in message
news:9c*************************@posting.google.co m...
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message

news:<c8**********@bolt.sonic.net>...
Am I unreasonable in expecting someone to be able to do this???


I don't think so. I wouldn't hire a programmer that can't solve your
problem. It's a good problem because it emphasizes on the ability to
understand data structures, algorithms and how to solve problems,
rather than just knowing the Java API and how to use it. I think the
former is MUCH more important for a good programmer. The latter is
what Javadoc is for. :-)

/Jesper Nordenberg


I agree - this is a very good test.

I have always set programming tests (usually slightly easier than yours)
when recruiting and I am amazed at the low average quality of the results.
It's quite scary how many programmers muddle through using a "darwinian"
approach - just changing things almost at random until it works and then not
really understanding why it worked. I have looked at many other people's
code in my time and a lot of it only hangs together by coincidence.

Also I don't think you should lay down the requirements 100% explicitly. If
someone is able to pick faults with the problem and have a discussion about
what the exact requirements are (such as some of the messages in this
thread) I would see that as a very good sign too - infact someone who goes
away on their and produces "working" code when the requirements are unclear
might count against them.

Stick at it though - if you manage to build a team where everyone pulls his
weight you will be surprised how much you can achieve. and always err on the
side of hiring a few good people rather than a lot of mediocre ones.

Andy
Jul 17 '05 #9

P: n/a
Spammay Blockay wrote:
[sniped description of programming problem] 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???


I think there's an important point here that no one else has yet mentioned.

I think this exercise is *way* too difficult -- so difficult that it will be
giving you little or no useful information.

The problem is that writing and thinking code while standing up in a stressful,
and above all, *social*, situation is just about impossible. At least I know
/I/ can't do it, and I've done a bit of interviewing and seen that other people
can't either. The bits of the brain you need for programming are occupied
reading the interviewer's body language, and trying not to shit yourself....

An example of how difficult it is to write code on a whiteboard from when I was
interviewing Java programmers (a thing I /hate/ doing, but that's another
story...) I wanted to ask the old "how to return two values from a method"
question in a way that had a bit more meat to it, so I decided to ask
candidates to write a method that took an array of ints and returned the max
and min elements. The first candidate -- a genuine programmer, I think -- just
froze up. Couldn't even see how to do a loop over the elements of the array to
/find/ the extrema (which I'd thought was too trivial to discuss). We never
even got close to considering how to pass both values back to the caller or
opening a discussion about whether the gain of looping over the array once
instead of twice was worth the extra bother -- which is what I was hoping
/good/ candidates would do). I simplified the question for the second
candidate. I forget now who it was that suggested sorting the array and then
taking the end-points... I dropped the question after that.

As a sit-down exercise, either on paper or (better, since you are looking for
approximate syntactic correctness) at a computer without the interviewer
watching, and with no set time, just "tell me when you're done", I think your
question would probably work. Although perhaps still be a bit too hard for
many applicants -- but that's OK, if your object is to winnow out those without
(IMO) basic skills and talents. But be prepared for most candidates to flub
it -- which is what you'd expect unless you happen to believe that /most/
programmers are in fact reasonably competent...

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.

Incidentally, for anyone who is wanting to respond "but the C++ standard
library has a String class, it's not a representative task to program something
that already exists". If a candidate said that then I (or my colleague) would
take that as a plus. But we'd still ask him/her to do the code -- after all,
if you can't code up a simple API that has already been defined for you (or a
simplified version of it) what hope do you have of creating *real* code ?

-- chris

Jul 17 '05 #10

P: n/a
On Tue, 18 May 2004 23:36:53 GMT, SP*********@BLOCKEDTOAVOIDSPAM.com
(Spammay Blockay) wrote (more or less):
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. .... 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, .... The code must be syntactically correct, and would compile.

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


As to whether this is a good test or not, it depends on

- how applicable knowledge of Binary trees is to the domain area your
group works in.

and, if not,

- whether the interviewee has to have a priori knowledge of binary
trees for you to feel s/he succeeeded.

You say later you are searching for:
" 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)."

Which is fair enough.

But I'd suggest you want their greatest knowledge on the common data
structures most used, or used at all, in the areas of your application
base you're hiring for.

Imagine an interviewee didn't have prior knowledge of binary trees.

As has been pointed out on the thread, it's a relatively simple
concept to explain to someone, but not every coder has experience or
even knowledge of what they are.

If you explained it, and they then coded it well, would that pass your
test?

If they knew what it was already, and therefore were just spouting off
what they knew, would that be as informative to you?
2) Have experience in all tiers of common sorts of applications
(UI, Business Logic/Middleware, Database, Network)

a) I note that you put UI as first in the list, but your questioning
seems concerned with middleware, and I suspect you are nothing like as
rigorous in your probing of the interviewee's ability to design
learnable, memorable UIs with good affordance, visibility and
feedback.

Often this is /should/ be a key skill looked for, but because it's
seens as a 'soft' human skills issues, and not a 'hard' techie area,
it is not checked at interview, even for people who will be writing
lots of user interfaces.
b) There's nothing wrong with hiring folk with experience of only a
couple of these, if they have an appreciation of the others. - a lot
of places have their developers specialise in a couple of those areas.

You'd be cutting yourself off from that pool of potential hires.


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

If they knew already what a BT was, this wasn't necessarily tested.

If they did not know what a BT was, then it might have been tested.

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)

Again, depends on the familiarity of the problem space (BTs) how much
this was tested.

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

There will be much less cognitive capacity left for this in the
'BT-newbies', but not for the fok who are just reciting from their
previous knowledge.

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

This would still be tested if you had to explain what a BT is.
Personally, I'd want them in a different priority order.

I'd want you to probe their knowledge of what a BT /is/ separately
from implementing one.

At the moment, you're conflating too much into one big lump, and
trying then to work out what your results mean.

You have no way of demultiplexing them.

In general, your first two objectives are against the interviewee's
knowledge, and your last four are against the interviewee's process
skills.
My view is : concentrate on 3,4,5,6

Test on whichever of 2) the interviewee is claiming to have.

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.

(i.e. that knowlefdge is a hurdle. If you jump the hurdle, you can go
on to demonstrate knowledge of the List class, thread-safing, etc.,
ability to pick up

But if they fall at the first hurdle you don't get to check the other
stuff. Worse, you may think that you are and that they are failing
those parts.

If they are good at what they know, and show ability to learn knew
stuff, then you'll get them to cover all areas if that's what you want
in your teams.

In the case of 1) test it on order of importance/frequency of use in
/your/ application base.

--
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
Jul 17 '05 #11

P: n/a
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message news:<c8**********@bolt.sonic.net>...
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???
--

If you posed that problem to me, I'd ask if you know about XML.

That's the de facto standard for representing a tree structure. Nodes
are defined as part of the API.

If you still insisted on your bizarre exercise, I'd ask why you are
trying to re-invent the wheel. Why not ask the interviewee to write a
compiler?
Jul 17 '05 #12

P: n/a


Spammay Blockay wrote:
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.

[ snip ! ]
Am I unreasonable in expecting someone to be able to do this???

- Tim

IMHO Yes. It's hard to get something like this to work while being
watched. It's also about as relevent as roman numeral generators to a
lot of people.

I ask people who claim to know Java what they think should have been
done differently when it was designed.

That seems to be pretty effective at identifying people who *know* Java.
Open ended and possinbly answerless questions will reveal more about
what's going on in their head than computer science 'challenges' like
the above. Also I've never met a real expert who went all quiet when
asked that question.

David Rolfe
Orinda Software
Dublin, Ireland
------------------------------------------------------------------
Orinda make OrindaBuild, A JDBC Access Code Generartor For Oracle's
PL/SQL. www.orindasoft.com

Jul 17 '05 #13

P: n/a
Dan Nuttle wrote:
Personally, I think the most important attributes of coders are 1) the
ability to "get things done", however nebulous that sounds, 2) the ability
to work as part of a team, and 3) the ability not to annoy the living hell
out of me with bizarre personal habits and mannerisms. A good coder can
quickly learn what a binary tree is, and code it, even if he's never heard
of the concept before.


When I first started interviewing job candidates several years ago, I
had the same basic attitude. The problem, though, is that you have to
go on what you can observe and measure. Writing code to implement a
binary tree like this demonstrates at least a certain minimum requisite
ability to think about code in abstract terms, and get something working
without a lot of compiler trial-and-error. Eventually, you'll have to
pick some concrete questions and tasks, and it *can't* always be
acceptable to get an answer of "I could learn that if I needed it".

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Jul 17 '05 #14

P: n/a
Chris Uppal wrote:
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
Jul 17 '05 #15

P: n/a
Chris Smith wrote:
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
Jul 17 '05 #16

P: n/a
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...

-- chris

Jul 17 '05 #17

P: n/a

"Spammay Blockay" <SP*********@BLOCKEDTOAVOIDSPAM.com> wrote in message
news:c8**********@bolt.sonic.net...
...
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.
...

Jul 17 '05 #18

P: n/a


Chris Uppal wrote:
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

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

Jul 17 '05 #19

P: n/a
In article <MP************************@news.pop4.net>, cd*****@twu.net
enlightened us with...
Chris Uppal wrote:
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.


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

Jul 17 '05 #20

P: n/a
kaeli wrote:
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)
Jul 17 '05 #21

P: n/a
In article <SI********************@nildram.net>,
ch*********@metagnostic.REMOVE-THIS.org enlightened us with...
kaeli wrote:
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)


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

Jul 17 '05 #22

P: n/a
Spammay Blockay wrote:
In article <Yc******************@newsread2.news.atl.earthlink .net>,
Dan Nuttle <d_******@hotmail.com> wrote:
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?

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.

--
Er*********@sun.com

Jul 17 '05 #23

P: n/a
kaeli wrote:
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
Jul 17 '05 #24

P: n/a
Liz

"Eric Sosman" <Er*********@sun.com> wrote in message
news:40**************@sun.com...
Spammay Blockay wrote:
In article <Yc******************@newsread2.news.atl.earthlink .net>,
Dan Nuttle <d_******@hotmail.com> wrote:
My personal opinion about interview questions is that they should be
designed to indicate whether the person being interviewed can be a valuablemember of your team. So the only relevant criterion to be applied to anygiven question is, does it help to indicate whether the person being
interviewed can be a valuable member of your team?

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


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.

--
Er*********@sun.com

Jul 17 '05 #25

P: n/a
Liz wrote:
"Eric Sosman" <Er*********@sun.com> wrote in message
news:40**************@sun.com...

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.


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

--
Er*********@sun.com

Jul 17 '05 #26

P: n/a
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message news:<c8**********@bolt.sonic.net>...
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
Jul 17 '05 #27

P: n/a
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.
Jul 17 '05 #28

P: n/a
Sam
"Chris Uppal" <ch*********@metagnostic.REMOVE-THIS.org> wrote in message news:<j4********************@nildram.net>...
Chris Smith wrote:
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
Jul 17 '05 #29

P: n/a
Eric Sosman wrote:
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
Jul 17 '05 #30

P: n/a
Chris Smith wrote:
Eric Sosman wrote:
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..."


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 ;-)

--
Er*********@sun.com

Jul 17 '05 #31

P: n/a
Eric Sosman sez:
Chris Smith wrote:
Eric Sosman wrote:
.... 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 ...


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.


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
--
Sufficiently advanced incompetence is indistinguishable from malice.
Jul 17 '05 #32

P: n/a
On Tue, 18 May 2004 23:36:53 GMT, SP*********@BLOCKEDTOAVOIDSPAM.com
(Spammay Blockay) wrote:
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.
---------------------------------------------

MCheu
Jul 17 '05 #33

P: n/a
Spammay Blockay wrote:
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


Jul 17 '05 #34

P: n/a
Liz

"Paul Schmidt" <wo*******@yahoo.ca> wrote in message
news:_p*********************@news20.bellglobal.com ...
Spammay Blockay wrote:
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


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.
Jul 17 '05 #35

P: n/a
"Liz" <Li*@nospam.com> wrote in message news:ftBrc.7772$JC5.729348@attbi_s54...

"Paul Schmidt" <wo*******@yahoo.ca> wrote in message
news:_p*********************@news20.bellglobal.com ...
Spammay Blockay wrote:
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


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.
Jul 17 '05 #36

P: n/a
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?
Jul 17 '05 #37

P: n/a
In article <t9********************************@4ax.com>,
MCheu <mp****@yahoo.com> wrote:

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.


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


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

--

Jul 17 '05 #38

P: n/a
In article <_p*********************@news20.bellglobal.com>,
Paul Schmidt <wo*******@yahoo.ca> wrote:
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

--

Jul 17 '05 #39

P: n/a
In article <d6**************************@posting.google.com >,
Herman <he*******@hotmail.com> wrote:
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

--

Jul 17 '05 #40

P: n/a
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
Spammay Blockay wrote:
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


Jul 17 '05 #41

P: n/a

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

Spammay Blockay wrote:
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


Jul 17 '05 #42

P: n/a
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message news:<c8**********@bolt.sonic.net>...
In article <t9********************************@4ax.com>,
MCheu <mp****@yahoo.com> wrote:
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.


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


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.

-----------------
MCheu
Jul 17 '05 #43

P: n/a
SP*********@BLOCKEDTOAVOIDSPAM.com (Spammay Blockay) wrote in message news:<c8**********@bolt.sonic.net>...
The code must be syntactically correct, and would compile.

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
Jul 17 '05 #44

P: n/a
The world rejoiced as perry <pe***@cplusplus.org> wrote:
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/>
Jul 17 '05 #45

P: n/a
"perry" <pe***@cplusplus.org> wrote in message
news:oA********************@news20.bellglobal.com. ..

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

--
Tim Ward
Brett Ward Limited - www.brettward.co.uk
Jul 17 '05 #46

P: n/a
Tim Ward wrote:
"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.
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
Jul 17 '05 #47

P: n/a
In article <c8**********@bolt.sonic.net>,
SP*********@BLOCKEDTOAVOIDSPAM.com enlightened us with...

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.

--
--
~kaeli~
A bicycle can't stand on its own because it is two tired.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 17 '05 #48

P: n/a
In article <MP************************@nntp.lucent.com>,
kaeli <ti******@NOSPAM.comcast.net> wrote:
In article <c8**********@bolt.sonic.net>,
SP*********@BLOCKEDTOAVOIDSPAM.com enlightened us with...

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


If you apply to me for a job as a "Java Programmer", you'd better
know Java well, without syntax aids. If as a "C Programmer", the same
goes as well. I don't think that's too unusual.
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.


You sound offended or something... is that the case?
Anyway, if I were interviewing you and you mixed up syntax
between languages, but caught yourself and could tell me
what language syntax you were getting mixed up, that would be
fine, too.

- Tim

--

Jul 17 '05 #49

P: n/a
In article <c9**********@bolt.sonic.net>,
SP*********@BLOCKEDTOAVOIDSPAM.com enlightened us with...
In article <MP************************@nntp.lucent.com>,
kaeli <ti******@NOSPAM.comcast.net> wrote:
In article <c8**********@bolt.sonic.net>,
SP*********@BLOCKEDTOAVOIDSPAM.com enlightened us with...

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


If you apply to me for a job as a "Java Programmer", you'd better
know Java well, without syntax aids. If as a "C Programmer", the same
goes as well. I don't think that's too unusual.


Perhaps not that unusual. I myself am a "jack of all trades", so to
speak, and code in whatever language I need to code in. I fix other
people's mistakes and modify other people's code as well as make my own
if the situation warrants it. I built an entirely new order tracking
system, complete with database, in a language I'd never before used
because my customer wanted it done in that language (which was Java).
And I do mean *I* built it - no one else worked on it with me. I also
admin the servers the applications run on if I need to.
I don't consider myself a "Java Programmer". I consider myself a
computer applications programmer. I graduated with a B.S. in Comp Sci,
not Java.
I can learn syntax. It's really hard to teach someone how to program
well if they don't have the right education, mindset, aptitude, desire,
and intelligence. But you can surely teach a good programmer a new
language.
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.


You sound offended or something... is that the case?


Yes. I take exception to the implication that not memorizing syntax
makes people bad programmers. I consider myself an excellent programmer.
My code is stable, well-designed, "dies" well if the machine dies,
doesn't bring down the server if it has any exceptions, is organized,
easily modified, easily followed. Most importantly of all, my customers
are very happy with it.
There is much more to good programming than syntactically correct code.
Any compiler can catch syntax errors. It's those logic errors that will
kill you. Which you obviously know from your other posts.

I take no exception at all to your desire for a Java Programmer. ;)
I just really had a problem with that "good programmer" statement.
Sorry.

I'm going back to lurking and learning now. *grin*

--
--
~kaeli~
"No matter what happens, somebody will find a way to take
it too seriously."
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 17 '05 #50

54 Replies

This discussion thread is closed

Replies have been disabled for this discussion.