How to Hire a Software Architect

Promote from inside first if you can. The person already writing design documents that other engineers follow is usually a better architect than an external hire who needs a year to learn your domain. When you must go outside, look at conference speakers on system design topics, consultancy alumni who have restructured many codebases, and engineers who publish architecture decision records or write about migrations that went wrong. Title searching is unreliable here, because plenty of architects are called principal or staff engineer, and plenty of people titled architect have not written code in years. Search by evidence of design authorship rather than title. Consistent evaluation matters when candidates come from very different backgrounds, so keep everyone on one scorecard inside your [applicant tracking system](/ats).

Define the decision rights. The single biggest source of failed architect hires is ambiguity over what they can decide alone, what they recommend, and what belongs to team leads. State it in the post. Describe the estate honestly: how many services, how much legacy, which parts nobody understands anymore, and whether the mandate is to modernise, consolidate or stabilise. Say how much hands-on coding is expected, because "architect" means slide decks at some companies and pull requests at others, and candidates have hard preferences. Mention who they influence, including whether they work with product and finance. Skip the tool checklist. Our [software architect job description](/job-descriptions/software-architect) starts from decisions and outcomes, and a [job description generator](/tools/job-description-generator) helps you tune the wording.

Ask for a design document they wrote. Any architecture decision record, request for comments, or migration plan works, redacted if needed. Documents reveal what interviews hide: whether they consider alternatives, whether they name the constraints and the tradeoffs, whether they write for the engineers who must implement it, and whether they commit to a decision or hedge. Then discuss that document with them, focusing on what they got wrong and what they would change now. An architect who cannot criticise their own past design will not adapt to your context. Avoid algorithm screens entirely for this role; they measure nothing relevant. If you need a live signal, ask them to sketch how they would split one of your overloaded services and where they would draw the boundary.

Use four conversations. First, the design document review. Second, a brownfield exercise on a real system of yours, where the question is not how to build it perfectly but how to improve it incrementally without stopping delivery. Third, a session with two or three engineers who would work under these decisions, because architects who cannot persuade practitioners create shelf-ware. Fourth, a stakeholder conversation on tradeoffs, cost and timelines with product or executive leadership. Watch for someone who asks about team size and skill before proposing a design, since architecture that ignores the people building it always fails. Our [software architect interview questions](/interview-questions/software-architect) work well for the brownfield and influence rounds.

Plan for a long search. The pool is small, evaluation is slow because it depends on judgement rather than test results, and the wrong hire is expensive in a way a junior mistake never is. Many companies discover mid-search that they actually needed a staff engineer or an engineering manager, which is worth checking before you start. Architects accept offers where decisions stick, where they have engineering credibility to build on, and where they are not asked to design in isolation from delivery. They decline roles that look like documentation duty. Track how long each stage takes with your [recruitment metrics](/recruitment-metrics), because a slow, unstructured loop signals exactly the indecision that senior candidates avoid.