Rooster Park: A Seattle Software Development & Staffing Consultancy

If you’re a startup, you’ve done one to investors, maybe several different times in different forms; when it comes to candidates, though, their motivation, initial interest level, and tolerance for BS are all very different.

As part of my never-to-be-published-book “Recruiting Secrets I’m Making Up As I Go Along,” I’ll give you the formula: the four sentences you need to craft and refine so they’re ready for any potential candidate you might want to join your team, with some examples for local Seattle companies.

1. This product is interesting

Explain the product you’re building. Focus on who it touches – ideally a real group of people that I might have heard of or care about – and make it a real, down-to-earth, noun-and-verb-heavy sentence that tells a story I can draw in my head. Avoid buzzwords and adjectives that just talk about how awesome you are.

Tred: “We’re making buying a car a dramatically less stressful experience: test drive a car from your home or office, negotiate online without any pressure, and close the sale, all without walking into a dealership.”

Panopto: “We’re making it possible for professors to easily record lectures along with any second-screen information they present, and for students to see and search the lectures at any time – something we would have wanted as students.”

2. This business has opportunity

Demonstrate why this business is worth a candidate’s time: maybe the entire market is big, maybe companies doing similar things have made money for their team, maybe you’ve become the biggest player in a rapidly-growing market. Don’t use numbers (“This is a 6 billion dollar market!”) unless I can immediately put that into a useful context – which I almost certainly can’t.

Limeade: “It’s super-early in the world of company wellness programs, we’re leading the space and getting referrals, and as more companies care about reducing insurance costs and having healthier teams, we’re the company they’re calling.”

3. Our problems are challenging

Great engineers (and designers, and writers) want to know that much will be asked of them, and that their skills will be put to good use and are needed for this product to be successful. (I’ve talked to plenty of engineers who went to exciting companies and left because there was nothing exciting for them to do.) One sentence that explains why there are challenges that they can help solve (i.e. not “we need regulatory approval in lots of countries,” unless you’re hiring a lawyer) goes a long way.

(If you don’t have these, skip this section.)

Point Inside: “Real-time, measured-in-tens-of-milliseconds geospatial search over tens of millions of data points, processing daily product changes over millions of products, and building fast, easy-to-use mobile APIs are all part of what we do.”

4. How you should value us

where are you as a company: you’re an early startup with huge upside opportunity, you’re a de-risked later stage startup that can pay market rates and still offer meaningful equity, etc.

5. Optional: I know you will like it

If you know the person who will see this, and you know what motivates him, add a sentence that points that out clearly and professionally. “John, I know you’ve been happiest at companies that are obsessed with great product design and that you can explain to your mom. Haiku Deck is one of them.”

That’s it. Write the pitch; have people you know read it; have them critique it; write it again; repeat. Make sure you can write it and you can say it out loud. Go back and remove the adjectives that sound like “awesome” and “great” and replace them with nouns.

Have a pitch you want us to see? Add it as a comment and I’ll take a look. (Oh, and the companies above? Who knows, maybe some of them are clients of ours. So email us if something caught your eye!)

Share Me:

A handful of our clients work in very specialized industries, or are often looking for talent where the number of candidates who will have expertise in a specific area is very small – even in a large software town like Seattle.

It could be small for a few reasons:
–It’s a new technology, or new enough that companies are either just starting to test it for production use or are doing their first deployments, so nobody has a track record of success; today, for example, the number of engineers with significant experience doing successful node.js deployments is much smaller than the number of companies that want to try.
–There are only a small number of local companies that ever need that technology, and so there’s no incentive for people to keep working in it; Windows device driver development, generally done by just a few Microsoft vendors, is a great example.
–It’s always been small – new engineers with this skill are effectively at replacement level.

Whatever the reason, hiring for these roles – especially if you need them all the time – can be frustrating: you feel like you’ve talked to everyone in town (mostly because you have). There are a few disciplines where I’m certain that we have the names and resumes for 100% of the discoverable engineers in Seattle in our database.

When a company gets into this role, there’s a lot of pressure – especially from people who are directly measured by their hiring, like internal recruiting and HR teams – to lower the bar: “I know that Bob didn’t pass our C development test, but he was sort of close, and we can’t find anyone as good as our current team – they just don’t exist!”

We all know how this one ends: unhappy engineers, unproductive delivery teams, and disappointment. Engineers do, and should, fight this urge – but that doesn’t get you closer to delivery.

If you find yourself in this place, don’t lower the bar, widen the net. (Or to avoid mixing metaphors: go broad, not shallow.) Find skills that are reasonably complementary and accept the cost of training (or enabling self-training) – and evaluate the candidates for learning potential (mostly with behavioral questions, plus asking them a few things out of their comfort zone to see how they puzzle through). Need ARM Cortex-A9? Look for someone who’s done any constrained development in the last 10 years. Need node.js? Look for server-side and dynamically-typed language experience (i.e. hire that Ruby guy).

This includes contractors: the problem is the same, and while it’s painful to eat the cost of training, it’s often more painful to never get things done.

