Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

Just because someone doesn't have many side projects doesn't mean they aren't a good developer. Often times we assume that other people will have had access to the same opportunities that we had - in college, in the workplace, and in life in general - but this is a fallacy. Perhaps a developer had to work their way through college and didn't have time to go to hackathons or work on side projects. Perhaps she was so busy running a developer network at her last job, in her last city, that she didn't work on something besides that. Or maybe they just don't care about side projects.

I think, ultimately, the goal of a technical interview is to get the interviewee talking about something that excites them. Seeing that an applicant can get excited, spend hours learning something, and dig deep into whatever they are interested in is the most important part of an interview.

Be careful with things like "cultural fit" as that nebulous term is often used to excuse personal problems. If you can, initially evaluate the interviewees work without looking at their name, race, gender, or other identifying information. By doing this, you help avoid inherent, subtle biases that your recruiters may have. Those biases exist everywhere, and the best we can do is take steps to mitigate their effects.

Finally, I think trial jobs are greatly under-appreciated. Offer an interviewee non-critical, non-trivial work on a week long contract basis. Pay them industry standard and work with them on the feature. If that feels right, hire them. If it doesn't, evaluate what went wrong and move forward from there.

I don't claim to have things figured out but I can create a list of things that owrk and things that don't work.

Things that work:

- white board interviews, they let you get a dialog going with the candidate,

- take home work, they let the candidate work at their own pace

- showing work samples, whether that's a hacker rank type thing or github repo or open source work that you use.

Things that don't work:

- white board interview, some people just aren't good at them and they don't map well to real world work

- take home work, its insulting to candidates that you expect them to do something on their own time without pay

- showing work samples, github repos, etc. To easy to fake or take others work as their own, some people don't work on open source-able code, etc

Hmm, so we can establish that no matter how you interview you'll cut out some good candidates. I think we've all come to the conclusion that there is not global maximum on how to hire. In my opinion, you're really just going to have to pick one option and stick with it.

As an aside, as a candidate that kind of sucks, if you don't like white board interviews then you're probably not going to work at a company like Google, Microsoft or Facebook. Your choices are to accept that you won't wokr there or to get better at white board interviews.

Well then we could start by looking at what really successful companies do.

The worlds most successful hedge funds tend to not allow people to really apply, instead they look around for who is doing great research and then reach out to them.

Now its easy to start by saying this isn't applicable to most other companies and you'd be right, your company probably can't have their pick of MIT professors, but it does open up an interesting line of thinking.

What are you looking for in a candidate and how do you find people who are doing great work in that area.

Honestly, I think finance has this area figured out better than tech does. They either hire new grads by doing very heavy university recruiting or they hire from competitors.

In finance the saying is that by the time you are 30 you don't need a resume anymore as wall street is so incestuous that everyone knows everyone else. You are only 1-3 degrees of freedom away from any other person, which means that to hire someone, I just need to pick up a phone and ask the 5 people I know that the candidate has worked with to see if a candidate is worth hiring.

The best technical interviews I've been involved with seem to be mostly conversation about what the candidate has done and likes to do, and what the company wants and is like. Typically the candidate has a general impression of the company from having heard about or read about it (or having friends that work there), and the company has a general impression of the candidate from their resume, cover letter, some public code/etc., and possibly common acquaintances. That seems to produce the best results.

EDIT: More importantly, the key problem in hiring is not finding people that are technically qualified. The key problem is assembling teams of people who mesh well and are productive as a team. The world's companies are filled with teams of brilliant people who don't work well together.

- Take home work immediately. Maybe it's just me but I'd rather not get this after the phone screen and whatever else. Just give me the work and have me submit it with my application or after I apply.

- Phone screen. This is important. When I say a phone call, I mean a phone call. I've interviewed with companies that refuse to have a regular phone call and will only do video calls over skype/hangouts/whatever. This is such a Silicon Valley thing. Guess what? Not everyone is in a situation where they can easily setup a video call. I know I'm not.

- Technical interview. Honestly the best technical interview I've seen is where the company ask you to get one of your old projects, walk them through how and why you structured the code the way you did, and then pair program with someone on the team and add a feature to the project. If you don't have past projects like that you can pair program on their code base.

When it comes to technical interviews and take home work, if you are asking questions that can be googled in 5 seconds then you are just wasting my time.

> [1] The best predictor of how someone will perform in a job is a work sample test (29 percent). This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it.

Based on the statistics he provided, it seems like a combination of work sample and behavioral questions will typically produce the best results.

The problem is that Google gets ~2 million applications per year, so there needs to be an aggressive, quick funneling process. If you're a smaller company, you can definitely afford to slow down and give candidates more of a chance.

[1] https://www.wired.com/2015/04/hire-like-google/

Then perhaps a phone interview so that the company can confirm I'm likely not cheating.

Finally an onsite white board interview or written test or at the computer programming test. Yes I get nervous doing white board interviews but if the difficulty level of the problem is not too great it is a useful filter.

I dislike long take home work because it requires too much of a time sink and it could be abused by employers fishing for ideas, competitor information, or just wanting free work for one of their problem areas. Algorithm tests on hackerrank or leetcode or wherever are still useful practice but take home tests can be too job specific and therefore prematurely requires candidates to commit to learning a particular companies needs without the company committing anything in return.

Questioning candidates about their experience in an informal manner by conversation may be of some benefit, but is likely just testing how well the candidate has prepared various stories about their past employment and past projects. Unfortunately, abandoned projects that taught a candidate a lot and served their intended purpose may not make as good a portfolio or story as completed projects that were just cookie-cutter implementations of projects found in books or tutorials or elsewhere.

The important thing for all of these filters though is that they be carefully calibrated in difficulty to the companies needs and job sourcing pool. If your large top-N company carefully optimizes it's customer funnel with a/b testing but has no real employee hiring sanity checks, then that is not good. Randomly have one employee at the company white board interview another employee at the company from a different department. Secretly test your interview process with known good programmers from outside the company.

Asking for a prepared presentation is a nice alternative to take home coding (If applicable to your work culture).

Phone call trumps videochat every time. Our communication isn't strengthened by a video chat unless there are prepared visual aids, don't solve problems that don't exist.

Let me know who I will be meeting during 'in person' interview. What teams are they on.

Live coding with a current employee is a good practice. Keep problems small, and loosely specified.