
The Ideal Interviewer - mharrison
http://panela.blog-city.com/the_ideal_interviewer.htm
======
jerf
I've found it helpful when interviewing and it's becoming obvious the
interviewee "really needs to hit Google" that you just say, "Just write the
function down with some appropriate parameters and keep going". For instance,
it's easy to have year and years of very detailed experience in a language,
yet still not quite remember off the top of your head how to open a file and
read some lines out of it, which turns out to be something that you do far
less often than you might think, because it's often totally abstracted away.
If you haven't got any clue what to do with a string, on the other hand,
that's probably a problem.

You still get what you need as an interviewer; even if you don't know the
parameters, you should still see basic error checking, you can learn a lot if
they don't provide the correct parameters, etc. This approach also allows you
to implement the "don't know the language" interview; I don't really _know_
PHP but I've interviewed people in it, because I know it well enough to see
the things I am looking for. In that case I don't even _know_ the precise
parameters to open to "nail you" on them in the first place! But that's not
what I'm looking for.

~~~
__mharrison__
The interesting thing is there are some people who on paper come across as
strong, but throw a simple programming problem at them and they give you a
blank stare.

I'm usually not playing the compiler type during the interview. Pseudo code
would probably work since I want to see problem solving. (But those who could
write pseudo code could just as easily substitute in their language de jour).

------
mgkimsal
I've been firmly freelance the past few years, but occasionally look in to the
'job' world (not being derogatory there). I've gone through a few interviews,
and I'm amazed at how poorly people usually do it. I'm also amazed at how
_differently_ some places treat interviewing for a fulltime job vs
interviewing for a 6 month contract. My own experience is that the people
talking to you about a fulltime gig may drill you pretty hard on rather
trivial stuff, but if you're coming in for a short term contract, or in a
consulting role, there's often little vetting - there's an assumption that you
already know stuff. Very odd, imo.

Sometimes I feel a bit insulted if they don't do some background checking. I'm
not a superstar well-known name, but I do have a unique name - there's only 2
of me in the world that I know of, and one is my uncle :) I've published open
source code, I've run a blog (a lot of tech on it) for a number of years, run
a web-development podcast, spoken at numerous web/tech conferences, as well as
other stuff. Googling my name brings up loads of stuff about me and what I've
done. Yet given all that, I'll talk to an interviewer (after someone's already
reached out to me based on what they've allegedly found) and I'll get "so,
tell me what you've done" or "what's your involvement in the community?". Good
Lord, it's all there - 20 seconds before a phone screen would yield loads of
info. _I_ go to the trouble of learning what I can about company X, yet the
courtesy is rarely returned.

Hint, recruiters - I have a note to recruiters on my main site. If you mention
that you've read it when you reach out to me, you'll get my undivided
attention simply because you bothered to read it.

Loads of 'old school' interviewing stuff was drilled in to me years ago - be
polite, on time, courteous, do research on the other party, express interest,
ask insightful questions, etc. If the other party doesn't show the same basic
behaviours, goodbye.

I struggle with this because there's time when I feel like I'm just looking
for an ego-stroke (as my wife has said). But at the same time, I've put time
and effort in to my craft, skills, and presentation of same, just like Company
X has put in to their org, website, team, etc. If you expect me to know your
company and be excited about working with you, research me and be excited
about me. Few companies bother taking this approach, then complain that they
can't find workers. :/

~~~
mharrison
Been there, done that.

Don't get me started on recruiters ... they could be so much more effective in
my experience.

~~~
mgkimsal
_they could be so much more effective in my experience._

Amen! I can count on one hand the number of recruiters that I'd _recommend_ to
either a company or someone looking for work.

As an industry, they must be being 'effective enough' because they're still
doing it. I'm waiting for a disruptor to hit that market and radically change
the way things are done. It'd be huge.

~~~
hapless
It's like real estate. Recruiting _looks_ like easy money, so it attracts
many, many entrants. Only a few are successful enough to stick to it as a
full-time job.

The incentives don't make sense. As a realtor, you get a huge, immediate
payoff when the house sells. You don't care about the price.

Recruiters are worse. As a recruiter, you get a huge, immediate payoff when
your client hires _any_ candidate at _any_ price. You don't actually care how
good the fit is, so the rational behaviour is to spray as many candidates at
as many clients as possible.

~~~
gnosis
_"As a realtor, you get a huge, immediate payoff when the house sells."_

"immediate", except for the fact that you might have been working to find or
sell the house for a year, and months to put the deal together.

This is assuming the house ever does sell at all, and you haven't worked for
months or years to get absolutely nothing.

And it assumes that _if_ the house sells you don't get cheated by your client
and actually do get paid.

 _"You don't care about the price."_

Except that usually real estate agents get a percentage of the sale price as
commission.

