People suck at technical interviews (2014)

1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume.

2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins

3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code

4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins.

5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins.

The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?

The project also spares the rest of the team from wasting time interviewing non-serious candidates.

Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail.

Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!).

So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did).

Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking....

Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...

This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together.

All interviewing I do, I do while talking to them and give them ample time to explain it back to me.

The candidate is investing their time. You should have enough respect to invest your time too.

The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.

> I would expect a video call where we go over the code together.

Thats what the next step is for.