
The 5 Biggest Interview Mistakes Startups Make - pchristensen
http://blog.standoutjobs.com/the-5-biggest-interview-mistakes-startups-make/
======
timr
Articles like this remind me of everything that's wrong with the tech hiring
process. Especially the linked "new-hire checklist", which says that you
should demand _"imbalance"_ and _"a glass full of kool-aid"_ in your
candidates, but mysteriously downplays the importance of _"domain knowledge"_
(really...this is what the author considers to be _good_ advice?)

Beyond that, I don't think I'm the only good developer who is tired of the
"gauntlet" mentality in tech interviews. Coding questions are fine and puzzles
are sometimes acceptable, but you have to remember that their _only_ purpose
is to answer one question: _does the candidate know how to code?_ If you
already know the answer to that question, it's time to sell the interviewee on
your company -- not to alienate them by beating them senseless with ever-more-
difficult problems and brain teasers.

Every interview question should satisfy one of two criteria:

1) if the candidate answers correctly, would it make me want to hire him/her?

2) if the candidate answers incorrectly, would it make me want to avoid
him/her?

If your questions are "hard", but they don't satisfy one of these
requirements, they're useless. And importantly, once you've got a sense of the
answer to these questions, _you're done with the interview_. There's no need
to drag it on, and subjecting a candidate to a grueling, capricious interview
process can _only_ serve to alienate her from your company.

~~~
dshah
Good points.

Agree with the premise that interview questions should provide useful
information.

However, recruitment is a delicate dance (much like any kind of relationship
where there's both "buying" and "selling").

Anything that's overly formulaic is probably sub-optimal.

At the end of the day, you're trying to have a conversation that helps both
parties determine if it's a good "fit". There should be an overarching "goals"
for the questions, but not everything that's said or asked will neatly satisfy
the criteria. Successful recruiting is more nuanced.

~~~
timr
What's more formulaic: asking a small set of questions that are known to
provide real information about a candidate's skill, or conducting an eight-
hour "gauntlet" interview loop of brain-teasers and puzzles?

Questions assessing "fit" satisfy the criteria I outlined: a good answer "fit"
question will make you want to hire the candidate. A bad answer will make you
want to avoid her.

------
ScottWhigham
I like this overall. I read Joel Spolsky's book on hiring techies and I've
tried his interview process for the past ten interviews I've done. Some things
work and some things don't.

I would add to this article and to Joel's approach that you need to ask some
basic coding questions during the telephone interviews to at least pick up on
things to review during the in-person interview. Example: for a programming
job, I want to know if a person knows the size of an "int" or if they can tell
me what the difference between a struct and a class is. If they can't, then I
need to make the decision right now to drop this candidate or consider them
for a more junior position.

Here's what happened to me recently: I have a job opening for a junior
programmer (still do actually) and I had a phone interview scheduled. I
prepped my notes and asked what I thought were good questions ("Tell me about
that job. Tell me about a challenge you had. Where do you see yourself in 5
yrs?"). The candidate breezed through these questions and I was excited.

For my in-person interviews, I had decided to use a 10-question Basic Skills
test. It is handwritten and very, very easy: "Write out the numbers 1-10 each
on a separate line in a console app", "describe how a web app works in detail
as though you are describing it to a brand new tech writer". It is timed -
it's really, really easy - and I allot up to 20 mins.

I handed my candidate the test as the first thing and he failed miserable.
Next!

My fault for not having a better phone interview process in place.

------
anamax
After a successful interview, both sides know whether the answers to all of
"can, will, fit" are yes.

The other mistake that companies make is in the description that they use to
find people. If a description says "{framework}" and nothing else, folks are
going to assume that {framework} is your problem and that you don't have
anything else. If you're developing {framework}, that's reasonable, but if
it's just a tool being used correctly, it isn't your problem and you should
talk more about what you want folks to do with {framework}.

