fhwang.net

hiring

Hiring techies at startups: Go narrow

Jesse Chan-Norris on writing a techie job description for Indaba Music:

... what I realized was that we needed a job description that spent much more time explaining who we are, as a team, and as a company, and by extension, the kind of person you should want to be if you want to join that team and work with us. I wanted to construct a posting that would attract the right kind of people and get them interested in us, that would sell our company as much as the candidates were selling themselves to us.

So this time around, instead of talking about years of ruby experience and a working knowledge of mongodb, we tell people that “Every member of our team is involved in the product development process. We challenge our developers, and we expect people to contribute at every step along the way” and we talk about how “We are a small team, and everyone is expected to exhibit a fair amount of autonomy.” And more than anything else, we lead with our core philosophy, which is that we believe that “the music industry is more alive than ever.” Forget all of those people who think that this industry is in the shitter – we’re just getting started.

I'd sharpen this even more. There's that piece of pitch-deck wisdom about how you never say "this is a $10 billion market so if we only capture 1% of it that'll be $100 million!" -- instead, you say "this is how we're segmenting this $10 billion market into a more precise $100 million market, and we're going to shoot for getting 100% of it". The idea being that nobody ever sold a new product by being a tiny bit better than the other guys to everybody in the whole world.

Well, I think it makes sense to think of hiring programmers that way too. You should define what sort of a place your company is to work at, and then really emphasize that differentiation as you write job descriptions, hang out at meetups, etc. No good programmer ever switched jobs because the next job sounded 1% better than their current situation. (Well, some programmers do that, because some of us are seriously brain-dead when it comes to making career choices, but that's another topic.)

To take an example: When Profitably started looking to hire engineers, we explicitly positioned ourselves as not another social media site. We talked about "complex analytical problems" in our job description, and sometimes I'd send out job emails actually making fun of the idea of working in social media.

That might seem unnecessarily negative, but keep in mind that the NYC startup scene is full of social media companies, and I was willing to bet that I wasn't the only techie in town who was a little fatigued by that emphasis. And I figured the most important thing was this: Above all else, break through the noise.

And, hey, you know what? If you really love working in social media, you probably wouldn't want to work at a company like Profitably anyway. But in the meantime, those little jabs at social media serve as a cue to the small minority of people who are tired of that scene, and maybe they'll read more about the company, and maybe even get in touch.

The nice thing about being a small company is that your hiring needs are small, and you can craft a job description that's that precise. Maybe it excludes everyone but ten programmers in town--if you're only hiring three programmers this year, you're good. Until the day when your massive prowess at tech hiring, combined with some real product-market fit, makes you so big that you've got Google-size hiring problems, at which point, congratulations.

Hiring Rubyists at a large company

A few months ago, at an NYC.rb happy hour, I had an interesting conversation with a technical recruiter. He was trying to hire Ruby and Rails programmers for a large company in the city, and was asking my advice because their goal was in the double digits and the company had been trying for some time with little success. This is sort of the inevitable result of the Railsification of the web programming business: As Ruby and Rails move from super-cutting-edge to comfortably middling, bigger and bigger companies decide to make the switch. And, for their efforts, they’re rewarded with the same recruiting pain that small startups have been living with for years.

It’s tough for a large company to hire in a technology like Ruby. Sure, you can proclaim loudly that you pay above market rates—but to work for a larger company, your typical senior Rubyist is going to need not just good money, but ludicrous, eye-watering money. Because no matter what happens, you’re not giving that programmer a chance to build the next Twitter or Facebook. And that opportunity is key to what a cutting-edge programmer gets psyched about.

It isn’t really about the equity, though that’s a nice bonus: It’s about the chance to learn. We know that the best way to be part of technological progress is to be thrown into a situation where you have to solve a million-dollar problem with way less than a million dollars, which forces you to try with some unproven set of tools and techniques. We read blog posts and listen to talks by the people who’ve been through that sort of trial by fire, and we wonder how well we’d do at it. And then we go look for somebody to hire us to try.

Larger companies rarely do this. They’re more likely to avoid the hard problems, or solve them in ways that risk less but cost more. That’s their prerogative, of course, but if that describes your company, and you’re trying to hire Ruby programmers, you’re going to run into this issue a lot.

Unless you look in a different place. That night at the bar, another Rubyist pointed out that there are plenty of .NET and Java web programmers who would love to get into the Rails game, but don’t see a good way in. For one thing, there’s the issue of experience: Most Rails teams are small, and accordingly there aren’t many entry-level Rails jobs in the world. And another issue is of risk: There are plenty of smart, curious programmers in the world who aren’t at the point in their lives where they can take on the risk of being the fifth employee at a seed-funded startup. (But if instead you get excited by that sort of opportunity, Profitably is hiring.)

So we suggested to the recruiter that they try to find those candidates—who largely don’t come to Meetups, and thus are harder to reach—and tie Ruby and Rails training into the final job offer. Of course, it’s a risky move for a company to hire somebody who doesn’t know Ruby yet, and I don’t think anything came of our suggestion. But it seems like there’s a match here that can be made. On one side, you have a large company that can’t easily hire Ruby programmers but has cash and can offer stable employment. On the other side, you have programmers who want to transfer their skills to Ruby, but need a stable employer and maybe some help with cash. There should be a way to connect the two sides.

I’m not sure who exactly this is an opportunity for. Maybe it’s an opportunity for a recruiting firm, which could find people with raw talent and experience in other technologies, and get them a sort of transitional offer which involves training and a job offer at the end. Or maybe it’s an opportunity for a consulting shop like Pivotal Labs, which already offers recruiting + training services as part of what it can do for clients, but would probably have to tweak the offering a bit for a different recruitment base.

But it’s got to be an opportunity for somebody. The severe pinch of technical talent in NYC isn’t getting better—if anything, it feels like it’s getting worse. It’s time to get creative with our solutions.