rc3.org

Strong opinions, weakly held

Tag: hiring (page 1 of 2)

How to hire a superhero

University of Rochester computer science professor Philip Guo has written a great post, shining a light on the bias in the computer industry in favor of people who look like him (or me). In it, he explains how he has gotten the benefit of the doubt in situations simply because he looks like what people expect a computer programmer to look like. It’s a first-hand account of what John Scalzi talked about when he wrote about straight white males playing the game of life on easy mode.

Here’s a bit from the post, Silent Technical Privilege:

… people who look like me can just kinda do programming for work if we want, or not do it, or switch into it later, or out of it again, or work quietly, or nerd-rant on how Ruby sucks or rocks or whatever, or name-drop monads. And nobody will make remarks about our appearance, about whether we’re truly dedicated hackers, or how our behavior might reflect badly on “our kind” of people. That’s silent technical privilege.

He contrasts that with the challenges placed before people who are outside the demographic sweet spot that so many people associate with being a computer programmer. As he says, you don’t have to be a superhero to succeed in software development, and we shouldn’t demand that people who don’t enjoy these privileges be superheros to make it in this business.

This leads me to the theory that if you want to hire superheros, you should ditch your biases and expand your hiring pool. The people who have persisted and succeeded in this industry in the face of the inequeties that Philip documents are much likelier to be superheros than your run of the mill bro who shows up to the inteview in his GitHub T-shirt with a cool story about making money in high school by creating Web sites for local businesses. There are plenty of superheros that fall into the privileged category, but they already have good jobs because they will never, ever be overlooked in the hiring process. The awesome programmer who also seems like they’d be super fun to have around the office? They get a job offer every single time.

The enterprising hiring manager has to think outside the box a bit. You know the feeling. The person seems like they’d be great at the job, but is different enough from everyone else that you wonder a bit how hiring them would affect team chemistry. I’m not talking about personality here, but demographics. (I’d never recommend that a non-competitor hire brilliant jerks.) The hypothetical candidate I’m talking about here has to deal with these unspoken questions every single time they apply for a job. That’s not fair, and it’s incumbent on our industry to change, but in the meantime, it’s possible to exploit these widespread biases to hire the superheros that most companies won’t even consider. At least that’s the theory.

The costly bias against older workers

Harvard Business Review posted an interview with MIT professor Ofer Sharone about the limited job prospects for older workers, especially the long-term unemployed. I agree with most everything Sharone says, but I want to put a bit of a different spin on it. In the interview, he addresses the excuses people use when they refuse to consider hiring older, LTU workers–skills mismatch, underemployment, and fear that they won’t stick around in general.

First, there’s the obvious point that I don’t see made often enough–if the job market were robust, none of these excuses would prevent businesses from hiring older workers, and the problem of long-term unemployment wouldn’t really exist because everybody who wants to work would have a job. Indeed, if economic growth were strong enough, people would be begging retirees to come back to work. This already happens in specific fields that enjoy full employment. I know I write this every time I write anything related to the economy, but it can’t be said often enough. The number one demand we should make as voters is that the federal government pursue policies that lead to greater economic growth.

Now I want to write a few paragraphs for people who are in the position to hire. I think it is inarguable that there’s a bias against hiring older workers in just about every field. I know the Web business well, and I know that it is lousy with ageism. From an economic perspective, this is painfully wrongheaded.

Recruiting great people is probably the most difficult task facing anyone whose job includes hiring. The competition for good people is intense, candidates are tough to evaluate, and the costs of getting it wrong or failing to fill key jobs can be really high. Plus, hiring isn’t a whole lot of fun. As a hiring manager, I’m always looking for an inefficiency that can be exploited. Bias against older workers is a truly spectacular inefficiency.

While you may disagree with the specifics of the 10,000 hour rule, at some reductive level it’s obviously true. Ten thousand hours is five years of full time work. If someone’s been in the work force 20 years, they’ve invested enough time to master four things, and one of those things is usually showing up to work and getting things done. Brilliance is great, but experience can be better, and there are plenty of people out there who are both brilliant and experienced. Age bias somehow makes it hard to see that some older workers are former young geniuses who’ve added a couple of decades of relevant experience since they started out.

