A single interview question

S

Stefan Ram

An »experienced Java developer« is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

What would that question be?

Here's my question.

Feel free to try to answer it without looking up a reference.

I believe that it does not appear on any public list of
interview questions and most beginners will not know the
answer while experienced Java programmers should know the
answer.

Mark all JavaDoc parameter descriptions from the
following list that are in perfect accordance with
Sun's current recommendations.

@param text the text of the tool tip
@param text The text of the tool tip
@param text the text of the tool tip.
@param text The text of the tool tip.

The idea is that every experienced programm will have
encountered the situation of writing or modifying the
documentation for a parameter many times. So he will have
looked up how to do this once and now know it by heart.

(OK, it might be that he does have written in many times, but
never cared to learn how to do it. So, I assume that someone
who cares is wanted.)
 
D

Daniel Dyer

An »experienced Java developer« is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

What would that question be?

One question is never enough. At what level do you pitch the question? I
try to always ensure that people who claim to be Java programmers at least
understand the requirements for equals and hashcode. I don't want to have
to fix their bugs.
Here's my question.

Feel free to try to answer it without looking up a reference.

I had read Sun's recommendations on this a long time ago. I was able to
narrow it down to 1 of 2 but I wasn't certain which one it was. Neither
of which are the way that I actually write my Javadoc comments.
The idea is that every experienced programm will have
encountered the situation of writing or modifying the
documentation for a parameter many times. So he will have
looked up how to do this once and now know it by heart.

(OK, it might be that he does have written in many times, but
never cared to learn how to do it. So, I assume that someone
who cares is wanted.)

I don't follow Sun's guidelines on brace-placement, so why should I care
about their opinions on my comments? I know from code that you have
posted previously that you also have your own unconvential code formatting
style, so why do you care about this particular recommendation?

Dan.
 
A

Arne Vajhøj

Stefan said:
An »experienced Java developer« is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

What would that question be?

Some open ended question where the applicant come
can come with some pro and con's. The important is not
what he thinks, but whether the argumentation makes sense
and cover some of the relevant alternatives.

Examples:
- what is your preferred way of persisting data and
why do you prefer it over alternatives
- which patterns to you use, which do you never use
and why

Get him (or her !) talking. Ask a few questions in between to
make sure that it is not just memorized but really understood.
Here's my question.
Mark all JavaDoc parameter descriptions from the
following list that are in perfect accordance with
Sun's current recommendations.

@param text the text of the tool tip
@param text The text of the tool tip
@param text the text of the tool tip.
@param text The text of the tool tip.

You will get someone that is good at writing JavaDoc for
sure, but that does not guarantee an experienced developer.

Arne
 
S

Stefan Ram

Daniel Dyer said:
I don't follow Sun's guidelines on brace-placement, so why should I care
about their opinions on my comments? I know from code that you have
posted previously that you also have your own unconvential code formatting
style, so why do you care about this particular recommendation?

I want to follow the recommendations of Sun
as far as possible and as I am aware of them.

The bracing style is an exception, because I
have a strong dislike of their style.

But regarding most other recommandations I have
no such strong preference of my own and are grateful
for a guideline.
 
P

Patricia Shanahan

Stefan said:
An »experienced Java developer« is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

What would that question be?

Generally, as an interviewer I'm trying to test two things:

1. Is the resume reasonably accurate?

2. Can the candidate discuss design issues clearly?

I would not be interviewing the candidate if the resume did not imply
the right programming skills for the job.

I usually pick a couple of fairly arbitrary items from their claimed
previous work and ask them to discuss some of the design issues they
encountered, and how they resolved them. The objective is to get into a
design discussion.

If I were limited to one question I would have to pick one previous
project, but I think it is better, if possible, to discuss a couple of them.

Patricia
 
L

Lasse Reichstein Nielsen

I believe that it does not appear on any public list of
interview questions and most beginners will not know the
answer while experienced Java programmers should know the
answer.

Mark all JavaDoc parameter descriptions from the
following list that are in perfect accordance with
Sun's current recommendations.

@param text the text of the tool tip
@param text The text of the tool tip
@param text the text of the tool tip.
@param text The text of the tool tip.

