
The Guerrilla Guide to Interviewing (2006) - fosco
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
======
frompdx
I have always had mixed feelings about the advice in this article. I think
there is some reasonable advice here, but for the most part I don't think
anyone should use this as a reference for how they should conduct interviews.

> hat means you can technically end the “day” of interviews after the first
> two if the candidate is not going to be hired, which is not a bad idea, but
> to avoid cruelty you may not want to tell the candidate in advance how many
> people will be interviewing them.

So, keep the candidate in the dark about how much time they should allot for
the interview?

> I can tell you from extensive experience that if you spend less than one
> hour on an interview you’re not going to be able to make a decision.

Ask the candidate to potentially give up six hours of their day? This seems
like a big ask.

> The trick is telling the difference between the superstars and the maybes,
> because the secret is that you don’t want to hire any of the maybes. Ever.

We only hire geniuses here, got it.

> It’s because it is much, much better to reject a good candidate than to
> accept a bad candidate.

This seems like common sense. Let's find out where it's going.

> On the other hand, if you reject a good candidate, I mean, I guess in some
> existential sense an injustice has been done, but, hey, if they’re so smart,
> don’t worry, they’ll get lots of good job offers.

Ah, we're social Darwinist and it's how we rationalize our behavior towards
potential candidates.

> How do you detect smart in an interview? The first good sign is that you
> don’t have to explain things over and over again.

Unless of course, you are terrible at explaining things.

> So: don’t listen to recruiters; don’t ask around about the person before you
> interview them; and never, ever talk to the other interviewers about the
> candidate until you’ve both made your decisions independently. That’s the
> scientific method.

Interviewing is a science! This must be why every interview I have done is
completely different.

> Being passionately negative can be just as good a sign.

Or, it can be a sign they will be passionate about being negative all of the
time.

> And the same thing happens in programming. If the basic concepts aren’t so
> easy that you don’t even have to think about them, you’re not going to get
> the big concepts.

This is where I find myself really frustrated with this article. I think this
is needlessly discouraging to newcomers. Imagine if you were just getting
started, you read this article, and then had to ask yourself if it was worth
continuing because you weren't sure if you could check this box. I was there
several years ago and found it discouraging in the short term and false in the
long term.

> I’ve come to realize that understanding pointers in C is not a skill, it’s
> an aptitude.

> For some reason most people seem to be born without the part of the brain
> that understands pointers.

In an article claiming that interviewing is a science, this claim is made and
justified with anecdotes. I don't buy it.

> A lot of the “script jocks” who started programming by copying JavaScript
> snippets into their web pages

> today it’s possible in many otherwise reputable schools to coast by on Java
> alone.

Never miss an opportunity to bash the language du jour.

> When you say, “There’s a bug in that code,” they will review their code
> carefully, and then you get to see if they can be diplomatic yet firm in
> asserting that the code is perfect.

If the candidate did a great job on the whiteboard exam, don't miss your
opportunity to play mind games with them for fun.

> Even if they are a bad candidate, you want them to like your company and go
> away with a positive impression.

It would be hard for me to walk away with a positive impression at this point
regardless of how the interview went if I was aware of the interviewer's
unfounded views and mind mind games.

> Finally, avoid brain teaser questions like the one where you have to arrange
> 6 equal length sticks to make exactly 4 identical perfect triangles. Or
> anything involving pirates, marbles, and secret codes. Most of these are
> “Aha!” questions—the kind of question where either you know the answer or
> you don’t.

I really do agree with this advice 100%.

> And when you find the smart, gets-things-done candidate, you’ll know it.

Just go with your gut!

I would like to see an interview guide that is actually backed up by data
rather than a snarky article full of anecdotes masquerading as something
scientific.

