Hacker News Reader

Comment by ivanhoe | Hacker News Reader

I would always hire an experienced generalist first. Being generalist means being smart and fast learner, and those are IMHO the crucial skills for any small or medium sized team. You will end up in new and unexpected situations here and there and the "specialist" mindset is not very good in dealing with this. You need a generalist to come up with the best hack, simply because he has a much wider perspective...

View on HN

The problem is that you'll never see the generalist's CV. The gatekeepers ahead of you (HR or recruiters) will always find someone with more of the right keywords or more of the desired experience to push first.

You might also end up with a jack of all trades - master of none. They often appear competent at first, but will fail once stackoverflow and their $LANG cookbook doesn't have a copy and paste answer. This does probably not apply to OP obviously.

not all generalists fit this stereotype. it is possible to be a generalist and not be a copy/paste drone

Of course, but who do you tell which is which just from a resume of an otherwise unknown person?

It's tough; when I was doing tons of tech screens a few years ago working for a consulting firm, I got pretty decent at picking out good resumes more than half the time. Mind you this was not my full time job. But you really need to do quite a bit of resume reading and phone screens before you get a good feel for it.

so, experience will get you so far.

Excellent point. And, conversely, how do I demonstrate, on my resume, that I'm proficient as a generalist without listing the things that specialist-oriented readers here suggest that I omit?

Look at the generalist's source code to make sure it's coherent and original. It's not a problem if they use something online as a model, especially when they're unfamiliar with an API or something, as long as they understand what they're doing. Also, good generalists tend to be more prolific when it comes to entrepreneurial endeavors, so look for a bunch of original side projects. What's most important with a generalist is his creativity and ability to learn a new technology. How he does this is not really important as long as he can do it. But originality in side projects probably indicates a desire for originality in code as well.

Yes, they will make it if they are interviewed. But I thought we were talking about a situation where the recruiter needs to decide which people are invited to an interview? And than its much more difficult because in some situations you can't read the code of all applicants for volume alone.

You interview them, just like we do for every unknown person. If you don't want to take the time to do that, then you do a quick search for work they've done, and then come back to the 'do I want to interview this person?' question. Ask them what their timeline for having a job is. Tell them that the interview will involve coding on this specific thing, give them weeks or a month to prepare for it.

Help your candidates do the best they can. Don't set them up to fail at a task they weren't expecting.

One of 'pg essays is about this. So finding low risk / low investment ways to work with someone solving a real problem cuts through most of the bullshit.

SRE

Reply on news.ycombinator.com