This isn’t rocket surgery, and it’s not the same thing as hiring for “raw smarts,” which can feel painful for small companies or companies under pressure to deliver (and everyone should be). You should be able to draw a bright line from the technology you need to the technology the candidate brings – but if they bring it, and they’re good at it, then hire.

Share Me:

Today Sam Altman, one of the Y Combinator partners, posted an article called How to Hire. There’s much to agree with in here, and a few points that I think are wrongheaded (mostly around the overused-and-underdefined phrase “culture fit”, and some assertions which are really just ageism), but the point that generated the most discussion on Hacker News was the idea of an audition.

Have people audition for roles instead of interviewing for them.

This is the most important tactical piece of advice I have. It is difficult to know what it’s like working with someone after a few interviews; it is quite easy to know what it’s like after working with them

Whenever possible (and it’s almost always possible), have someone do a day or two of work with you before you hire her; you can do this at night or on the weekends. If you’re interviewing a developer, have her write code for a real but non-critical project. For a PR person, have her write a press release and identify reporters to pitch it to. Just have the person sign a contractor agreement and pay them for this work like a normal contractor.

I’ve seen this discussion happen a dozen times, and the sides break down the same way:

–Pros: Whiteboarding is artificial, and real coding is a better reflection of skills; hiring is a two-way street; wouldn’t you want to really get to know your colleagues?; I wish someone would test me that way.

–Cons: it’s simply not true that people have “a day or two” to give you outside of the interview process – some combination of work, family, and personal obligations. “The developers who know what they’re worth won’t put up with this.”

The best answer, of course, comes from remembering the goal of interviewing in the first place: to find people you should hire, and then hire them. Obvious stuff, but there’s a less-obvious corollary: if there’s part of your process that keeps you from finding people you should hire, you should change that process. No matter how awesome your company is, asking for homework as part of the interview process will keep some people you would want to hire from interviewing.

If you think that a working session will give you different data than a whiteboarding session, then integrate it into your interview day: instead of five hours of whiteboarding, do two hours of whiteboarding, two hours of real-world programming, and an hour to establish values alignment.

Real-world programming could be pair programming, or could be what one of our clients does, where they ask the candidate to bring a laptop with their development environment, and a VGA connector (or they’ll provide one), gives the candidate a problem and a projector, and watch while asking questions.

With a setup like this, you give the candidate multiple ways to show success (i.e. he freezes at the whiteboard but can write great code the first time through; she takes a while to get into a problem but clearly understands data structures), and you gather a wide variety of information.

(BTW, many companies actually don’t have a contractor agreement – and even more individuals wouldn’t know what to do if they were paid as contractors. Don’t hand-wave this away.)

(Pedantic note: the use of the word “audition” in the original context doesn’t make sense. An “audition” is an interview, but with singing and dancing, or crying on command. If you audition for a play, they don’t have you come spend a few days as Peter Pan before someone decides if you get to stay.)

Share Me:

Danielle Morrill created an awesome term a few weeks back – Zombie Startups – in a post about how to know if your own startup is a zombie. I’ve been using this highly-evocative term with candidates since I read this, and in doing so, realized I needed a way of helping a potential (or current) employee evaluate if the startup she’s looking at is a zombie.

Seattle has its share of zombie startups – companies that it just doesn’t seem like are going anywhere – and engineers should know what they might be getting into. Here’s a two-question way.

1. Is the metric that matters moving?

Share Me:

We’re the impetus for ~20 engineer-to-engineer interviews/week – either clients talking to candidates or internal technical screens to validate quality before the client sees the candidate. Some of our candidates are from out of town or out of state, and our consultants can’t leave their office for every interview they’re going to do – so we want to make remote interviews work.

The good part is that the technology is really there: I’m asked enough how we do it that I wanted to write it up quickly. You really just need two tools: Google Hangouts and Collabedit.

Google Hangouts: This is the first 1-1 or multi-user video chat that I’ve found just works almost 100% of the time – very little video stuttering, no terrible echoes just because your mike and your speaker are on the same piece of hardware (i.e. your laptop), and really easy to get going. We tell candidates we’re going to use this ahead of time and ask them to get it set up – and while some candidates don’t have webcams, that’s becoming rarer and rarer. We send out a Hangout link ahead of time when we can (as Google Apps users, we get access to those), but you can easily just use gmail chat and go right to video.

I can’t emphasize enough that Google Hangouts have demonstrated that the future is here – you can legitimately start these conversations on the fly and feel confident that they will work at least as often as your cell phone connection will. I’ve never been able to say this about skype or other solutions.

Also note that Hangouts have a one-click screen sharing option, so either the interviewer or the candidate can replace their face with a window at any point. But why do that when you have…

Collabedit: Collabedit is a real-time shared coding window: you create a link on the fly (and can share it via chat), pick the language for formatting, and then ask questions and see real typed-out answers. There are similar solutions, other EtherPad-based clones like Stypi – I’ve just been consistently happy with Collabedit. I’ll often start the interview with the question I want to ask in a comment that I can just paste into the collabedit window, so the candidate doesn’t have to remember what I said out loud.

