Read on Twitter
Frequent question from #founders who are just getting started:> How do I hire my first developer, when I'm not technical? How do I know they can code?
Here's how to do this with confidence, using the questions and techniques I've used interviewing *hundreds* of engineers.
> How do I know they can code?
Good news: you're not looking for code. You're looking for product validation, for learning and for solutions to user problems.
Focus on finding product-focused engineers who can work with you to validate, learn and solve. No tech chat needed.
Good news: you're not looking for code. You're looking for product validation, for learning and for solutions to user problems.
Focus on finding product-focused engineers who can work with you to validate, learn and solve. No tech chat needed.
In an interview, I always start with a simple question:
> Please can you tell me about a recent project you've worked on that you were proud of?
> Please can you tell me about a recent project you've worked on that you were proud of?
This is their opportunity to tell you a story about something they've worked on, but also on how they worked on it, and why they were proud of the outcome.
Developers who are focused on user problems and user outcomes have no problem diving in with a story.
Developers who are focused on user problems and user outcomes have no problem diving in with a story.
For bonus points: tell them in advance you'll be asking this. This removes the disadvantage from people who are less good at thinking on the spot, and will bring better answers from all candidates.
You're not looking for thinking on the spot. You're looking for user focus.
You're not looking for thinking on the spot. You're looking for user focus.
Listen to their answer (I like to write notes), and ask questions to learn more. Here are fifteen potential follow ups:
1. What was the motivation for doing this project?
2. What problem was it solving?
3. How did they find out it was a problem?
1. What was the motivation for doing this project?
2. What problem was it solving?
3. How did they find out it was a problem?
4. What different solutions did they consider?
5. What were the hurdles along the way?
6. What went well?
7. What went better than expected?
8. What went worse than expected?
9. Who did they collaborate on to come up with the solution?
5. What were the hurdles along the way?
6. What went well?
7. What went better than expected?
8. What went worse than expected?
9. Who did they collaborate on to come up with the solution?
10. Did they work with any users on the solution?
11. Did you work with any business stakeholders? Anybody from customer support?
12. Did your project make it to real customers? Did it go live?
13. Was the project a success? Did it solve the problem it was designed to?
11. Did you work with any business stakeholders? Anybody from customer support?
12. Did your project make it to real customers? Did it go live?
13. Was the project a success? Did it solve the problem it was designed to?
14. What else did you learn along the way about the problem and your users?
15. What would you do differently next time?
This will give you a really good insight into how they like to work.
15. What would you do differently next time?
This will give you a really good insight into how they like to work.
If they're passionate about customers, know why they were working on a project, collaborated with people to get it done, know how it performed in the real world and have insight about how they'd do better next time, you're onto a winner.
Another plan is to get them to explain something technical to you:
> How would you describe [X] to a layperson?
Software is the process of translating human problems into computer solutions - this allows you to see their translation abilities, just the other way around.
> How would you describe [X] to a layperson?
Software is the process of translating human problems into computer solutions - this allows you to see their translation abilities, just the other way around.
If you aren't a developer, you're going to be relying on them to explain technical stuff to you, so you can help them make decisions on trade-offs and priorities.
So this again is something you can test without having to know the technical details yourself.
So this again is something you can test without having to know the technical details yourself.
Example topics (and quick summaries of potential answers):
How would you describe "Git" to a layperson?
A "version control" system which allows you to store all changes to code, and deploy them to your customers. Analogous to "track changes" in Word. Less-commonly used examples are Subversion (SVN) and Mercurial.
A "version control" system which allows you to store all changes to code, and deploy them to your customers. Analogous to "track changes" in Word. Less-commonly used examples are Subversion (SVN) and Mercurial.
"APIs"
Application Programming Interface - a way for two systems (and two parts of the codebase) to talk to one another. Typically one side (the client) will send messages in a format defined by the other (the server).
Application Programming Interface - a way for two systems (and two parts of the codebase) to talk to one another. Typically one side (the client) will send messages in a format defined by the other (the server).
"MVC Frameworks"
Model-View-Controller framework, examples: Rails, Laravel, Django, Express. Software libraries which define a structure for code, a number of conveniences for developers and provide consistency between applications (therefore easier [aka cheaper!] to work on)
Model-View-Controller framework, examples: Rails, Laravel, Django, Express. Software libraries which define a structure for code, a number of conveniences for developers and provide consistency between applications (therefore easier [aka cheaper!] to work on)
"Serverless"
A way of hosting your application on the web that doesn't require the maintenance of full servers (computers connected to the internet, either real or virtual), disks, operating systems etc - instead you just load code directly and set when it should run.
A way of hosting your application on the web that doesn't require the maintenance of full servers (computers connected to the internet, either real or virtual), disks, operating systems etc - instead you just load code directly and set when it should run.
"Node JS"
A way of running JavaScript (language used on web pages to create interactive elements, such as carousels) to do "backend" non-visual operations such as saving to a database or sending an email.
A way of running JavaScript (language used on web pages to create interactive elements, such as carousels) to do "backend" non-visual operations such as saving to a database or sending an email.
"Responsive Design"
The standard way of building websites so the exact same code is used on mobile and desktop, but rendered differently with parts of the page repositioned, and sizes change. This is in contrast to having the "mobile version of the site", which is now rare.
The standard way of building websites so the exact same code is used on mobile and desktop, but rendered differently with parts of the page repositioned, and sizes change. This is in contrast to having the "mobile version of the site", which is now rare.
If an engineer can explain these concepts to you as if you were a layperson, then you can expect that they'll be able to do the same when it comes to talking about the product you're building together.
