How to Hire Solution Architects: Signals, Tests and Scope

Solution architects design how a specific system will meet its requirements within real constraints. The job is judged on whether those decisions survive contact with delivery, which makes delivery proximity the central hiring criterion. This guide covers it, drawing on FISTA Solutions' forward deployed engineers work.

What separates a strong solution architect?

Trade-off reasoning grounded in delivery. Strong architects explain what they gave up and why, and can point to systems built from their designs that are still running.

Signal	Strong	Weak
Describes decisions	With trade-offs and constraints	With patterns and ideals
Relationship to delivery	Close, accountable	Detached, advisory
Record of decisions	Written with reasoning	In slides, then lost
Failure stories	Specific and instructive	None offered
Response to constraints	Designs within them	Argues they should change

What is the single best interview question?

Ask about an architectural decision they got wrong, how they found out, and what they changed.

Architects who have never been wrong have either not shipped or are not paying attention. The answer also reveals whether they stayed involved long enough to learn the outcome, which many do not.

Should architects still write code?

They should stay close enough to delivery to be accountable for buildability. That does not require full-time implementation.

Architects entirely removed from the codebase produce designs that meet requirements on paper and break in practice, and the delivery team absorbs the cost while the architect has moved on.

Why record decisions?

Because in two years somebody will ask why the system works this way. Without the reasoning, they will either repeat the analysis or reverse a decision for reasons that were already considered and rejected.

Short written records — the decision, the alternatives, the reasoning, the consequences — are cheap to produce and durable. Ask whether they keep them.

How do you test for constraint awareness?

Present a realistic constrained scenario: an existing system that cannot change, a team without a particular skill, a regulatory requirement, and a deadline.

Strong candidates design within the constraints and name what they are trading away. Weak candidates describe what they would do in better circumstances, which is not the job.

What about non-functional requirements?

Ask how they established availability, latency, and data retention targets on a previous project, and who agreed them.

Architects who accept vague requirements produce systems that satisfy nobody's actual expectation, because everyone assumed a different number.

How do you evaluate communication?

Ask them to explain a technical decision as they would to a finance director. Architecture work involves persuading people who will not read the diagram.

Candidates who cannot make the business case for a technical decision will lose arguments they should win.

How do you avoid the ivory tower problem?

By defining accountability. If the architect is accountable for the system working, the incentives align; if they are accountable only for producing a design, they will optimise for defensibility rather than buildability.

Ask what they were measured on in their last role.

How does AI change architecture work?

It adds a new class of decisions: where non-deterministic components are acceptable, how failure is handled when a model is wrong rather than unavailable, and what human oversight the design requires. Architects who treat an AI component as an ordinary service will design systems that fail quietly. See what is an slo for ai systems.

Contract, staff augmentation, or permanent hire?

Augmentation suits a defined programme where an experienced architect shapes the approach and hands over. Permanent hiring suits organisations with a continuous portfolio and accumulated context worth keeping.

What are the common hiring mistakes?

Hiring for pattern vocabulary. Detaching the role from delivery. Measuring on documents produced. And appointing someone with no authority to a role whose value depends on decisions sticking.

How do you onboard them well?

Give them the systems that hurt, the constraints nobody writes down, and the decisions people keep re-arguing. That third list is where an architect earns their cost quickly.

What does good look like after 90 days?

Decisions recorded with reasoning, non-functional requirements agreed with numbers attached, and at least one long-running argument settled.

When do you not need this role?

When a single team can hold the design in its head and the system does not span organisational boundaries.

What should be measured?

Delivered systems that match their design intent, decisions that stay decided, and delivery teams' ability to proceed without escalation.

What should you do first?

Write down the three decisions your teams keep re-litigating. Those are the architect's first quarter.

How do you handle build versus buy?

Ask about a build-versus-buy decision they made and how it turned out. The interesting cases are the ones where the obvious answer was wrong: a product bought and then heavily customised until it cost more than building, or a component built because no product fitted and then maintained for a decade.

Strong architects weigh the maintenance tail rather than the purchase price, and they say plainly when the honest answer is that both options are bad.

How FISTA Solutions helps

FISTA Solutions provides architecture close to delivery through forward deployed engineers and staff augmentation: decisions made within real constraints and recorded with their reasoning, non-functional requirements agreed with numbers, architects accountable for buildability rather than only for designs, and AI components designed with explicit failure and oversight behaviour through AI agents and AI enablement. The record is 150+ projects for 50+ companies across 12+ countries.

To add architecture capacity, message FISTA on WhatsApp, or read hire enterprise architects.