
Ask HN: What are the best practices for hiring software engineers? - adamgamble
What are the best methods you&#x27;ve found for determining whether a person is A) qualified and B) a good fit for the company culuture?<p>Do code tests work well? Is there some saas product that can help test engineers? Some other method i&#x27;ve never heard of?
======
lsiebert
Small companies don't have to filter thousands of candidates, and can innovate
around how they hire. They have to be like moneyball.

Big companies whiteboard because that's how it started, everyone who works
there knows how to whiteboard, and you can argue that it's correlated with
skills used in development. They don't have time to pair program. They can
afford to throw away people who could be good based on their arbitrary
metrics.

Startups can make innovating around hiring a selling point to candidates. They
can talk to candidates about what sort of process would best demonstrate their
skills and be in their comfort zone. They can look at non traditional
candidates based on github accounts or OS contributions. They want people who
can deliver.

Google's hiring innovations are more likely to be small steps. By being agile,
startups can get ahead of them.

As to what best practices are, behavioral interviews that ask people what they
would do in a particular situation are correlated with job skills. So is
actual work, so paying someone to work for you, or perhaps even volunteering
to help them with something by pairing, may give you insight into them.

------
bitshepherd
One former employer tested prospective hires by handing them a print-out of a
script, nothing too fancy, just some shell script, and ask them to explain
what the script did and if there were any errors.

If one can read the language, and know what it does, the errors are pretty
obvious. If the prospect doesn't know it, they're not able to talk to it, and
the bullshit meter goes off pretty quick if they try faking it.

------
MalcolmDiggs
Generally speaking: You need someone you trust, who is at (or above) the level
you're hiring for, to screen candidates for you. Just put them in the same
room together and let them have a conversation for an hour or two.

A non-technical person screening a technical person is generally not a good
idea. It doesn't matter what prepackaged barrage of tests you put them
through, or what saas product you make them sign up for. Most engineers know
how to _sound_ like they know what they're talking about, and how to craft
their past experiences to sound relevant to your position. Only another
engineer can tell if all that talk is meaningful or not.

This leaves many startups in a rough position: How does a CEO screen their
tech co-founder? How do front-end developers screen a backend guy? And this is
where your network comes in. Call in favors, ask around. Find someone who is
employed doing the job you're hiring for (or ideally a more senior version of
it), and ask them to do the screen for you. Don't give in to the temptation to
screen them yourself (if you're not technical), there's really no point in it.

------
z3t4
Take your candidate to a computer, ask the programmer what he/she is working
on. Have the candidate sit down and continue the work for ten minutes. If it
works, hire him/her.

~~~
probinso
Have you tried this? Do you feel that personal projects correctly reflect
production releases? Is it necessary that they do?

~~~
z3t4
I mean; ask the programmer who is currently working on that computer, what
he/she is working on. Then see if the candidate can pick up the work from
there, with some hints from the programmer.

~~~
clbecker
The engineers working on a team might spend hours in sprint planning meetings,
doing research, and working out an approach with their team before they start
coding anything. How would you expect to get a fair assessment of someone by
dropping them in the middle of someone else's code work, and putting them on
the spot?

------
zer00eyz
A) Give them a "take away" project... or bring them into the office to DO a
project. Make it simple. Have them write "login". Don't be specific, tell them
the exercise meant to be vague. Tell them that there are some things they may
want to "hint at" or be a skeleton. If they are back end, you want just the
api... front end just the UI (they can create static json for responses). Do
they encrypt, did they leave hooks in for password reset, were they writing
code that was going to be hard to I18N?

The white board is a terrible way to get a sense of a persons ability to code.
Does your design team ask candidates to come in and "design" on the
whiteboard? Why would you pull an engineer that far out of context to see what
they do.

I have seen interviewers bring in "code samples", sometimes with bugs in them.
"Read this and tell me what you think it does" becomes a great question, or
what is this for. Syntax highlighted code printed in color may speed this
exercise along but isn't required.

References help, but really your calling someone they expect to give them a
golden review. Linked in is your friend here, some "outreach" may get you a
different perspective than the people they have listed.

B)Short of someone being lazy, or unwilling to learn, there is more than a bit
of bullshit in "corporate culture". There have been several occasions in my
career where I heard that my immediate boss didn't want to hire me as I would
be a "bad culture fit", usually followed by a promotion. Culture is code for
"status quo".

