"I do think that the grueling and intimidating software interview process is a very serious problem in our field."

I'd have to agree. The interview process is irreducibly stressful, but that doesn't mean we have to go out of our way to make it worse. It isn't even good for hiring most men either, after all! It's just a bad idea.

I've personally had fairly good success hiring people who happen to be women, and I suspect a good part of that is that my interview attitude is that I'm there to find out what you can do, not to find out what you can't, which seems to be the unexamined default of a lot of interviewers. You don't start at "perfect" and get marks off for failure... you start at essentially zero and work your way up. "Starting at zero" may sound superficially harsh when I put it into English, but in practice this produces a much friendlier interview environment, I think, because we're discovering positive aspects instead of negative ones.

(Another reason to prefer this is that in practice this also helps avoid the problem of the senior candidate being thrown softballs, or the junior candidate being asked to design a cloud infrastructure. It really doesn't take that long for me to key in on where your most likely "knowledge frontier" is and probe for details there. As opposed to just going through a rote set of questions looking for demerits. It is a harder style of interviewing, though, precisely because you can't just go through a rote set of questions... even the standard question set I use has a lot of ways of approaching them and several "levels of detail" I can get into depending on experience and skill level.)

The end result is still, frankly, stressful. It's a big deal, and the interviewee would have to be outright irrational to forget that. But it helps if you as an interviewer remember that, too, and have some compassion.

> my interview attitude is that I'm there to find out what you can do, not to find out what you can't,

Have you ever considered trying to find out and confirm what the candidate has done in the past, instead of the almost impossible task of finding out what they "can do" in a few short hours? Barring some major new life issue, a developer's past performance is highly predictive of their future performance.

Edit: Removed longish rant.

If I can, yes. But many interviewees are not prepared for that, and I've had to adapt to that.

If you are interviewing, please by all means bring samples of your work and be ready to discuss them, if you possibly can. But some people come from places where they can't talk about what they did (like, literally, Federal law in some cases), or for some other good reason can't really substantiate what they did.

You also have to account for the fact that a lot of the ways of finding out what they did in the past are somewhat unreliable. Many past employers have their own reasons for not being forthcoming or entirely truthful. The interviewee is incentivized to exaggerate their claims. In this context it's hard to get very much solid information of the type you're asking for.

My preference is to see past accomplishments, then use the interview to substantiate that they are indeed your accomplishments and you were not just generally in the area of accomplishments that happened to be occurring. But alas, that's not always an option.

That's what interviews for hardware engineers are like. I'm an embedded systems engineer, and as such about half my work is programming. I've only worked for companies that are primarily electronics manufacturers. I've hesitated to apply to companies that are more software focused largely because of my perception of their interview process.

Interviews for electronic engineers consist mostly of talking about projects the candidate has worked on (for young people these might be college and hobby projects). The interviewer's questions are things like "what did you consider the most difficult part of that project?" or "What tools did you use for that?" or "why did you do it that way and not this other way?" No one has ever asked me to design something on a whiteboard, nor would they dream of asking me to rattle off the pinout of some random microprocessor.

The software company interviews I hear about sound more like someone being tested to prove they aren't lying about their qualifications than like adults discussing a business deal.

What about developers with little experience, that come right out of school, or are applying for an internship position? Are you going to cut them out of the process? If so, are you okay with the fact that you'll often be missing out on getting an early lead on good junior developers? Good developers rarely kick around on the job market, and so it's often much more difficult to hire them when they've become more senior. Joel Spolsky's take:

http://www.joelonsoftware.com/articles/FindingGreatDeveloper...

I'm not suggesting to do this exclusively. By all means, hire promising devs out of college using the method the GP prefers.

I'm just suggesting that when an applicant like this exists before you, it makes more sense (assuming you're happy with their accomplishments) to confirm that these are indeed their accomplishments than to try to cram in some ad hoc heuristic for determining their range of skills in an hour or two.

And if my peers are any indication, the reason it's become so hard to hire senior devs is that no one wants to go through the headache of the interview process anymore once you've reached a moderately satisfactory job situation.

When I used to hire people, I focused more on their intelligence, their focus, and their motivation. Any idiot can google snippets of code or memorize answers to questions. What I wanted was someone that could handle learning what they don't know, motivate themselves to get the job done, and most of all, get the job done.

