We made the mistake of starting out with a development agency based in Turkey, or so we thought that’s where they were located. We wasted a lot of money (6 figures) and, more importantly, we lost 3-4 months with absolutely nothing to show for it. It was demoralizing, and it would’ve been really easy to quit at that point. We didn’t start heading in the right direction until we took the leap and decided to start building our own team.

Looking back, it seems obvious to build a team. However, it’s hard to fault any non-technical person who is attracted to the idea of writing up a spec sheet, passing it to an agency, paying a fixed price, and being promised the world. It’s tempting, but it’s usually the wrong move.

That left us with one viable option: hire an internal developer as an addition to our team. The other option, of course, would have been to find a technical co-founder. However, I’m not sure anyone would’ve wanted to join us at that point. I do think anybody who has the opportunity to get a technical co-founder should do it; it will save a lot of heartache, time, and (very important) cash.

Most technical founders will tell you not to start a software company if you don’t have a technical background. This is sound advice in many ways. The path to building a profitable SaaS company is really challenging; add in the fact that you’re clueless about development, and the odds are truly stacked against you. However, it would be hypocritical of me to give the same advice, since David and I took that very path; my advice, instead, would be to slowly, cautiously, and patiently search for smart people, no matter how difficult.

Hiring an Outside Agency (Usually) Isn’t a Good Idea

It’s no secret we have a bad taste in our mouths when it comes to using development agencies. I’m sure plenty of people have had the opposite experience, and I’m sure there are situations where it would make sense to work with one. That said, you’ll most likely overpay, you might get screwed, and you’ll end up with the first version of a software with no way to build on top of it.

Building a successful product is all about learning. There’s no way you’re going to nail everything your customers want on the first try, so even if you can get to an MVP with an outside agency, well, that’s only step one. In the same regard, your interests are simply not aligned. From the agency’s perspective, the task is to go from point A to point B as quickly as possible, because that’s when they get paid. They’re not the ones who have to live with that codebase for the lifetime of the company; you do. It’s essentially short-term vs. long-term thinking.

Let’s say your plan is to start with an agency, spend a fixed amount of money, get an MVP, start selling it, and then hire a developer once you have the revenue. Sounds good in theory, but this will be very hard to achieve in practice. There’s a very good chance your target customers will not be breaking down your door to get access; in fact, it will likely be the exact opposite. You’ll have to break down their doors just to get them to take a look. You’ll have to learn about objections through endless calls. You’ll have to make improvements to save initial customers. You might have to make small pivots, or even change the core of your product, in order to get initial traction. Which is why, in my opinion, starting with an agency to build an “MVP” of your product is like taking a shot in the dark.

Not to mention, you don’t have any assets. A product without a way to improve it is more of a liability. A company is simply a group of people working together on something; if you just have the something, you don’t have a company. Investors will not even consider investing in a product without a team behind it, even if it does have some early success. And while I’m not saying you need investment, it is good to see things from that perspective. You should build your company in a way that it can be handed off to someone else, even if that’s not your intention at all.

Get Ready for a Long and Arduous Process

Hiring great people is not easy; it takes a lot of time and commitment. You might interview 100 candidates and still not find the right programmer for your team. That’s okay. You have to stay committed to making the right hire, not the easy hire.

In order to save valuable time, you should think of your interview process as a ladder. Everyone starts out on the ground, and they slowly progress up the rungs as they pass your interviews, tests, etc. The further someone climbs up the ladder, the more time you’re spending with that person. So, ideally, you’re filtering candidates out at each step in the process. This will keep you from wasting time with unqualified candidates.

A Quick Look at Our Hiring Process for a Technical Position

Early on, we put job posts on a few different sites, including UpWork and Stack Overflow. We’ve tried running ads for our posts, and we’ve tried using sponsored listings on job board sites. None of these tactics are effective, unless you can actually attract people to your company. It’s your job to sell the position and, more importantly, the opportunity.

At Demio, we’re able to offer things that a lot of larger companies simply can’t offer: a small and nimble team, a flexible and relaxed work schedule, the ability to work remotely from anywhere, exciting technical challenges, great team communication, and more. We put these benefits front and center in our job posts. We also clearly express our company values, and we’re very specific about the type of person we’re looking to hire. So, when the right person finally reads that job post, it almost seems like it was written specifically for them. Our team members have told us when they first saw the job post that attracted them, they knew Demio was the right company instantly.