The second advantage is that older workers have an actual track record of stuff they’ve delivered, and often that’s lots of lots of stuff. They’ve usually worked on all sorts of projects good and bad, with all kinds of managers good and bad. This track record makes it easier to evaluate them during the interview process. The tough part with older workers is that you have to be somewhat clever when you’re hiring, because you can’t afford the older workers who are obviously great. They’re pulling down huge paychecks at places like Google or Facebook running engineering teams or inventing the next generation of the tools you rely on.

The third advantage is that older workers can often be a useful stabilizing influence and source of perspective in an organization. Having people around who saw the highs and lows of the dot com boom is not a bad thing. If you’re in finance, having people around who remember both the 2008 financial crisis and the savings and loan crisis from the 80’s is probably a good idea. After reading The Soul of a New Machine, I’d love to work with anyone from that team. They know things about working on a high pressure skunkworks project that anybody could learn from. Things aren’t that different than they used to be, but if you don’t work with anyone who’s been around awhile, you’d never know that.

Here’s the catch. There are a fair number of people who discover over time that their profession isn’t really something they’re passionate about, even if they started out that way. Maybe they don’t love the work as much as they thought they would at one time, or maybe that love was beaten out of them by a succession of crappy managers and sucky jobs. Keeping the fires burning brightly over the long term is a skill unto itself. When you’re interviewing older workers, you’re interviewing people who may have already figured out that for them, the job is just a job, but need to keep bringing a paycheck home every week. Regardless of how they get there, people who aren’t passionate about either their work or the mission can bring the whole team down.

Passion is the number one thing I look for at an interview. A fair number of people are obviously brimming with sincere passion for the company, or some aspect of the job, or something that will propel them to show up every day with the kind of energy that makes work fun. For those that aren’t, the best approach is to find a topic that makes their eyes light up, whether it’s programming, or stamp collecting, or Seinfeld, and then comparing that level of passion to their passion when they talk about the work they’ll be doing.

Right now, older people are an undervalued asset. Smart business people will figure out how to take advantage of that inefficiency. I’m not just saying that because I turned into an older person when I wasn’t paying attention.

Interviewing is just a model of employment

Etsy has gotten a lot of attention for its efforts to increase the gender diversity of its engineering team in the past year. The short version of the story is, Etsy made a concerted effort to recruit more female engineers, and made some changes to its hiring model that led to positive changes there. For more details, see First Round Capital’s coverage of a talk on how we did it by Kellan Elliot-McCrea, our CTO.

Unsurprisingly, this effort has drawn criticism. The most visible example is a blog post from Meghan Casserly from Forbes, which accuses Etsy of instituting a double standard, undermining female engineers even as it attempts to add more to its staff. Here’s the crux of her post:

In other words, hiring women engineers is hard. Especially if you hire them like men. “Don’t lower standards,” Elliott-McCrea says, but isn’t exempting women from the same brutal challenge-based interviews their male colleagues undergo doing just that? While I applaud Etsy for its single-minded dedication to increasing gender diversity in its ranks, instead of feeling uplifted by Elliott-McCrea’s presentation I find myself stuck on the question: Is hiring women as women just PC pandering?

There’s a lot that’s wrong with this blog post, starting with the assertion that Etsy has exempted women from anything. For example, “brutal challenge-based interviews” were never a standard part of the interviewing process at Etsy.

The post serves to illustrate a larger point that I want to make. The reason companies interview engineers at all is that they need to assess what kind of team member they’ll be. Can they write code? Can they deliver results in a timely fashion? Will they drive everyone nuts? Are they capable of learning? Interviewing is one way to get the answers to those kinds of questions.

The hiring process is about creating a model of a potential employee that the employer hopes accurately represents what kind of employee they will be. These models are not terribly accurate, and there is a huge amount of space within which a company can experiment in order to refine that model.

Nobody has convinced me that stressful “challenge” style interviews accurately model the work of software developers. People who do well at them are not necessarily more qualified than people who do poorly at them. Answering interview questions is itself a skill, and being good at it doesn’t mean you’ll necessarily be good at the job. Etsy is iterating on how it builds a model of software engineers through the hiring process. Every company should be.

