LOL. I'd say it's more like watching 6 people describe a
"wibble", where none of them has been told what a "wibble" actually is
:)
As per most responses here (or at least what we *should*
respond with) - "it depends".
I'd still argue that there's little value in asking very
specific in depth technical questions - that's more of a memory test than
anything else. I'd rather ask questions that help the candidate show me what
he/she *can* do and do know rather than what they cannot do or do not
know.
I agree that a slightly aggressive approach is useful to
determine how the candidate performs under pressure - I would suggest you fore
warn the candidate they are going to receive a tech grilling - most won't expect
that and so will be rocked onto the back foot when it happens
:)
Another 2 penneth,
neil
I have to laugh. This thread is starting to sound like the six blind
men describing an elephant.
As was mentioned, it is very hard to find somebody who can do the
high-level design at all 8 layers, manage a staff of people, and still fit that
into a 23 hour day. If you find one, keep him or her. If you don't find one,
don't be terribly disappointed; look for one that's close and has the right
personality to be made into one. There's plenty more of those, but be sure
you're ready to keep him/her later because there are others looking for that
type of person :)
FWIW, I think interviewing wtih Brian might be a laugh. Can you
answer all the questions? Nope. Not every one. But you can still
enjoy it and I think Neil was wise enough to mention that, "no, I don't know it
all but I do know how to use a book" :) (ok, so I paraphrased. The
point is that you use it or lose it. But knowing what questions to ask and
where to find the answers is far more resilient than knowing everything there is
to know about a product set on a given day. Most of the players on the
team that wrote the application or product don't know either. But they do
know where to go for the answers....)
One thing that does come to mind would be to follow Brian's advice and ask
open ended questions. Those are going to be the hardest because you're not
going to be able to study for that. You'll have to walk through it under the
pressure of an interview. That will tell the interviewer a lot about the
person and what they would do 6 months from now when the technology is totally
different and how they would deal with your unique situations.
Best of luck in you hiring endeavors. I for one am interested to hear a
follow up in a few months to hear how it went.
Al
On 7/24/06, Ken
Schaefer <[EMAIL PROTECTED]> wrote:
I suppose there are several "roles"
that senior people could hold: some are managerial, some are architectural,
and some are deeply technical (i.e. high level support). Architects, in that
taxonomy, would do design work. Whereas a PSS engineer would probably spend
more time with a debugger than using Word and Visio to produce high-level
designs.
Cheers
Ken
Subject: RE: [ActiveDir] OT: Interview
Techniques
A senior guy IMO should be more
focused on "design" aspects than "support" and thus should be able to answer
questions along the line of:
"How would you design
a schema change process, encompassing initial request through to
implementation."
The answer to the above should
help determine alot of info from that person (see below) - even if they cannot
answer the question fully.
- Does this person think
logically
- Does this person explain
ideas in a cohesive manner
- Does this person answer
questions with fluff and BS or are they succinct
- etc
To answer 'what do the FSMOs
do?' one can simply state - "I'd look it up in a book". I'd therefore always
try to ask questions which can only be answered through experience (where
possible) and not just through reading a book.
My 2 penneth,
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of
mike kline
Sent: 24 July 2006 07:16
To: ActiveDir@mail.activedir.org
Subject: Re:
[ActiveDir] OT: Interview Techniques
Brian,
That was a good story, very funny. So what did the guy do? Did he
just get up and leave? I know from reading your posts you are usually
straight and to the point. I would be sweating if I had to interview with
you.
Going off course a bit. What are some types of AD questions that you
all consider to be "senior level"? For example what if you ask
someone how to do a metadata cleanup? Would you all consider that to be
a mid level question? Just wondering because I always grapple
trying to figure out questions for the mid vs. senior level candidate.
I've got no second thoughts about being an
asshole during a tech
interview. I ask the question, you either answer it
or tell me you don't
know. If you choose not to tell me you don't know and
demonstrate that
you don't know through what you tell me instead, I'm
already pretty much
through. If you're arrogant like this candidate you
describe, I'm likely
through as well.
My favorite exchange as of
late goes like this:
Me - Tell me a little bit about your experience
migrating Exchange 5.5
orgs to 2003
Them - blah blah blah
Me - Ok,
can you name the three types of connection agreements in the
ADC?
Them
- well uh blah blah well uh excuse excuse
Me - other questions
Me - So
would you be comfortable migrating a 10K user 5.5 org to 2003?
Them -
Absolutely
Me - How can you be comfortable doing that when you can't even
explain
the first step of the migration to me?
In any case,
others have put some really good advice here. What you want
in a technical
lead is someone who can get their hands dirty without
getting scared or
screwing up. They should also have no second thoughts
about delegating
work and asking their subordinates for help. That
person needs to be able
to deal with upper management, and they also
need to make sure their self
esteem is in check - none of that "I did X"
when all they did is watch.
Hiring your new manager can be a little
difficult on both sides from the
point of view of why wasn't someone on
your team promoted to that
position?
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
