First you probably need some silent, persistent and occasionally cantankerous folks that can grudgingly work on annoying boring problems all night just because they want to solve it no matter what. If you have a few of those, you really have to start looking for more social people that can glue the herd of cats together so all noses point the same way.
My experience has been that solving a very technical problem and solving a social one are very different skill sets and very few people have both skills and are capable of using both of those skills at the same time.
> First you probably need some silent, persistent and occasionally cantankerous folks that can grudgingly work on annoying boring problems all night just because
So you want people who are willing to be overworked and underpaid with the statistically worthless equity?
What next? You also want people who after they do a 996 work schedule to also have enough “passion” to work on open source projects during their free time?
I'm at the stage right before this question even applies — solo founder, no hires yet. But reading this thread is making me think about it differently.
The thing I'd add from my perspective: before you hire your first person, you need to know what's actually bottlenecking you. For me right now it's distribution, not engineering. I can build features all day, but I can't clone myself to do outreach, write content, talk to users, AND keep shipping at the same time.
So if I were making my first hire, it wouldn't be another developer. It would be someone who can talk to customers and translate their pain into product decisions — basically a generalist who understands both the human side and the technical side. The person wvh described as "social people that can glue the herd of cats together."
The hard part is that in the early days you can't afford specialists. You need people who are comfortable doing three different jobs badly before doing one job well.
There is a difference between somebody who has used an algorithm/component/framework/library, and somebody who knows how to solve a problem using an algorithm/component/framework/library.
In the beginning, you need the person who knows how to solve the problem. They are harder to find.
If you are pressured to grow quickly, you might be tempted to lower the bar. You can, as long as you understand that the person who knows how to solve the problem is still critically important, because they will be telling people which algo to use.
I think every company that uses tech needs at least one of these people to start with.
Low ego about their ideas and what they build. I.e they can be wrong, thrash their own code without any issues, and work on other people idea.
But if they can't strongly advocate for an idea or against an idea they don't like and just give up, you don't get their full 'utility'. Which, tbh, is not a big issue with juniors with not a lot of experience, but still.
'low ego', but not too low. You want passionate debates.
This will be down voted to death but I look for ability to communicate and autism.
In the general population about 20% of people shows some traits that qualify as autistic with about 10% showing those traits enough that could qualify for a ASD diagnosis. Among software developers those numbers are roughly double. People with autism are prone to high anxiety with deliberate habits of trying to hide it, masking behaviors. You don’t want Dunning-Kruger type behaviors as the common establishment of your organization. Instead you want people who aren’t afraid to risk doing original things and will bluntly tell you about product risks as opposed to putting their personal preferences first.
Ability to communicate determines how a person organizes their thoughts on the fly. It also exposes their potential for working closely with others. Strong teams come from people that support each other as opposed to people who lack empathy or demonstrate low social intelligence. Strong skills alone can tank a team if communication is garbage.
People who make (mostly good) decisions and ship stuff as quickly as possible. Ideally while being nice people to work with.
Your first hires need to be people who make the company faster, not slower. A single bad hire can sink the ship. Someone who is great in a large corporation can ruin an early start-up.
Personally, I'm hoping for low-ego high achievers. But that's up to you. This is where you get to define what the company culture will be.
In such a small team you will have to wear a lot of hats. You will be constantly making important decisions and setting your own priorities with very little guidance. You will have to dig into areas you're not prepared for because there's no one more specialized to do it. Independence (with practicality! not idealism) is very important.
Specifically what i used to check, whether candidate also motivated with mission that I have. If its not motivate them then there is a cultural fit problem and might not good fit for early days.
Unless you are saving starving children in Africa, no one cares about your mission. Any interviewee with any type of social skills knows how to pretend and feed you the BS like they are excited about the mission.
You are the founder but even for you once you take outside funding, your “passion” is irrelevant, your investors only care about the “exit” and if you do get acquired, two weeks later you will more than likely have a blog post on your website about “Our Amazing Journey” announcing the sunsetting of your product.
It is naive for anyone to go into any company and treat it as any more than a trade for money for labor.
"Get shit done" is by far the most important attribute of your first few employees. You need people who can work independently without a lot of direction, and focus on the right things while the rest of the world burns around them.
They don't need fancy credentials or to be super smart or have a great internet presence; what you should look for is a track-record of shipping, and evidence of independent work; and when you interview them, find out if they have good judgement, if they have a sense of when to trade off perfect for good enough, if they're able to diagnose and fix things when they're broken.
As you grow, you can add more traditional engineers to build a more conventional, well-rounded team. But most companies don't get to 20 employees if their first 5-10 aren't able to work quickly & make good decisions without getting side-tracked on all the myriad little distractions of designing the perfect framework for the framework, office politics, dev environment isn't quite right, etc, etc.
Worth noting that the 'just ship it' advice works differently depending on market type. B2B with long sales cycles needs different validation than consumer apps. The data from failed B2B launches is usually insufficient for product decisions.
Curiosity, intelligence, empathy and relentlessness. If you have all 4 you are unstoppable for making great products and help the team and business scale.
I think this is where you’ll define the company culture. Maybe in the first 10, but certainly in the first 100. If you want to design the corporate culture, this is where it starts.
Something that is not in the 1M+ people studying for interviews and throwing pieces of paper (CVs, cover letters, degrees) at the job application:
A verifiable track record beyond the CV, that is extremely hard to fake with valuable experience that you did not know you needed.
As I said before at least 2 of the following:
1. Open source contributions to high-profile / major repositories (with code-review in the open with core maintainers). No hello world / demo projects.
2. Production-grade shipped projects / side-projects with paying customers or high-profile companies using it and is bringing in recurring revenue.
3. Given several presentations at conferences discussing anything from your project as a library author, maintainer or at a company showcasing your engineering expertise.
All are extremely difficult to fake and easy to verify and requires a level of effort on the applicant to qualify which filters 90% of noise out there. Years of experience is not a requirement but a bonus.
The rest of the other methods like leetcode, hackerrank, take home projects or quiz trivia, wastes time on both the interviewer and the candidate and both can be cheated easily using AI.
> Given several presentations at conferences discussing anything from your project as a library author, maintainer or at a company showcasing your engineering expertise.
What sort of positive signal is this supposed to be? Why would presenting point towards a productive employee?
In my experience, this correlates more with soft skills and “one man band” founder/maker companies that tend to sell training products or (if they do exist in a company environment at all) invariably work in DevRel and aren’t pushing code.
The whole point is to reinforce the track record of someone applying to said founding engineering role which you can look up what they have presented and see how well they answer questions from the audience which are soft skills applicable in founding engineer / CTO / senior roles which goes beyond AI-generated CVs or cover letters.
This can be found all the time, from many tech talks or conferences large or small and 99% of the time, the person presenting already covers most of the requirements and makes the selection process easier, not harder.
One part I did miss in my post was to require at least 2 out of 3 of them so, I added that in. But I'd rather optimize for hiring candidates who are builders and know what they are talking and what to build even with AI and can easily answer deep technical questions (because they have experience and have done it), than those studying for the interview and need constant hand-holding and are over-reliant on AI.
Remember, this is for recruiting founding engineers and the bar has to be high way above the noise.
This is funny, because these exact same things were great filters to eliminate BS candidates. It's always the ones who talk a big game who tend to be the worst when the tire meets the road.
Some of the absolute best candidates were always the ones with a github that hadn't seen a commit in half a decade, nary a presentation or conference mentioned in their cv. This was true at two different FAANGs and a couple of other FAANG-adjacent companies.
Basically no one who has a life outside of work, or a household to upkeep or a family to take care of.
Your criteria heavily biases towards very performative and obvious signs of hard work in a commercial setting, completely oblivious to hard work and character outside of it.
> Your criteria heavily biases towards very performative and obvious signs of hard work in a commercial setting, completely oblivious to hard work and character outside of it.
Hiring people based on knowing what should be built, how to build and especially knowing how to make the business money is not performative. I'd rather optimizing the hiring process for builders instead of rest-and-vest day-care slackers or leetcode grinders just for passing the interview.
There is nothing more performative than anyone doing these puzzles and answering quiz trivia, which doesn't make you or anyone money and it is only a waste of everyone's time.
First you probably need some silent, persistent and occasionally cantankerous folks that can grudgingly work on annoying boring problems all night just because they want to solve it no matter what. If you have a few of those, you really have to start looking for more social people that can glue the herd of cats together so all noses point the same way.
My experience has been that solving a very technical problem and solving a social one are very different skill sets and very few people have both skills and are capable of using both of those skills at the same time.
> First you probably need some silent, persistent and occasionally cantankerous folks that can grudgingly work on annoying boring problems all night just because
So you want people who are willing to be overworked and underpaid with the statistically worthless equity?
What next? You also want people who after they do a 996 work schedule to also have enough “passion” to work on open source projects during their free time?
I find this attitude and expectation disgusting.
Also unrealistic.
I'm at the stage right before this question even applies — solo founder, no hires yet. But reading this thread is making me think about it differently.
The thing I'd add from my perspective: before you hire your first person, you need to know what's actually bottlenecking you. For me right now it's distribution, not engineering. I can build features all day, but I can't clone myself to do outreach, write content, talk to users, AND keep shipping at the same time.
So if I were making my first hire, it wouldn't be another developer. It would be someone who can talk to customers and translate their pain into product decisions — basically a generalist who understands both the human side and the technical side. The person wvh described as "social people that can glue the herd of cats together."
The hard part is that in the early days you can't afford specialists. You need people who are comfortable doing three different jobs badly before doing one job well.
There is a difference between somebody who has used an algorithm/component/framework/library, and somebody who knows how to solve a problem using an algorithm/component/framework/library.
In the beginning, you need the person who knows how to solve the problem. They are harder to find.
If you are pressured to grow quickly, you might be tempted to lower the bar. You can, as long as you understand that the person who knows how to solve the problem is still critically important, because they will be telling people which algo to use.
I think every company that uses tech needs at least one of these people to start with.
Low ego, More passion and drive, hustling mindset, Generalists, Good judgement. Simple thing i would do is Ask lot of "Whys"
Why you did this?, why this way? , why you joined this company?
This gives good understanding of both Personality and Hard skills.
Low ego about their ideas and what they build. I.e they can be wrong, thrash their own code without any issues, and work on other people idea.
But if they can't strongly advocate for an idea or against an idea they don't like and just give up, you don't get their full 'utility'. Which, tbh, is not a big issue with juniors with not a lot of experience, but still.
'low ego', but not too low. You want passionate debates.
This will be down voted to death but I look for ability to communicate and autism.
In the general population about 20% of people shows some traits that qualify as autistic with about 10% showing those traits enough that could qualify for a ASD diagnosis. Among software developers those numbers are roughly double. People with autism are prone to high anxiety with deliberate habits of trying to hide it, masking behaviors. You don’t want Dunning-Kruger type behaviors as the common establishment of your organization. Instead you want people who aren’t afraid to risk doing original things and will bluntly tell you about product risks as opposed to putting their personal preferences first.
Ability to communicate determines how a person organizes their thoughts on the fly. It also exposes their potential for working closely with others. Strong teams come from people that support each other as opposed to people who lack empathy or demonstrate low social intelligence. Strong skills alone can tank a team if communication is garbage.
People who make (mostly good) decisions and ship stuff as quickly as possible. Ideally while being nice people to work with.
Your first hires need to be people who make the company faster, not slower. A single bad hire can sink the ship. Someone who is great in a large corporation can ruin an early start-up.
Personally, I'm hoping for low-ego high achievers. But that's up to you. This is where you get to define what the company culture will be.
In such a small team you will have to wear a lot of hats. You will be constantly making important decisions and setting your own priorities with very little guidance. You will have to dig into areas you're not prepared for because there's no one more specialized to do it. Independence (with practicality! not idealism) is very important.
We only hire 10x programmers at my company
So the first hire must be a 10x programmer
The second one obviously also must be a 10x programmer but keep in mind the bar has now moved so he has to be 10x the previous one (100x)
In short it gets very challenging trying to find the final 10^10x programmer
I'm a 10↑↑10x programmer. Can I have a job?
for early hires I’d say ownership matters a lot, people who can deal with messy situations and figure things out without much structure
Specifically what i used to check, whether candidate also motivated with mission that I have. If its not motivate them then there is a cultural fit problem and might not good fit for early days.
Unless you are saving starving children in Africa, no one cares about your mission. Any interviewee with any type of social skills knows how to pretend and feed you the BS like they are excited about the mission.
You are the founder but even for you once you take outside funding, your “passion” is irrelevant, your investors only care about the “exit” and if you do get acquired, two weeks later you will more than likely have a blog post on your website about “Our Amazing Journey” announcing the sunsetting of your product.
It is naive for anyone to go into any company and treat it as any more than a trade for money for labor.
"Get shit done" is by far the most important attribute of your first few employees. You need people who can work independently without a lot of direction, and focus on the right things while the rest of the world burns around them.
They don't need fancy credentials or to be super smart or have a great internet presence; what you should look for is a track-record of shipping, and evidence of independent work; and when you interview them, find out if they have good judgement, if they have a sense of when to trade off perfect for good enough, if they're able to diagnose and fix things when they're broken.
As you grow, you can add more traditional engineers to build a more conventional, well-rounded team. But most companies don't get to 20 employees if their first 5-10 aren't able to work quickly & make good decisions without getting side-tracked on all the myriad little distractions of designing the perfect framework for the framework, office politics, dev environment isn't quite right, etc, etc.
Care, initiative, long-term thinking, clear communication, collaboration skills, soft skills, candor, technical expertise.
Oh, just go out and buy 10 Mac Minis.
Worth noting that the 'just ship it' advice works differently depending on market type. B2B with long sales cycles needs different validation than consumer apps. The data from failed B2B launches is usually insufficient for product decisions.
Curiosity, intelligence, empathy and relentlessness. If you have all 4 you are unstoppable for making great products and help the team and business scale.
I think this is where you’ll define the company culture. Maybe in the first 10, but certainly in the first 100. If you want to design the corporate culture, this is where it starts.
Their expendability in getting the first few dungeons over with so I can farm enough starter gear to outfit my actual long-term party with.
Something that is not in the 1M+ people studying for interviews and throwing pieces of paper (CVs, cover letters, degrees) at the job application:
A verifiable track record beyond the CV, that is extremely hard to fake with valuable experience that you did not know you needed.
As I said before at least 2 of the following:
1. Open source contributions to high-profile / major repositories (with code-review in the open with core maintainers). No hello world / demo projects.
2. Production-grade shipped projects / side-projects with paying customers or high-profile companies using it and is bringing in recurring revenue.
3. Given several presentations at conferences discussing anything from your project as a library author, maintainer or at a company showcasing your engineering expertise.
All are extremely difficult to fake and easy to verify and requires a level of effort on the applicant to qualify which filters 90% of noise out there. Years of experience is not a requirement but a bonus.
The rest of the other methods like leetcode, hackerrank, take home projects or quiz trivia, wastes time on both the interviewer and the candidate and both can be cheated easily using AI.
It is that simple.
> Given several presentations at conferences discussing anything from your project as a library author, maintainer or at a company showcasing your engineering expertise.
What sort of positive signal is this supposed to be? Why would presenting point towards a productive employee?
I agree.
In my experience, this correlates more with soft skills and “one man band” founder/maker companies that tend to sell training products or (if they do exist in a company environment at all) invariably work in DevRel and aren’t pushing code.
The whole point is to reinforce the track record of someone applying to said founding engineering role which you can look up what they have presented and see how well they answer questions from the audience which are soft skills applicable in founding engineer / CTO / senior roles which goes beyond AI-generated CVs or cover letters.
This can be found all the time, from many tech talks or conferences large or small and 99% of the time, the person presenting already covers most of the requirements and makes the selection process easier, not harder.
One part I did miss in my post was to require at least 2 out of 3 of them so, I added that in. But I'd rather optimize for hiring candidates who are builders and know what they are talking and what to build even with AI and can easily answer deep technical questions (because they have experience and have done it), than those studying for the interview and need constant hand-holding and are over-reliant on AI.
Remember, this is for recruiting founding engineers and the bar has to be high way above the noise.
> Open source contributions to high-profile / major repositories (with code-review in the open with core maintainers). No hello world / demo projects.
And surgeons should also have a track record where they can talk about how they do open heart surgery during their free time at home…
If someone has side-projects with paying customers, why would they be seeking employment ?
This is funny, because these exact same things were great filters to eliminate BS candidates. It's always the ones who talk a big game who tend to be the worst when the tire meets the road.
Some of the absolute best candidates were always the ones with a github that hadn't seen a commit in half a decade, nary a presentation or conference mentioned in their cv. This was true at two different FAANGs and a couple of other FAANG-adjacent companies.
Basically no one who has a life outside of work, or a household to upkeep or a family to take care of.
Your criteria heavily biases towards very performative and obvious signs of hard work in a commercial setting, completely oblivious to hard work and character outside of it.
> Your criteria heavily biases towards very performative and obvious signs of hard work in a commercial setting, completely oblivious to hard work and character outside of it.
Hiring people based on knowing what should be built, how to build and especially knowing how to make the business money is not performative. I'd rather optimizing the hiring process for builders instead of rest-and-vest day-care slackers or leetcode grinders just for passing the interview.
There is nothing more performative than anyone doing these puzzles and answering quiz trivia, which doesn't make you or anyone money and it is only a waste of everyone's time.
You mean you don’t want to hire someone who does 40-45 hours a week and closes their computer and has a life outside of pecking on a keyboard?
Do not exceed token budget.
Teamwork makes the dream work. High energy. Low BMI. Eager to solve problems. Fast learners.
Give me 10 of those and you can kiss anyone goodbye.