[seanwilson]

> As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.

Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?

[woud420]

It's quite easy, just use bias. (No, not really)

[ubernostrum]

How are you expected to weed out unsuitable candidates?

Here are my rules:

1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them.

2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living.

3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language.

4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code.

5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE.

6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember?

7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill.

8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job.

I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.