Resumes are fine, it's really in how you treat them. When I read resumes I generally ignore where people have worked and gone to school and instead look for what they have done. If there's either a good match between the general type of stuff they've done in the past and what the role is, or if there's stuff on there that is interesting enough such that I'd enjoy hearing about it, I give a thumbs up.
When I interview, I tend to spend most of the time asking in depth questions about the projects I find most interesting on the resume. What was easy? What was hard? X sounds like it would be a problem, how did you solve it? What was fun? What was headbangonthewall miserable? Generally this gives a sense as to whether or not there's any bullshitting going on, and gives a sense for whether or not the candidate has a good head for thinking about hard problems.
Finally, I'll ask a few questions to probe for "difficult-to-work-with" red flags and finish with a few fairly easy "technical challenges" that offer opportunity for the candidate to either walk about having solved the problem, or walk away having solved the problem and demonstrated understanding of the solution from top to bottom.
What kind of "difficult-to-work-with" questions do you ask? I'd like to filter out these people but I'm not sure what sorts of questions to ask to suss that out.
Basically I goad them into complaining about past bad work experiences and then pay close attention for subtle clues that may indicate that they are systemically disrespectful or unwilling to compromise on things that don't seem worth fighting for. Were they bothered by people, situations or outcomes?
Tell me about the most frustrating time when you needed a thing, or consensus on a thing, and you had to go through way too much to get it.
Tell me about the most frustrating time when you needed a thing, or consensus on a thing, and no matter how hard you pushed, you never got it.
And, of course: The fastest way to be shown the door around here is to be an agitator of your colleagues on the grounds of race, sex, religion or any other attribute that has little to do with work. Nobody here is in the business of policing behavior and nobody wants to be. This requires perhaps more discipline than other places as the hammer falls harder and quicker here if things go awry, so it demands either heightened discretion or a heightened sense of self awareness and awareness of those around you. Do you think you would be able to work under such conditions?
I'm not quite sure what you're trying to ask with that last question. I can't tell if you're saying "you're out if you behave badly" or "you're out if you complain about other people people behaving badly"; "Nobody here is in the business of policing behavior and nobody wants to be" comes across as the latter.
> unwilling to compromise on things that don't seem worth fighting for
It's quite possible the interviewee thinks the item is worth fighting, but you don't because of different principles/axioms. Are you looking for a justification in this case?
On the positive side, you might have someone complaining bitterly because the codebase they worked on had twelve different implementations of string/buffer classes and was resistant to any attempt to unify them. Or someone complaining that they pushed for continuous integration and never checking in anything that broke the build, but people kept bypassing code review and breaking things anyway. Or that there was a standard release process in place for hotfixes, but some Nth-level manager handling a customer escalation would demand a one-off release for their customer without going through the normal process. A well-explained complaint like that would suggest that the interviewee pushes for good processes and solid engineering practices.
On the negative side, you might have someone complaining at length about a bikeshed issue (see http://blue.bikeshed.com/), or complaining about processes they had to follow that sound reasonable to you (for instance, "one change per commit", or "don't break the build"). Or someone complaining bitterly that they don't get to use technologies invented five minutes ago.
It's a lot easier to get information about what people stand for and care about by finding out what they fight against.
What about the opposite, someone who has no answer for either of those because they have never pushed hard enough for something or is too willing to roll over whenever someone higher up insists on something?
If that were a problem, they'd be unlikely to have interesting projects on their resume or would have failed the "talk about your interesting projects" phase. In other words: it wouldn't matter if they were easy to work with in that case because they wouldn't be considered a good candidate for the job.
Every single time I read these recruitment threads on HN or anywhere else it always comes back to "who can bullshit the most" and "can you solve this ridiculous problem you will never encounter while employed here".
Glad to see an article about trying something different in recruitment, it is a BS industry, partly because it is so difficult to measure "success" and follow up the process with meaningful data.
It sounds like you're saying "resumes are fine, as long as you ignore most of the stuff that is considered important in contemporary resume culture." It's broken at a conceptual level, even if there are functional workarounds.
The experiment from the article basically does what you describe, cuts out the stuff to ignore and goes straight to the project history. It would be beneficial for this to spread even if some people can suss it out in the current process, because there is still a large culture of looking heavily at things like alma mater and GPA.
When I interview, I tend to spend most of the time asking in depth questions about the projects I find most interesting on the resume. What was easy? What was hard? X sounds like it would be a problem, how did you solve it? What was fun? What was headbangonthewall miserable? Generally this gives a sense as to whether or not there's any bullshitting going on, and gives a sense for whether or not the candidate has a good head for thinking about hard problems.
Finally, I'll ask a few questions to probe for "difficult-to-work-with" red flags and finish with a few fairly easy "technical challenges" that offer opportunity for the candidate to either walk about having solved the problem, or walk away having solved the problem and demonstrated understanding of the solution from top to bottom.