Prev: Udating public devmode with IPrintOemDriverUI::DrvUpdateUISetting
Next: How to capture avshws(AVStream sample)
From: Pavel A. on 22 Jun 2005 22:04
Hello all,

An unusual question this time...
The Boss wants me to invent a few tests for our job interviews.
Test tasks should be doable in 1.5-2.5 hours.
For the driver jobs, he wants the candidate to write a little driver...

But if he would begin from nothing, this would take lot of time only to type in all the boilerplate code.
So I'd rather let him start with a ready, "live" driver (maybe a DDK sample)
and ask to add something, or find a bug.

Using some real hardware would be great - if it won't take > 15 minutes to learn.
Also the tasks should not require knowledge of all the tiny details of
specific device classes such as HID, NDIS or storage (unless we're looking
for somebody with exactly this experience).

Dear Experts, can you suggest little tasks suitable for interview, that demonstrate
common kernel mode skills or just common sense and intelligence?
What sort of interview tasks do you use in your company?

Thanks in advance,
-- PA



From: cristalink on 22 Jun 2005 22:36
I would ask the candidate a basic theoretical question, like what's the
difference between a mutex, fast mutex, unsafe fast mutex, and guarded mutex
(btw, the answer is here
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/synch_table.doc).

Then I would offer a practical test, say, given a unicode_string directory
name with or without the terminating backslash, append a unicode_string file
name. 2.5 hours should be enough to do the job right.

--
http://www.cristalink.com


"Pavel A." <pavel_a(a)NOwritemeNO.com> wrote in message
news:%23dTmRh5dFHA.688(a)TK2MSFTNGP14.phx.gbl...
> Hello all,
>
> An unusual question this time...
> The Boss wants me to invent a few tests for our job interviews.
> Test tasks should be doable in 1.5-2.5 hours.
> For the driver jobs, he wants the candidate to write a little driver...
>
> But if he would begin from nothing, this would take lot of time only to
> type in all the boilerplate code.
> So I'd rather let him start with a ready, "live" driver (maybe a DDK
> sample)
> and ask to add something, or find a bug.
>
> Using some real hardware would be great - if it won't take > 15 minutes to
> learn.
> Also the tasks should not require knowledge of all the tiny details of
> specific device classes such as HID, NDIS or storage (unless we're
> looking
> for somebody with exactly this experience).
>
> Dear Experts, can you suggest little tasks suitable for interview, that
> demonstrate
> common kernel mode skills or just common sense and intelligence?
> What sort of interview tasks do you use in your company?
>
> Thanks in advance,
> -- PA
>
>
>


From: Gary G. Little on 23 Jun 2005 10:42
This is purely personal opinion but ... that kind of testing in a job
interview is pure bovine scatology. First, you're placing the individula in
one of the most stressfull circumstances there is, and it is amazing exaclty
what can be forgotten by an individual in that kind of situation. You may
pass up an extremely brilliant and consiencious engineer simply because in
the heat of battle all the adrenaline erased the memory of what "&=" means in
C.

Ask the interviewee to bring "clean" examples of their code, and possibly
ask for specifics on using spinlocks or maybe even threads. Have an interview
panel that questions them on programming knowledge, driver competency, and
look for understanding of concepts but not buzzword usage. Taking a test, or
writing driver code in the interview? No.

I don't know about anyone else, but I would shake your hand, politely say
"No thanks" and walk out the door.

The personal opinion of
Gary G. Little

"Pavel A." wrote:

> Hello all,
>
> An unusual question this time...
> The Boss wants me to invent a few tests for our job interviews.
> Test tasks should be doable in 1.5-2.5 hours.
> For the driver jobs, he wants the candidate to write a little driver...
>
> But if he would begin from nothing, this would take lot of time only to type in all the boilerplate code.
> So I'd rather let him start with a ready, "live" driver (maybe a DDK sample)
> and ask to add something, or find a bug.
>
> Using some real hardware would be great - if it won't take > 15 minutes to learn.
> Also the tasks should not require knowledge of all the tiny details of
> specific device classes such as HID, NDIS or storage (unless we're looking
> for somebody with exactly this experience).
>
> Dear Experts, can you suggest little tasks suitable for interview, that demonstrate
> common kernel mode skills or just common sense and intelligence?
> What sort of interview tasks do you use in your company?
>
> Thanks in advance,
> -- PA
>
>
>
>
From: Ray Trent on 23 Jun 2005 12:11
Gary G. Little wrote:
> This is purely personal opinion but ... that kind of testing in a job
> interview is pure bovine scatology. First, you're placing the individula in
> one of the most stressfull circumstances there is, and it is amazing exaclty
> what can be forgotten by an individual in that kind of situation. You may
> pass up an extremely brilliant and consiencious engineer simply because in
> the heat of battle all the adrenaline erased the memory of what "&=" means in

