Don't hire only self-described awesome developers | Hacker News Reader

Don't hire only self-described awesome developers

blog.hirelite.com

94 pointsnathanh80 comments

I agree that self-evaluation is a poor filter. That being said... I know that I am not actually "awesome." From time to time I do something people tell me is awesome, but that's because I do a lot of things and once in a while something I try turns out ok.

But here's the thing: I've never been rejected for a job because someone said "Mr. Braithwaite, we advertised for awesome, and you are not awesome." Everybody seems to be in on the secret that "awesome developer" doesn't actually mean John Carmack, Linus Torvalds, and Andy Hertzfeld rolled into one with a side of Alan Turing.

So while I don't think of myself as awesome, I look at advertisements for "awesome developers" the same way I look at advertisements touting the "awesome team culture" and "awesome office location" and the "awesome potential to get stinking rich." I just ignore them.

This may not apply to everyone, but I'm sure that advertising for an "awesome developer" will still get you good people who have self-critical capabilities. They just have to be a little jaded and cynical. In which case, it may not lose you a candidate, but it won't win you any candidates either.

So I doubt it's seriously harmful, but I also doubt it's a great strategy.

p.s. Now that my secret's out, I expect someone is going to phone screen me one day and ask: "So, are you really, really awesome? Because if not, we're done with this call." And I'll have to 'fess up.

Awesome point there.

Almost by definition, anyone who really is a badass, rockstar, ninja, etc. at what they do is viscerally repelled by the cockiness exuding from job ads seeking people who describe themselves as such... and would never dream of applying for such jobs.

Why is that the definition of "badass, rockstar, ninja, etc."?

Well, there's the cockiness, but there's also the fact that many times those words are code for "slave". My first job was like that. They advertised for "rockstar" .Net programmers. Only, in this case, "rockstar" apparently meant "willing to work 18 hour days for no extra pay or benefits save the manager telling you how awesome you are and how much money you're saving the company". Ever since that, I've looked at job postings looking for "rockstars" or "ninjas" with a jaundiced eye.

I was going to comment along these lines, but you summed it up very well.

This could possibly be A/B tested, i.e. have one job that's described as looking for 'awesome' vs 'good' developers for the same job and see what type of candidates it attracts at various levels of the interview process.

Here's a post about basics of job descriptions, but it also has some tips for a/b testing your hiring posts: http://katemats.com/benefits-job-description-prove-wrong/

Really great point re: ignoring self-proclaimed awesome anything. I automatically filter out meaningless words, but I also read through job posts quickly so sometimes I'm inexact and accidentally filter out the entire post. I guess it's up to the company if they want to read this post and improve, or risk getting ignored by busy readers?

When I see job post titles like these, sometimes I find myself trying to give the company the benefit of the doubt and assume that they're just bragging about themselves instead of asking developers to evaluate themselves ("awesome developer" => "awesome job for a developer").

It's fine to brag, but they can do so much better than a single dimensional word like awesome. All companies think they're awesome. I'd love it if they took the time to express the subtleties of WHY they think they're awesome.

p.s. Thanks for the comment. I read a lot of your writing and appreciate the perspective.

Its become ad-speak, like in car commercials when they always seem to claim "the best X in its class". For the most part, meaningless. Something to fill the space.

Great point. I've always said that the danger with thinking you are awesome is that it makes you stop learning.

I used to think I was awesome back when I didn't know anything more than a single language and paradigm. It's only years later by seeing a second language, then a third and by looking at other projects' sources that I realized how silly being awesome really is.

After a decade of writing code, I've reached the point where I learned enough to admit I know next to nothing.

> sorry to break it to you, but a little over 49% of developers are below average.