Fetishizing interviewing, or a specific style of interviewing, betrays the same sort of lazy thinking that I wrote about the other day. I’ve seen great engineers turned down for jobs due solely to the fact that the entire panel of interviewers all took the same approach. The model was broken, but the interviewers thought that the problem was that the candidate wasn’t up to the challenge. The Forbes blog post falls prey to the same problem.

Lauren Bacon makes a related point in her response to the same Forbes blog post.

What are job interviews for, anyway?

I read two blog posts on Friday that made for an interesting contrast. The first was a post by Mike Loukides arguing that the problem with the economy is not a lack of qualified candidates, but rather a lack of flexibility on the part of employers when it comes to who they hire. The other post I read was by Carlos Bueno on how to get hired at Facebook. He references an earlier post by Steve Yegge on how to get hired at Google.

Not only do the posts from Facebook and Google focus on listing specific skills that engineers they might hire need, but they include skills that engineers will never actually use at work. For example, both of them focus on the need to prepare to program on a whiteboard. I have well over a decade of experience as a software developer, and I’ve never programmed on a whiteboard. I don’t feel particularly uncomfortable with it, but I don’t think it is a clear indication of one’s ability as a software developer.

I don’t worry about how Google and Facebook hire. Their process works well for them, and will continue to, as long as they remain some of the most desirable places in the industry to work. Their method isn’t going to work for your company, though.

For most companies, the way to find stars is to deemphasize skills and to focus on intelligence, attitude, and communication. There are no risk-free hires, and the low risk hires from a skills standpoint often lack creative potential. The skilled, creative people already have great jobs. I can teach a smart person about Big O notation in half an hour. Teaching a poor communicator to be work well with teammates is nearly impossible. Focus on what’s important.

In the end, the excessive focus on skills and experience that seems endemic is hurting more than it’s helping.

Why pre-screening applicant Facebook accounts is a bad idea

Reg Braithwaite’s (hypothetical) resignation letter makes it perfectly clear why companies demanding to pre-screen applicant Facebook accounts is a terrible and potentially self-destructive idea. Aside from the very real problems he mentions in his letter, there’s also the fact that if you are even tempted to do this, you need to grow up.

The perfect job ad

The perfect job description serves two purposes. It attracts the kind of people you would hope to hire, and almost as importantly, it discourages the sorts of people you don’t want to hire. Going through big piles of resumes is not fun. Job ads that extoll the virtues of your workplace without laying out any of the potential drawbacks may attract lots of resumes, but it’s almost certain that 90% of them will be from people you don’t want to screen, much less hire.

This ad for an investigative reporter from the Sarasota Herald-Tribune is a masterpiece of the form. Some number of people are going to be incredibly enthused by the ad, but a lot of people would read it and know instantly that they are not interested in or cut out for the job. I guarantee it saves them a lot of time.

I remember once interviewing someone about whom I had real doubts. I wasn’t sure what questions to ask to confirm my suspicions, so instead I just tried to scare them away by telling them that it was a small company and that people who couldn’t do the job would be exposed. Anyway, I was outvoted, the person was hired, and they didn’t last six months. Maybe we should have written a more honest job description.

One criteria for evaluating software developer candidates

I’m often thinking about what qualities make for a good software developer. One attribute that I think may be important is the capacity to keep the details of a large system in your head. What I mean is, the ability when someone brings up a new feature, to quickly know exactly how it should be implement in the context of the existing system. Or, to be able to recall where the code is in the system that performs some function that needs to be added to some other part of the system. These days, between search tools and the code navigation capabilities built into the better development tools, there are lots of ways to find things in a large body of code, but I think that having a mental map of a system remains valuable. I also think that having this ability may signify the presence other valuable traits that a developer should possess. After all, it’s not fundamentally different from having a good working knowledge of the Java collections framework or the popular Ruby gems or the massive number of PHP string functions.

Two questions for Friday afternoon:

  • Am I correct in assuming this is something you should look for in developers?
  • What questions would you ask in an interview to find out whether someone possesses this quality?

Buy your developers nice hardware

