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

[Toby DiPasquale <toby@cbcg.net>]

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.

-- 
Toby DiPasquale
___________________________________________________________________________
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