
Ask HN: Why did you Not hire that candidate? - peterchon
Was it more a technical reason? or a personality reason?
======
serve_yay
I try very hard to focus on what the candidate knows. Most of the other stuff
is bullshit anyway.

Recent interviews:

\- A somewhat well-known poster here, the kind of coder who parachutes in when
startups are having trouble shipping and need help. Didn't actually know the
programming language very well, which is sadly common amongst coders of the
language in question. Sometimes that's ok, but this person presented
themselves as an expert in the language and did not know very basic things
about it.

\- Again, not very strong with the language, but very strong in other
languages and overall quite an impressive candidate. I recommended to hire
this person, but for a different engineering role. Got hired for a different
role and is doing a great job.

~~~
Impossible
I had an interview pretty recently where, I'm positive the interviewer came to
the conclusion that I didn't know the language despite years of experience
because I made some embrassing syntax mistakes during a phone screen. This was
something I know, is very basic and core to the language but I hadn't done in
a while because it's a construct that is explicitly disallowed in the code
base I currently work in.

~~~
serve_yay
That sucks! I think it's unfair to ask candidates to write code on the spot.
You're already nervous, and if you don't have your computer with you then
you're totally out of your element and without the tools you normally use. We
have a small coding exercise we ask candidates to do at home in their own
time. I think it's much more fair that way.

In the interview itself, as I said, no coding. Sometimes I will ask the
candidate to spot bugs in a function, or read code and say what it outputs, or
have a whole function written with one thing missing, and ask what's missing.
But asking the candidate to create something where nothing yet exists is not
fair, I think. Whiteboard coding and all that, it's no good.

When I say the candidate didn't know the language well, I meant conceptually.
Like, imagine if someone told you C had a built-in array type, for example. It
was that sort of thing. And remember, this was a person claiming expertise.

------
neonfreon
I think that's a false dichotomy. It's not simple to separate "personality"
from "technical". A person's personality is what drives them to acquire
technical skills. Candidates with a curious, open minded personality will
spend more time acquiring technical skills than more passive or close minded
candidates will. In my experience it's rare to see someone with solid
technical skills that doesn't have passable interpersonal skills too. Learning
is just too social.

This plays out at a larger scale too - some cultures are more open to
borrowing from other cultures, and some are more closed. The more open ones
utilize better technology than the closed ones.

~~~
byoung2
_In my experience it 's rare to see someone with solid technical skills that
doesn't have passable interpersonal skills too._

I've worked with some developers who are brilliant technically, but are not
people you would hang out with outside of work. You don't want to duck out or
pretend you have a doctor's appointment just to avoid going to lunch with a
coworker. You also don't want an arrogant know-it-all on your team, even if he
is a genius with code. I remember interviewing a guy and asking him how he
would accomplish something in PHP, and he said "PHP sucks, I would write it in
a real language." That's the kind of person you don't want to hire to work on
a PHP app.

~~~
neonfreon
I don't think "would hang out with them outside of work" or "would make a good
lunch mate" is the right way to think about personality fit when hiring. I've
had many effective coworkers and employees that I didn't spend any time with
outside of work. If you can't work with someone that doesn't click perfectly
with you, shame on you, not them.

'That's the kind of person you don't want to hire to work on a PHP app.'
Definitely. I would also be surprised if they were even technically capable of
giving a good answer, given that attitude.

'You also don't want an arrogant know-it-all on your team, even if he is a
genius with code.' Agreed. And since nobody else wants to work with someone
like this, this type has a tendency either tone down their attitude or to get
weeded out before they can really grow technical expertise. I've interviewed
hundreds of people and can only think of a couple of examples that were close
to that, and those were either for internships or people fresh out of college.
Do you often run into people that are technically a great fit but are too
arrogant to hire?

