

Interviewing for Intelligence - kevin_morrill
http://refer.ly/interviewing-for-intelligence/c/5603c8c0875c11e2bfbf22000a1db8fa

======
mvanveen
> It's surprising to me how many candidates explain these algorithms'
> performance as if the hash table was a magic black box that instantly works.
> Here they've lost the tree for the forest! They know what hash table is, at
> least at a high level, but forget that it has specific implications.

A lot of advice I've read about interviewing suggests that a candidate should
leave answers open and provide room for the interviewer to poll for more info.
I'm curious to know if the author goes out of their way to poll about the
specifics of the hash table implementation?

In fact, one of my favorite interviews in recent memory was a hash table
discussion not unlike the one the author is hoping for. I was happy to find an
interviewer whose questions balanced theory with practice and was happy to
drive to a solution with them. However, I wouldn't have offered up this
analysis without first understanding that this is where the interviewer wanted
to drive the discussion. Every good programmer knows that premature
optimization is the devil.

The author may instead be trying to raise the point that its up to the
discretion of the interviewee to see that the hash table implementation is the
critical performance detail. e.g. gotta do open addressing here b/c our
hashing function has weird edge cases where it collides all the time and
chained hash would bring us closer towards a log(n) traversal on that edge
case.

However, in my limited interviewing experience, interview problems such as
this are often designed to be open-ended conversation rollers moreso than
where implementation specifics like this are able to jump out easily.

~~~
kevin_morrill
In the question I was referring to, I don't care if they can implement a hash
table. I just want them to recognize that when they compare using a hash table
to other alternatives, that looking up items in a hash table has a performance
cost.

I agree it would be sort of silly to ask an open ended question and then hold
it against a candidate when they don't talk about something as if they're
supposed to read your mind.

~~~
mvanveen
Hi kevin,

First of all, thanks for replying!

I think without more view of the forest, as it were, I'm finding difficult as
a reader to understand the type of analysis you're hoping to get out of your
interviewees.

Would you agree that one interpretation of your thesis is to have interviewees
be able to adress the "why" behind a given implementation? Your reply suggests
that it's not the implementation specifics that you're after, but that was the
understanding I got out of the original article.

> I just want them to recognize that when they compare using a hash table to
> other alternatives, that looking up items in a hash table has a performance
> cost.

As you obviously know, looking up items in a hash table has exactly a constant
performance cost (amortizing the cost of a resize, and accounting for load
factor, etc.), making it an attractive solution in cases where you need a
lookup. I'm curious if your point is that the interviewee is missing that
nasty c constant in front of the big o, (e.g. computing a hash for an item or
the cost of a resize is impractical, say) or if the issue is that they are
just missing something big picture and fundamental given the problem
statement.

The former really speaks of "losing the tree for the forest", as in the person
black-boxed something they needed to open up, whereas the latter strikes me as
more of a lack of conceptual reasoning.

Thanks for your time! I noticed I was downvoted, so apologies if my inquiry
frustrates or upset you.

~~~
JailhouseRodeo
I think the author was trying to show us how smart he was, not only in areas
of codez (intimate knowledge of hash table) but also in areas of businessing
(something called 'liquidity trap'). We should all hold him in high regard,
because he only hires A players and had kicked many non-hashtable saavy B
players (180+ in all) to the curb.

------
Kerrick
Wait, when did refer.ly pivot from being a startup helping people with
affiliate marketing and social shopping, to an online magazine?

~~~
changdizzle
i have the same question - i could have sworn just the other month when the
betapunch post came out referly was still the referral tracking system

~~~
dmor
Referly CEO here - We've been headed in this direction for awhile, but just
crossed over (with the new tagline) about a week ago. An in-depth blog post
from me about the change and our new direction, plus a ton of stuff we
learned, is forthcoming - probably this weekend if I can sit down for a few
hours and knock it out. I'd really appreciate any feedback you have on the new
experience, both as a reader and as a contributor (if you decide to go that
far).

~~~
grandalf
I'm curious about how YC and your other investors influenced the pivot. Did
you get good advice? What was the dialog like? Was code refactoring involved?
Did this change your marketing strategy?

------
technotony
I've heard the Singapore civil service, renown for recruiting smart people,
have what they call the 'helicopter test'. Specifically they are looking for
people who are just as able to converse intelligently flying 1000 feet above a
topic as they are skimming the surface and getting into the details, and will
specifically test candidates on both perspectives and their ability to fly
between the two. Seems well aligned with what you are looking for.

~~~
98709870987
anecdotal

------
justin
"You’re looking for people who are 1) smart and 2) get things done"

Number 2 is a lot harder to determine than number 1 in my experience. You can
determine if someone is a good programmer by having good programmers ask them
increasingly challenging programming questions. The hard part is figuring out
if they are an effective and productive employee.

------
bromang
the author seems to be in the business of creating fairly simple internet
apps, so I'm not sure why his interviews would ever need to deal with the
implementation of hash tables...

------
fellytone84
I agree with the value you place in intelligence and like how you qualify your
essay as a discussion, but in perspective, your methods are simply imprecise
and as you said, anecdotal.

You humorously contrast your essay to a "randomized clinical trial," but to be
matter-of-fact, these trials exist: IQ tests or their politically acceptable
stand-in, the SAT.

I guess what I'm asking is this: what's stopping you from requesting something
like the SAT even if it's only for curiosity's sake?

------
khitchdee
Confidence:

If asked a question completely outside their domain of expertise, they
wouldn't bail on it but instead start trying to find an answer.

~~~
thisone
That's also the sign of a bs'r

You know, the person who knows nothing about a topic, but will talk for hours
on it?

There should never be shame in admitting "I don't know" and then following it
up with, "but if faced with that I would..."

~~~
ams6110
What I have found to be interesting is that the more I learn about a technical
topic, the less confident I become. Because I am now more aware of how much I
don't know, or about how a small detail can make a big difference.

I used to think I was pretty knowledgeable about web security. The more I
learn about it, and about how easy it is to get it wrong, or overlook
something important, the less confident I feel in my ability to implement a
secure web app.

------
orangethirty
I interview for maturity, discipline, and honesty. My codebase is made to be
maintainable by most programmer. I dont include any magic and make sure that
it is understandable. But I don't interview for intelligence. Because
intelligence without the three factors I look for does not mean a thing.

------
saosebastiao
This is confusion of intelligence and knowledge. I don't know how a hash
function works...but that is a reflection of my experience, not my
intelligence. I did not study to be a computer scientist...but I sure as hell
can optimize your supply chain.

------
martinced
In which alternate universe would the exact formula needed to compute the GDP
be absolutely crucial to explaining what a liquidity trap is?

And of course his "appeal to authority" consists in citing an article from the
totally and utterly overrated Spolsky...

Dismissed.

~~~
aaronc
I don't understand what you mean. The author said "Despite his confidence, he
couldn't even explain what GDP is, which was essential to his explanation."
which seems like a perfectly reasonable complaint. If you are trying to
describe a concept to me that I don't know about, I might ask you to explain
to me a much more basic idea that you are referring to. If they can't explain
the basics then all of the explanation of the original subject matter is
wasted.