Note that we’re using this to replace the traditional technical phone screen as often as we can – I’d like to be there 100% of the time soon. There are many problems with the typical phone screen – I’ve found at least two of them to be improved this way:

Interviewers focus better. It’s easy to get distracted by incoming email or a piece of code if nobody can really see what you’re doing, and information just disappears. The video requirement really does mean you get better feedback.

Fewer forgiven sins. Even with just a small amount of data, it’s clear that we’re passing fewer candidates with video/code than we did with phone screens. Since we go into every screen wanting the candidate to be successful, it’s easier to paper over flaws you think might be there when you’ve just heard voices – it’s harder to do that when you’ve really interacted.

That’s it: two tools that make hiring folks in other locations a more comfortable and confident experience.

Share Me:

I’m participating in a panel discussion on hiring smart – team building, avoiding (and learning) from mistakes, and having a strategy – hosted by Turnstone Seattle on February 6. RSVP here. There are a crazy number of RSVP’s, which should make this more fun, and the panel is moderated by the extraordinary Rebecca Lovell. I’m on the panel with Kate Matsudaira and Phil Gordon, which means that if I do get a word in edgewise, it better be a thoughtful one. Hope to see you there!

Share Me:

Rooster Park celebrated the end of a very-successful 2012 with a few fun items.

First, here’s our holiday card, designed by root beer float – we sent (and personally signed) ~200 of them to our current and previous consultants, clients, and FORPs (Friends of Rooster Park).

Second, we sent out about 175 Rooster Park-branded Kleen Kanteen Insulated Mugs (with both tops!) to a similar group. They’re a huge hit: we’ve sent out a few extras and will need to reorder more. Highly recommended.

Lastly – and most importantly! – we had our annual post-holiday party two weeks ago. We took over Hotel Andra‘s ballroom and Tom Douglas’s minions provided a mix from various restaurants – including, importantly, the Dahlia Lounge donuts.

We also had a photo booth, which after a few drinks, ended up being a huge hit. Here are some of the hundreds of photos – thanks to everyone who made it!

Share Me:

This last week, Rooster Park staff participated in Vittana‘s Geeks Give Back challenge. Vittana is a local organization with a global mission: to help raise people out of poverty by supporting their educational process through microloans. It’s an amazing team and mission, growing fast, with a >99.8% repayment rate from their students.

I’m insanely pleased to announce that we were the third-place team in the challenge, raising $4418 in just one week. (This includes a Rooster Park 100% match of all contributions.) More than a quarter of our team participated, and we helped 24 students worldwide – from systems engineers in Nicaragua to chefs in Bolivia. (See more details at our Vittana Team Page.)

If you’re a FORP (friend of Rooster Park, duh), feel free to help via our team page as well – the challenge is over but the need still stands. Thanks to all of our folks who participated!

Share Me:

Today is the Seattle TechStars Demo Day. As part of our commitment to invest in Seattle startups, I’m attending the first portion: because we heart the Seattle tech community, Rooster Park is a sponsor of the demo day afterparty (as are a handful of our favorite clients). Come say hello and get one of our new business cards from one of us (or collect the whole set).

Share Me:

Every week or so, we’ll talk to an engineer who thinks she’s interested in leaving Microsoft. (We heart Microsoft! They’re a great client! This is reality. Back to the show.)

Leaving usually means wanting to go to a startup or smaller company, and (even) in Seattle, the vast majority of those are based on open source technologies – they’re most often Java, Ruby, or Python shops. But many of those companies don’t have time to train up someone who’s spent her entire career on Microsoft technologies – they look at a resume with nothing but C# and ASP.NET for the last ten years and start to imagine how long it will take that person to be productive, and then they move on. (Companies with primarily Java stacks may be more willing to budge on this.)

So how do you get yourself technically ready to be an attractive candidate?

There are two paths: one obvious, one less so.

Obvious path: start building things. Go spend six months in your I-want-to-leave-so-I-made-some-free time actually building something “real” that runs on an open source stack, in a language that might be interesting (the ones above are good choices, especially Ruby or Python). Make sure the application does something that someone can see. It doesn’t have to be complicated, it doesn’t have to be great – the bar here isn’t “are you an amazing Ruby developer” but “did you take learning a non-Microsoft technology seriously.” That’s part of the secret: if you’re a good developer with solid CS fundamentals, and you’ve made a concerted effort, that makes you a viable candidate.

Less obvious path: move to front-end web development. There’s one set of technologies that Microsoft uses that matter a lot outside of the company – client-side web technologies! At this point, the web client side is where the Microsoft-specific and other stacks converge. Javascript & jQuery at a software engineering level and CSS expertise in particular matters a lot: experience with something like Backbone.js is even better, though I don’t know how much of that is being done inside Microsoft walls. Go over to one of the Bing groups (or some of the Windows groups) that are writing high-quality web client side code, get yourself on that team, and go build things people will see. This is real engineering, and the world outside of Microsoft knows the difference between a webdev whose skills are more around pixel perfection and a software engineer who can write client-side Javascript.

(This is the first post in a will-really-be-ongoing series called “So You Think You’re Ready to Leave Microsoft.”)