How can I better my interviews?

What is broken with software engineering interviews and how can it be fixed?

• Microsoft style 45-minute whiteboard interviews about data structures, algorithms, and brain-teasers only go so far. Some companies have swapped out that interviewing style with a coding project to see how the person fits in that workflow instead. What is broken about the interview process and what alternative solution would be better? See also: http://www.jeanhsu.com/2011/08/30/redesigning-technical-hiring-process/ and http://www.humbledmba.com/everyone-sucks-at-interviewing-everyone

• Answer:

  In my experience, many great people are looking for jobs, not contract work.  The vast majority of excellent engineers I have hired were employed elsewhere when I found them, and I recruited them away.  There's no way I could have done that with Freedman's suggestion of contract work first. In my experience, you have to hire into a probationary period, and then fire if that doesn't work out.  It's like what Freedman suggests, except it's default-stay instead of default-go, and it's essential to do things this way if you want to be able to hire out of as large a pool as possible. I don't spend a lot of time doing standard coding interviews because I do try to hire either people who already have jobs, or graduating college students.  (Although fizzbuzz at least is necessary for the latter; it's amazing what kinds of people can graduate with a CS degree). At the end of the day, I don't think there's a magical solution to the interview process, and I don't think that Freedman hires many top-notch engineers with his process.