Real estate agents also want to make their client happy so that they'll get
recommendations and referrals from them in the future, and want to work with
that agent again when they look to buy or sell another home.

~~~
hapless
Exactly, they get a percentage of the sale price as a commission.

1% of a $300,000 house is $3,000. 1% of a $325,000 house is $3,250.

The realtor has $250 to gain from holding your house price as high as
possible, increasing the amount of work he has to do. He has $3,000 on the
line to sell it at the lower price, with less work.

The rational behaviour is to sell as fast as possible, and damn the price.

------
iam
Lets look at the "Ideal interview" examples, it doesn't look like any of those
involved asking technical questions (e.g. coding on the whiteboard)?

The trouble is that unless someone is highly referred from a technical
coworker you trust, it's going to be hard to know in advance if you have the
technical chops or not.

Anyone can write down on their resume they've done A, B, C and are well-versed
in X, Y, Z. They might even be able to talk the talk. But when it comes to
writing code they might completely freeze or write something that would make
college students blush.

Finally, the time is limited (could be 45 mins, could be 1 hour) during the
interview, and the most important thing in most peoples minds is technical
chops. That's why I'll usually start out with that (unless the candidate was
referred or seems highly qualified, in which case I'll merely get into that
later), since it could just weed out the candidate before getting very far.

With your regard of "Convince me why I want to work at your company," I think
that only happens once a candidate has proven to be worthy. At least in my
last company we would be in "sell" or "buy" mode for a candidate (sell meaning
we try to convince him/her to join, buy meaning we try to convince ourselves
if he/she should join) and it would start out in buy mode.

There's nothing worse than interviewing and hiring a candidate with a great
personality than just finding out he/she couldn't code their way out of a
paper bag. That being said, I do dislike interviews where they spend the
entire time just asking technical questions as it should be obvious after one
or two, so a particular balance needs to be sought.

~~~
__mharrison__
Where did I advocate not asking technical questions? In the ideal situation,
you've already looked at my code, and know the work I've done from the
recommendation. (Note I said "highly recommended").

WRT convincing. Sure you start off in buy, since you're hiring. But you should
be open to the thought that a great candidate probably has other great options
on the table, and they need to vet those out. Ideally you would provide them
that opportunity.

~~~
iam
Right, as you said the technical question is unnecessary if they've already
looked at the code. Which would be pretty hard unless the candidate kept
his/her code up somewhere (linked from the resume) or had former coworkers
essentially vouch for his/her code quality.

And even if the candidate does have the code up, not all interviewers would
bother spending the time to look at it. At the end of the day I think it is
based off some kind of reputation on whether or not people believe in the
technical chops enough to skip asking the candidate the question.

And it's really hard to draw the line between belief and sloppy interviewing
where they simply forget to ask.

I wonder, in your cases where you experienced the ideal interview, which
factors do you think contributed to it?

------
dkarl
I'm trying to become a better interviewer, and it can be very hard. Here's a
story of a badly wasted phone screen I did this week. I screened a guy with a
graduate degree in math who worked in a network analysis group for a telco. We
talked about the current project he was working on, and his previous project,
and while it was really cool statistical modeling of network failure and
recovery, he didn't actually do any of the modeling or mathematical work. As
best as I could tell, he just wrote scripts to munge data into convenient
formats for his teammates to import into the modeling software. He knew next
to nothing about statistical software. I described what we did and asked him
what kind of work he thought he could do for us, and he basically said he'd do
network modeling and analysis for us -- exactly what he _wasn't_ doing at his
current job, it seemed.

Afterwards I told my boss, "This guy is a total miss. He just writes Perl
scripts to munge log files. Why did we even talk to him?"

"Oh, he's a really sophisticated low-level network performance guy. He has a
lot of hands-on knowledge of networking hardware and protocols."

Well... shit. I guess munging log files can be more than just munging log
files. I couldn't tell that from his resume, though, and he didn't give me any
clue while he was talking to me. Was that my fault?

~~~
mgkimsal
Maybe, kinda, sorta.

If you didn't decide to interview him, or set it up, you should have asked the
person who did (in this case, your boss) what it was about the person that
caught their attention in the first place. Why did your boss think this was
worth pursuing? With that knowledge in place, it would help shape your
questions.

------
allenc
One of the most annoying forms of interview has to be the immediately
technical phone screen. I remember talking with startups, and during the
initial phone call they'd leap into a canned set of technical screening
questions, which themselves are some set of factoids which are supposed to
translate to how good of a programmer you are.

I understand the need for startups to screen out absolute idiots before they
spend time talking with a candidate; it's easy enough, though, to look the guy
up beforehand or send the guy a coding question he could work on in isolation.
Just make it a policy to only talk to candidates that have something technical
you can verify beforehand.