Not buying nice computers for software developers is a mistake. I put this so bluntly because I think it’s an easy mistake to make if you don’t really understand developers. I’m not going to make an argument based on the productivity gains to be had through the use of more powerful computers and bigger monitors. Those are good reasons to make sure people have the tools that make them most effective, but the reasoning behind making sure developers have nice computers goes beyond that.

First of all, it should be noted that many developers are computer enthusiasts. The developers you most want to hire fall into this category. They know the difference between the laptops Dell sells for $600 and the Lenovo ThinkPads that sell for $2,000. They can tell the difference between the nice 20″ LCD monitor and the crappy one. And in most cases, they care about those differences. So when they get a hand me down laptop or a new computer that’s substandard when they start a job, most developers find it a little disheartening. They know they could have something better, and in many cases they do have something better sitting at home on their desk. Ideally, when you’re looking to save money, it should be in an area where people won’t notice. When it comes to their tools, people notice.

The second point is that providing developers with top of the line tools lets them know that the company takes their work seriously. It almost doesn’t matter what someone gets paid — if they are given substandard equipment, it makes them feel like the company doesn’t really value their work, probably because whoever is making the decision doesn’t understand their work. Going all out on equipment is a strong signal to prospective employees that you have a clue.

And third, it’s not that expensive. Software developers tend to be pretty well compensated, and when you add on the amount of money it costs to provide benefits, a work space, and everything else, the difference between a cheap computer and a nice computer is really small. The most expensive laptop in the Apple Store is $2,500. The cheapest is $1,000.

To make my point, I’m collecting job ads that promise nice computer hardware to developers. Here’s a job posting from Tumblr:

You’ll get to work in a nice office in New York City on a Mac Pro with giant monitors on something you actually care about that’s used by well over a million people.

And here’s what Mint.com offers:

Engineers get their own top-of-the-line laptop with 4GB RAM and a docking station, and flat LCD monitor for their desk. Built-in unlimited mobile broadband is a company-sponsored option. Having the right tools is important.

I worry more about equipment purchases as someone who’s gone out and hired developers than as an end user. Finding good developers is really, really difficult, and companies should give themselves every advantage that they can. Having an equipment policy you can brag about is a tangible advantage, and I’m always amazed when companies forgo that advantage.

The modern developer résumé

This job posting led me to a thought — are people getting jobs based solely on their Github profile? If not, how long will it be before people do find jobs that way?

Maybe it’ll take a Github profile and a blog. If you know what someone has written about their work over a long period of time, and you know what kind of code they’re producing, what else is left? Interviewing for team fit, perhaps, but such a record certainly takes a lot of guesswork it seems.

On experience

The Presidential campaign this year has me thinking about the topic of experience. The Democrats have nominated the relatively inexperienced Barack Obama for President, and now John McCain has selected the even more inexperienced Sarah Palin as his running mate. It has me thinking about how I evaluate experience.

The approach is the same regardless of whether I’m deciding who to vote for in an election or which programmers to bring in for interviews based on their responses to a Craigslist ad. I see experience as a relatively primitive criteria for making decisions.

If I am looking at two programmers, and the only thing I know about them is that one has ten years of experience and the other has only one year of experience, my initial assumption will be that the more experienced programmer will be more capable when they start the job. Nobody competent would stop their evaluation at that point. Generally speaking, I read the résumés, Google them to see if they blog and to see what kind of things they’ve posted to online forums, and if they seem promising, bring them in for an interview.

What I really want to see in a programmer is desire, curiosity, intelligence, talent, and knowledge, probably in that order. Experience doesn’t tell me a whole lot about any of those qualities, what it mainly demonstrates is that they haven’t given up.

The nice things about political campaigns is that the media exposure given to candidates enables us to judge them by criteria beyond their level of experience. We learn how they’ve used their time in office, what they did before they entered politics, how they respond to the pressure of the campaign, and their knowledge and insights into the issues of the day. (Or at least what their political sense tells them to say they think about the issues of the day.)

Right now people are talking about Sarah Palin’s level of experience because we don’t know a whole lot more about her. But by November 4, we’ll have seen enough of her to be able to make judgements based on other, better criteria. Sadly we’ll have to listen to people on all sides prattle on about experience as though it’s highly indicative of something the whole time.

Older posts

© 2024 rc3.org

Theme by Anders NorenUp ↑