Of course, there *are* programming job positions (even in the driver
arena) where the ability to think on your feet in incredibly stressful
situations is an absolute job requirement (perhaps even the primary one).

Usually these tend to be more in maintenance positions rather than
development positions, but it can be useful to stress candidates if
that's what you really need. Gary's right, though, if that's not what
you're looking for, it's not the best approach.

If you want a test of significant scope, it would be better to give them
a "homework" task that allows them to design something at their own
pace. This has the added bonus of gauging their interest. If you're
worried about "cheating", ask yourself what you really care about. If
they have external resources that allow them to complete the kinds of
tasks they'll be assigned, isn't that worth considering? And besides,
you can usually detect that by asking them to explain their thought
processes, etc. during a second round interview.

In any event, asking us for an appropriate task is fairly useless. We
know nothing about your requirements or even technical/business area.

As a general rule, I find it useful to find a programming question you
can ask every candidate in exactly the same way so that you can judge
differences between them accurately over time. My personal opinion is
that it's best to ask a programmer to implement some fairly small
function that would be relevant to (though probably not exactly
representative of) the work they would be doing.

The best examples of this will be easy to answer at least *correctly*
while standing at a white board if they're even half-way competent (you
need this because it's hard to measure someone on a scale that only goes
from 9.9-10.0), but possible to answer really well only if you're really
good. The question needs to have some depth to it, so spend some time
finding a good one, figuring out what you would consider to be an
optimal solution, what the failure modes are, etc. "Trick" questions
aren't at all useful.

The question should probably have several different solutions of
differing qualities. I've gotten at least 28 unique, distinct, correct
(though sometimes really atrociously bad) answers to the question I most
typically use (what is it? That would be telling :-).

I would suggest that you not pay attention to the details of syntax,
variable naming, style, etc., etc. in this kind of task (those are
better analyzed based on a code sample). Those are useful things, but
they're the easiest to forget or gloss over under stress, and the
easiest fix if there's a problem. I usually even tell the candidate to
implement it in whatever language they're most comfortable in (that by
itself can be quite revealing).

The stuff to look for is thought process: How do they approach the
problem? Do they understand the underlying concepts that are needed to
solve it? Do they get a conceptually correct answer? How many "hints" do
they need (usually you'll need to clarify your question this way... how
much clarification and what kinds of clarification they ask for can be
quite illuminating)? Do they think about verification of their answer?
If so, do they approach unit testing in a sensible way (e.g. are their
test cases good ones)? I could do on, but you get the point.

On another note, the most useful general interviewing rule I've found in
my many years of interviewing people is this: depth, not breadth. Find
one fairly generic question (even if it's the old saw "what's your most
significant accomplishment), but once they've given you the "typical
interview answer" drill down for details, details, details. Make it an
inquisition (though a nice, friendly one :-).

How did they solve that problem? What did they have to learn to solve
it? Who did they have to work with? What did you find exciting about
that task? How did they interact with that team? How did they organize
their work on that problem? What was the architecture of the solution?
How did that architecture pan out during development? How did they
manage stress during the effort?

I've only started to scratch the surface here... make a list of things
to dig into about that one generic question. They should be things your
organization cares about (motivation, technical ability, and team skills
are almost always the top three). The list should probably be at least
20 items long. Don't get wedded to it, though, that's just a guideline
to keep you on track... you're going to have to mold the interrogation
around the answers you get.

People can prepare for and fake almost any broad typical interview
question. In fact, the worst candidates will probably be the best
prepared in this way and will have the most slick answers. However, they
can't fake depth on any one particular thing you choose to narrow down
on. Depth can only come from an actual memorable experience and having
reflected on and learned from it.

Once you get a sufficiently deep answer, ask for their *second* most
significant accomplishment (or whatever your generic question was), and
drill down on that. While it's quite unlikely that someone can prepare
for one in-depth inquisition, it's very nearly impossible to do it for 2
or more.
--
.../ray\..
From: cristalink on 23 Jun 2005 17:37
<<<How did they solve that problem? What did they have to learn to solve
it? Who did they have to work with? What did you find exciting about
that task? How did they interact with that team? How did they organize
their work on that problem? What was the architecture of the solution?
How did that architecture pan out during development? How did they
manage stress during the effort?>>

I was always wondering what are the right answers to this sort of questions.
Apparently these can only help to sort out mentally unwell people, but I
guess there are better ways.

>> How did they interact with that team
- Verbally and in writing. Sometimes they employed the body language.

>> How did they manage stress
- Drank vodka and took antidepressants
- Went door-to-door to collect donations for needy families
- etc.




