Generalist programmers get hired all the time at startups; as someone else mentioned, requirements are always changing and it often doesn't make sense to specialize immediately. At Justin.tv, we hired a ton of generalists before we ever hired any specialists.

What I meant in the post was that if you are going to be programming then you need to demonstrate that you are a good programmer, hopefully with some specific abilities or experience that demonstrates you'll be able to work on the actual problems of the company. We hire people all the time that don't have massive experience in web development, but they demonstrate skill in some related way (e.g. maybe they talk about how they've used Python for scripting in their phd work). Anyways, the point is that even a generalist has specific projects that demonstrate they are a good programmer, and this goes beyond just listing a ton of languages they've dabbled in. Good programmers are generally very good at specific stuff they have experience in, and aren't necessarily good yet but can become good in other areas.

I read your post and this comment as arguing for resumes to focus on achievements ("this awesome thing is my fault") rather than tasks ("I did thing X as a means to an end while in role Y"). Is that a fair summary?

If so, I think you're off the mark a bit when you say this applies only to startups; I think this applies when you are applying to specific roles at a company, regardless of the company's size. I don't work at a startup at all, but resumes with lists of papers with no direct relevance where the candidate is one of 10 co-authors, academic honors, TA positions that are irrelevant to the job at hand, lots of description about a former team's job rather than what the candidate did, etc. make my brain glaze over. I have to spend more time looking for the core nuggets of achievement buried within, and that's generally not time I have. It's not necessarily a killer for someone's interview process, but it's certainly not fun and drains my time.

Meanwhile, people I encounter outside of the normal resume-submission process who simply point out something really cool they've done? If it's something really awesome, they get recruited, no real resume required.

I spend quite a bit of time reviewing resumes, interviewing and hiring engineers, and I am not looking for specialists. If a candidate has an in depth knowledge of a particular subject, that is awesome, but completely optional. The requirements are: Strong problem solving ability, a love for writing high quality code, and the ability to learn fast and work independently.

One thing I do agree with in the original post is that the resume is a really bad way for me to learn about candidates, and most candidates resumes are much too long. A blog, open source contributions or stackoverflow answers are much more helpful and really make candidate stand out from the crowd for me.

Within the last couple months we also started requiring all candidates to do a coding challenge before applying (http://thumbtack.com/challenges), and it has been an epiphany for us. My current process is to look at the challenge submission without seeing anything else about the candidate, grade it, at which point I'll then look at the resume to see how many years of experience (I have higher expectations for the solution the more years of experience the candidate has). For borderline submissions I'll dig deeper into the resume, but 90% of the decision comes from the challenge submission and maybe 10% from everything else.

OK. Problem #1 "Your solution should be in Javascript and CSS"

Smart people don't play monkey games. If you want a monkey at the very least be honest about it. If you want a rockstar you better have a damn good reason for them to come to your company rather than just start their own. Playing monkey games to see if your possible new team rockstar is good at reading minds through osmosis is the first reason they won't even look at you. Better stick to brogrammers, however I doubt you even see many of them.

I would say we have a lot of evidence that great candidates enjoyed doing our challenges, but certainly it isn't for everybody. You are free to not do the challenges.

As for your secondary point about the quality of our team, I encourage you to read our engineering blog (http://www.thumbtack.com/engineering/) and look at some of our open source contributions (https://github.com/thumbtack). I think you will find more than enough material there to see what our engineering team is all about.

In addition to other answers, there's a linguistic element as well. Generalist language is generic, overused, hence relatively meaningless and uninteresting, and won't get you very far. Concrete, specific, original, and niche terms are much better at catching attention, sticking in people's minds, piquing interest.

Aside from knowing this intuitively, witnessing it in everyday life (and on HN), I've seen internal adsense A/B testing demonstrating it.

Another tip I've recently learned from watching a friend make this mistake is, if you have the opportunity to see a writing sample of the people you're applying to, even just email - mirror their writing style. Among the SV crowd that tends to be:

1. Short paragraphs, no walls of text.

2. Direct, Concise. Every sentence should be as simple as possible, but no simpler.

3. Your best skills only. Ref #2.

4. Your best work examples only. Don't elaborate, just a sentence.

5. What the article says.

6. What Swizec says above (http://news.ycombinator.com/item?id=3907717)

> Overall, startups are looking for employees who are exceptional in the one key thing that they will be doing

Key - in my opinion - being the operative word. In other words, you may be doing many things, but how good you are at those things aren't as relevant as how good you are at this key thing.

Much like the idea of the "T" shaped employee from Valve's employee handbook. Broad set of capabilities with depth in a specialty.

The generalist is the CTO, if they're bothering to hire somebody, they're looking for something in particular you're strong at that they need even if you'll be wearing multiple hats.

Things change very fast in startups. As your problem space emerges, you will be changing technology also to fit that picture. Strict specialists are rarely good in that kind of environment.

If you're doing a standard web app stuff that doesn't push any boundaries of science, you probably won't need a specialist until after you've hired four or five engineers anyways.

I didn't say strict specialists, I said someone who had something they were strong at but still able to adapt.

I'm a CTO hiring this sort of person right now.