How to interview a technical co-founder | Hacker News Reader

How to interview a technical co-founder

chrisloy.net

99 pointschrisloy50 comments

I've got a problem with mixing 'co-founder' and 'hiring' terms: to me they look mutually exclusive. If you're searching for someone for 'co-founding' your startup, then you're asking for a partner. If you're trying to 'hire' someone, then you're asking for an employee. Partners are not to be interviewed, at least not with a 'coding test'.

Think of the reversed situation: you're a 'business guy' (whatever that means), and a 'technical co-founder' is asking you to join the founding team on the business side, but first he's asking you to prove your business skills by tossing an Excel sheets and saying 'please find the formula errors'? What will you think of him?

> first he's asking you to prove your business skills by tossing an Excel sheets and saying 'please find the formula errors'? What will you think of him?

This Excel test will not prove much. However, asking "what do you think is the problem with that particular company" or "what do you think the issue with the company whose P&L sheet you are looking at" may not be a bad idea.

Most importantly, they have to be extensively interviewed about the strategy. That is unless they have a proven record, in which case it might be a dangerous exercise.

However, a dirty little secret: finding a non-technical co-founder is magnitude easier. That is, unless we are talking a rock-star level, which is a totally different story.

So how do you find a business partner? It sounds like you’re suggesting that you need to already have been personally close to and trusting of your partner for a long time, or perhaps find a partner based on recommendations from very close and trusted friends or colleagues. That’s probably how it happens most of the time. Is that the only viable way to choose a partner?

Go with recommendations, seek them out personally, or just take the person most willing to partner with you and use your gut feeling in how they interact with you.

There is no “easy mode” in finding a partner. You will have to take some risk here as well.

> use your gut feeling in how they interact with you.

The problem here is that intuition (gut feeling) is best trained in environments where you have:

1) The opportunity for lots of repeated trials.

2) Rapid feedback which results from the data you currently observe rather than from

So if you're predicting tomorrow's weather, intuition is useful: your prediction can't change the weather, you can do this 365 times in a year, and you'll get feedback the next day.

Picking a founder (or heck, uni project partner) is unlike this in that you don't have many opportunities to do it and the feedback only comes months later. So, its better to think through a more deliberative and explicit thought process.

That deliberative process might involve a difficult, awkward conversation like "Hey, so if we jump into this, we are going to have to really trust each other for a lot of things. I think its best if we explicitly come up with ways to prove to ourselves and each other that we have the skills to tackle the known challenges we're going to have to face."

I don't know where "easy mode" comes into it at all.

> The problem here is that intuition (gut feeling) is best trained...

You have had an entire lifetime of trial and feedback in understanding the character, talents, and ambitions of other people. If you don't have that, or if you can't trust it, you probably should not be a founder yet. Wait until you actually have those skills because they're critical for everything else in running a business.

You partner with someone whom you 1) respect and 2) have worked with well in the past. I really don't understand how anyone could possibly partner with a stranger no matter how stellar their resume or how skilled they are.

You can have a 3rd person who knows both of you well to make an intro.

I've now helped two successful companies get off the ground. In both cases, it wasn't Excel skills that made it happen. It wasn't my code either, although that helped. It was B2B sales. And I don't mean that just in terms of bringing in the money; the people doing the selling also learned what we needed to build to do that selling.

So although I would never administer a test saying "please find the formula errors" to a potential cofounder, I do have a basic pass or fail test: "Can you lead product through sales?" If you can, I can build it and we'll get rich. If not, I'm not sure what value you can bring. I can build projects on spec all by myself.

I agree. Co-founders are by definition not hired. They should not have to "prove themselves" over the span of a week. Rather, you should already have the proof and conviction based on months to years of prior experience that they are the right person with the right skills.

Moreover, please do not be the silly business person who walks up to some engineer and be like: "I have this great idea, it's going to be great! Can you build it for me? Oh and by the way, because I guess it looks like you're going to be the technical one, I guess I'll have to be the CEO, and I'll take 80% of the equity [despite you doing all the work]." I've had enough of those stupid conversations before.

Good technical co-founders build what they want to build. Not what you want to build. Thus, you need to align as people, and build what you collectively want to build together. Technical co-founders work for themselves, not for you.

A Harsh truth but quite enlightening. Thanks.

Regarding the non technical cofounder, he or she should ideally have a track record in either acquiring consumer users with the acquisition channel he/she intends to use, or has successfully sold to enterprises in that vertical and size.

Without that track record, you're in for a crap shoot imo.

I agree with all of this (caveat, downplay the "interviewing" angle a bit), and let me add some more things I found helpful in my recent cofounder search:

