Re: [PLUG] OT (but not really): Tough Interview questions

["K.S. Bhaskar" <ksbhaskar@gmail.com>]

On Wed, Feb 11, 2009 at 10:19 AM, Toby DiPasquale <toby@cbcg.net> wrote:
> On Wed, Feb 11, 2009 at 9:55 AM, K.S. Bhaskar <ksbhaskar@gmail.com> wrote:
>>> Having said all that, this is a spectacularly dumb question to ask.
>>
>> [KSB] Why is it a dumb question?  [More below.]
>
> Because: what does it tell you if the candidate doesn't know the
> answer? Is he unable to compile code or call executables if he doesn't
> know how many sections are in an ELF header? No. Unless you're writing
> a linker, you just don't need to know this.
>
> Since you're obviously gainfully employed and presumably are doing a
> good job, tell me this without looking it up: which section of the ELF
> header contains uninitialized static data? See what I mean? This has
> nothing to do with your job and even if it did, you'd just look it up
> and move on.
>
>> [KSB] The fact that a question has many levels is actually good.  In
>> an interview (I am an interviewer more than I am an interviewee), I
>> like to drill down to see how much a candidate really knows.  One of
>> my favorite questions is "What is a legitimate use of recursion?"  A
>> good interview question is one that allows the candidate to ask
>> questions back, and to be the basis of a discussion that allows the
>> interviewer and candidate to get deeper and deeper into a discussion
>> until one of them hits bottom or the interviewer decides s/he has
>> learned enough to make a decision.
>
> Why would you care about how much he knows? To me, this misses the
> point of interviewing. You're not hiring a candidate for his current
> knowledge; you're hiring them for their ability to do the job you're
> asking them to do. This requires a lot less up-front knowledge and a
> lot more capacity for learning, team skills and problem solving
> abilities than most interviews can ever hope to capture accurately. If
> current knowledgebase mattered for anything, you'd never hire anyone
> out of college.
>
>> A good interview should allow the interviewer to decide whether the
>> candidate is worth investing more time pursuing and should be relevant
>> to the job so that the candidate can decide whether the opportunity is
>> worth investing further time pursuing.
>
> Yes, that's definitely true. Unfortunately, asking arcane,
> know-it-or-you-don't questions doesn't tell me whether or not I should
> invest more time. It just tells me how many textbooks or man pages the
> guy's memorized. Maybe it tells you something, but it doesn't tell me
> anything.
>
>> To that end, good questions are not those with cut and dried answers,
>> but open ended questions where the answers involve making intelligent
>> choices and have opportunities for discussion about issues.  If I were
>> interviewing someone for a sysadmin position, I would probably ask
>> about backup strategies or securing systems.
>
> Again, I agree, and those would be good questions to ask. But what you
> should not ask is how WAFL works or something similar because those
> kinds of questions aren't pertinent a) to their work, or (more
> importantly), b) whether or not they can do the job.

[KSB2] I think you are missing the point.  Good interview questions
are not know-it-or-you-don't questions.  They are segues into
discussions where a good interviewer can not only appreciate what a
candidate knows but also how a candidate thinks and reasons.  To that
end, a question on the ELF format could and should lead into a
discussion on why object file formats are needed, what is important
about object file formats, what are the factors to be considered in
choosing object file formats (and why).  It could lead into a
discussion about how processes load and execute object code, or
perhaps how operating systems are bootstrapped.  [Presumably the
question is for a system software developer position.]

Yes, I am currently gainfully employed.  But in the course of my
career, I have interviewed (I estimate) close to a thousand people.  I
have been interviewed between fifty and a hundred times, and I have
hired somewhere between fifty and a hundred software professionals.  I
speak from experience.

Let me share a story.  I started up a software engineering department
in the Boston area in 1992/93 when DEC was laying people off by the
tens of thousands and the technical job market was *much* worse than
it is now.  HR ran an ad in the Sunday Boston Globe, and received a
thousand resumes - yes a thousand resumes, but the advertisement was
not just for my department - in response.  I didn't hire a single one.
 A few weeks later, I ran an advertisement giving my interview
questions, and pulled in exactly the type of people I wanted.  There
were still about 200 resumes to go through, but it was a lot more
productive for me as well as for those I interviewed.*  The moral of
the story is that a good interview question is a good interview
question even when the candidate knows the question before walking
into the interview.

Cheers
-- Bhaskar

* I did have one candidate whom, when we started into the interviews
exclaimed in shock and surprise, "You're asking questions from the
advertisement.  I don't know!"  I showed him the door about five
minutes into our conversation.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug