ramblinjan

A phenomenal candidate can leave pretty easily, too.

But when I'm taking about not being afraid to make a "no hire" call, I'm not talking about the incredibly strong candidates. They tend to shine pretty well if you don't have a hiring process that is difficult for the sake of being difficult (e.g. brain teasers and whiteboarding). When I talk about not being afraid to dismiss someone, I'm talking about the (perhaps admirable) human urge to give an underwhelming candidate another shot.

> then be upfront about that instead of surprising candidates during a stressful interview

People are rarely humble enough to actually reflect on this if they're excited about a job.

> People should be aware of what they accidentally select for in candidates

Absolutely.

There's also the cost of impact on a team, etc.

Shameless self-plug, though, for another post I wrote about organizational process: http://ramblinjan.com/development/2016/07/05/Going-Agile-Whe...

I definitely haven't given up on fixing those. I just, uh...I have a lot of feelings.

It's really really hard to come up with explicit actionable advice when a core part of your argument is that you need to do what is right for your team/company. To extend my TDD analogy, it would be like trying to write tests for someone else's codebase without any context.

If you want some specific feedback for your team, please reach out to me on Twitter. I'm always thrilled to talk to people about process and organizational development. I'd love to chat with you about actionable ideas for your specific need.

You've got me looking back at what I've written, because I actually agree with you on company culture (if the company's culture is a positive force). My point about technical recruiters is because they're very often totally separated from the engineering culture. Oddly enough, I'm speaking about smaller companies more so than bigger ones because a large company is less likely to give their engineering teams enough autonomy to really do anything with what I've written.

The main thing I wanted to get at here is that a hiring process can not be thought of as separate from your engineering process. I'm not trying to argue that hiring should be insulated from reality. I'm arguing that there are a lot of companies who are ignoring the fact that it isn't.

Isn't my original blog post at least a little bit of evidence that I've put a good bit of time into thinking about that?

I mean, a "bad hire" with the consulting/open source shop where I did a lot of interviewing & hiring was something pretty specific. A bad hire where I am right now is something pretty specific.

I hate the "objective statement" (since it is almost always just filler nonsense), but a good personal statement can go a long way. It's like a good thesis statement: make a bold claim that is backed up by the evidence in the resume. But it helps to tell people what unique stuff they should look for.

I'll have to think some on this. I really was not trying to take the brutal "we only hire the best" nonsense that a lot of companies do.

Thanks!

Definitely didn't take it as pedantic. Thanks for the reminder about the impact this could have on an audience I didn't think about. I added a small disclaimer.

Made a small edit based on your comment. Thanks!

Made a slight edit. Thanks for the feedback.

The title got updated by HN, I think. I'm not trying to call everything engineering (I don't actually think everything should be approached as an engineering process). My argument is that the decisions you make about culture and process in hiring inevitably affect your actual team's process.

It depends on your definition of "perfectly acceptable." Almost every job in every industry with a hiring cycle rejects "a majority of candidates," especially when there's limited space.

> These costs can easily outweigh the cost of a bad hire.

How so? You're right that I've relied a good bit on the anecdotal, but aren't you doing so a bit here? Bad hires are ridiculously costly--especially on a small team--because they aren't just expensive. On a good team, almost every new hire lowers everyone else's productivity initially.

Hiring more people because of loss aversion also falls prey to the trap of "more people = more productive" that's been pretty thoroughly debunked in the software industry (http://a.co/3ierKnl)

Fair point.

Thanks for the feedback. I'll have to give it some thought because it seems like I failed to explain this well enough (though I may just straight up be wrong about it altogether).

The candidates who ended up frustrated weren't feeling that way because we were jerks to them (I don't think). Maybe what I'm getting at is don't be afraid to push people to the limit a little bit in a task, because their reactions to it say as much as their approach.

This is a great point.

When I talk about intentionally frustrating candidates, it's mostly based on a technical interview we would do that a lot of people would struggle with. It hit the critical thinking itch, I think, and some people can't handle that. Y'all have me thinking that this section could use a little revision, though.

Good point. I tried to be pretty conservative so it didn't feel like I was fudging numbers to make a point about speed in earlier rounds, but I wonder if I should clarify.

I'll definitely include this when I write more for an audience of applicants. Resumes are soooooo boring, so anything to stick out is a big deal.

"Colleges and employers interested in predicting the success of applicants would do better to look at a student’s grades, which measure personality traits, like grit and attention to detail, more effectively than IQ and SAT tests"

High grades are a great predictor of high parent involvement and a knack for succeeding in a rigid education system. They might as well say colleges predicting long-term success should look at economic status of applicants.