Don,
Thanks for your input, at least your are not making fun of my English.
You made it clear that driver work != Kernel work, which may not have been
obvious.
Although *I do concur* with most of the arguments in this thread.
Some companies, at least in my country, still uses debatable screening
questions -at least because of lack of time- knowingly taking the risk of
ruling out good people this way.
Far from perfect, the list I gave was gathered in the field from what people
asked me over the years (a very small subset) in the US&Europe for kernel
related jobs.
I found some of them useful from my small view of the world and wanted to
share with the group.
I used them as a guideline to fuel a discussion around os technology. (ex:
evolution of os architecture: os->micro k/subsystems->Vms?) when I happened
to do interviews.
This is not used to trick any candidate for sure but someone passionate
about this field will at least give some meaningful start of an answer to
some of them, if not for giving a clue for the level of coaching needed.
For what it seems a hideous data structure question, I certainly don’t ask
for a ‘Knuth’-full proof of a ‘name-your’-tree complexity, nor sample code
to design but some never heard of O() complexity nor can give at least the
name of advanced data structure, being old fashion, deciding of linear or
log implementation or just to know what is the property of an np-complete pb
is relevant, I think.
Have a good day.
Jerome.
“Don Burn” wrote in message news:xxxxx@ntdev…
> Jerome,
>
> As I stated in my earlier post, limiting things to non-driver
> specific means problems, see comments inline:
>
> “jchristatos” wrote in message
news:xxxxx@ntdev…
…
> > What is a windows subsystem? (Native vs Win32 ? why does it exist?) can
> > lead
> > to discussion with Virtual machines.
>
> What the h**k do virtual machine have to do with driver writing, sorry I
> > Recursion removal strategy (why is it bad in drivers)
>
> Sorry, a UMDF driver does not care, nor a user mode printer driver. So
you
> can’t go there unless you say you are driver specific.
>
> > memory access optimization (tiling…)
>
> Again, UMDF or mini-ports and some other things do not care it is hidden
> from them.
>
> > C compilation steps.
>
> Are you talking about BUILD or compiler / linker internals here? If BUILD
> maybe but be careful, since this has changed from rev to rev, and things
> like PreFast and SDV are not relavent to all drivers.
>
> > Security (token, SID…)
>
> Why, sorry this is specific to driver which can get at IRP’s
>
> > Cache Manager/VM interactions.
>
> I did not know that writing file systems which is where this is relavent
was
> required for all driver types.
>
> > Boot process description, Exec load process (what is the c-runtime,
> > pagefault handling),
>
> Again, you can be a good driver writer and probably not care.
>
> > Shared library (imports, rva…)
>
> Are we talking compilers/linker or driver here? Most driver writers have
no
> reason to know this?
>
> > Give your debugging strategies/support.(Bsod debug howto)
>
> This is highly dependant on driver type, again user mode has differing
> concens than kernel mode, which has differnces in the classes of driver.
>
> > Give 3 examples of filter drivers.
>
> Again, you are thinking WDM there are a heck of a lot of people who don’t
> need to deal with filters.
>
> > Give n links to internet/blog related sites.
>
> Good one, I do ask this, unfortunately I use to see if people think
certain
> sites are good, so I can appologize and say I have a meeting that will
make
> the interview short (to get rid of the loser). You may have a different
> view of those sites.
>
> > Describe advanced Data structure implementation (B-tree, …), give O()
> > properties.
>
> THE LAST TIME A POTENTIAL CLIENT ASKED ME THIS CRAP, I POINTED OUT THAT
WAS
> WHAT REFERENCE BOOKS WERE FOR, AND WALKED OUT. I did consult for them in
> the end, but upped my rates because they wasted my time with stupidity
like
> above.
>
> >
> > Should quickly give a grasp of the field by the candidate I guess, I
have
> > plenty more.
> >
>
> Sorry, what you are saying is these are relavent to your limited view of
> device drivers, the world is a lot broaded. This discussion did lead to
> one good question “What are some simple things that all driver writers no
> matter what their specialty should know?” If they try to answer the
> question with anything other than a description why this is impossible,
then
> you can probably say they are not an expert.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>