- the most important thing for an early stage startup is that they can validate. That means building incomplete and imperfect prototypes quickly and repeatedly. "Getting the architecture right", "clean code", etc, are usually the wrong skills for a super-early-stage startup, and your CTO shouldn't prioritize them.

- more important is that you get on well with the cofounder. You're going to be working together for a long time. Make sure your personalities mesh, that you can spend a large amount of time together, and that you can discuss/argue constructively.

- Having the same values and goals for the company are paramount. When finding a cofounder recently, I wrote a questionnaire with 40 open-ended "values" questions for cofounders to answer (and then I sent them my answers). It was very apparent when I met someone with values overlap and when I didn't.

Ended up with a great cofounder, have been working together for 6 months now: http://ellenandpaulsnewstartup.com

As an experienced developer, who spent the summer exploring options after my last company was sold, I had many approaches from non-technical founders. Most of them completely skipped vetting me, and just were hungry for someone who could code. One I worked with part-time for a few months, with the explicit agreement that it was a test run on small projects to decide if we wanted to move forward together. The last one did interview me, and ended up being my #1 choice to work with because, aside from agreement on the product and how we'd build it, she was clearly thinking about the bigger picture, not just trying to find a coder. (Although the market drove me to take a different full-time job instead, anyway.)

All that to say, another criteria is that if your potential co-founder is too easy to convince to join you, that is a red flag - a good potential founder will have many options on the table. If you are their only option, there is a reason for it, and you should walk away.

> If you are their only option, there is a reason for it, and you should walk away.

Depending on your other options, it still might be interesting. Just know you are walking into a potential trainwreck.

> Most of them completely skipped vetting me, and just were hungry for someone who could code.

How did these people find you?

I am ready to quit my stable job and do something fun for a while. Where do you I find people in the same boat.

Networking. All of my consulting contracts came from people I already knew, who either hired me directly or introduced me to someone who needed help. And those contacts and clients then introduced me to other people who were looking to found something new. FYI, I found zero value in meetups or other networking events, because the people who are working hard on good ideas are too busy (in general) to attend such things.

What was the source of your network, if I may ask? Old college friends? Church? Co-workers?

One contract came from a partner of a business I used to code for. The rest were just asking around town, in particular with people who worked in marketing - they knew who needed help growing their business, and would pair me up with business owners who had specific tech problems to solve.

Same story here. Quit my job a few weeks ago, and now looking for some fun stuff to do. If I don't find something by myself soon, probably will have to resort to spamming/broadcasting in LinkedIn like the next commenter advised :)

I guess this is a terminology question: If you already have founded a company, how can you be looking for a co-founder? Isn't it already founded?

As a technical person and potential co-founder, I would be very wary of the "Company with non-technical founders looking to get their product built" scenario. First, it looks like they're looking for an employee, not a founder (see above) and second, I would want to vet that product idea front-to-back in terms of technical feasibility and schedule.

The "founder" title carries prestiege, which can fool some folks into thinking they are really founders. The important part, if you really want to be a cofounder in more than title, is to make sure you have equal share and control with all other cofounders. Otherwise you are indeed just an employee (which can be fine as well if you are satisfied with it).

Doesn't have to be equal. Had to be substantial (depends on stage of joining and how much derisking has been done)

To me that's an employee with substantial power, but mostly it's a semantic disctinction which goes to my original point. It does get a little fuzzy when you have enough share to "not get fired".

The opinion of your trusted friend or acquaintance is often just as illusory as your ability to judge for yourself. After all, you aren't subjecting your buddy to the same rigor you would a candidate, and you are just as incapable of judging their actual ability as the candidate's. You may trust your friend to give you good feedback, but if your friend is inexperienced or in a completely different technical domain (therefore lacking context), their opinion can even be counterproductive.

And how are you selecting your friend? How many tech people do you really know? Surely not that many if you're non-technical and interviewing for the position instead of partnering with one of them.

Time and again I see founders choose poor technical cofounders. Often it's enough to get the business off the ground, but then as the company grows they fail to grow with it. Now they're a CTO without the ability to handle strategy or manage people.

The sub-optimal recourse in these cases is often to hire a VPE to manage people while the CTO acts like the principal engineer. Now the VP reports to a CTO who is incapable of doing that job and (privately) insecure about it.

Basically I'm saying a non-technical founder selecting a technical cofounder is a crapshoot and people don't answer enough uncomfortable questions up front. Management skills (or at least aptitude) should be part of the selection criteria. There should be a discussion up front about how the position will evolve over time, and what the success criteria are at each stage, and what happens if those aren't met (mentoring, career counseling, step into new role with reduced title)? And the same conversation should happen in reverse, from the CTO to the CEO.