And you can't figure those things out just by looking at a resume or by quizzing them for hours until they break. You have to actually talk with them. Engage them in conversation. Learn who they are and how they fit into this field. Learn about their past experiences and their future goals. Then the question as to whether or not to hire them is easy.

Resumes are a starting point. Previous knowledge is a time-saver. Problem-solving and motivation is where its at.

*As a side note, most of my interviews were 30 minutes or less. I only regretted one hire, and I got rid of him pretty quickly.

Well if you want to be an innovator in that space, then you can offer an interview process that is more friendly to them.

That means, no onsite interview processes that require taking vacation days to complete mostly. Or off hours interview processes.

Talk to them about school projects or classes. I recall one candidate was in a compiler class, and told me about the compiler s/he had working. I asked 'what's a recursive descent parser'. They didn't recognize the term. I asked what grammar the language had. They didn't know. Other's show excitement, talk about having had to study things on their own because it wasn't covered in class but they really wanted to learn it, and so on. You quickly get a sense of who has a fire burning and who is going through the motions.

It's tough though, because when you are a small company that expects developers to jump in and be productive, you do need some kind of process. That process can be referral based, in which case testing isn't as necessary because you can rely on past shared experience, but that obviously limits your talent pool.

When you are interacting with an unknown (or a less known) person, you have to have some kind of vetting process. And with a small company culture, typically false negatives are far less harmful than false positives.

You're making fair points. I think I understand the equation you're setting up here (harm of false positive vs harm of false negative, along with probabilities for each). I'm just starting to believe that the damage of so many false negatives to avoid the occasional false positive may be harming the industry more than we realize.

Let's not forget, we're an industry where employers very consistently claim a serious and economically harmful shortage of talented developers. At the same time, we're an industry that accepts an interview process they open acknowledge will result in the rejection of good candidates because they feel that the damage of a false positive is so high.

Is there a chance that there is a strong "negativity bias" at work here?

http://en.wikipedia.org/wiki/Negativity_bias

In other words, is it possible that the bad memories of a false positive is masking the thousand paper cuts that are inflicted on the high tech workforce though grueling interviews? What overall harm does it do to an industry when a programmer who would have been successful gets rejected from a promising job due to a poor performance on a one hour data structures problem at a white board? I think there's the harm you see, and then the harm you don't.

This one line suggests the harm may be serious and extensive. I'm not making any particular prescription here, I'm just saying that when developers experience repeated rejections due to repeated false negatives, this may be vastly more harmful in a global sense than people currently realize.

EDIT: false positive/negative switch (vonmoltke mentioned below).

> I'm just starting to believe that the damage of so many false positives to avoid the occasional false negative may be harming the industry more than we realize.

I think you have "false positive" and "false negative" backwards, but I agree with your point. I have long thought that the industry systematically understates the damage of false negatives and overstates the damage of false positives.

If you are hiring, it fits one of two broad categories: catch as catch can, or specific need. In a catch as catch can situation, the "always hiring" mode, the company can afford to place more emphasis on minimizing the false positive rate at the expense of the false negative rate because the desire is to skim the cream off the top of the applicant pool as it comes to you. The company doesn't need new people per se; it finds slots for these highly-capable people somewhere in the company after the hire is made.

In the specific need situation, the company is hiring to fill a hole. Either work is not getting done, or other people are overburdened with the responsibilities this new hire will take on. In this case, every day that passes costs the company in some way. The cost of a false negative is related to the quality and size of the applicant pipeline. A false negative could add anywhere from a few days, if the company has a strong pipeline, to a few months, if the company has a weak pipeline, to the timeline for filling this position. The "false negatives are cheap" position comes from the former, but I would say that very few companies actually have an applicant pipeline that strong. Furthermore, if you can go months without filling a position and not suffer any ill effects, you need to ask yourself why you are looking for someone in the first place.

You're on to something here. There's the specific, need-based interview, and there's the "sure, we're always looking for talent" interview.