I'm being nitpicky, but this isn't true (unless you're talking about the median).

I think developers follow a skewed distribution by most measures (prolificacy, quality), with something more like a power law distribution. If this is true, the majority of developers are below-average. A sobering thought!

The opposite is also possible however. If 90% of developers are equally good, and 10% are really terrible, then 90% of developers could be above average. If this is the type of problem your devs are solving, you shouldn't be paying top wages or trying to get "ninjas."

Nitpick aside, this is a great article about avoiding the wrong kind of self-selection in your applicant pool.

The overwhelming majority of natural phenomena follow the normal distribution. Do you have any reason for assuming software development is somehow different?

Well, I don't know how you got that assertion about the normal distribution. But, one reason you could think it's not a simple normal distribution is that computer science classes often have bimodal grade distributions.

Software development is not a natural phenomenon.

A lot of genetic traits follow normal distribution due to the way genes are combined. It doesn't follow at all from this that human skill follows a normal distribution, especially looking at the whole population. It seems to be more like a power law distribution.

Distribution of software development skill in the entire population is probably normal. However, developers are not the entire population, they are a tiny slice of the right tail. So the distribution is more like an exponential distribution, which has the mean smaller than the median.

The performance of doctors follows the normal distribution. I think that extrapolating to programmers is not a huge stretch.

    It used to be assumed that differences among hospitals
    or doctors in a particular specialty were generally 
    insignificant. If you plotted a graph showing the 
    results of all the centers treating cystic fibrosis—or 
    any other disease, for that matter—people expected that 
    the curve would look something like a shark fin, with 
    most places clustered around the very best outcomes.
    But the evidence has begun to indicate otherwise. What
    you tend to find is a bell curve: a handful of team
    with disturbingly poor outcomes for their patients, a
    handful with remarkably good results, and a great
    undistinguished middle.

http://www.newyorker.com/archive/2004/12/06/041206fa_fact?cu...

The difference between doctors and programmers is that programmers get to build/leverage tools that are abstractions of other tools, hence you can have orders-of-magnitude differences in productivity between programmers who use the best tools and those who don't. I assume that there's not that much variation between the way two different doctors carry out the same task like there is with programmers.

Actually, doctors do have order-of-magnitude tools for improving certain metrics, such as recovery and infection rates: http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...

Do you have any reason to assume that programming competence is a "natural phenomenon" ?

We're not talking about the statistical central limit theorem here, we're talking about people who are passionate about programming and spend years working on their craft.

You can only invoke the normal distribution thing when you're talking about an outcome that is the average of many independent quantities.

Research into the performance of medical doctors shows that their skill follows the normal distribution: http://www.newyorker.com/archive/2004/12/06/041206fa_fact?cu...

Actually, a lot of natural phenomena does NOT follow a normal distribution. The problem is that most people assume it does anyway, and that's where a lot of errors come from.

Statistics requires a lot of correct assumptions in order to be accurate; sadly, most people overlook or fail to check their assumptions.

The thing is, natural phenomena doesn't follow normal distribution, but the sum of non-normal variables, will approach a Gaussian distribution, as per the Central Limit Theorem[1][2].

The problem is people assuming a normal distribution on a single variable with unknown distribution.

[1]: http://en.wikipedia.org/wiki/Central_limit_theorem [2]: http://stats.stackexchange.com/questions/22387/why-it-is-oft...

Yes, that's correct. If anyone wants to know more, an elementary statistics book will teach you all about the central limit theorem and the law of large numbers. Very useful things to know.

mlvljr, for some reason your post is showing as "dead". I'm not sure why??

Khan Academy has a good lesson on the law of large numbers http://www.khanacademy.org/math/probability/v/law-of-large-n...

The phenomena are normally distributed, but there are often steep threshold effects in performance. For example, no number of teacup poodles is sufficient to win a dogsled race. Most dogs have above average completion times on the Iditarod race.

Which is not to say there is no market for chasing frisbies.

Given that there are N animals of size X, how many animals are there of size X/10?

Software development is not a D&D stat block item. No reason to believe it is even quantifiable (although I like to think some developers approach writing code the same: rolling dice). If it were quantifiable, what would be the metric?

I think this black-and-white/good-bad developer is way over simplified for our industry.

I think majority developer is above average AT SOME THINGS, someone may be a great javascript developer who can barely get a C program compiling, someone may be awesome AI developer who is blissfully ignorant about engineering best practices, etc.

I am not much of a stats guy, but median seems more appropriate in some ways because you're hiring a person, not a statistic. Of course, it'd also be fair to say that your median developer is significantly less awesome than someone in the top 10%.

Thanks for catching this (Xcelerate below too). I'm updating the post to reflect it (having some trouble with caching on Posterous it appears though).

Technically an average is general statistic and mean and median (as well as mode) are specific types of averages. As a person with a stats background I often use "average" to mean the general concept instead of a strict arithmetic mean.

It was easy to figure out what the author meant, and his point should be taken for what he meant: half of people are below median.

I wish more companies knew what they really wanted before asking people to come in. I am at the point where I am getting sick of sitting through three hours of clown questions that having nothing to do with the type of coding that I would use in production only to find out weeks later that it was all a waste because I am not what they were looking for. I understanding perfectly that I will not always be a good fit for the job, but go bother someone else if you want someone to jump through three levels of interviews only to decide that you want a different skill set.

PS Thanks for indulging me in this rant. This just happened last week and I am still a bit annoyed that I wasted that much time at a company only to find they wanted someone with a completely different skill set (ie RPG).

Not to try to temper your frustration (which is quite legitimate), but in this context, "we're looking for a different skill set" is almost certainly a foil. Quite often companies will say things like that when really they mean they were just fundamentally disappointed in you for reasons X or Y they would find too awkward or risky to disclose to you.

Have to agree here. If you got to the onsite interview then there is a high likelyhood they thought there might be a fit.

This has been discussed before but basically telling a candidate that you passed on them for a specific reason is seen as an invitation to argue the point, so people say something like 'wrong skill set.' Easier just to move along and not worry about it too much.

Since no-one puts up adverts saying

  "wanted - crap developer, poor time-keeping, 
  rude attitude and bad test coverage a must"

then we are just going to have to put up with this.

It's just like job title inflation or real estate agent descriptions of property (You also never see "pokey little hovel for sale, noisy neighbours")

Just ignore the fluff, read the actual job and decide. I must +1 this bit - nice idea, where self-selection actually works:

  Instead, try expressing a piece of your culture or
  mission: dog-loving hacker, activist developer, 
  foodie web developer

  Or something about your development process: 
  generalist software engineer, creator of performant & 
  maintainable code, quick-and-dirty hacker

Flippa came close with "Seeking Mediocre Ruby Devs", http://webcache.googleusercontent.com/search?q=cache:6zrwYfQ...

¨... emacs users probably shouldn't bother applying." Is this a joke?

Seems like a pretty snarky comment to put into their job posting.

Of course it's a joke.

Luckily, awesome and crap, are not the only choices we have available. I agree with the OP here, just try to convey what you're looking for, and leave out the adjectives.

Regarding Valve's T-shaped employees:

When I first read Valve's employee handbook, I thought the T thing was a bad idea because it killed the chances of people who would probably be really good candidates. But after thinking about it some more, I see where Valve is coming from.

I spent the last decade working as a non-teaching/research faculty member in academia, where the T/R faculty members were (for the most part) either vertical lines or em dashes. The vertical pipes were world renowned experts in their fields, but their fields were niches within niches. They never strayed far outside of their comfort zones, and a lot of them ended up publishing essentially the same half dozen papers over and over for the entire span of their careers. The em dashes had broad knowledge across a large swath of subject matter and made great 1000- and 2000-level course instructors, but they never really became experts at anything and their research output suffered.

I do wonder how many potential candidates have been scared away by the publication of Valve's employee handbook and that image of the Heavy Weapons Guy, though. I certainly have. (I fear my T is too wide and not tall enough, so I don't even bother sending in a CV despite having a desire to work there.)