Nowadays, we pretty much post exclusively on We Work Remotely, which was created by the great guys over at Basecamp. Obviously, this site is only for companies that allow their employees to work remotely, which is a huge benefit for us. We’ve found that candidates exploring this site are generally looking for something very similar to what Demio has to offer. The best part is that it’s not just limited to developmental positions, but also support, marketing, design, and more.

How We Filter Candidates

We try to filter out as many candidates as possible through our job post alone. For example, we might include something as simple as, “Start your application with #Demio in order to be considered for the position.” You’d be surprised at how many job-surfers will simply skip over that small detail because they’re applying to 50 jobs a day. This allows us to instantly filter out 50% of potential candidates without wasting a minute of our time.

We then reach out to the candidates who stand out to us and set up an initial interview, which is more of a meet-and-greet than an actual interview. The purpose of this initial call is just to see if it could be a good fit. Do we click? What’s your background? What are you looking for? Maybe this position isn’t actually what you thought it was. These are basic questions that allow us to gauge a candidate from a 10,000-foot view. If it doesn’t feel right, we can be upfront and honest with that candidate and save both parties a lot of time.

At this point, our pool of candidates is significantly reduced, and we can focus on doing quality interviews. Following the initial communication, we usually move into a more technical interview with the goal of making sure the candidate actually meets the position’s requirements. We want to be certain the candidate can back up what was said on his/her application. If they pass the technical interview, we’ll issue some kind of short programming test that will allow us to see not only how the candidate works, but also the code he/she writes.

If the candidate has managed to survive thus far, there’s a good chance he/she will be hired. Our final interview is all about culture, vision, beliefs, and personal attributes. This is probably the longest and most important interview, and it allows us to hire programmers that are not only skilled, but also share similar values/beliefs with our company and team. We make a decision out of the small pool of candidates who have passed all of our interviews, and then set up a final call to make the hire. This call usually goes over smaller details, salary, start date, etc.

DOWNLOAD YOUR FREE WEBINAR STRATEGY CHECKLIST BELOW  

Use this checklist  to design your very own high-converting webinar marketing strategy from scratch, then automate the process to attract high-quality leads. 

We promise to never spam or send emails about cats.
Okay, maybe some cat stuff.

Three Rules You Should Follow in Your Hiring Process

There are three guidelines we strictly follow at Demio, and we never make exceptions. It can be tempting to try to speed up the interview process and push a hire through, but you need to make sure you’re being thorough. In the same token, you don’t want to scare away A-players because your interview process is too long. Once you know a candidate is a good fit, you need to move fast. Make the hire as soon as you decide, or you’ll risk losing that candidate to another company that didn’t make the same mistake.

If it’s your first technical hire, take your time. Move slowly and be thorough. The right hire at this stage will be the difference between being able to actually launch a product and complete failure.

That being said, here are three rules that every non-technical founder should follow:

1. Use a Technical Adviser or Short-Term Consultant

This will be key for you. You’re not a programmer, so how are you going to judge the code of one? The answer is by using an adviser. Find one, or even two short-term consultants you can use to help interview and test candidates. Even if you have to pay a consultant $100 per hour, it’s worth it; you’ll probably only need them for 2-3 hours anyway, and it can save you months of time and tens of thousands of dollars in wasted development.

How can you find a consultant? There are many options. You can use freelance sites, such as Upwork or Freelancer; just search for developers/consultants who have a similar skillset to the position you’re looking to fill. The ironic part is that you won’t actually know if this consultant knows what he/she is talking about, and that’s why I recommend considering getting two advisers instead of just one. It’s also why I recommend taking out your wallet and paying for quality here rather than trying to save a few dollars. Another route, which is even more preferable, would be to have a technical friend help you with your interview process–someone you can trust.

2. Give a Development Test

This rule alone has helped us filter out a ton of candidates that can talk the talk, but can’t walk the walk. When you’re hiring a developer, you should know how they code, just like you should know how a writer writes or a photographer takes photos.

Using your technical adviser/consultant, you can pay to have him/her create a short development test in the desired programming language for which you’re looking to hire. Usually, our tests consist of building some kind of small application that can accomplish a set of tasks. Not only will you see if they can deliver a working prototype within a reasonable amount of time, but your technical adviser will also be able to look at the code, documentation, and overall “architecture” your candidate chose.