I have no idea what Sun's recommendation is. I know what the format is
on the project I'm working on.

Also, someone might be able to answer this question while not being
able to program their way out of a wet paper bag. If you only get one
question, I'd go for something that is actually about programming.

/L
 
S

Stefan Ram

Lasse Reichstein Nielsen said:
Also, someone might be able to answer this question while not
being able to program their way out of a wet paper bag.

It's about the probability that this will happen. There is
always a chance that an interview might be misleading about
future performance.

To get out of a wet paper bag, I'd start with a breadth-first
search (using an XO as hardware to cope with the wetness).
If that does not find a way out after a certain time, I would
switch to a brute-force algorithm.
 
P

Patricia Shanahan

Stefan said:
It's about the probability that this will happen. There is
always a chance that an interview might be misleading about
future performance.

You would reject me as a job candidate, based on my lack of Java
knowledge, and accept someone straight out of their first Java
programming class who happens to have studied Sun's programming
standards last week.

Patricia
 
L

Lew

Stefan said:
I want to follow the recommendations of Sun
as far as possible and as I am aware of them.

The bracing style is an exception, because I
have a strong dislike of their style.

But regarding most other recommandations I have
no such strong preference of my own and are grateful
for a guideline.

I agree that initial-brace placement is "wrong" in Sun's guidelines, but there
is a deeper reason to follow Javadoc conventions. The placement or absence of
a period, the presence or absence of a capitalized first word of a description
- these things affect how Javadoc produces its output.
 
L

Lew

Patricia said:
I would not be interviewing the candidate if the resume did not imply
the right programming skills for the job.

I usually pick a couple of fairly arbitrary items from their claimed
previous work and ask them to discuss some of the design issues they
encountered, and how they resolved them. The objective is to get into a
design discussion.

If I were limited to one question I would have to pick one previous
project, but I think it is better, if possible, to discuss a couple of
them.

An interviewer once posed me a hypothetical: "You bought a VCR, then foolishly
threw away the receipt and box, before deciding you didn't want to keep it.
What do you do about that?"

I said, "If I can't gift it to a friend, I'll donate it to charity and take
the write-off."

He went nuts with excitement. Seems in all the interview-question seminars
he'd attended devoted to that question, the notion of a charitable donation
had never come up.

Meanwhile, I'm thinking, "Interview-question seminars?"
 
G

Gordon Beaton

An »experienced Java developer« is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

I've never been asked technical questions at any interview.

On the other hand, I get asked about various projects I've been part
of, what my roll in those projects was, whether I considered them to
be success or failures, how I define those concepts, why I think the
failed projects failed, and what I might have done differently.

My impression is that the technical stuff is only a small part. On the
other hand, the ability to work together with others in a team and fit
in is more important, harder to learn, and will end up costing the
company more if I lack those skills than if I lacked programming
skills.

/gordon

--
 
L

Lew

Gordon said:
I've never been asked technical questions at any interview.

On the other hand, I get asked about various projects I've been part
of, what my roll in those projects was, whether I considered them to
be success or failures, how I define those concepts, why I think the
failed projects failed, and what I might have done differently.

My impression is that the technical stuff is only a small part. On the
other hand, the ability to work together with others in a team and fit
in is more important, harder to learn, and will end up costing the
company more if I lack those skills than if I lacked programming
skills.

OTOH, as a programmer I've worked with lots of teammates who had great people
skills but were bad programmers. I'd prefer the reverse. I believe that
unless the person is a psycho their programming skills will most definitely
harm the company if they're lacking.

Would you take skydiving lessons from a very charismatic instructor who didn't
pack your chute correctly?
 
L

Lew

Lew said:
unless the person is a psycho their programming skills will
most definitely harm the company if they're lacking.

Unless they're a psycho their people skills will not prevent harm if the
programming skills are lacking.

Not, "A psycho with bad programming skills will be all right."
 
L

Lew

Lew said:
Unless they're a psycho their people skills will not prevent harm if the
programming skills are lacking.

Not, "A psycho with bad programming skills will be all right."

Darn it. My sentences aren't saying what I mean. I mean a good programmer
even with bad people skills won't harm the company unless the bad people
skills are to a point of distinct harm.