I don't even bother sending in a CV despite having a desire to work there

I am reminded of the story retold on (e.g.) this page:

http://emmalarkins.blogspot.com/2008_08_01_archive.html

There's a famous anecdote about the famous science fiction editor John Campbell meeting a fan of his magazine. When the fan mentioned that he'd written some stories, Campbell remarked that he didn't recall seeing any submissions under this fan's name. "Oh, no," the fan remarked. "I haven't submitted them to you because they're nowhere near good enough for that." That's when Campbell exploded and said, "How dare you reject stories for my magazine! You submit the stories to me and I'll decide whether they're good or not."

Even if you don't want to apply and endure the ignominy of being bounced, (though you should just grit your teeth and get bounced; you'll get over it, and "getting over it" is a skill worth practicing!) I'd encourage you to take a current or former employee of Valve out for coffee some day and ask what it would take for you to get a job there. Have a five-minute chat. You might learn something, and you might even be surprised. One of the points that the OP makes is that it's really easy to make a mistake in evaluating your own depth of skill.

The best programmers I know continue to have a healthy paranoia and distrust of their own skills.

They understand how a small mis-understanding or mis-assumption can lead to inflexible situations beyond anyone's wildest imagination.

Most importantly, they are completely comfortable with the following phrases and using them very often:

- I don't know, let me look into it. - You could be right.

This reminds me a phone screening that I self-sabotaged:

