Six months later the product is slower, nobody can say why, and the junior is quietly job-hunting. You conclude juniors don’t work.

That is the wrong conclusion. I have watched this pattern often enough to say it plainly: the junior almost never fails because of the junior. They fail because nobody senior was attached. The ones that work all have the same thing in common: a named, more experienced person who reads their work and tells them when they are wrong.

The real number

Take an illustrative case. A junior at €32,000 a year costs you around €38,000 once employer costs are added. Exact figures vary by country, but the shape doesn’t.

Leave them alone for six months and you have paid about €19,000. For that you get code that only they understand and that someone will probably rewrite. On top of that you spent your own time: say five hours a week answering questions you can’t really answer, which is about 130 hours of a founder who should be selling.

The payslip says cheap. Everything else says expensive. Unless someone senior is attached.

Here are four checks to run before you hire, or today if you already have.

Check 1: Who reads every change they make?

What to look at: Whether a second person looks at each piece of work before it goes live. Engineers call this code review. It means someone reading the change and saying “this will break when two people sign up at once.”

A bad answer: “They send me a message when it’s done.” You can’t judge the work, so you are approving it by feel.

What to do: Name one experienced engineer who reads everything the junior ships. Not “available if needed.” Reads everything.

Check 2: Who decides what they build first?

What to look at: The first three tasks you plan to hand over.

A bad answer: “Fix whatever is broken and add the new features.” Juniors can’t rank risk. They will spend two weeks polishing a settings page while your customer data sits unprotected.

What to do: Have someone senior write the first month as small, finished tasks, ordered by what hurts you most if it fails. Juniors do very well with a clear task and badly with a vague mission.

Check 3: What happens on day three when they’re stuck?

What to look at: Where the junior goes with a question they are embarrassed to ask.

A bad answer: Nowhere. Or worse, to you, and you nod and say “sounds right.” Stuck juniors don’t announce it. They go quiet, then they guess, and guesses in a live product become your outages.

What to do: Fix a weekly hour with a senior, plus a rule that questions in writing get answered the same day. The cost is small. The silent two weeks it prevents are not.

Check 4: Can they break things your customers will see?

What to look at: What access the junior has on day one. Can they change the live product directly? Can they see every customer’s data?

A bad answer: Full access “to move fast.” One wrong command and a customer’s records vanish. This is not an insult to juniors. Seniors have done it too. The difference is that a senior has usually been burned once and builds a safety net.

What to do: Give them a practice copy to work in, and make going live a step that someone senior approves. Widen their access as they earn it.

The one rule to take away

Before you sign anything, fill in this sentence:

"[Name] will spend [number] hours a week reviewing [junior’s name]’s work, and starts on [date]."

If you can’t fill in all three blanks with a real person, a real number and a real date, don’t hire the junior yet. You are not saving money. You are deferring the bill and adding interest.

Where this leaves you

I’m not arguing against juniors. A well-supported junior is one of the best deals in hiring. They are keen, they learn your product properly instead of bringing habits from elsewhere, and in a year they are worth far more than they cost.

But “well-supported” is doing the heavy lifting in that sentence. If you are a non-technical founder, you are the one person who cannot supply the support. You can’t tell good work from plausible work, and neither can the junior yet.

So there are two honest routes. Hire a senior first and let them bring juniors in later. Or hire a junior with a senior attached from the start, someone who also helped choose them, so you are not guessing on both sides.

What you shouldn’t do is hire the cheapest person and hope. That choice is how the “juniors don’t work” story gets told, and it is usually the founder’s setup that failed, not the junior.

technical hiring — 15–20% of first-year salary, on successful hire only. engineers screening engineers; or a backed junior at 12–15% with three months of senior mentoring attached.

It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. Book a teardown · What it costs