The latter can lead to an unintended problem. I once went on an interview where I was passed from room to room, on the hour, and taken through my technical paces each time. Each interview was intensely technical. If my interview had been my only exposure to the company (i.e., I hadn't gone to the site, read press releases and articles, and so forth), I would have no idea what the company does, other than that it seems to involve operations-research style math (optimization and stochastic processes), data structures and algorithms, and complex sql. I certainly would have no idea what they planned on having me do from a business point of view. I didn't get an offer (was busy, hadn't adequately refreshed my knowledge of tree traversal, markov chains, and linear optimization to immediate post-exam undergrad/grad levels), but I wasn't hot on the company anyway, because it left me with the impression that they wouldn't value my business input in any way.

So, why would they do this? Maybe they're just sort of looking generally for people. They figure, eh, if we find candidates who can rock an exam[1], sure, let's go ahead and make an offer, I'm sure we'll find something for them to do. Because their need isn't immediate, their standards (no false positives) will be set unusually high.

The unintended consequence is that yet another developer in this space is now reluctant to interview, because who wants to prepare for and re-take their undergraduate/graduate math and CS exams?

[1] At this point, I don't even think we should call this an interview, it was an exam that lasted longer than my MS graduate exams, with far less information about what would be tested.

I'm a big fan of looking at developers' github contributions. It's a good way to see that they can actually write code and it doesn't involve a high-pressure whiteboard test.

On the other hand, it can be a negative for somebody working for a company that discourages or forbids open sourcing their work. Or people who don't have free time to spend on FOSS projects.

...or who work on open source projects that aren't hosted on github?

Don't confuse activity for productivity. Most of the activities people engage in when searching for a new employee are complete wastes of time, at best.

I personally find it is net-better to stop wasting that time, just try people at essentially random, and get back to my own work.

Only if you have a policy of not having positions for Junior programmers.

Fog Creek has the same hypocrisy as any other company that demands X years of experience from applicants but consider it somebody else's problem how they get that.

As a business owner who is a developer and hires developers: getting my experience was my responsibility. It's now yours. And you won't do it on my dime.

I'm not in the business of using money to make developers. I'm in the business of using developers to make money. The jobs I offer are not because I want to give someone a job, they're because I want someone to come do a job for me.

Until very recently, the vast majority of Fog Creek's devs came through the internship program. Which is restricted to people who are going back to school afterwards (and, with a few exceptions, is only for undergrads).

Worse: they demand that you can code, and don't consider it their problem to teach you how to do that.

Anyway I thought it was well established that years of experience is a bullshit measurement anyway and you should just apply no matter what - worst thing happens, you end up getting hired.

The worst that happens is that you have a bunch of go-nowhere time-wasting interviews with people who can't properly evaluate you anyway.

That time is certainly valuable to me.

That would be bad, but consider the time wasted if you ended up being hired by them.

I agree.

Personally, I can handle all sorts of adversarial situations, but I've never done well with "rigorous" interviews. I think I was raised to be humble and that's built into my DNA, but the business world embraces overpromise/underdeliver.

At the same time, I've successfully managed large teams, budgets, interfaced with super-high level people and negotiated hard-nosed deals. I gotten myself into these roles by other means -- 90% of interviews that I have done have been formalities.

IMO, that's a symptom of a bigger problem, as what you do has more to do with where you are and who you know than any other factor.

It's why I switched to a PM role. I miss programming every day, but I hate the thought of doing another stupid technical interview.

Not all companies require them if you have decent experience. My friend interviewed with several companies and flat out told them "I don't do code tests anymore, my experience should speak for itself." Obviously your milage will vary but he ended up in a good position at a large well known company.

Edit: Also if you have a connection into the company that can vouch for you, that will work as well. The best coding test that can be administered is "yeah I've worked with this guy before and he's a good developer."

As I often say, interviews based on the final year algorithms and datastructures exam are just a way to sneak ageism under the HR radar.

What final year algorithms and data structures exam are you referring to?

Questions like pruning a red-black tree or manipulating a linked list on a whiteboard.

Actually I was more curious about the final year exam itself. Is this required in some schools? I have never heard of such a thing in colleges in the US.

No algorithms and datastructures in CS??

i can only imagine people who work at Google are some sort of interview ninjas.

I disagree. How many people actually do the bare minimum and work their way through Cracking the Code Interview, and make sure they know all of the material covered by those questions? I think having that would do a long way towards proving oneself in the tech interviews.