«

"Default User" <> writes:
> Keith Thompson wrote:
>> (Richard Bos) writes:
>> > Keith Thompson <kst-> wrote:
>> >> "Default User" <> writes:
>> >> > Seebs wrote:
>> >> >> Sounds like a pretty bad interview question to me.
>> >> >
>> >> > Sounds like a terrific one to me. You can just get up, shake his
>> hand, >> > and leave without wasting any more of your time.
>> >>
>> >> Or you can tell the interviewer that it's a very silly thing to do,
>> >> and he can tell you that was the answer he was looking for.
>> >
>> > And then you can tell him that you'd prefer your employer not to be
>> > trying to set traps for his employees.
>> >
>> > Really, if you would do that to him, you'd never get hired. Why
>> > should he be allowed any more dishonesty than you?
>>
>> In a real job, you're likely to be faced with bad requirements.
>> As an interviewer, how would you judge an applicant's ability and
>> willingness to question such requirements?
>
> That's true, but irrelevant. The requirements in a real job should not
> be a deliberate trap to see what the reaction will be.

That doesn't answer the question. Being able to respond reasonably
to unreasonable requirements is a valuable skill. How do you test
that in the course of an interview?

And I wouldn't say this is necessarily a trap. If I were an
interviewer, I'd give the applicant some credit for giving a
reasonably good answer that conforms to the requirements. I'd give
even more credit for pointing out the problem with the requirements.

You could even phrase the question in a way that avoids any question
of dishonesty, such as "How would you respond to a requirement
like this?".

> In the given case, the applicant has no way of knowing a trap has been
> set. The best he or she can do is assume that this is a legitimate
> question. Given that assumption, then the only reasonable conclusion is
> that it's a clueless question that indicates a clueless interviewer,
> futher indicating a clueless organization.

The best he or she can do is *ask*.

> Like I said, get up and leave. Whether it's a dumb question or a trap
> doesn't matter.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:

> "Default User" <> writes:

> > That's true, but irrelevant. The requirements in a real job should
> > not be a deliberate trap to see what the reaction will be.
>
> That doesn't answer the question. Being able to respond reasonably
> to unreasonable requirements is a valuable skill. How do you test
> that in the course of an interview?

There's no indication that it's supposed to be an unreasonable
requirement. If you think it is, and the interviewer thinks it's just
dandy, then you fail anyway.

> And I wouldn't say this is necessarily a trap. If I were an
> interviewer, I'd give the applicant some credit for giving a
> reasonably good answer that conforms to the requirements. I'd give
> even more credit for pointing out the problem with the requirements.

The evidence at hand is that the interviewer is incompetent. You have
to assume a trap to come around to a competent interviewer. So either
it's a trap or the interviewer is unqualified to interview. Either way,
I'm out of there.



Brian


--
Day 401 of the "no grouchy usenet posts" project

On 2010-03-11, Default User <> wrote:
>
> The evidence at hand is that the interviewer is incompetent. You have
> to assume a trap to come around to a competent interviewer. So either
> it's a trap or the interviewer is unqualified to interview. Either way,
> I'm out of there.
>

I once had an employer ask if I knew Java, and the correct
answer (which I got) was "no". The company did a lot of
embedded development and he wanted to make sure I could
manage memory (or at least knew I was supposed to).

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

"Default User" <> writes:
> Keith Thompson wrote:
>> "Default User" <> writes:
>> > That's true, but irrelevant. The requirements in a real job should
>> > not be a deliberate trap to see what the reaction will be.
>>
>> That doesn't answer the question. Being able to respond reasonably
>> to unreasonable requirements is a valuable skill. How do you test
>> that in the course of an interview?
>
> There's no indication that it's supposed to be an unreasonable
> requirement.

I agree that, based on the limited information we have so far,
it's likely that the interviewer's question was bad, but not
deliberately so. To put it more harshly, the interviewer thought
it was a good question, but only because he was incompetent.

> If you think it is, and the interviewer thinks it's just
> dandy, then you fail anyway.

If I'm right and the interviewer is wrong, and I'm unable to convince
him of that, then yes, I lose. There's not much to be done about
that (unless you're willing to lie and tell the interviewer what
he wants to hear; I'm not).

>> And I wouldn't say this is necessarily a trap. If I were an
>> interviewer, I'd give the applicant some credit for giving a
>> reasonably good answer that conforms to the requirements. I'd give
>> even more credit for pointing out the problem with the requirements.
>
> The evidence at hand is that the interviewer is incompetent. You have
> to assume a trap to come around to a competent interviewer. So either
> it's a trap or the interviewer is unqualified to interview. Either way,
> I'm out of there.

Let's forget about this particular question for a moment.

In the real world, the ability to recognize bad requirements (and
to bring them to the attention of whoever generated them with
the goal of fixing them) is a valuable skill for a programmer.
You're typically not going to be asked to judge the quality of the
requirements; it's going to require some initiative. If you were
an interviewer, how would you test candidates for this ability?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:


> Let's forget about this particular question for a moment.
>
> In the real world, the ability to recognize bad requirements (and
> to bring them to the attention of whoever generated them with
> the goal of fixing them) is a valuable skill for a programmer.

Yes, but that normally consists of getting with the architech and the
requirements writer(s) and going over concerns.

> You're typically not going to be asked to judge the quality of the
> requirements; it's going to require some initiative. If you were
> an interviewer, how would you test candidates for this ability?

You'd present a list of requirements, and ask what the sort of
evaluation the programmer would do prior to starting the job. Ask for
any concerns with the requirements as shown and explanations of why
there would be a concern.

If you want to test something, test it. Don't hide it in another test.




Brian

--
Day 401 of the "no grouchy usenet posts" project