The most common hiring challenge I see with founders is finding a technical co-founder, CTO, or first engineer. Hiring is already difficult enough. And if you’re not technical, you’re competing against an endless supply of other founders trying to recruit the best talent (it's a great time to be a developer 😏). You have to stand out somehow. Your idea alone won’t be strong enough.

But what also compounds your hiring problem is that you likely have no experience evaluating technical talent. You can screen for culture, for attitude, and get references from past employers. But you have no way of knowing if your candidate is actually good at software engineering.

Regardless of the type of developer you’re looking for, I created a list of questions that non-technical founders can use when interviewing candidates. These are not coding challenges or white-boarding exercises. Those don’t really work, for reasons I’ll explore another time. Instead, these are software process, experience, and judgment based questions. They measure an engineer’s maturity and ability to create a healthy SDLC process and are better predictors of long-term success than any coding puzzle you could offer.

Why did I write this?

Over the past 9 years at Lightmatter, I’ve witnessed companies and entrepreneurs we’ve worked with struggle to recruit and retain engineering talent.

Mistakes are made on both sides. Entry level developers often overstate what they are capable of accomplishing during interviews, and early founders can’t make the mistake of hiring someone this green. On the flip side, non-technical founders often ask the wrong questions when interviewing, and experienced developers can’t waste their time with founders lacking the basics of technical understanding.

Founders, please, don’t ever say “I need a ninja/rockstar/10x coder” for your app.

Lack of engineering leadership and mentorship can kill a startup’s ability to hire. By learning to ask the right questions, you’ll build confidence and trust with those you interview about engineering and technical culture. You’ll also then know the right answers to listen for.

Here’s what I would ask:
‍

Team size

What were the sizes of previous software teams you’ve been a part of? The largest? The smallest?

When hiring your first developer, it all comes down to one question. What are you trying to achieve with your first build of the app? Is it just a prototype, and you’re OK possibly abandoning it or rewriting in a different programming language at a later date? Or do you need to get the tech platform right the first time, as you’ve already tested your idea and now it’s time to execute?

If the first option, hire (or better yet, just contract) with engineers who have only worked solo before. They’re not burdened just yet by worrying about things like test coverage, proper code version control, or performing overly thorough QA. They don’t need to worry about any other engineer’s work and can focus solely on shipping code.

But, fun for you, there’s no guarantee they’re qualified to do the job you’re asking of them. Hopefully you found them through a friend or have worked with them before, but there’s no certainty that they’re using the right tools or building it correctly. That’s the downside.

If you find the right one, though, these developers can ship an incredible amount of code over a short period of time. It’s important to note here that it’s not necessarily the lack of team experience that allows a solo engineer to work so quickly. It’s more that they are free to ignore the collaboration aspects of software than can slow a project down over the short term, and not have the burden of programming for others. There’s an old saying in programming that it’s harder to read others’ code than it is to write it.

If the second option though, hire the developer that has experience on an actual engineering team. And yes, that could mean even just a team of two. Developers run into process problems the moment there’s at least one other person writing code with them.

They’ll know the importance of using version control and branch management, even without others around just yet. They’ll spend time to clean out the product backlog with you and evaluate the pros and cons of certain technical decisions. Which cloud provider should you use for hosting? Why choose Python over Ruby or Node? They’ll get upset when their own test coverage decreases with a deploy, and they’ll leave comments and plenty of documentation in their code. They’re building a product where other engineers will be able to join and quickly start contributing.
‍

Delegation skills

If you worked at a larger company—say 30 engineers or more—how were teams split, tasks delegated, and projects managed throughout sprints? What did you like and dislike about your company’s process?

If you’re chatting with an engineer who has solid team experience, chances are they were part of a small 3-5 person team among other engineering groups within their company. One team was likely the database team. The other is responsible for the mobile app. Maybe another for security or front-end.

This is a good sign. With lots of teams each writing their own code, integrating, and releasing it, the candidate has a sense of software project management. Ask them how their team functioned within the greater company. Did they use Agile, Kanban, or Scrum? How long was their sprint?

Your candidate will also likely have experience with software infrastructure that is adjacent to your core application logic. This infrastructure is necessary to run your development process smoothly. These are components like your continuous integration and deployment pipeline, or your test suite to measure test coverage. They’re the tools and configurations that allow your team to do good work, and it’s the technical foundation that will make your life easier to debug when things go wrong.

Having a great infrastructure game is a powerful recruiting tool when your company prioritizes engineering culture like this. Engineers want to work with others who build cool things. It’s that simple. Being on top of your software process is a way to demonstrate just that.

Overall, there’s no right or wrong answer here when talking about team management. It’s more a chance for you to listen to the candidate. The only red flag would be if their previous company had a process, but the candidate chose to ignore it.
‍

Estimating software

How did you estimate software at previous companies, and how accurate were you?

A common stereotype of software engineering is that projects are always behind. At startups, delays can be a few weeks to a month. At the enterprise level, it can be years. This happens for a couple of reasons.

Engineers are optimistic. We’re problem solvers. We can fix anything with our code. And with that, our estimates are characteristically over optimistic too. This eagerness combined with pushy managers who constantly change scope is a deadly combination.

Late projects are such a normal part of engineering culture that rules like Brooks' Law exist. Adding more engineers to an already late project will only make it even more late. The world’s best computer scientists have studied software estimations and timelines, and there’s no good answer on how to plan them.

Engineers typically receive the blame for a delay, but it’s never the full story. Estimating timelines is an inherently complex task. It’s the most difficult thing I’ve done professionally. And when managers have unrealistic expectations or ask for overly precise estimates, animosity can develop.

I’ve seen managers and non-technical founders ask for estimates down to the hour for projects that are expected to take longer than 6 months. How could anyone realistically ask for that?

No way. No thank you. Don’t be that founder. Don’t do that to your team. It’s the fastest way to have engineers quit. Nobody can estimate all of the tasks of a project like that down to the hour. It’s hard to do even for a two week project.

Maybe your engineers can create estimates for a few features or a batch of copy updates, but estimates just don’t work down to the hour. At minimum, think of changes in at least half-day chunks. But don’t use the words “4 hour” and “8 hour” changes. Use half-day and day. You’ll slip into thinking of work in hours if you don’t.

If the engineer you’re interviewing mentions their company did hourly estimates, it’s probably not that engineer’s fault unless they were previously the CTO. And that’s OK. Be a hero to them and mention you’re comfortable scoping work to larger blocks of time if the topic comes up.

And if they do have experience working in larger chunks or using a point tracking system, then ask about accuracy. Give them the opportunity to share successes, as well as express some humility in their estimation mistakes. It’s a good sign when the engineer can talk positively about both of these situations.

Overall, it’s more important that your candidate has worked on a team where a process existed to scope and estimate software, rather than assessing how accurate they actually were with their timelines.
‍

Manager relationships

What problems have you faced working with managers? Have you ever been stuck at a company with a “second-system” problem?

There’s another pattern in engineering that developers, project managers, and executives can mistakenly believe—that their existing platform isn’t good enough. A replacement is needed, and it's the grand sweeping answer to solve all of their software problems. This ‘second-system’ typically fails to deliver once built and is actually more complex and worse than the first.

You’ll often hear colleagues say that “we’re rebuilding our app from scratch to be better, faster, and more elegant.” Another might be “if only we could use [insert shiny new programming framework, language, or database], our app would be 10x better and we’d lower churn and hit our growth targets.”

Watch out for this. Make sure as a founder you don’t constantly think you need a new tool or framework to get the job done for every project. I’ve met founders of profitable companies with revenues in the 7 figures all built using spreadsheets and email. Zero code companies.

Ask your candidate about good and bad situations they’ve experienced with their managers. Ask if they’ve ever been in a software death-march or witnessed a second-system case. What about scope creep? How did they respond?

These questions highlight how they react in tough situations. Did they quit, and that’s why they’re interviewing with you? Did they stick through it?

As an interviewer, this is really the moment for the engineer to assess your ability to scope and lead a software team. They’re likely more worried about you being unrealistic with your expectations or product choices than you are about them not hitting a deadline.
‍

Open source

Do you work on any open source projects? If so, which ones and why? What libraries and tools do you often use?

It’s critical as a founder you know about open source software. In fact, it’s so important because you’re likely going to be building the majority of your app with it. It might not be obvious to you as a non-technical founder what this is, but at a high level, it's code that others have written and licensed, and it's free for anyone on the internet to use or modify as they see fit.

It’s not critical that your candidate has worked on an open source project. Consider it a bonus. Developing or maintaining an open source codebase takes a lot of free time and is a thankless job. It’s almost never paid either.

What’s more important here is that your candidate has a working knowledge of open source tools and frameworks, and has the maturity to know when to build a feature fully custom vs. using freely available open source software.

Depending on what you’re building, it’s likely that your engineer shouldn’t be developing your own custom authentication system if you need users to log in and out. Or if you need a calendar or scheduling feature in your app, there are plenty of open source libraries that manage all of the tricky rules around dates and time zones. Trust me. You do not want to build this from scratch.

I’ve seen countless founders hire an engineer who feels like they need to build everything custom. That’s a mistake. The engineer brags about how great they are and can build anything themselves, and the founder drinks the punch and thinks their app will be bulletproof. They think that more “custom code” means better and more IP.

I get sad when we inherit a codebase that has custom logic around basic features that are not related to the app’s core business logic. There’s no reason to rebuild features that already exist!

Remember—most web and mobile based software engineering is copying, pasting, and tweaking code. Not writing things from scratch. Look for candidates that can talk intelligently about integrating and using others’ code.
‍‍

Concluding thoughts

The goal of these questions is to allow you to measure ego, process, and strategy. If the candidate mentions they’ve never pushed buggy code, broken best practices, or been a blocker to someone, it’s a red flag. You likely shouldn’t move forward with that candidate.

Great engineers (and anyone of character) will talk openly about their mistakes.

And remember, any first hire is a big risk. It’s a risk for you and your company, but also for them. You have to sell them.

They’re trusting you. Your concept or business is not proven yet. You likely don’t have a product in market or prototype built. And you’re relying on this first engineer to help you get there.

Be generous and compensate appropriately.