We usually try to keep our tests small enough that they can be completed in less than one day. These are not paid tests, so we don’t expect the candidate to commit more than a day of their time for a position that he/she might not even end up getting. We also try to set an agreeable deadline, usually 2-3 days from the start time; this small detail alone allows us to see if our candidate is capable of hitting deadlines and delivering results on time.

3. Don’t Hire on Technical Skills Alone

Seemingly obvious, but easily overlooked by non-technical founders hiring a programmer for the first time. Culture matters, even for programmers; it matters for everyone. However, it can be really easy to overlook some “bad” qualities in a candidate just because their programming skills are amazing.

Remember that this employee will be with your company for (hopefully) a long time, and they’ll be a part of your team, just like any other hire. Someone with a toxic personality will ruin your culture and, eventually, destroy your team.

Actual Programming Interview Questions You Can Ask

Do you currently have a job?

If yes, what do you like about it and what do you hate? Why are you looking to leave?

If no, how did your last job end?

This series of questions will allow you to get an idea of the candidate’s availability. If he/she is in a current position, then he/she might not be eager to jump to a new job unless it’s the “perfect” fit. If the candidate was recently fired from a job, you can find out why (from their perspective) as well as learn about some of their flaws as an employee. If the candidate recently quit a position, you can find out the reason for their quitting and usually get a general idea of what he/she is looking for in an employer.

When working with smaller teams, what do you think is the most important quality the team needs to have?

Every company is different, and every company has different values. At Demio, we really value communication and trust. By asking this question, we can find out if the candidate shares similar values.

What was it that attracted you to the advertised position?

This question will allow you to gauge your candidate’s level of interest in the position. Not only that, but this information may become valuable when it’s time to negotiate and make the hire; if you know what your candidate wants, you will know how to sell the position.

Where do you see yourself in 5 years?

There’s no right or wrong answer to this question; we generally ask this to candidates to see if it’s even something they have thought about. If they have thought about it, chances are they’re more long-term and plan-oriented. You can learn a lot about a candidate from this question, like whether they want to be in the same position, grow into a new role, or even start their own company.

What are your greatest strengths and weaknesses?

A seemingly generic question, but it’s actually one of my favorites. Occasionally, you’ll receive weaknesses that are really strengths in disguise, for example: “I work too much.” More often than not, however, you’ll receive honest answers from your candidates, and it will save you a lot of detective work. Why try to figure out what they’re good and bad at when they can just tell you? You’ll also be able to see how self-aware the candidate is.

You Should Ask Meaningful Questions

The above examples are just a few of the many programming interview questions we ask our technical candidates, but I thought these could easily be applied to whatever developmental position for which you may be hiring.

When you’re writing some of your own questions (which I highly recommend doing before hosting an interview), you should have a goal for each one. Don’t just ask questions for the sake of asking questions. If you have a company identity document that goes over your company’s values and beliefs, you should use that to craft some of your interview questions. For example, if you have a core value of being customer-centric, you can probably craft some kind of question around product development to find out your candidate’s thoughts and to see if they share similar values.

When it comes to asking technical programming interview questions, you should save these for your technical adviser or consultant. Don’t ask questions you’re not in a position to ask; your candidate will sense your lack of knowledge in the area.

Conclusion: It Gets Easier

Hiring developers as a non-technical founder is really challenging–maybe one of the hardest parts in the early stages of your SaaS company. It was for us. Take comfort in the fact that it gets easier over time. Not only do you get better at interviewing and filtering candidates, you’ll also have developers on your team whom you can rely on.

When you have technical employees whom you already trust, you can utilize them for future technical interviews. You’ll no longer have to rely on an adviser or consultant to filter candidates, but you still can if you get value from it. When you create development tests for a certain programming language, you’ll be able to use that same test well into the future when hiring for new roles.

I know it seems overwhelming, and it can be. But trust me, making a bad hire in the early stages of your company will be 100 times worse than going through this thorough process. Not only could they cost you a ton of time and money, but they could also single-handedly kill your company. A great hire, on the other hand, will propel your company forward and reduce your overall stress to a major degree. Take the time and find the right person; it’s always worth it.

DOWNLOAD YOUR FREE WEBINAR STRATEGY CHECKLIST BELOW  

Use this checklist  to design your very own high-converting webinar marketing strategy from scratch, then automate the process to attract high-quality leads. 

We promise to never spam or send emails about cats.
Okay, maybe some cat stuff.