I’ve seen this several times with founders who leave established companies, raise an early round, and then need to hire their first engineers. They remember the quality of people they worked with and the interview process those people went through, so they recreate some version of it.
You get a technical screen, system design, behavioural interviews, and several people giving feedback before anyone is comfortable making an offer. I understand the instinct. When the engineering team is small, a bad hire is hard to absorb, but candidates are now evaluating a very different company from the one the founder left.
At the founder’s previous employer, the name probably meant something in the market. Candidates could compare compensation, look up current and former engineers, and get some idea of what joining would do for their career. A long interview process may have been annoying, but the opportunity on the other side was easier to understand.
A pre-seed or seed startup is harder to judge. The product is still changing. The role can change with it. The next round is not guaranteed, and nobody knows what the equity will eventually be worth. The candidate is also trying to work out what it will be like to work with the founders every day.
This matters even more when you are trying to hire experienced engineers who already have good jobs. They can be interested in your startup without being willing to spend several evenings proving themselves to a company they are still trying to understand. Their current job is familiar and pays them every month. Your startup is asking them to exchange some of that certainty for a possibility.
I’ve seen founders spend months in this position and conclude that good engineers are hard to find. Sometimes the hiring process is making an already difficult decision harder.
At GitStart, we used a different approach for some hires. We called it Hack Week. The candidate joined us for a short, paid working period on a scoped piece of work, which gave us information I found difficult to get from interviews. You could see how someone entered a codebase they had never seen before, what questions they asked when requirements were incomplete, and what they did when they got blocked.
The candidate was learning too. They could see the code they might inherit, how engineers reviewed each other’s work, and what happened when people disagreed. At a small company, those details tell you a lot about the environment.
I later experienced something similar from the other side when I joined Circus from Hong Kong. I came in as a contractor for about a month to improve part of the notification infrastructure. The scope was small enough that I could get into the work without first learning the history of the whole product.
By the end of the month, we had worked together long enough to know that we wanted to continue, and the contract eventually became almost four years.
My work expanded far beyond the original notification project. I worked across payroll, payments, timesheets and other systems used by film and television productions in Canada, and over time I took on more engineering leadership. I also moved from Hong Kong to Canada during those years.
I still think about how small that first decision was. Circus did not have to work out whether I would be there four years later, and I did not have to make that decision either. We agreed to work together on a real problem for a limited period, then made the next decision with more information than we had at the start.
A short paid engagement can also help with candidates whose resumes are harder to read. If someone has worked at a company you know well, part of the evaluation has already been done for you. New graduates and engineers from smaller companies do not come with the same shorthand. Working together gives them another way to show how quickly they learn and what they can actually contribute.
I would not make this mandatory. Some people cannot take on outside work because of their employment agreement, family responsibilities, or simply lack of time. The work also has to be paid and clearly bounded. A startup should not run candidates through backlog items and call it evaluation.
Interviews still have a place. There are things about judgment, leadership, and past decisions that are worth discussing directly. I just do not think an early-stage company needs to copy the full hiring machinery of the company its founders left.
I would keep the hiring bar and be more flexible about how an early-stage team gets enough evidence to make the decision. At GitStart, I saw this from the hiring side. At Circus, I came in from Hong Kong expecting to work on notification infrastructure for about a month, and ended up staying for almost four years.