------
byoung2
To find the last new hire, 95% were weeded out just based on resume for lack
of experience, or non-relevant experience. Of the remaining 5% who made it to
a phone screen, 80% were weeded out because they could not convince me that
their knowledge matched their experience (e.g. 10 years of Javascript but they
can't explain Function.prototype.call() or Function.prototype.bind()). The
rest who passed the phone screen, the decision to not make an offer came down
to personality fit or geography (quite a few people were out of state, and
would not be able to move here quickly).

~~~
Bahamut
I'm continually amazed when I hear numbers like this. For the last two
frontend hires, I went through maybe 20 resumes (resume reviewing, phone
screens, and in person interviews). A few were personal referrals. One of the
hires was a referral of mine from IRC - he turned out to be an excellent hire.

IMO, some of what you describe sounds like the wrong way to hire. Stuff like
Function.prototype.bind can be easily found By Googling. You want candidates
who can adapt to the unknown. I remember a well-known PHP developer in the DC
area telling me a story about him guest interviewing candidates for a friend's
company - he asked a lot of intense edge questions about PHP to candidates,
and only one would give him straightforward answers about not knowing the
answer and being willing to Google the answer. That candidate ended up being a
phenomenal hire for that company.

~~~
byoung2
_Stuff like Function.prototype.bind can be easily found By Googling. You want
candidates who can adapt to the unknown._

That is true, but it is a warning sign that someone with 10 years of working
with Javascript has never had to use those functions (even if they had to
Google it 5 years ago, they should remember it now). It would be like hiring a
driver with 10 years of experience who didn't know what the parking brake was
for. Granted it is possible to live your whole life in a flat state and never
have to use it, but that's rare, and even if true, I want a driver who has
seen at least a hill or two.

Once you've passed the basic questions like this, we definitely get to more
difficult and tricky questions, and even a question that has no answer to
force the candidate to either BS or admit he doesn't know.

~~~
Bahamut
I still prefer to give a candidate the benefit of the doubt there, unless
there is more supporting evidence.

I have more sympathy towards people who may have not been fortunate to have
seen the more challenging aspects of development and help them get there -
only 2 1/2 years ago, I was unemployed for the past 2 1/2 years out of grad
school without any company having given me such a shot at any career, and here
I am now as a lead frontend engineer who is trusted to solve any problem
thrown at me and build a team. Just as I was pissed off that so many companies
were originally dismissive of me despite my education pedigree, I try not to
be dismissive of candidates because they didn't happen to use [insert
feature]. Stuff like that is easily studied or taught, and I evaluate almost
wholly on things that (almost) can't be studied since it pre-empts candidates
from giving me answers that hide important characteristics about them.

------
bitshepherd
I'll bring it from the other angle. I know why I wasn't hired (though I wasn't
told):

\- No formal background

\- I don't code on the spot, and not on a whiteboard with zero resources but
rote memory

\- I'm not "senior" enough (with >15 years in roles with progressively
increasing responsibilities and contributions)

\- Buzzword trivia was fun in 2003. Not so much.

\- Had an off day

The roles I've been hired into where I wasn't subject to a dog and pony show
have arguably been the best, as I've been approached as a person and a
professional, and not as a little blue box filling an opening in the calendar.

------
bzalasky
Because the candidate couldn't write a JavaScript function that allows
chaining method calls on its result... along the lines of
myFunction().setAttr('a').setAnotherAttr('b').toString(). In my experience,
candidates either tackle this in 5-10 minutes, get close and finish with some
hints in 20-30 minutes, or have no clue.

If it goes well (first scenario), I like to spend the rest of the interview
pairing on a task like writing a parse method for a Backbone model that needs
to transform a response for a charting library or something like that with
Underscore/Lodash.

One time, a candidate started checking emails on his phone during an on-site
interview. That candidate wasn't hired.

~~~
jhildings
Out of curiosity, what is the things you need to do to make that possible?

~~~
bzalasky
Something along the lines of this:

    
    
      function myFunction() {
        var a, b, func;
    
        func = function () {
          return {
            attrA: function (attr) {
              a = attr;
              return this;
            },
            
            attrB: function (attr) {
              b = attr;
              return this;
            },
    
            toString: function () {
              console.log([a, b].join(' '));
              return this;
            }
          }
        }
    
        return func();
      }
    

