Pitching Your Company to Candidates

The Pitch.

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 bring joy to their users with the things they make. 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!)

Don’t Lower the Bar, Widen the Net

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.

(Did I write this post so I could do cool stuff with Paper, co-founded by a Friend of Rooster Park, and because I heart what Stratechery is doing? Perhaps. Also, it’s been a while. Hello!)

Hiring, Auditions, and Interviewing For Success

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.)

Avoiding Zombie Startups

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?

Let’s break this down.

Continue reading Avoiding Zombie Startups

Hiring Smart – Seattle, February 6

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!

Happy (Weeks after the) Holidays

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).

Rooster park holiday 2012

Rooster park holiday 2012 2

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!

IMG 0014IMG 0032

IMG 0035IMG 0044

IMG 0057IMG 0066

IMG 0082IMG 0086

IMG 0097IMG 0105

IMG 0131IMG 0137

IMG 0143IMG 0160

IMG 0169IMG 0171

IMG 0174IMG 0110

Leaving Microsoft: Software Development Skills

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.”)

Creating a synchronous hiring process

I sent a mail to a client today that looked like this.

Here’s why.

One topic I always cover with potential new clients is “what does your interviewing process look like.” Here’s how this conversation often goes:

Client: “Send us the resume, I’ll send it to the hiring manager. If she likes it, we’ll schedule a phone screen. If that goes well, we’ll do another phone screen, and then bring him in for a set of interviews, usually with 3-4 people. Then we can make a decision.”
Me: “Great, that makes sense. How long does that take?”
Client: “Well, it depends.  The hiring manager’s really busy, so it can take her a few days to get back to me. Then I have to find a spot on an engineer’s calendar, then I need to review the feedback with him and sometimes the manager, then schedule a second one. Then our admin will help coordinate an interview day. I don’t really know.”

This is a common answer, an understandable answer, and a terrible answer. In engineer-speak, it’s taking something that’s time-critical enough to be synchronous and making it asynchronous. In human-speak,  it’s allowing all kinds of delays in a process where you lose if you are slow.

Your process needs to be fast, and making it fast means putting it all in sync. This includes things like

  • Expect fast turnaround from your managers. If recruiting is really Job #1 for your company right now, then the internal admin/HR/recruiter person should be able to walk up to the manager at any free moment, have her spend 90 seconds reading the resume, and then make a decision on next steps. Sitting in an inbox (or printed on a desk) is time wasted.
  • Every interviewer knows and can act on the next step in the process. Phone screen goes well, you want another one? Great. When you’re talking to the candidate, ask him his availability; jump on Outlook or Google Calendar, see the free/busy times for the engineer you want to schedule, and book the appointment while you’re on the phone. Boom, you just skipped another runaround and another few days’ worth of delay. You think the candidate is ready to be brought in to interview? Great, you’re empowered to find a day when talking to her and then get someone to actually schedule the right interviewers, and you can even book the conference room (the one with the whiteboard, close to the bathrooms). This means HR and mgmt needs to inform interviewers of the process and empower them to make the next decision (if it’s a positive one).
  • Set an SLA of <48 hrs between steps. There should be a reportable reason why the next step in the process takes more than 2d in every case. Try to keep it to 1. Look for ways around artificial constraints (the “right” interviewer is out of town? Can you find another one? etc.)
  • If you’re going to want something else, ask for it in advance. If you want a coding or test plan sample, ask the candidate to bring it with her on interview day. Have that ready for you.
  • Debrief always happen the day of interview. Scheduling an interview should always include scheduling the debrief (however your company does it), and it should always happen on the day of the interview, so that there’s a consistent practice. (There may be advantages to a day’s delay to allow folks to cogitate – I haven’t seen that be true in general – but let that be the exception, not the rule, and then schedule a second debrief – again, while you’re in the first one.)

Note that being fast and being thorough are not in conflict. You can have as many steps as you need, as long as you keep them close together. We’ve had two candidates join teams in the last month, both at companies with a four-step, ~8hr process, both which made it happen in four days. It’s the delays, not the steps, that kill momentum and lose candidates. (Ideas on evaluating your steps will come in a later post.)

Oh, and the email? The number of days from Step 1 to Step 4 for a candidate at one client. Does that seem like a large number? Check your own stats.

The P’s of Onboarding a Recruiter

A while back, I wrote about how to set up your recruiter for success. Recently we’ve  put together an outline on what we need to know when we bring on a new client, and I figured it was useful enough that I’d share it. I think this works for both new in-house recruiters (for very small companies) or third parties, though it’s certainly targeted at the latter.

I call it the 4 P’s, mostly to be clever. This post applies to both recruiters and companies, since as an employer, you want to make sure your recruiters have what they need.

Continue reading The P’s of Onboarding a Recruiter

Handling rejection

A few weeks back, we had a candidate interview onsite with a client. It didn’t end well. Some quotations from a mail we received the following day, errors left intact:

I was exposed to a couple of rank amateurs with an agenda.

If you wanted a code monkey, you should have advertised that fact and not waste my time.

I am not amused by seeing dogs running around in a business setting. It’s unprofessional and quite infantile. Indeed, the  the idom “The Country is going to the dogs” has become more than a metaphor.

Continue reading Handling rejection