"Ray Trent" <rat(a)nospam.nospam> wrote in message
news:uKR6u3AeFHA.2960(a)TK2MSFTNGP10.phx.gbl...
> Gary G. Little wrote:
>> This is purely personal opinion but ... that kind of testing in a job
>> interview is pure bovine scatology. First, you're placing the individula
>> in one of the most stressfull circumstances there is, and it is amazing
>> exaclty what can be forgotten by an individual in that kind of situation.
>> You may pass up an extremely brilliant and consiencious engineer simply
>> because in the heat of battle all the adrenaline erased the memory of
>> what "&=" means in
>
> Of course, there *are* programming job positions (even in the driver
> arena) where the ability to think on your feet in incredibly stressful
> situations is an absolute job requirement (perhaps even the primary one).
>
> Usually these tend to be more in maintenance positions rather than
> development positions, but it can be useful to stress candidates if that's
> what you really need. Gary's right, though, if that's not what you're
> looking for, it's not the best approach.
>
> If you want a test of significant scope, it would be better to give them a
> "homework" task that allows them to design something at their own pace.
> This has the added bonus of gauging their interest. If you're worried
> about "cheating", ask yourself what you really care about. If they have
> external resources that allow them to complete the kinds of tasks they'll
> be assigned, isn't that worth considering? And besides, you can usually
> detect that by asking them to explain their thought processes, etc. during
> a second round interview.
>
> In any event, asking us for an appropriate task is fairly useless. We know
> nothing about your requirements or even technical/business area.
>
> As a general rule, I find it useful to find a programming question you can
> ask every candidate in exactly the same way so that you can judge
> differences between them accurately over time. My personal opinion is that
> it's best to ask a programmer to implement some fairly small function that
> would be relevant to (though probably not exactly representative of) the
> work they would be doing.
>
> The best examples of this will be easy to answer at least *correctly*
> while standing at a white board if they're even half-way competent (you
> need this because it's hard to measure someone on a scale that only goes
> from 9.9-10.0), but possible to answer really well only if you're really
> good. The question needs to have some depth to it, so spend some time
> finding a good one, figuring out what you would consider to be an optimal
> solution, what the failure modes are, etc. "Trick" questions aren't at all
> useful.
>
> The question should probably have several different solutions of differing
> qualities. I've gotten at least 28 unique, distinct, correct (though
> sometimes really atrociously bad) answers to the question I most typically
> use (what is it? That would be telling :-).
>
> I would suggest that you not pay attention to the details of syntax,
> variable naming, style, etc., etc. in this kind of task (those are better
> analyzed based on a code sample). Those are useful things, but they're the
> easiest to forget or gloss over under stress, and the easiest fix if
> there's a problem. I usually even tell the candidate to implement it in
> whatever language they're most comfortable in (that by itself can be quite
> revealing).
>
> The stuff to look for is thought process: How do they approach the
> problem? Do they understand the underlying concepts that are needed to
> solve it? Do they get a conceptually correct answer? How many "hints" do
> they need (usually you'll need to clarify your question this way... how
> much clarification and what kinds of clarification they ask for can be
> quite illuminating)? Do they think about verification of their answer? If
> so, do they approach unit testing in a sensible way (e.g. are their test
> cases good ones)? I could do on, but you get the point.
>
> On another note, the most useful general interviewing rule I've found in
> my many years of interviewing people is this: depth, not breadth. Find one
> fairly generic question (even if it's the old saw "what's your most
> significant accomplishment), but once they've given you the "typical
> interview answer" drill down for details, details, details. Make it an
> inquisition (though a nice, friendly one :-).
>
> How did they solve that problem? What did they have to learn to solve it?
> Who did they have to work with? What did you find exciting about that
> task? How did they interact with that team? How did they organize their
> work on that problem? What was the architecture of the solution? How did
> that architecture pan out during development? How did they manage stress
> during the effort?
>
> I've only started to scratch the surface here... make a list of things to
> dig into about that one generic question. They should be things your
> organization cares about (motivation, technical ability, and team skills
> are almost always the top three). The list should probably be at least 20
> items long. Don't get wedded to it, though, that's just a guideline to
> keep you on track... you're going to have to mold the interrogation around
> the answers you get.
>
> People can prepare for and fake almost any broad typical interview
> question. In fact, the worst candidates will probably be the best prepared
> in this way and will have the most slick answers. However, they can't fake
> depth on any one particular thing you choose to narrow down on. Depth can
> only come from an actual memorable experience and having reflected on and
> learned from it.
>
> Once you get a sufficiently deep answer, ask for their *second* most
> significant accomplishment (or whatever your generic question was), and
> drill down on that. While it's quite unlikely that someone can prepare for
> one in-depth inquisition, it's very nearly impossible to do it for 2 or
> more.
> --
> ../ray\..





 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Udating public devmode with IPrintOemDriverUI::DrvUpdateUISetting
Next: How to capture avshws(AVStream sample)