In our current tech job market, it makes sense for the company to convince you
it makes sense to talk to them further; chances are, if you're any good and
someone they want, you can and will get multiple offers anyway. Even if the
company wastes "talk time" to candidates that wouldn't make the cut, it's
worth not driving away the guys who got annoyed by its strong-hand "we need a
strong code monkey" interviewing tactics.

------
techiferous
"Don't ask me where I want to be in 5 years...If you want to know if I want to
pursue tech vs management, just ask that."

I agree. Not that I don't have any long-term goals at the moment, but I expect
life to change and I usually flex with those changes so who knows where I'll
be in five years?

------
trustfundbaby
Probably a little offtopic but if I don't make the cut ... call and tell me or
email, don't have me wondering what's going on.

Its so simple but an amazing number of companies just will not take this
simple step. So rude, and people remember things like that.

~~~
enjo
Also tell me why.. and don't have your administrative assistant make the call.
YOU (the person who interviewed me) call me. Tell me what you liked and what
you didn't. I took a few hours out of my day to come talk to you, give me some
honest feedback here.

~~~
__mharrison__
This is annoying, bad sadly I believe there are legal issues that prevent more
than one sentence "we decided to pass on you" (IANAL).

~~~
wtn
The OP wasn't asking for a loveletter—he just wants always to receive a
confirmation of the "no" answers after they have been made. It's not much to
ask.

------
keeperofdakeys
Here is a relevant article about how when interviewing programmers you should
actually test if they can program: [http://www.richard-banks.org/2009/08/some-
developers-just-ca...](http://www.richard-banks.org/2009/08/some-developers-
just-cant-develop.html)

------
strlen
> _I understand that C is the "lingua franca" of interviews, but if you read
> my resume (or even talked to me) you'd know I'm not looking for a C job (and
> really haven't used C since college). While, I'm open to coding in C, it's
> cooler if you don't force me to use C._

The article assumes that the reason someone would ask them to use C on an
interview is because it's lingua franca, and they're only interested in the
interviewee's algorithm knowledge.

Algorithms are great and should be a part of an interview, but I am
interviewing software engineers, not algorists: I'll ask about general
algorithms (the ones you might find in first half of "Algorithm Design Manual"
and in "Programming Pearls"), data structures (where I'll expect the
interviewee to understand pointers: whether in a language like Python or Java,
where every value (with exception of Java's primitives) is a pointer or in a
language like C where pointers are explicit).

I'll also ask about algorithms specific to their job, or (if I am interviewing
a candidate for another project, as a part of a panel) I'll leave that to
other interviewers. If, for example, somebody lists ten years of distributed
systems development they should be familiar with the various consensus
algorithms, pros and cons of them (I will not expect them to implement Paxos,
but it would be nice if they know how multi-Paxos and ZAB solve some of the
issues Lamport's original algorithm had). Again, this is for experienced
candidates being interviewed for a role in which they claim existing
experience.

There are also simple algorithms (related to string or array manipulation)
that are just easier implemented in C. If ask someone to reverse a string in
place [NB: I don't actually ask this], they'd have an easier time doing it in
C than in Java.

However, there's more to C than a language in which to implement algorithms:
it's also a systems language. I want candidates I hire to understand how their
computers work. I'll challenge them to understand how various system calls
work, how parts of libc are implemented, how memory allocation works (and, if
I am interviewing a candidate for a Java, Python et all collection how garbage
collection works, and in what cases might it fail to work). In this case,
knowing C (and having it used it, at least in your own free time after
college) is invaluable, not because of the language itself-- but because it's
a great portable assembler.

I understand people are frustrated when they're expected to know C, even
though they won't be programming in it: however, it's not about the language,
it's about knowing about an area of computer science that isn't often as
glamorous, but is just as crucial as algorithms and data structures.

~~~
__mharrison__
I'm not completely convinced that programming in C in an hour long interview
is the most productive way of testing system call, libc and garbage collection
knowledge.

I do agree if you are applying for a systems level job, C testing should be
more rigorous.

~~~
strlen
You don't have to answer every single question in C. It's just that you're
going to be much more likely understand a question e.g., "how do free() and
malloc() work" if you know C. You also don't want to be asking difficult
questions for the entire hour: I always prefer to let the candidate introduce
themselves, warm them up with an easier question (to help make the candidate
less nervous), add a challenging twist to the easy question, and then asks the
most challenging questions.

Understanding systems matters for more than systems levels jobs: perhaps you
don't need it if you plan to work on CRUD apps in a financial organization,
but if technological aptitude is an enabling factor for a company you're
applying to (that's the case for companies in Silicon Valley: otherwise
there's no point to being in the most expensive part of the country), you
should understand more than your segment of the stack (that goes both ways:
systems programmers should still understand HTTP and high level languages if
they work in a web services company).

~~~
__mharrison__
ack and ack :)