Lastly: Talk to your HR department about terminating bad employees after 90
days. No matter what you do, sometimes you just get it wrong, and getting that
person out is better than dragging it out.

EDIT: I should have mentioned that rather than focus on "culture" you should
be finding out if the person cares about your product.

~~~
mywittyname
Curious, how often does this work for your company?

Anytime I'm given non-trivial homework for a job interview, I decline because
there are a dozen other companies that can determine my competence in a few
hours of interviews.

I understand that hiring is risky for startups, but this approach seems
excessive for what it is supposed to determine. It seems like you could get
nearly all the same principal information about a person's talent by giving
them an even more simple assignment, like writing a method to determine if two
dates overlap.

A lot of what you're looking for is to see if a developer follows industry
best-practices. It's just as easy to ask them, "what are some security/design
considerations that need to be accounted for when creating a login page." You
get the same information but in much less time.

~~~
imsofuture
I've had really great experience hiring technical roles with 'homework'. Both
product engineering + technical support. Each time, I've made sure that anyone
completing the assignment is compensated with a $50 or $100 Amazon gift card
(depending on the task). I don't think I've had anyone choose to not
participate. I'm also happy to compensate people that make a solid effort and
realize they are in over their head and gracefully bow out (specifically
that's only happened when hiring borderline technical roles, like support --
no project is nightmarishly difficult).

I understand your time is valuable, and so is mine. I would like to see how
you work, on your own time, in a low-pressure environment. The information I
receive from that is easily worth $100. Plus, if we do proceed to further
interviews, we have a fantastic non-theoretical project to discuss.

~~~
geebee
I refused to do a take-home interview exam for the first time a couple of
months ago. I don't think a $100 gift certificate would have made much of a
difference. The opportunity was a decent one but I've just had very bad
experiences with take-homes in the past (spent a lot of time, didn't hear back
for a month, got a one-sentence rejection from a recruiter, never talked to a
developer). I might consider doing it later in the process, when I have a
stronger sense that the exam will be taken seriously and given proper
consideration. I'm just not willing to put this kind of time into what may
simply be "screening".

I think Gayle Laakman McDowell's comments on this subject were good:

[http://www.gayle.com/blog/2013/09/18/companies-who-give-
cand...](http://www.gayle.com/blog/2013/09/18/companies-who-give-candidates-
homework-assignments-knock-it-off)