My advice: Ignore all points except the last one. I've seen a lot of startups trying to hire a technical co-founder on their own, even following advice similar to point 1-5, but still ending up with a co-founder that was a bad technical fit ~80% of the time. With the involvement of a technical person in the interview process, usually either referring the candidate or having an additional technical interview with them, that figure drops down to ~20%.

Honestly, even that's a crapshoot. In fact this article presumes that it should be an interview, when it should really be a conversation.

If a non-technical founder wanted to "interview" me, I'd tell them to shove it. If they wanted to have a conversation about how we could bring our complementary skills together to solve a problem, then I'd certainly be much more interested.

I mostly agree. A co-founder interview should be more of a conversation rather than a traditional "company vs. employee" interview. Nevertheless, if it is already a running project, there is an imbalance of trust and skin in the game, similar to a job interview. So going through a technical screening can be a very easy way for the candidate to close that trust gap.

Also, the popular perception between technical co-founder and early employee-CTO is very blurry (unless you go by virtual vs. real shares). Some people will call a CTO that joined 3 months into the project and holds 10% virtual shares a co-founder and some people won't. Same goes for "technical co-founder" vs. "early CTO" interviews.

I'm assuming this is a technical co-founder in the stricter sense, rather than an early-employee CTO. If the case were the latter, I'd most likely be inheriting a dumpster fire built by an agency or a jilted technical co-founder, neither of which is a good position to be in.

If that's the case, then the onus is on the founder as much as me to prove their worthiness. I've inherited too many dumpster fires in my career to implicitly trust the word of non-technical co-founders.

If you're joining 3 months into what's often a 7+-year mission (where if you're successful you'll be underpaid for a long-time and make your money on stock) and you expect a 90-10 distribution of shares you better be getting something like a salary (co-founder in name only). These kind of distributions are part of why yCombinator discourages unequal co-founder distributions. You're asking for the company to implode over co-founder issues if you think your 3 months at the start is worth a 90-10 distribution in shares especially when as a non-technical founder hiring a technical co-founder the technical co-founder generally has bigger opportunity costs financially.

As a technical person, if I wanted to hire a technical co-founder, I'd probably:

- get started on my own without them

- if I was lucky enough to find someone I actually wanted to partner with, I'd make sure we'd be able & willing to own code both of us had written

- not get too attached to my pre-founder code (probably a good idea in general)

- offer them a nominal hourly rate for a week or two just to validate skills & compatibility while they decide for themselves if they really wanna do a startup with me

- when they fully committed, offer them the same comp package I offered myself, including number of shares

- hope it all works out!

You said yourself that you're a "technical person", so probably not the target audience of this article.

Looking for anyone who is an expert in a domain your not familiar with is difficult. Especially a co-founder, as your success together will depend maybe more on dedication & your relationship VS technical ability.

At a minimum, look for someone who:

- Has the ability to explain something complex from their area in terms you understand.

- Is not afraid to question or disagree with you, but does so in a way that doesn't make you feel bad.

- Is looking for a challenge and is genuinely interested in what your doing

- Displays a history of non-conformity, thick-headedness in some way.

- Really thinks/codes in terms of minimal viable product

- Who you get along well with!

Wow, I thought this one had just disappeared into the void. Glad to see I got people's attention and provoked debate, even if it seems much of it disagrees with my underlying assumptions.

For what it's worth, one thing I don't cover in the article is whether this is a good idea in the first place. It obviously isn't ideal, and as I say it is a difficult situation to be in. From my perspective, I think a non-technical founder is obviously better looking for a trusted former colleague or friend to join as CTO. Proven mutual history is the best thing you can lean on here.

But if this isn't possible, I would definitely espouse an interview process - however formal you prefer that to be. My post is therefore really intended as a how-to guide for someone in this awkward spot, looking to identify the skills and experience for technical leadership without the background to do so.

Of course other soft skills and fit are just as important. But any decent founder will need to identify those in all people joining the founding team. This is just intended as a step-by-step guide for those specific skills needed for a technical co-founder or CTO. I hope it is helpful for someone!

If you are going to build a company, not a team of 2, the core skill of CTO is to ability to hire talented technical people to the correct positions. This is hard. Most people can't do this well.

Most of the early stage teams are better off to avoid using C-titles and talk this through from the get-go. The founders and first employees might be great builders, but not necessarily great CTOs when you start to grow the team.

That probably goes for the non-technical founder as well right? I.e. bring in someone more experienced to grow the business once the founders proves the market exists.

I think the reliance on open source work is too heavy. Plenty of amazing engineers have done work at organizations serving millions of customers but have not made contributions to open source. A portfolio is mentioned but is at the bottom of the list of importance, and even noted as such. The author mentions company blogs. At decent sized organizations these could be written by the marketing departments, little regard to the engineers.

