Skip to content

Top Best Ask Show New Jobs

Ask HN: How does your team hire engineers?

11 pointsnayshins10y ago7 comments

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?

7 comments

6 comments · 4 top-level

karterk10y ago· 2 in thread

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.

pmiller210y ago

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?

karterk10y ago

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.

pmiller210y ago

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_tik10y ago

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?

jotux10y ago

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

j / k navigate · click thread line to collapse