Fab.com Flash Sale. White Terrier Mini Block Kit, 31% off
Fab.com
With nanoblock, kids can create incredibly-detailed 3D works of animal art. nanoblocks are about one-eighth the size of standard building blocks, so these micro-sized pieces will enable you to execute the finest details in ways that other construction toys simply can’t. With over 110 pieces, the White Terrier Mini Block Kit will help kids build this friendly pet—and his matching bowl—small enough to fit in the palm of your hand!
Before we had multiple engineers on the team, we would ask out strongest technical friends to come by and interview people to help us. This allowed us to ensure we always had ~4 engineers interview every candidate, even if we were just 2 founders to start with. As we scaled to past 4 people, we still had every engineer on the team met every hire.Our 10 Step Engineering Hiring Process at Mixer Labs
Before my company, Mixer Labs, was acquired by Twitter, I spent a big chunk of every day on hiring. A lot of entrepreneurs I help out ask about the process we used to hire a very strong engineering team and so I thought I would share the steps we would take in this post.
1. Resume screen.
We would source people from friends, engineering meetups, LinkedIn, basically anywhere we could find someone who seemed good. I think of approximately 100 resumes or profiles we looked at closely we hired 1 person.
2. Phone screen 1 - culture fit and “reasonable to set up technical call”
After choosing a subset of profiles or referrals to follow up on, I would do an initial “culture fit / is this person worth talking to” phone call or a “sell” call to people not actively looking. In some cases people did not want to leave their job (if I was reaching out to them), or they might be a bad fit to begin with. I would screen for things like:
I would simultaneously try to sell the person on the opportunity, to get them excited about our company. Remember, all interviews go both ways as the candidate is also interviewing you as an employer.
These interviews would literally take 15-30 minutes and I set expectations up fron that the call would take 15-20 minutes (if someone is asked to block 15 minutes on their calendar, they usually block 30 minutes anyhow, so we never ran out of time). These short blocks of time minimized the time spent on this first screen and often I would know within 5-10 minutes if the person was worth a second conversation.
I would meet the really promising people in person for a coffee if they were somebody I was trying to convince to leave a comfortable existing job.
Of 100 people we started with, maybe 15-20 people got an initial phone calls or coffees.
3. Phone screen 2 - engineering interview.
This second phone screen focused more on engineering questions and ensuring the person was strong technically and merited an in person interview. This would take 30-45 minutes and be performed by a rotating set of engineers on our team. Different engineers had different filters / set points (e.g. some were much harder “graders” then others, so I would take this into account when scheduling in person interviews, asking the candidate to do an additional phone screen (if they seemed marginal), or dinging them.
Of the 100 people we started with, 7-8 would probably make it through the phone screen to an in person interview.
4. In person interviews.
People would come in and be interviewed by each member of the technical team for ~45 minutes. We would sometime put an extra 15 minute buffer for engineers who tended to take longer with candidates.
If one of our team had worked directly with the engineer before, we would skip them past phone screens directly to an in person interview. We had *everyone* interview with everyone on the team, even truly exceptional engineers we had worked with in person before.
Of the 100 people we started with, 2-4 made it through the in person interview.
5. Discuss the candidate
We had each person write down their thoughts of the candidate before we discussed them and then asked each person for their opinion. We also asked people how they would rank the candidate against all the other candidates we had interviewed. I.e. below a certain bar they were not worth considering further.
For a while, we used to graph the stack ranked interview feedback vs years of experience to look for outliers who are stronger then average. We would pursue these outliers aggressively.
6. Half to full day work with team
We asked a subset of the people we moved forward with to come in to work with the team for a half day or full day to test their working style, how much they could get done in a day, design/engineering choices they would make, and also whether they were interested enough in us to actually take the time off to meet with us.
We would always give the candidate the same coding problem, and we would always through away they code at the end. The purpose was to test their skills and fit, rather then have something productive come of the day. At the end of the day, we would all gather around and the engineer would show us his or her work.
3 out of 4 people who came in to work with us we moved forward with to the beer test. In some cases, having someone come in to work with us made us moreexcited about them as a candidate (i.e. it was someone we were going to ding based on interviews, whom we kept due to their performance coding). They may have been medium on the in person interviews, but great coders who just got a lot done and were good to work with.
7. “Beer test”
We would take candidates out for dinner or beers to see if they were a good culture fit. I.e. would our team enjoy having the person around, drinking beer with them etc. In a small organization culture fit is paramount.
We actually dinged a really exceptional engineer that made a lot of grossly off color comments in the beer test. He was one of the strongest engineers we met, but felt he would be a bad fit culturally, and this only came out during the beer test.
1-2 out of ~100 people whose profiles we started with would make it through the beer test to be given an offer.
8. Reference checks
We would check ~5 reference per candidate. Only one candidate who made it to the reference check phase got dinged because of his references (we actually always tried to back channel to references the candidate did not provide, and in this case the engineer had some politically driven conflicts with others, so we decided not to hire him). As a small organization we did not want to take the culture risk, although that engineer went on to thrive elsewhere.
Great reference checking will be the subject of a future post.
9. Offer
We would make the offer to the candidate in person or on the phone, depending on our prior relationship to the candidate. I may get into more details on making an offer in a future blog post.
10. Close
Of the people we made offers too, about 2/3 to 3/4 of them accepted. Most of the people who did not join Mixer Labs, tended to stay with their existing employer. We would use a number of tools to close the candidate, including e.g. having them meet with our investors to get our investors view of why we were a good company, or we would invite the candidate to events we had at the company, such as our speaker series (even when tiny, we invited CEOs and other industry execs or entrepreneurs in to our company to give talks on their experiences. This was a really cool company perk everyone enjoyed).
Hiring is a numbers game
All numbers quite rough (e.g. 100 profiles to 1 hire is more or less what happened with us but I am pulling all the numbers from memory so they are rough estimates. I actually had big spreadsheets with all the details but can not find them) - but hiring is very much a big numbers game. You need to set up a funnel and optimize each step.
All else being equal, we chose to optimize for false negatives over false positives. We kept our bar really high, and due to this grew (painfully) slowly. But it is was worth it as we ended up with a pretty extraordinary team.
Does your company do something differently that works really well? Let me know in the comments what you do differently - I always love to hear how people approach hiring and what works and does not work.
Let your customers help your Customer Development
You hear it again and again — stories that extoll the virtues of understanding what your customers need. Zappos has built their whole business around the idea that happy customers are the key to success (see Delivering Happiness for more). Pair that with the enthusiasm for the Lean Startup Movement and everyone points to customer development as critical to traveling down the road towards product/market fit. At Profitably, we’ve generated such a backlog of ideas and tweaks that we could keep building in perpetuity. Some of these concepts come from scratching our own itches, some come from experts in the finance space, and others come from business owners that never want to hear the words “general journal.” So how do you effectively capture and act on those ideas? How do you cut through the noise to develop the car and not a faster horse? I don’t have the answer, but since we’ve gone through a number of iterations on this I’ll share what we’ve arrived at so far. First off, there are many ways to get feedback from people and you should plan on using as many as you can. There are many types of learners — some like to read the manual first while others rip open the box and start playing. Before people even sign up for Profitably, we give them lots of resources. We keep updating our FAQ to handle common questions, are constantly publishing relevant content on our brochure site (app specific and agnostic) and even give people the chance to jump into a demo. We put an email address and phone number on every page, you can submit a question through the Zendesk tab on the side, and I’ve even hooked up live chat on the pricing page. This alone generates a good volume of feedback and food for thought. Remember — this is all coming from people who haven’t even signed up. Now, let’s assume that all of this great content is able to convert some of these visitors into leads and trial signups. (You are tracking all of this and reading Lincoln Murphy’s great advice on SaaS marketing, right?). Even signing up for a free trial is a commitment. There’s an opportunity cost associated with the time you’ll devote to getting started, so bear that in mind. In our app we offer the same communication channels from the brochure site, and I’ve also created Kiss Insights prompts based on specific triggers (e.g., someone has returned x number of times and has been using the app for more than x minutes). I’m conscious of the fact that people are using the app to answer a business need, not take a survey, so the questions are quick and hopefully in context (and easy to ignore!). I also follow up with every person that signs up to get a sense of their business and what problems they’re hoping we can solve. Sounds great, now how do we turn all of those emails and calls and text snippets into stories/features? We’re still rolling it out, but I love what I’ve seen so far with User Voice (believe it or not we use yawa — yet another web app). We capture requests, questions, suggestions from all of these channels and figure out how to cram them into a sensible product development model. The set up includes epochs (or “epics” as we call them) for the high level blocks of functionality that are still in the distance, along with more granular ideas or tweaks for what’s already out there. We considered keeping the longer roadmap ideas internal but ultimately decided it’s more important to get your ideas out there and get feedback. Product development is about figuring out the single most important problem that exists right now and doing that and only that (source) This is important to remember, and tracking feedback through User Voice helps us be measured in our decision making. When it’s time for us to start our next sprint we have a weighted backlog to pull from. Even better, anyone that voted for an idea is updated on progress, from review all the way to completed. Maybe some day we’ll let people add stories right into Pivotal Tracker! (ed. note from Francis: false). What stinks: UV doesn’t allow me to attribute ideas to someone else, even as an admin. Instead, I’ll do the adding and then send the link back to the requester. If they vote or comment the link is still there, but I’d much rather see ideas linked to other people than me. Overall I’m really happy with how our experiment’s progressing. Want to hear more? Know how we could be even more awesome at capturing this feedback? http://blog.profitably.com/post/5912606169/let-your-customers-help-your-customer-development
Your marketing spend should be very minimal until you validate that you have created a product that people want or need (an important exception is for network effect products, which I’ll cover later). I would suggest 95/5 ratio between product and marketing. You don’t necessarily need a marketing person on the team to do this early validation. Once you’ve validated that people want or need the product, you should spend as much as you possibly can on customer acquisition as long as the value of each user exceeds the cost of acquiring them. Often this requires raising additional funding, but if you can present proof of profitable, scalable marketing channels then it should be easy to raise the additional funding. Of course you should complement this paid customer acquisition with free sources if possible (and you can start these early in the validation process). If your product really does a good job solving an important need, you should also have strong organic growth. At this point the spend ratio generally tips toward marketing. I’ve seen it as high as 80% to marketing and 20% to product.
