🙋 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 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.
It's a good idea to talk about some specific tech, too. This allows you to see how they make choices.
> I've read a lot about using Node for this project - do you think it would be suitable?
> I've read a lot about using Node for this project - do you think it would be suitable?
A product-focused developer can explain why a given tech is suitable (or not) for a given project - ideally, after asking more questions so they can understand the plan.
As a CTO, I look for low-friction, easy-to-get going tech that that's supported by a large ecosystem.
As a CTO, I look for low-friction, easy-to-get going tech that that's supported by a large ecosystem.
Why is the ecosystem so important?
* Size: a piece of tech that's widely used is also likely to be kept up-to-date and added to frequently. You can benefit from using the same tech as huge companies, taking advantage of their debugging, contributions and ideas.
* Size: a piece of tech that's widely used is also likely to be kept up-to-date and added to frequently. You can benefit from using the same tech as huge companies, taking advantage of their debugging, contributions and ideas.
* Libraries: does this language/tech have open source support for things you'll want to do? If you want to integrate to Stripe, and this language already has an open-source integration library, that's time saved and value created more quickly.
* Support: a bigger ecosystem means a higher likelihood that when a developer googles an error or a problem, there will be an answer ready to go. You don't get this on brand new tech.
* Hiring pool: if you use a popular tech, your hiring pool will be larger.
* Hiring pool: if you use a popular tech, your hiring pool will be larger.
* Quick prototyping: you're getting started, so you need to be quick. Languages and libraries that are suited to getting stuff live quickly, at the expense of speed and scale, are your friend. The ecosystem enables this through support and size.
The topic of tech is especially important if you already have some product built - perhaps a prototype.
Beware the developer who tells you to immediately start again in their preferred tech. That's time you've already spent building a product, being spent again for no new value.
Beware the developer who tells you to immediately start again in their preferred tech. That's time you've already spent building a product, being spent again for no new value.
Rewriting isn't always wrong, but is now really the time to be re-building stuff you already have, rather than crack on and learn more?
Instead, ask them how they'd gradually move away from your existing tech, and what the benefits would be at each stage.
Instead, ask them how they'd gradually move away from your existing tech, and what the benefits would be at each stage.
⏭ Another way to evaluate an engineer is a trial project. Hire them to work with you to build a new feature or fix a bug.
This is an approach favoured by some great companies, most notably @automattic, who make Wordpress.
This is an approach favoured by some great companies, most notably @automattic, who make Wordpress.
Be flexible on timing and scope so that people with dependents and caring responsibilities are not disadvantaged. Some people will be able to do a full week project, others only a couple of hours.
And, pay, in cash, for this work.
And, pay, in cash, for this work.
Do not expect "the passionate" to do it for love (or equity). You're paying for the value of de-risking the hire... plus you're getting a new feature or a bug fix, and they're getting an opportunity to see what working with you is like.
Because you're evaluating how they collaborate and approach a problem, be sure to commit your own time to this project too. You should be available on the same basis you would be if they were hired.
That could be immediately via Zoom/Slack, or if you are planning asynchronous working, then that's how you should run the trial.
The key to successful product building is detail - and you need to understand every bit of it.
The key to successful product building is detail - and you need to understand every bit of it.
Because they'll try not to make assumptions, a great developer will immediately have a lot of questions. Beware the developer who dives straight in and changes things - you should expect to provide them with a lot of context and a shared understanding of the goal of the work.
This process and these questions may cast you for the first time into the role of customer advocate, product manager and project manager. Good! There is no substitute for this work.
Projects get late one day at a time, and products go wrong one detail at a time.
Projects get late one day at a time, and products go wrong one detail at a time.
The good news: this is the same skillset you need if you decide to hire a freelancer or outsourced team to help with your product team. So being in the detail and working with a developer to translate user needs to code is a great skill to learn.
Further reading:
How @basecamp use a take-home test to hire programmers: m.signalvnoise.com/hiring-program…
How @automattic hire developers: automattic.com/work-with-us-o…
And how one of the team found it: nbloomf.blog/posts/2017-05-…
How @basecamp use a take-home test to hire programmers: m.signalvnoise.com/hiring-program…
How @automattic hire developers: automattic.com/work-with-us-o…
And how one of the team found it: nbloomf.blog/posts/2017-05-…
Hope that's helpful :) Want to learn more about managing engineers? Join my mailing list!
samsworldofno.ck.page
samsworldofno.ck.page
• • •
Missing some Tweet in this thread? You can try to
force a refresh