In the "skills" section of my resume I have a list of technologies that I have "limited experience" with, on which I have included C# and Python.

During the interview the interviewer started a question with "In C#..." to which I interrupted him to mention that my knowledge of C# was pretty limited. The question turned out to be a pretty easy question about OO (or something like that). The next question started with "In Python..." and I again interrupted him, only to have him ask an easy question about dynamic vs. static typing.

This is sort of the opposite problem, where I was so afraid of overstating my abilities to the point where I made myself look bad.

This is why I never interrupt. It's never to your advantage unless you're pressed for time.

There's another corner case: You are actually not that good in the area the question's from, but you know the answer to the first question. By interrupting, answering the question right, you might get the interviewer to tick the box for that area as covered, and spent his time on evaluating your other qualities.

(At least that's how I sometimes managed to get better marks in my oral exams, which aren't too far away from some job interviews.)

On a related note, when hiring, I often get candidates describe themselves as very motivated, love learning new things, give out their 100% on every task, etc.. Most of them never bother to finish and reply on a simple coding task I send as an initial screening.

So yeah, filler BS goes both ways.

(PS. Coding tasks in prescreening are contentunous topic. My POV: if you don't have open source "portfolio" I can look at, and if you can't be bothered to spend an hour to potentially save both of us from a couple hours on an interview day, I don't want to talk to you anyway).

If the coding task wouldn't take longer than a preliminary interview, I can't see what's controversial about it? If you want to make sure, that no poor slob is putting in days, just make it a timed task. I.e. hand in whatever you have an hour after you've got the problem.

I can see that being asked to code for days is a no-no for prescreening.

Some people do take the piss a little with their coding task requests, but an hour isn't too bad. I do appreciate when someone is willing to look at code I've written beforehand, though - at the end of the day, even if you're being quite focused with your job hunt, if every application took an hour it'd really limit how many you could do.

When I was looking for my last job I rejected a company based on the simplicity of it's code task. A company's code task should interest and challenge. View helpers satisfy neither requirement (for me).

I disagree, and cite fizzbuzz. There are so many programming candidates who can't even answer a simple problem like fizzbuzz that it prunes out a good number of candidates by asking a simple question like that. Not every step in an interview is intended to meet the same goals, e.g. your coding question could have easily been a quick pruning method versus saying anything about what sort of work is being done there.

Amen. "Rock star" or "awesome" in a help-wanted post are code words for me, meaning that the hiring company or manager is a) a douche, b) woefully inexperienced, c) doesn't understand developers, or d) all of the above. I hit the "next" button whenever I see the code words.

I am an excellent developer with many years of experience, but I have never once described myself as a "rock star."

Indeed. Also add "ninja" to the list (WTF is that supposed to mean anyway?) Other tip off phrases: "must love fast paced environment", "ability to juggle multiple projects" (read: our process is non-existent or broken)

A ninja developer is someone that no one on the team has ever seen or interacted with but somehow gets their work done. Usually in the dead of night.

> "First, sorry to break it to you, but a little over 49% of developers are below average".

Nope -- 50% of developers are below the median. If I could hazard a guess I would say something like 80% of developers are below average.

I think the best developers tend to already know where they want to work anyway; the wording of job postings probably has little effect on these people.

Interesting question, do great developers at the top throw the curve, leaving most developers below average? What about those who wreak havoc and ruin, which must be fixed by others? Achieving -10x productivity might be difficult, but are there more negative productivity developers than rock stars?

I remember Barnes and Noble had a job offering that was looking for "rockstar developers to work in a start-up like environment." When the guy asked me if I were a rock-star, I said no. He ended the conversation right there.

If that's the case you're probably better off. I'd imagine they would have unreasonable expectations. Plus they would more likely hire a dishonest person that would say "of course I am!" regardless and probably miss out on a good, honest worker.

Interviewing is a game, and it is expected that you play a certain way to get the job. Other aspects of the game include when they ask you why you left your last job. Your answer needs to be something bland or positive about how you completed all your goals at the previous place, and it's time for a new challenge. The fact that the last place was soul-sucking and terrible should not be mentioned as part of the job seeking process. Being positive is just part of the game. Don't give people excuses to count you out if you want the job. There are all kinds of jobs where lying is just part of the application process. Police, for example, it's just common knowledge that when they ask if you've done drugs of any kind, you say no.

He was really asking if you were "hip" and "with-it."

