Hiring Is Broken – My interview experience in the tech industry

So, to clarify, you're advocating that programmers be hired based on resume, references, and a conversation about prior projects? I'm not sure I agree with this. It seems you'd be selecting for ability to present yourself as a good programmer over actually being a good programmer.

What is your objection to attempting to verify someone's programming skill directly? It's certainly not an easy thing to do, but it doesn't seem apparent to me that it's impossible or not worthwhile.

If the standard "whiteboard algorithmic brainteaser" is not a high quality signal (which I'm not sure I grant, Google seems to think it is, and they claim to have the data to back it up, though they're probably much, much more false-negative tolerant than most), it seems like there's plenty of dials to twist to try and increase the signal-to-noise and cost/benefit.

a) Length of interview (one hour? full day? trial run of several weeks?)

b) Topic (algorithmic vs. brainteaser vs. some attempt to simulate the "real world" to some level of fidelity?)

c) Interface (Whiteboard vs. on computer vs. something else?)

(I'm being a little disingenuous with the whiteboard vs. computer thing. I don't get the value of writing on a whiteboard. I'm kinda hoping someone might be able to elucidate that.)

There's probably not a one-size-fits-all. Depends on your tolerance for risk, how senior you're trying to hire, how tight the job market is, etc. But I really would hesitate to work at a place that just took people's word on their programming ability.

Seriously there's a job with your name on it if you're interested.

When I interview candidates I sit with them for half an hour or so to get to know them. Then I give them purposely broken, poorly written piece of code which I tell them to pull apart. This proves incredibly effective as even if they miss some of the more obvious errors I can at least point them in that area and then see if they can see the problem on their own. There are about 100 different things to talk about so it really gives me an idea of the level they are at, and also the type of programmer they are; passionate, lazy, smart, meticulous, inexperienced, confident etc. Then if I feel they are worth a second interview, I get them back to sit with me and my team for the day to see how they fit in with the team. Then all being well I offer the job.

I used to believe this myself, mostly because I didn't have a strong CS background and was still successful at carrying out software projects at a relatively high level.

The truth is, as I learned more CS I learned that these things are actually pretty crucial. Not necessarily for executing one single project, but for building a large system that scales reasonably? Absolutely. I spent years reinventing the wheel of basic data structures and algos simply because I did not know them or how to use them.

Bottom line: I would not want to work with the me of 5 years ago because I wrote shitty code while proudly proclaiming that CS was theoretical bullshit that didn't matter in web development, and I think many people who make these types of claims really just don't understand how applicable a good CS foundation is.

I'd agree that ideally you want some kind of work sample as well. Either an OS contribution, github or even small project written specifically for the interview. You can't ask someone to write enough code on an interview that you really see what happens when they have to structure a real project (ie: thousands of lines) or work within a real system (ie: millions of lines). This is where CS foundations in interviews have their relevancy.

And as they're all similar style questions, they should just read up on these. Hold off on interviews until you're confident, or just schedule the less-desirable firms first, so that you have enough time to read up.

Interviewees know that these questions are coming, they can control the schedule, and they're the only ones who know their own energy and state. Nobody tells them that it's up to them to do flow control. But it's a hot market and people want good programmers. Even if you don't do tree searches or inversions in your normal work day, you can show that you're good because you can understand this stuff. Most candidates can't. So please, take your time, skim the textbooks, take a few notes, maybe do a few flash cards.

Only way to bypass that is to start your own company or know somebody in a powerful position.