Ask HN: How does your team hire engineers?

[nayshins]

Having been researching different hiring practices, it seems that most companies converge on a few different techniques (e.g. algorithms on a whiteboard, take-home challenge, pairing, and technical interview questions). This leads me to ask:

How does your team hire?

Do you believe in the efficacy of your process?

How do you think your hiring process can be improved?

[pmiller2]

My current company does a pretty traditional "algorithms on a whiteboard" type interview segment or two, an "object/app modelling" segment, and a "chat with the CTO" segment.

It seems to be effective in the sense that I don't recall anyone getting hired and then quickly fired, and my coworkers are all very smart, capable people.

OTOH, it's ineffective in the sense that we probably need to hire at twice the rate we actually are.

I'm not sure what I'd do to improve the process, honestly. Every approach I've ever seen or thought about has significant disadvantages.

[petr_tik]

I was wondering if any company in the US or outside ask for the candidate's preference about whiteboard vs. takehome project? It seems to be a highly debated sticking point for both camps: some feel they would rather have an easy (generic) way to prep by refreshing their CS101 and save time, while others want it to resemble actual work-like environment + problem.

What stops a company preparing 2 tracks and letting the person choose? Yes, it must make HR's, hiring managers' and interviewing engineers' lives a bit less planned and convenient, but it should increase the overall happiness levels for each candidate regardless of the result, which should result in referrals and a filled position (which is what the company really cares about).

What am I missing or is someone already doing this?

[jotux]

http://sockpuppet.org/blog/2015/03/06/the-hiring-post/

[karterk]

This has been an area of interest for me as well. I have spoken to a lot of engineers and hiring managers on this subject, and my takeaway is that no two engineers seem to agree on what's the best way to hire people.

Some think that code-while-on-the-phone interviews are bad (too much pressure for some candidates), while others think that take-home interviews bring all kinds of issues (e.g. candidates copy pasting code from Stackoverflow).

Some think that white-boarding is important (insights into the thinking process versus syntactic correctness), while others think that it's not a true evaluation of what the candidate will actually be doing at work.

Some think that asking pure algorithmic questions are bad (does anybody even implement their own hashmaps at work?) while others think that it's a reflection of how much a candidate explores the depth of a subject.

Some swear by HackerRank/Codility based automated tests to "filter" unqualified candidates, while others think that looking at Github for their code samples would be a better evaluation.

Some want generalists, while others want specialists.

Some people reject candidates on arbitrary "culture-fit" reasons.

Personally, here's my ideal interview process based on all these conversations and my own 100+ interviews in various places I have worked:

* Minimum reliance on resume - some people are just bad at writing about their achievements

* Have an initial 30-min call to learn about the projects that the candidate has worked on (especially if you are hiring a specialist). This should not be a filtering round unless you see something totally off target.

* Send the candidate a take-at-home coding assignment. This should ideally take only 2-3 hours and should be directly related to the kind of work she will be doing at work.

* Have another 30-60 min follow-up call to ask the candidate about the approach taken, alternate options, and possible extensions. This will help one ensure that the candidate had not merely copy pasted the code from the Internet.

* If everything looks good, bring the candidate onsite for face-to-face interviews.

* I prefer 2 rounds of face-to-face - the first round asking questions around the candidate's areas of strengths, and projects previously worked on by her. On the second round, I prefer asking questions that are from the domain I am working on. This will allow me to find out how the person attempts to understand a new domain, and whether the person listens/asks questions etc.

At the end of the day, interviews are subjective, and I have made peace with the fact that you're always going to miss out on people who might have just had a bad day.

[pmiller2]

I, too, have gotten interested in this area.

> Send the candidate a take-at-home coding assignment. This should ideally take only 2-3 hours and should be directly related to the kind of work she will be doing at work.

I used to be a fan of this, but I'm not so sure anymore. The reason is that if you give me a test that "should" take 2-3 hours to complete, I know I'm going to be competing with people who are spending large multiples of that amount of time on it.

Unfortunately, I don't have a solution to offer for this problem.

Edit: compete -> complete. Freudian slip?

[karterk]

Practically speaking, someone looking for a job change does not have 10 hours to spend on every company's coding challenge. So, you will have only a few people who would go out-of-the-way to do something like that.

And, that's not very different from someone spending more than the expected 40 hours at work. One can't do much about that if that person genuinely loves coding all day and does not mind working 60 hours a week.

Finally, in the follow-up call, I do ask the candidate how long the assignment took and how she spent her time across multiple tasks. Obviously if someone spent 10x the expected time, then that's another data-point to the final decision.

[pmiller2]

Suppose a candidate spends 9 hours on your 3 hour challenge. What's the incentive for them to tell you the truth? I think the only way around that is to not tell them what the expected time commitment is, but that still doesn't completely remove the incentive to spend much longer than intended and to understate the amount of time spent.

As to the time commitment, I would say finding the time to do these coding challenges is no harder than finding the time to come in and interview. And not every company even does a take-home coding challenge. The last 2 companies I've worked at did not.

My point is not that there's no signal there. My point is that the incentives encourage candidates to spend arbitrarily large amounts of time on these challenges and to not mention the fact, which distorts the signal.