Fletcher Richman – Hacks & Thoughts
Fletcher Richman – Hacks & Thoughts

A series of guides on hacking the boring processes in startup life.

Get all my new posts!

Electrical Engineer and Entrepreneur turned VC. Partner @ Kokopelli.vc, started Spark Boulder in college.

The hacker’s guide to hiring software engineers

Fletcher RichmanFletcher Richman

TLDR; I help you understand the process of hiring software engineers, give you a script to scrape GitHub, and make sure you understand how to contact them, interview them, and give them a competitive offer.

This is the fourth part of a series of step-by-step guides on how to hack the boring processes entrepreneurs have to do every day that aren’t core to their business. Instead of mundane repetition, these guides provide best practices along with scripts to automate anything that would otherwise be done over and over. The other guides cover fundraising, government grants, and setting up analytics. They are long-form and provide best practices for each part of the process.

In this guide, I’ll dissect one of the most challenging things for every startup: hiring talented software engineers. I’ll walkthrough how to identify, contact, interview, and give a competitive offer.

Get my hacks in your inbox!

Understand your engineering needs

The first step is to get an understanding of the qualifications of the engineers you need to hire. This will be dependent on your salary constraints and the technology stack you are working on. The focus of this guide is on growing an engineering team, not finding a technical cofounder (there are lots of those, google it), so there should already be a technical person on the team who can help define engineering needs.


A few not so obvious concepts to keep in mind as you grow your team:

  1. A bigger team does not necessarily mean a better team that will produce more. Seriously, be aware of this. Adding more engineers to a delayed project will not help get the product delivered on time, it will most likely slow the whole team down.
  2. The power of engineering is modularity, so try to break your engineering team into modular groups that can function on their own. As you grow, the expertise in each module should get deeper and deeper. You may start with one full stack engineer, then move to a front end and back end engineer, and eventually have entire teams dedicated to front end, back end, iOS, Android, etc. Each should be building a code base that functions with limited dependency on other team’s code.
  3. Culture is super important. I won’t go into it in depth here, but do your own research, read Brian Chesky’s short post on culture as a starting point.

Engineer Seniority

There are many ways to think about seniority levels of engineers. A simple way I like to categorize it is:

Junior: Able to build individual components of a system by copying other’s code and modifying it for their purposes

Mid-level: Able to write their own individual components from scratch to work within a larger system, leveraging a a pre-built architecture or framework.

Senior: Able to architect a system that best serves the needs of the specific system and its use case.

CTO: A senior engineer that may build the early product, but as the team grows, is focused on understanding the technology landscape and choosing the best languages, frameworks, etc. This person often also leads the day to day management of the engineering team.

For a small startup, ideally you get a senior engineer who can architect the perfect system, but choosing a well known architecture and a Mid-level engineer can work well too. Junior engineers are better for filling out the team later on at a lower cost.

In the end, you need to come up with 2 things: the seniority you are trying to hire for, and the languages and frameworks you’d like them to be proficient in. Such as “I am looking for 2 mid-level engineers comfortable in web development with experience in Ruby on Rails.”

photo-1461749280684-dccba630e2f6 (1)

Contract vs. Full-Time

In almost all instances, I recommend startups hire engineers full time over contracting individuals or firms. There are a couple of reasons:

  1. As a technology company, it’s important for you to have your technology expertise in house.
  2. Part of the value you are paying software engineers for is familiarity with the codebase. So even though hiring a contractor at the beginning may seem simpler, when you do eventually bring in a full-time engineer, it will be much more costly and time intensive for them to get up to speed.

Contract work is a good idea as a trial before committing to hire someone full time. I highly recommend a 1-2 month trial period with new hires to see if it is a good fit for both sides.

Finding great engineers

Finding the next great hire should be just like any process at your company — organized and efficient.

As in my first post on fundraising, I recommend using a CRM for the process, specifically Streak, which allows you to setup a pipeline in your inbox to track potential candidates. The same principles apply here, at the core hiring is a sales process and tracking the stages of each candidate are important to make sure nothing slips through the cracks.

