Hiring is a difficult task that I'm currently in the middle of attempting, so Harj's article is something I recognize. I'm not after a first dev, but I am part of a team that is after a dozen or so devs and I've now been day 1 on three different ventures.
The problem is that the main piece of advice is correct but unuseful. Indeed, you should look at people you've worked with. In some sense they've all interviewed with you already, so you know what it's like to work with them, you know how good they are at communicating, and you know their limitations.
Unfortunately, most people haven't worked with enough people to have more than one or two likely candidates for whatever they're thinking of doing. Your homies are either not right for the role, unwilling to move from a position of comfort, or not willing to put your friendship on the line.
The same is also the reason why your company cannot grow via connections of employees past some point, the r < 1 on that series and it will converge on some low number.
Where my problem is a bit different to the article is that before you have any devs, you have a really big problem identifying good devs. Heck even hiring for devs outside your specialty is hard. If you can't do X, how are you going to find a good X? You will end up falling back on recommendations and reputation, and you'll pay up for a branded individual if one is around. Not in itself terrible, but every penny counts early in a startup.
I was talking to a shop who were after their first programmer a few months back, and they did the sensible sounding thing of bringing in a trusted friend from a FAANG to interview people. Main issue with that is that person is thinking about how a megacorp hires people. Mainly avoid guys who can't reverse a linked list, and stick the new guys into a process that already exists. But it's not quite the same things you care about as a day 1 startup.
Day 1 guys need energy. Sad to say it, but this probably tilts against people who have kids. In my first day 1 jobs, I didn't have kids, I could wake up at 6 and code to 11 at night. Or you do like my current firm, where I was also day 1, but let people work from home. Then you suddenly have a very big carrot for experienced hires. The guys in the previous paragraph did the same.
Day 1 guys also need a high degree of autonomy. When you've got nothing, as in not even a chat about what stack you're using, day 1 guy needs to put down those foundations. This is a lot harder than you think. Not only do you need to consider budget, you need to think about what a small team can do, you need to think about what imaginary future employees will want to work with, and you need a way to get from little team to big team where your hands aren't tied by your day 1 decisions. And you gotta balance current technical debt against future payments on that account.
You also need to be broadly read. You can be highly specialized, but you need to have some idea of what's going on in the software world in general. Chances are you will end up picking the most standard choice of everything that isn't your specialty, like Django for a web framework or SciKit for a bit of ML. But you need to have an idea about a huge variety of things to know what the landscape roughly looks like.
So how do you find a person like that? Well actually none of the methods other than "network" will actually check for these qualities. Most people are specialists with a label that enables them to move to other jobs with similar titles (Low Latency c++ dev), and recruiters are on the lookout for the label. Inbound and Outreach are also not going to tell you how broad someone is, because everyone writes stuff on their CV to look specialised, with a bit of breadth to catch a few interviews. Meetups, maybe, depends on how good you are at directing the conversation. A skill in itself.
The problem is that the main piece of advice is correct but unuseful. Indeed, you should look at people you've worked with. In some sense they've all interviewed with you already, so you know what it's like to work with them, you know how good they are at communicating, and you know their limitations.
Unfortunately, most people haven't worked with enough people to have more than one or two likely candidates for whatever they're thinking of doing. Your homies are either not right for the role, unwilling to move from a position of comfort, or not willing to put your friendship on the line.
The same is also the reason why your company cannot grow via connections of employees past some point, the r < 1 on that series and it will converge on some low number.
Where my problem is a bit different to the article is that before you have any devs, you have a really big problem identifying good devs. Heck even hiring for devs outside your specialty is hard. If you can't do X, how are you going to find a good X? You will end up falling back on recommendations and reputation, and you'll pay up for a branded individual if one is around. Not in itself terrible, but every penny counts early in a startup.
I was talking to a shop who were after their first programmer a few months back, and they did the sensible sounding thing of bringing in a trusted friend from a FAANG to interview people. Main issue with that is that person is thinking about how a megacorp hires people. Mainly avoid guys who can't reverse a linked list, and stick the new guys into a process that already exists. But it's not quite the same things you care about as a day 1 startup.
Day 1 guys need energy. Sad to say it, but this probably tilts against people who have kids. In my first day 1 jobs, I didn't have kids, I could wake up at 6 and code to 11 at night. Or you do like my current firm, where I was also day 1, but let people work from home. Then you suddenly have a very big carrot for experienced hires. The guys in the previous paragraph did the same.
Day 1 guys also need a high degree of autonomy. When you've got nothing, as in not even a chat about what stack you're using, day 1 guy needs to put down those foundations. This is a lot harder than you think. Not only do you need to consider budget, you need to think about what a small team can do, you need to think about what imaginary future employees will want to work with, and you need a way to get from little team to big team where your hands aren't tied by your day 1 decisions. And you gotta balance current technical debt against future payments on that account.
You also need to be broadly read. You can be highly specialized, but you need to have some idea of what's going on in the software world in general. Chances are you will end up picking the most standard choice of everything that isn't your specialty, like Django for a web framework or SciKit for a bit of ML. But you need to have an idea about a huge variety of things to know what the landscape roughly looks like.
So how do you find a person like that? Well actually none of the methods other than "network" will actually check for these qualities. Most people are specialists with a label that enables them to move to other jobs with similar titles (Low Latency c++ dev), and recruiters are on the lookout for the label. Inbound and Outreach are also not going to tell you how broad someone is, because everyone writes stuff on their CV to look specialised, with a bit of breadth to catch a few interviews. Meetups, maybe, depends on how good you are at directing the conversation. A skill in itself.