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. You have to stand out somehow. Your idea alone won’t be strong enough.
It’s a great time to be a developer.
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 though. Those don’t really work, for reasons I’ll explore another time. Instead these are software process, experience, and judgement 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 that you could offer.
Why did I write this?
As a co-founder of a Lightmatter, I’ve seen over the past 6 years companies and entrepreneurs we’ve worked with struggle to recruit and retain engineering talent.
Mistakes are made on both sides. In interviews, junior developers often overstate what they are capable of doing, and early founders can’t make the mistake of hiring someone this green. And non-technical founders ask the wrong questions when interviewing too. No experienced developer wants their time wasted by a founder who thinks they’re “technical-enough”. Lack of engineering leadership and mentorship can kill a startup’s ability to hire.
By learning to ask the right questions, you’ll show you’ve taken the time to educate yourself about your software and overall developer culture. You’ll also then know the right answers to listen for.
Here’s what I would ask:
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.
And, fun for you, there’s no guarantee that 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.
But if you find the right one, 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 means 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 with you where other engineers will be able to join and contribute at an alarmingly quick rate.
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 responsible for the mobile app. Maybe another for security, or one for the front-end.
This is a good sign if so. 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.
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 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 black and white. Estimating timelines is inherently a 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 2 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.
There’s another pattern in engineering that developers, project managers, and executives can mistakenly believe. It’s that their existing platform isn’t good enough. A replacement is needed, and in a grand sweeping fashion it will 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.
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 is code that others have written and licensed, and available for anyone on the internet to use or modify as they see fit for free.
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 can be 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 code base 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 of 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.
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, broke 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.
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.
If you liked this story, follow me on Twitter for more.