Naturally you want a competent programmer with competent people skills. (Like
being able to formulate a sentence that expresses his intent.)
 
G

Gordon Beaton

OTOH, as a programmer I've worked with lots of teammates who had
great people skills but were bad programmers. I'd prefer the
reverse. I believe that unless the person is a psycho their
programming skills will most definitely harm the company if they're
lacking.

Would you take skydiving lessons from a very charismatic instructor
who didn't pack your chute correctly?

No, but the company is not taking that kind of risk every time they
hire someone. Given two experienced candidates I'd probably choose the
one I got along with best.

I'm not saying that programming skills are unimportant, only that
those who have interviewed me have chosen to focus on team skills at
the interview. Maybe they can see from my CV that I probably have
"sufficient" programming skills.

Or maybe it's just a Swedish thing, or it reflects on the type of
companies I like to work for, or maybe it has to do with the ability
to learn people skills as compared to programming skills, or the
testability of these things in an interview situation.

I've worked on projects with people who really were a liability due to
their inability to work as a team member, despite apparently brilliant
programming skills. I once petitioned to have someone removed from a
project in order to avoid failure, and I heard that he was later fired
as a result of being kicked out of another project for a similar
reason.

Not every project member needs to be a star programmer, but they all
need to be able to work together.

/gordon

--
 
J

Joe Attardi

Stefan said:
Mark all JavaDoc parameter descriptions from the
following list that are in perfect accordance with
Sun's current recommendations.

What a horrific, and useless, question to ask at an interview.
Especially if this is your one and only question!

What does the memorization of an arbitrary section of a guideline have
to do with their programming skills?
 
P

Patricia Shanahan

Joe said:
What a horrific, and useless, question to ask at an interview.
Especially if this is your one and only question!

What does the memorization of an arbitrary section of a guideline have
to do with their programming skills?

For Stefan, at least, this question might serve as a way of eliminating
any applicant without basic initiative and Google skills. The base
article of this thread is now the first Google hit for:

"stefan ram" interview

Patricia
 
L

Lew

Gordon said:
I'm not saying that programming skills are unimportant, only that
those who have interviewed me have chosen to focus on team skills at
the interview. Maybe they can see from my CV that I probably have
"sufficient" programming skills.

Your points are well taken. The bottom line seems to be that a good
programmer has to have both good programming skills /and/ good people skills.
Either one's lack can torpedo a project.
I've worked on projects with people who really were a liability due to
their inability to work as a team member, despite apparently brilliant
programming skills.

What I was referring to, however, wasn't the kind of saboteur-level badness
you describe, but the more usual social awkwardness so many engineers evince.
I do not think it necessary for a programmer to be another Dale Carnegie,
only that they be fully committed to the team's goals and not hostile. It
doesn't take a diplomat to be a good team member.

There is a middle ground. Blunt, sometimes rude people who speak truth for
the good of the project are an asset, even if they ruffle feathers. Perhaps
especially if. OTOH, saboteurs, bullies and s**theads must go. A person must
be willing to work with the team; I would forgive a lot of social ills given
that basic commitment. Unwillingness to support the common weal is a sin on a
team.
 
C

christopher

An >>experienced Java developer<< is to be hired.

You may ask him just one question to estimate how
much experience he has with Java.

What would that question be?

Here's my question.

Feel free to try to answer it without looking up a reference.

I believe that it does not appear on any public list of
interview questions and most beginners will not know the
answer while experienced Java programmers should know the
answer.

Mark all JavaDoc parameter descriptions from the
following list that are in perfect accordance with
Sun's current recommendations.

@param text the text of the tool tip
@param text The text of the tool tip
@param text the text of the tool tip.
@param text The text of the tool tip.

The idea is that every experienced programm will have
encountered the situation of writing or modifying the
documentation for a parameter many times. So he will have
looked up how to do this once and now know it by heart.
I have experience from java 1.8.8 -- what's that, 15 years? I am
currently employed as Technology Director in a startup company, and I
code daily (its a small company!). I have never *once* used javadoc.
Your logic is flawed, and your real world experience questionable.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top