Building Engineering Teams

Design the shape first

An all-senior team is expensive, slow to agree, and short of people who will do the unglamorous work. An all-junior team ships quickly in a direction nobody senior evaluated. Most teams need a mix, and the mix should be decided before the first hire rather than emerging from a series of urgent gaps.

Ask two questions. What does this team need to be able to do that it currently cannot? And which of those gaps needs deep experience versus capacity? Those give you a shape rather than a queue of requisitions.

Also consider what the team can absorb. Every hire costs existing engineers onboarding time, and a team that doubles quickly spends most of a quarter teaching rather than building.

Write down what levels mean

Senior at one company is mid at another and lead at a third. If your levelling exists only in people's heads, offers become inconsistent, internal progression becomes arbitrary, and interviewers calibrate against different bars without realising it.

The definitions do not need to be elaborate. Scope of problem, degree of independence, and effect on others is usually enough: whether someone is given a task, a problem, or an area, and how much their work raises everyone else's.

Write it once, use it in the posting, in the rubric and in the offer. Most levelling disputes are really a missing document.

Evaluating technical work

The best predictor is work resembling the job. A focused exercise in a realistic context, ideally paired with someone from the team, tells you about problem-solving, how they handle being stuck, and whether working with them is any good.

Two common formats to be careful with. Abstract algorithm puzzles measure preparation for that format more than day-to-day capability. Long unpaid take-homes select for candidates with spare time, which is a demographic filter rather than a skill one; if you use one, keep it short and say honestly how long it should take.

Whatever the format, ask them to explain their reasoning. On a real team the reasoning is what colleagues actually consume, and it is harder to fake than the output.

When to reach for a contractor instead

Some engineering needs are genuinely temporary: a migration, an integration with a system nobody in-house has touched, a specialised platform for one project. Hiring permanently for those means either carrying a role after the need has passed or hiring someone whose interest ends with the project.

A contract engagement is the better instrument there, and it can usually start in days rather than months. See Hiring Contractors and Finding AI Developers for evaluating specialist skills you do not have in house.