Some Thoughts on Hiring

Hiring and growing your engineering team is one of the most important things you can do for your new startup. It’s also one of the hardest things in my experience. I’m not an expert yet but I’ve learned a thing or two along the way...

Sourcing

For me, this was one of the hardest parts about hiring. When I started Checkmate we moved cross-country from Florida to San Francisco. I brought my family and my wits but not much else. I’ve never been a particularly strong networker but I knew almost nobody in San Francisco.

This was fine when I was just heads down trying to build our MVP. Not so much once it became time to build a team.

Don’t get me wrong, I’ve spent many years of my career working remote and know it can be very effective but it takes a certain kind of company culture to be successful. We were trying to build a different kind of culture that called for folks being in the office most of the time. Startups are hard work and the bonds that can be built in-person are stronger in my opinion and help keep the team together in the good times and the bad.

What do you do when you want to build a strong, cohesive team with local folks but you have no local network? Well, I guess you start networking… ugh.

Nooooo, not networking!

And so I tried... I went to local relevant tech meetups but the atmosphere was just bigger/colder than I was used to in Florida. Everyone seemed to already know each other and there were cliques that I was not part of. I tried reaching out to the few people that I did know in SF but they were all happy at their jobs. This wound up being a dead end for me.

I posted on job boards where I thought my ideal candidates would be looking — not Monster or Indeed or the like since I knew those would just bring in a lot of bad applicants. These cost us a bit but at least candidates started coming through. I only ever made one hire from job boards though which ultimately didn’t work out.

I wound up tapping into my remote network and brought in an ex-colleague to fill in as a contractor to keep up with our schedule. He wound up working with us pretty much full time for a year or so I believe. This helped reduce some of the pressure but was ultimately a bandaid.

Then I heard about something new and different — Hired, a kind of auction/match-making site for engineers or at least that’s how it felt in those early days. Instead of posting a job and hoping they would find you, Hired flipped things around a bit. Every week a new batch of pre-screened candidates would come through that you could basically pitch your company to. You could review their resume and skills and then make them a non-binding offer before ever even speaking to them. If they liked your pitch then you would be put in contact with each other for further interviews.

In those early days, Hired was not even really expensive, especially when compared to recruiters. We jumped on board. Some of our best hires came through their platform and they filled a crucial gap in my ability to source candidates early on.

Do what you need to do to fill up the top of your funnel. Everything else depends on it. Hopefully your networking-fu is better than mine was. If you’re at a bigger company or an A-list startup this is less of a challenge since you’ll either have professional in-house recruiters or candidates will naturally be drawn to you.

Interviewing

So you’ve finally got some folks coming through your pipeline (you did establish a pipeline, right?) and its time to interview them. Good for you! This is where the rubber meets the road.

When you’re just getting started you likely won’t have much of a formal interview process. This is something you will continuously iterate on and refine as your company grows. I recommend you read about hiring and interviewing as much as possible. I read stuff from

and and a ton of others.

While you’re struggling to source candidates and not getting many applications you can afford to spend more time with those that do come through. This gives you an advantage against bigger companies in that you can be more caring and attentive with each candidate (treating them like actual people) instead of just forcing them through Standard-Annoying-Hiring Process.

Use this advantage — tailor and customize your process to maximize on shared understanding.

Since you don’t have to be quite as aggressive at weeding folks out of your funnel, you can opt to skip some steps that bigger companies need like coding challenges and multiple rounds of phone screens. Assuming they have a solid resume and background you might be able to do a quick phone chat and then bring them straight in for an on-site and lunch.

In my experience the only on-site interview that matters is a pair programming exercise. There are a few approaches you can try here…

• Made Up Problem: You invent a problem to pair program with the candidate on and mostly let them drive while you watch. To me this is sub-optimal especially if you just wind up with a sad algorithm problem to work on. At least you’re pairing and not white-boarding.
• Actual Work: I find this to be the most effective way to learn about a candidate’s abilities and work style while working on real-world domain-relevant work (versus working on binary search trees that you never use directly). It is also the best way for the candidate to get to know what working with you would be like. I would pair with them as a peer in this kind of exercise, taking turns driving. The ethics on this are somewhat questionable as you are actually working with them. Should they get paid as a contractor then? I don’t have a perfect answer here but we did not and instead just kept the times reasonable. If you’re gonna have them work with you for any extended time though then obviously they should get paid.
• Break/recreate-a-feature: I find that this strikes a pretty good balance between the previous two options but also takes some effort to set up. What I would do is take tests (you do have tests right?) for some recent code that is working in production and intentionally break that code in various ways. A variation is to simply remove the code that makes the feature’s tests pass but leave the tests alone. The candidate then gets to fix the broken code or reimplement the feature to the specs. It ensures they are still working on real-world problems but alleviates any concern around them writing new code without being paid for their services.

After pairing, I’d always make sure to take the candidate out to lunch with as much of the team as I could including my co-founders. This gave them a chance to meet some non-technical co-workers and was a nice, relaxed, informal atmosphere where hopefully they could open up a bit more about things. It also gave me some other valuable viewpoints on the candidate.

Don’t forget that while you are interviewing the candidates they are also interviewing you and your company. In addition to assessing their ability to perform the job at hand, you also want to understand what they are looking for and what’s important to them and help them understand more about your team, your process, your company, and your vision. Even if they don’t wind up getting an offer the effort spent here is important and worthwhile. You want them to have a good “candidate experience” (recruiter-speak) since they will likely talk about you once they leave your office either way.

As your team grows you will have to refine and expand this process. You won’t be able to keep skipping all those phone screens because your funnel will, hopefully, have too many applicants and you’ll need to be more aggressive about who you spend your team’s time with.

It’s not a perfect system but it’s a good place to start.

The Offer

Alright! So someone finally made it through the interview process. Congratulations, this should be a rare occurrence. She’s amazing! She’s the perfect person for the job!

If you did the work of understanding during the interview process the actual offer should be relatively straightforward. They should be pumped to join your team because you showed them how amazing you are, the cool shit they’ll be working on, and how much they will grow. You spent some time probing to figure out the things that matter most to them — salary, equity, personal time, remote flexibility, whatever it is.

All you have to do now is send them the offer letter and you’re done, right?

Wrong…

I’ve had folks change their mind even after accepting an offer. Hell, to be honest I’ve done it myself (and felt terrible about it). Shit happens.

You have to understand the inner dialog that plays out in their head once they’ve accepted your offer. Suddenly now things are real. They start doubting their decision and second guessing everything. They are looking for something they missed. Anything. An out. They may get counteroffers that are hard to turn down especially if they aren’t unhappy with their current gig.

You need to keep reassuring them that you want them. That they will be doing meaningful work. Let them know all the cool projects they’ll be working on when they start. You want to make them feel welcome — maybe have your team take them out for drinks to start establishing a social bond. Remind them of just how awesome things are going to be.

Keep the lines of communication open. They haven’t really accepted until they’re sitting in a chair on their first day. Don’t take anything for granted.