depends on definition of rock star , by my definition there is handful of those , but judging by hiring companies there is a lot. I is all about perspective.

The truly in-the-know companies would be advertising for meek devs, however meek devs don't test well with investors, which is really what this rock star business is about. It doesn't matter what the skills actually are, if the devs don't believe they are rockstars, it's difficult to sell them as such to investors.

Well known fact, low-skills people tend to be more confident http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

I realize this is an issue of job listings as opposed to what developers are calling themselves (mostly..) but something that bothers me as a designer are the amount of portfolios that start "I build beautiful hand-crafted [user experiences, websites, pixels]," or otherwise bloat the person's talents right off the bat with words instead of examples. Maybe I'm being a jerkface here, but that type of language immediately makes me second-guess the person's capabilities (and usually, rightfully so). One's work should speak for itself and be the first thing someone sees when they come across the site.

I'd be interested in hearing what others think about this trend.

Interesting comment!

When I read portfolios/personal sites like that, the first thought that always crosses my mind is, "They were looking for a creative way to say that they design _________ but settled on a tired cliche." However, that kind of marketing speak doesn't necessarily make me second guess the person's work. Rather (to use your example), some people may be great designers, despite the fact that they can't write their way out of wet paper bags (and thus need to settle on cliches).

Sizable personal bias aside, I have some data that argues you may be correct. When I rebuilt my website last summer, I built a fairly typical main page with lots of space for a headline. I spent the rest of the year A/B testing headlines to see which one got more people to delve deeper into my site.

I ran many tests, but the best performing headline I came up with was "Everything I put in this box makes me sound like a pretentious geek". The difference was truly immense - my pretentious geek headline outperformed everything else by at least 2.5%!

Consequently, my homepage contains the words "Everything I put in this box makes me sound like a pretentious geek". I sacrificed branding in favour of results...and I'm pretty sure my University would like me to give back my marketing degree! ;-)

Hooray for A/B! I like that you include the written acknowledgement that you sound pretentious, I think that actually adds credibility by having a sense of humor about it and recognizing that it's a thing people are doing. Something I didn't mention is that when someone sort of takes the piss in that manner, it actually positively affects the way I feel going through the rest of their site because at least I know they've got a good attitude and are probably fun to work with.

Surely someone here has posted a job ad asking for "awesome", "rock start", "ninja", etc. Tell us how it went. What kind of people applied? And did they really fit the description?

The use of superlatives in the job ad can work to your advantage when it comes to negotiating pay. If they want "awesome" devs then they should be prepared to pay "awesomely"....

As an addendum to your article on hiring "rockstars". A few weeks ago, I wrote a piece further highlighting how 'rockstar' is a broken metaphor in the development world, based on personal experience performing with rockstars on stage.

http://news.nucleusdevelopment.com/2012/08/03/so-you-want-to...

A good developer is one of the most humble people you'll ever meet; for he knows the great, intrinsic flaw there is in being human.

The quietest, most-reserved people are the best. Look for the person who delivers consistently but doesn't talk about it.

Depends on what you are looking for. In a leadership position talking might be one of the things to deliver.

Yes, but talking when appropriate. People who run their mouths are terrible leaders.

Indeed.

A dev displays leadership by delivering great software. I'm not saying other types of leaders don't have to talk, but I just wish people could grasp that a developer ships software by sitting and working at a computer for a very long time, sometimes up to 12 hours a day. Doing social visits and meetings is time that a dev is not delivering. If a developer stops developing software so they can spend the majority of his or her time with face-to-face visits and meetings, that person is no longer working in a developer role.

No one seems to believe this, but developers have to develop software at some point. There is no way around it, no one else is going to write the code, make the tests, etc. In the business world unfortunately, people drop out development but keep calling themselves developers. A developer leader is someone who delivers software.

While I agree with delivering great software, I disagree with the notion of spending ages at the computer being the right kind of tool in a variety of circumstances. Often thinking stuff over well will decrease the time you have to spend coding. (And that can include thinking together with a colleague.)

I think we do not so much disagree in the essence, but just in the amount of hyperbole.

(As a snarky aside, I almost never sit at my computer. Sitting kills you. I might be able to do 12h at a standing desk, but no way I'd manage to do that sitting down. Though my eyes (and brain) will give out long before that.)

"Job titles do matter." I stopped reading here.

sounds like just a subset of the general rule:

"Don't hire only self-described awesome [whatevers]."

Reply on news.ycombinator.com