Open source contributions shouldn't be a deciding factor as I've seen a few very active open source devs unable to do the commercial work on the proper level. On the other hand, lack of open source meaningful activity is a red flag.

Author here - completely agree with you. I think the presence of these things can be a nice shortcut to establishing expertise, but lack of them does not imply lack of expertise. These are just suggestions of things to look for, and it certainly isn't my intention that people be ruled out because of an empty GitHub profile. I hope that isn't what it sounds like.

Skipping over what others have pointed out - you don't interview a co-founder.

a) ensure this is someone you are going to get along with b) get someone else to assess their technical competence - you can't assess it and the guidelines you provide won't work reliably.

I would suggest people double down on point 6, "Find someone to help". If you don't have anybody in your network, pay somebody.

Why? Well, there are two abilities that are only partly correlated: coding and talking about coding. A non-technical founder can only ever evaluate the talking part. My approach to interviewing involves both chatting and pair programming. A surprising number of people are pretty good talkers and pretty terrible doers. Indeed, some of the best talkers are the worst doers, because they've had to become extremely good at talking to keep getting hired.

(As an aside, some of the best coders are pretty bad talkers, but those are not the people you want for a tech cofounder.)

So please, non-tech founders, borrow or hire an expert. There are plenty of people who sell their time by the hour, including former tech leads and tech founders. Like accounting or lawyering, interviewing programmers is a skill not easily acquired. When you need it, it's worth paying for.

nice article, though:

> A non-technical founder interviewing a technical one is akin to a brain surgeon hiring a rocket scientist. Forgive the self-aggrandisement!

It's not self-aggrandisement but lacks acknowledgement that it's equally complex the other way around. As engineers we tend to think no aspect is more important than the product we build. Yet without the right person to understand financial growth (and the patience to carry us along despite our lack of understanding), it's going to be rough! (not just finance, but sales, marketing, even legal depending on the field).

That was my intended point (I'm a CTO at a startup).

I consider myself a decent rocket scientist (CTO) but would make a terrible brain surgeon (CEO) ;-)

It'd be interesting to find some successful CTOs (e.g. people who built up a company from the ground up to a successful exit) and ask them how they'd want to be interviewed for their job.

This is great advice. Any decent CTO will immediately be put off by this kind of interview for a “co-founder” and be spared working with someone who doesn’t know his circle of competence.

didn't realise you could hire a 'co-founder' suspect it means subordinate who is paid in share options

How things really work: Non-technical founder tells potential technical co-founder his great idea. Technical "co-founder" goes and creates Facebook/SnapChat on their own ;)

For finding a technical co-founder, I think this is more like it:

Imagine you are looking for someone to marry and to cook for you. You will have to get along with them for years. You will need to share intimate secrets with them. The main thing that is really different is that you will not be having sex with them (although from what I hear that is not actually very different from most marriages).

The other thing is that instead of cooking food, they are doing engineering research. Pretty much all software projects are complex research projects. Now, imagine if the woman you married were a bad cook. You could always go out for takeout after dinner lots of the time. But say your entire business was built on making sure that her eggplant soufflé or whatever was 100% on point. If it doesn't taste good, it just crashes and you can't make money. But this is not eggplant soufflé its a completely new dish you need her to invent as a master chef. Only its more complicated than that. It has a thousand moving parts. Its sort of like they are inventing a new type of space ship for you.

So anyway, I would try to do smaller test projects or subprojects with people first and be very careful making a selection of a partner. Ideally it would take several months or a few years, checking out multiple people.

Also be aware that about 50% of all marriages end in divorce.

The implied power structure here is so typical.

Way too many startup “CEOs” want to sit on their ass watching TV and drinking beer (eg going to conferences and drinking beer) while their partner builds the product based on their incoherent and ever changing whims.

Finding a spouse or long-term romantic partner certainly seems like an apt analogy, but I wonder if the analogy really holds for any specifics beyond the empirical observation that a significant percentage of both marriages and businesses “fail.” I put that in quotation marks, because I’m not convinced that the “success” criteria for either are well-defined. The standard view for marriages seems to be that any marriage that ends before one partner dies was a failure, but I don’t see why a separation or divorce necessarily implies that there wasn’t a net benefit for both partners. Likewise, if a business eventually ceases to exist, I don’t think that necessarily implies that the founders didn’t benefit on net (even if there was no obvious benefit, like a payout). I claim this even though I realize that both “failures” must usually cause considerable pain and/or hardship for all participants for some amount of time.

Reply on news.ycombinator.com