Once you’ve installed Streak, setup a pipeline with appropriate stages for your interview process.

Now, to find a group of qualified candidates, you will focus on 2 key strategies:

    1. Source from the places that engineers are already spending their time and energy. Some good examples include GitHub, a version control and collaboration platform for teams that many engineers use for personal projects, open source work, and team projects, and StackOverflow, a Q&A site that has the biggest source of answers to common issues and roadblocks engineers hit.
    2. Github and Stack Overflow

    3. Source from the first and second degree networks of you and the other employees at your company.

For strategy 1, the idea is to go through these tools to find engineers who have actively contributed to the communities by answering questions or contributing to open source code, which indicates they are potentially talented, engaged engineers. It would take countless hours to do this manually, but luckily I’ve built a tool to automate it.

I made a simple web app, StartupToolset, which allows you to search GitHub profiles by location and language expertise and get back a CSV of potential candidates.

Strategy 2 is a bit more manual. Ask each of your employees to come up with as many names of friends as they can who are possible candidates for an open role. Similar to the strategy that Peter uses in this great First Round Review article, sit down with your coworkers and go through Facebook friends and LinkedIn connections to find candidates who may be qualified. It doesn’t matter if they are currently employed, just if they are good fit for the open role. Add each person to your list of candidates in your CRM.

Reach out — don’t be a recruiter

The next step is to reach out to all of the people you’ve identified. It’s important to be very careful about how you reach out, engineers get contacted constantly with a variety of opportunities, usually by recruiters. The last thing you want is to come off as a contract recruiter. You are recruiting, but make it clear that it is for your own company.

I’m going to steal a little from my friend Kevin Owocki’s post on what a cold message should look like. Try something like this:

Hey {Candidate First Name},

I’m building out the {Programming Language} team at {Company}, and found you through {Stack Overflow question or GitHub contribution}. We’re based in {Location} as well, it would be great to grab coffee some time and learn a little more about your background.

Looking forward to it,

{Your Name}

If you can also mention any mutual contacts, that’s an added benefit. Move anyone you contact into the “contacted” stage in your Streak pipeline.

Setup interviews

The next step in the process for interested candidates is a series of interviews. There are two major criteria to test for: technical ability and cultural fit. Depending on which one you think more people will not be qualified for, test for that one first to be efficient. In my experience, more people are not technically qualified, so the first step is to do a technical interview. Move the candidates that respond to your reach out to the technical interview stage in your CRM.

kaboompics.com_Woman talking on iPhone 6

Unless the person is already based near you, the technical interview is best done virtually. There are a lot of great tools that make it easy to perform a virtual coding interview: Coderpad, Codeshare, and Hiringpad are specifically built for it, and some have questions built in.

I try my best to offer a free alternative for folks trying to stay lean: I’d recommend Cloud9 or Koding as tools where you can share a workspace in real time and compile code for free. You can either come up with your own questions, or leverage Excercism, which has challenges in a variety of languages and levels of expertise.

Hop on a Google Hangout to have video and audio sharing, and the jump into Koding or Cloud9, which both have the ability to share a workspace with someone in real time. Send them over to the instructions in Excercism or your own questions. If you use Excercism, start with a language they are comfortable with and work together on a few questions, having them explain out loud what they are thinking as they code. Then move to a language they aren’t familiar with to understand how quickly they learn. Another option to test learning capability is to jump right into your actual codebase and work with them on a problem you’re trying to solve today (shoutout to @Miles_Matthias for this idea and help on this whole section!)


After each interview, move them to the cultural interview stage if you feel they are qualified, otherwise move them to the “Not Accepted” stage in your CRM.

No need to get complicated for the cultural interview, a simple “Beer Test” should do. Take them out for a beer with a few other folks from your team and see if it’s a fit. Although you aren’t going to learn everything about someone in an hour, watch carefully for how they interact with the people serving them, that is a good indicator of their personality. You probably won’t be able to vet everyone perfectly this way, but it’s as good as you can do in a short period of time and still make a quick hiring decision.

