A larger applicant pool created a different problem

In a LinkedIn reflection about our hiring at Throughout, I shared that we had received more than 350 applications. I had expected more candidates to make the process easier. Instead, the volume made the limits of a CV and an interview more obvious.

That figure describes the hiring period in the original post. It is not a current vacancy count or a claim about the size of our team. The useful lesson was what the process revealed about evaluating someone for a startup environment.

Technical ability needs working context

We saw candidates with strong backgrounds and convincing interviews. Day-to-day work exposed questions that those signals did not fully answer: could they take ownership, communicate when stuck, learn something unfamiliar, and adapt when requirements changed?

I do not see these qualities as a replacement for technical competence. They explain how technical competence becomes useful inside a team. A developer who can describe a tradeoff and ask for missing context helps others make progress too.

Make ownership and communication observable

Rather than treating “ownership” as a personality label, I would look for specific working behaviour. Does the person explain what they know, identify what they still need, and make the next step clear? Can they discuss a difficult decision without hiding the uncertainty?

A bounded technical discussion can explore those behaviours alongside code. Ask how the candidate would clarify a requirement, communicate a blocker, or change an approach after feedback. Use consistent expectations rather than rewarding confidence or presentation alone.

Automate coordination without outsourcing judgement

Processing the applications manually was becoming difficult, so we built a recruitment workflow. Applications entered our CRM, AI helped analyse and rank CVs, assessments were assigned, and scheduling and candidate communication were automated.

We deliberately kept the final judgement with people. A ranking can organise information, but it cannot decide who we want to build a company with. I treat AI output as something to examine, not as a substitute for understanding a candidate’s work and context.

Hire for the environment you are actually building

A startup role often includes incomplete information and shifting responsibilities. That does not excuse unclear expectations from the company. Explain the working environment and give candidates a fair opportunity to show how they reason within it.

My biggest lesson from that period was to look beyond what someone already knows. How they learn, communicate, respond to feedback, and take responsibility determines how their skills develop with the team. Hiring is only the beginning; onboarding and leadership must support those behaviours afterward.

What to take away

  • Treat application volume as context, not proof of hiring quality.
  • Evaluate technical reasoning and collaborative behaviour together.
  • Keep hiring decisions accountable to people.