The problem here is that take homes allow companies to externalize the
inefficiencies of the interview process - they may demand many hours of a
candidate's time while dismissing that candidate in five minutes. The $100
gift card may make this a bit better, but it's still a bargain for the company
(I'm certainly not surprised you consider the information easily worth $100).

------
ruraljuror
I have been very happy with coderpad.io to do remote coding interviews.

------
clbecker
In my experiences working with developers, there’s only a few issues that have
made an employee difficult to work with. Most of it is around personality,
motivation, and communication. It’s rare that I have a difficult time working
with someone because they lack certain skills (but do have the motivation to
learn them), and for all of the devs I’ve gotten to know and work with over
the years, I feel like a detailed review of their previous work experience
would have told us enough about their skills.

Good things to check for:

how open minded are they? \- Do they stubbornly stick with a certain way of
doing things? \- How readily will they apply someone else’s feedback? \- Do
they insist on doing things their way? \- Do they think all code written by
others is crap? \- How much do they bristle at someone else’s code style vs
working with it?

How well can they communicate with non-technical people? \- How do they talk
about their interactions with product managers/marketing/sales/customer
service/etc? \- Do they blame any issues on customers or colleagues being
"idiots"?

Can they talk through a past problem they solved? Can they talk through the
whole context of a problem they solved? \- do they understand the customer
problem they were solving and why it was important? \- can they speak to
multiple approaches that were considered and what their drawbacks were? \- A
great one is, did they go down a wrong path and learn something?

\- Some other things to assess are - do they focus on the right problems to
solve? Do they have a history of building systems that are more complicated
than they need to be? Do they over-optimize areas where it’s not necessary or
do they have a sense of where potential bottlenecks might lie; how to find
them; when the right time is to worry about them?

If they can talk through a past problem they solved in detail, that’s a super
great sign. The more detail they can get into and help you understand, the
better. If they just start gushing technical details, they’re either nervous,
or they had a very siloed role in developing the solution. I personally prefer
engineers who can get invested in the context of a problem.

When it comes to coding in an interview I’ve found that very simple coding
problems can surface all the info I need about their coding proficiency. \- if
the problem is simple, they’ll be able to just “stream” the code from their
head on either a whiteboard or a machine. \- experienced developers will even
manage to talk through edge cases and workarounds \- if they struggle with
this challenge, then they’re not going to do better with a more complicated
problem. \- for experienced devs I’ll want to see that they’re proficient with
the syntax of at least one language (if they don’t remember a specific method
name, that’s ok - problems that can be solved by a google search shouldn’t be
held against them)

\- springing a complex coding question in front of them and expecting a
perfect solution on the spot is a lot to ask for. “Real” solutions to complex
problems will be debated and built upon by multiple people. If you go through
this exercise, focus on how they tackle the discussion itself.

\- I avoid brain teasers and puzzles. There’s plenty of good developers who
can solve a real-world problem well but suck at solving technical brain
teasers.

\- In any interview, its important to take notice of how nervous the
interviewee is. Some people may be able to handle interviews better than
others. When you’re nitpicking their answers later on, keep this in mind. Some
candidates might blank out on an otherwise simple problem; some might ramble
on and seem disorganized. I’ve seen too many candidates get turned down
because of a few specific details they mishandled due to nerves.

------
jerven
Our process is a bit different from what is common in the rest of industry.

We do 3 things of which the first 2 are standard.

* CV screen * Phone screen, asking what, why, what is missing on CV * Interview -> starting by a presentation done by the candidate, then classic discussion/interview

The 3rd step is what is uncommon, we always ask a potential candidate to
present a bit of code. Their own if possible, open source otherwise. The
candidate selects the code and makes a small presentation powerpoint style or
walk through.

We always learn a lot of this. What code was selected? What do they
like/dislike about. Do they have opinions, and do they consider tradeoffs are
they willing to read other peoples code?

I think that for us, having some kind of taste in code and be willing to work
with and improve code written by others is a crucial part of our job. We can't
afford rewrites, we are willing to do migrations.

For the interviewing team it is always nice to have such a small presentation
because we always learn something new. It is never a waste of time! The
candidates seem to enjoy it too because they have something concrete to talk
about. In our very limited sample since doing this we have had less
stuttering/sweating by potentials. White board coding just didn't work for us.

Then of course we have the 15 minute selling of the organisation/job to the
candidate. No point in interviewing a great candidate and then lose them
because you can't sell them on working for you. For that reason one of the
developers will be waiting at reception for the candidate, and will walk them
in, offer a coffee/thee/water show the conference room and tries to make the
candidate as comfortable/relaxed as possible. Key is we try to show to the
candidate that we appreciate their time.

For a candidate, you will not spend more than 3 hours total in the process. 30
minutes phone screen. 60 minutes interview with some extra time 60 minutes
admin/contract details

Between each step there is a go no go decision and we normally make that the
same day.

A no-go in the phone call might be 6 years of experience but never used
CVS/Git or similar. Interview no-go tends to be voicing out loud that you are
not willing to dig into a problem. e.g. DB perf issue, won't touch it DBA job.

Contract issues is when we can't afford you ;(

Of course we hire once every 18 months on average because we are a small team
working on a very stable project.

Of course this is under Swiss law so there will be a probationary period but
we have not used it in the last 10 years and I hope that continues. There is
at will employment here but as in the US what is 'at will' can become a very
expensive legal issue if not handled well. Also the negative morale on a small
team on letting people go without a clear why is terrible.

Thing is we don't have 100's of candidates nor 10's of positions so what works
for us might not work for you. So we tend to get 50 CV's, with 10 potentials,
and 2 clear candidates in that pile.

Of yes, we always check at least one of the character references people put on
their CV. But never someone in their current work environment (unless we know
that will be OK, e.g. people leaving due to fixed term contracts at research
institutes)

~~~
probinso
I've had about five interviews in my life where I needed to give a
presentation spanning from 10 minutes to an hour of time. These interviews
were my favorite. I felt at the very least that I got honest and complete
feedback and had a high degree of confidence that the team interviewing me you
understood what my strengths and weaknesses were.

I wish that more companies would do this.

The only real problem occurs when the audience attending is not interested in
the interview process. I have had it be the case where I felt like my entire
presentation was dismissed. It takes a lot of time to write a good
presentation and I think that it's worth it to invest that time as long as the
audience is willing to participate.

~~~
jerven
The not interested does not happen with us because we hire so rarely.

But I also think that a team not interested in your presentation is rarely a
team you want to work with.