This allows us to call myFunction multiple times, set attributes (imagine it
were createPerson instead, with a name, age, etc...) and not run into problems
with state being shared.

I like this question because it covers closures, this, objects and functions.
It also doesn't qualify as a brain teaser, IMO.

~~~
fragmede
> It also doesn't qualify as a brain teaser, IMO.

That's debatable. It requires a piece of unusual thinking ('return this'), and
a bit of magic (knowing about the 'this' magic variable), but once you've seen
it, the answer's obvious, and it's pretty easy to replicate everywhere.

~~~
bzalasky
Understanding 'this' is foundational when it comes to understanding
JavaScript, IMO. So, I don't think it's that unusual. Out of curiosity, what's
another question that demonstrates a solid understanding of JavaScript as a
language?

~~~
fragmede
Yeah, but returning 'this' to let you chain things like that? Definitely a
trick. Not as obscure as Duff's device, but a trick, nonetheless.

------
Warewolf-ESB
There is no rule as to what the reason is. Firstly, the person must be a good
fit for the team - a team player, right values, work well with the other
members, be self driven, passionate etc. If that is ok, then secondly they've
got to be able to do the job! Technical skills must align to the salary they
are asking for - if they are expensive resources then they really need to do
what they say they can. If they are not so expensive then there is more room
for new learning and basic growth. None of this is possible without the right
attitude. Successful candidates must have both.

------
Bahamut
\- Candidate could not form coherent answers to my questions

\- Candidate was lacking in fundamentals in his/her domain

\- Candidate could not demonstrate a good critical thinking ability

The first was a total dealbreaker on a phone screen.

I prefer strong critical thinkers, and am willing to eschew complete knowledge
of a domain from a candidate and mentor him/her up to speed, but weak critical
thinking is nearly a dealbreaker for me as a manager.

I have been extraordinarily happy with all the people I have hired so far.

~~~
jtheory
I agree about critical thinking, but how do you test it?

I've seen signs of poor logic crop up just when going into detail about past
experience; but otherwise it can be hard to see -- particularly when the
candidate has been working on projects where someone else was providing
technical leadership.

I do ask candidates to go through a thought exercise -- basically a software
dev related puzzle requiring no special knowledge (except a bit of basic
crypto). Something like "here are the 5 constraints; walk through how these 3
scenarios would work" \-- no code involved, but requiring the ability to
convert constraints and goals into step-by-step instructions.

This has been pretty useful (there's a surprisingly huge range in the types of
responses I get) but wouldn't reveal much about how good someone's choices
would be deciding how to implement new features from scratch, for example.

~~~
Bahamut
I task candidates with problems, and then I ask questions as the candidate
attempts to solve the problem to learn what the candidate is thinking, and how
the candidate approaches the problem - solving the problem isn't important to
me, but seeing how the candidate works is. I'll ask questions like "Why did
you choose [insert data structure]?" or "Why didn't you approach this problem
[insert way]?" or "Why did you approach this problem this way?", or even
questions like "What would happen if you chose to do it [insert way]?" You
also find out a lot about the person's knowledge as well.

I don't necessarily expect perfection in code design - I can help teach that,
but a good foundation is paramount.

------
api
I find a lot of candidates with tons of college experience and theoretical
knowledge, but no grease under the fingernails... no practical experience
building real systems.

------
andersthue
If I wouldn't work for him/her, then I will not hire him/her.

~~~
neonfreon
I've read this is Mark Zuckerberg's policy when hiring people to report
directly to him. It makes sense when hiring management positions, but there is
a lot of room in organizations for people that aren't going to manage others
and don't necessarily need the skills, experience and interests that make good
managers.

~~~
andersthue
The question I ask myself is the above. If I would not work for a person
because, perhaps there is something fishy or it is not a good fit, I will not
hire him.