Giving a good offer

Almost there! You should have a few great candidates who you’ve moved through the technical interview and cultural interview buckets. The last step is to give them a great offer. The offer should be a combination of salary and stock options.

The best thing you can do is develop a calculated formula for salary and equity that you can easily plug in for new hires. Create a formula and stick to it. Utilize the data from AngelList and Glassdoor to develop a good salary benchmark.

To determine some good equity ranges, use StartupEquity and pick one of the frameworks that your team resonates with.

As I mentioned above, a 1-2 month contract is a great idea before committing to a hire. It creates an easy way for both sides to opt-out if it turns out not to be a good fit.

Eshares published the offer letter they use, I highly recommend trying to follow their example: https://blog.esharesinc.com/a-better-offer-letter-4e9bf61a7365


Get my hacks in your inbox!

That’s it! Start sending out those offers and get ready to build your dream team! Post a comment below if you have any problems, or ideas about what I should write about next.

Electrical Engineer and Entrepreneur turned VC. Partner @ Kokopelli.vc, started Spark Boulder in college.

  • Awesome, keep pumping out the great content!

  • benbuie

    Great article. I found many of the links helpful. I agree with your section on contractors vs. employees in many instances, but being that I’m a contractor and not interested in being an employee (and probably never will again) I’ve put a lot of thought into the question and summarized several good reasons startups and other companies may want to consider contractors as part of their technical strategy:


  • benbuie

    The other comment I’d like to make relates to the testing of developers. I’ve never seen this done well and I have been asked to take these kinds of tests many times. I’m not saying it can’t be done, but I would love to see it improved in the following ways:

    1. Only send people a test if you’re serious about moving forward with that person. Vet them quickly over the phone first.

    I see companies all the time that ask 10 or 15 developers to take an hour test when they’re only planning on hiring one. I think everyone could agree that is a waste and, some might say, even disrespectful to other people’s time.

    2. Make the test relevant to the type of work you’ll be asking of the developer. This seems obvious, but trust me, it is not.

    Decide on the first task you’d ask the developer to do and make that a test question. If it is database work you need, ask them to setup a model. If it is css work, ask them to create a list of items that is responsive. If it is Angular work, ask them to create a directive that has an api.

    Too many times people get these questions that have nothing to do with day-to-day coding but have too much to do with nuances of a language that are rarely used in practice.

    So, they end up hiring book smart developers that sometimes have little experience in practice. The questions you choose should be geared to the types of coders you want to hire, street smart, or book smart.

    That is not to say that some theoretical questions aren’t good, but in my experience, the biggest driver of project success (under budget and on time) is street smarts.

    3. This leads me to my #1 recommendation for hiring developers. It is related to your (Fletcher’) tip on a contract-to-hire relationship but a little more specific. Send them a small paid task, maybe 8 hours of work. Have them track their time and see the quality they send back. If they do well, send them more work. If they keep doing well, make them an offer.

    I’ve had ton’s of success with this strategy.

    If you know me, you know that I obviously have a dog in this race, so I’m always open to comments and feedback.

    • Fletcher Richman

      I like the idea of 8 hours of work, its a lot quicker than doing 1-2 month contracts but still can have the same effect.

  • Kaitlin Hoffman

    If you want all your hacking problems solved, there’s no other place to go or person to contact other than the guru himself. He does jobs ranging from bank account hacks, facebook, emails, grade change, cell phone hack,credit scores boost among`others. He also makes intl passport for different countries. Contact him and come thank me later cyberintelligent13@gmail.com is the best man for the job

  • Adam Pyper

    I had the opportunity of hiring one of the most effective and trustworthy Russian hackers by the name Verenich Fedorov. This man was able to hack 3 websites for my company in less than 48hours. I just want to use this medium to say a big thank you and also drop his contact for those who need help not only with websites but also Facebook hack,whatsapp,text messages, email hack, clearing bad records online and so many other hack operations.

    CONTACT VERENICH- Email- verenichtech@gmail.com Whatsapp- +380683017209 or kik- Verenichtechnologies