How to Hire a Solutions Architect in 2026

Post a “Solutions Architect” job listing and you’ll get three very different kinds of applicants: cloud generalists who’ve picked up a certification but never sat across from a client with a real constraint, ex-consultants who are excellent at the conversation but haven’t touched infrastructure directly in years, and a smaller group who can actually do both. The title doesn’t distinguish them. Your interview process has to.

What the role actually is

A solutions architect’s job is translating a business problem, with all its real constraints, budget, existing systems, compliance requirements, a skeptical stakeholder who’s been burned before, into a technical approach that can actually get built. That’s a different job from a cloud architect, who typically owns infrastructure design for one product or team and answers “how do we build this” rather than “what should we build, given everything in the way.”

The distinction matters because the skills don’t automatically transfer. A strong cloud architect can be a mediocre solutions architect if they’ve never had to defend a design choice to a non-technical stakeholder or negotiate scope against a fixed budget. And a strong solutions architect with weak hands-on technical depth will produce designs that sound right in a slide deck and fall apart in an implementation review. You need both, and the interview process should test for both explicitly rather than assuming one implies the other.

Certifications are a filter, not a decision

AWS Certified Solutions Architect, Google Cloud Professional Cloud Architect, and Microsoft Certified: Azure Solutions Architect Expert are the three certifications that show up most often on strong candidates’ resumes, and for good reason: they prove someone has studied a platform’s services systematically rather than picking up fragments on the job. That’s a real, useful signal, especially at the entry to mid level where you have less direct work history to evaluate.

It’s a weak signal on its own, though. A certification exam doesn’t test whether a candidate can sit in a room with a client who insists on keeping a legacy system nobody wants to touch, and still propose something that gets built. Use certifications to filter a resume pile down to a reasonable interview set. Don’t let a certification substitute for the actual interview.

What to test instead

A real, messy scenario, not a generic system design question. Give the candidate an actual situation from your own business or a client engagement, with identifying details changed: a legacy system with a specific limitation, a budget ceiling, a compliance constraint that rules out the obvious answer. Ask them to propose an approach.

Then push back, on purpose. Introduce a constraint they didn’t account for after they’ve committed to a direction. This is the part that actually separates candidates. Someone who’s only ever worked with idealized requirements will either get defensive or cave immediately and agree with whatever pushback you give, neither of which is what you want from someone who’ll be doing this with real clients. The candidate you want revises the design specifically in response to the new information, explains what changed and why, and can articulate what tradeoff they’re now accepting that they weren’t before.

Ask about a design they were talked out of. Not a design that failed, one where a stakeholder or engineer pushed back and the candidate changed their approach. You’re listening for whether they can describe the disagreement honestly and explain what they learned, versus a story where they were “right all along” and just had to convince everyone else. The second pattern is common among people who are good at sounding confident and worse at actually being right.

Have them read, not just write. Hand them an existing architecture diagram or a system design doc from your own stack and ask them to identify the biggest risk in it. A solutions architect spends a meaningful part of the job evaluating other people’s designs, whether that’s a client’s existing system or an engineering team’s proposal, and that’s a different skill from generating a clean design on a blank whiteboard.

Breadth vs depth

Most solutions architect postings ask for broad multi-cloud experience, and most candidates who list all three major platforms on their resume have surface-level familiarity with two of them. In practice, a candidate with deep, current, specific expertise in one platform and working fluency in a second is more valuable than one who can name services across three but can’t go deep on the tradeoffs within any single one. Test for depth on whichever platform matters most to your stack before you weight breadth at all. If your organization is genuinely running production workloads on two clouds simultaneously, that changes the calculation, but that’s less common than the job postings suggest.

What to pay

Level	India (annual)	US (annual)
Entry-level	$20k-$35k	$120k-$160k
Mid-level	$30k-$50k	$160k-$220k
Senior / Principal	$55k-$100k+	$220k-$320k+

Client-facing experience and current certifications push a candidate toward the top of each band, and it’s worth being specific in your posting about how much of the role is client-facing versus internal, since that changes what “senior” actually means for the position. A senior solutions architect who’s spent their career on internal infrastructure teams is not automatically prepared for a role that’s mostly client conversations, even at the same nominal seniority.

---

This role sits close to the DevOps engineer and cloud architect hires in our series, and it’s worth deciding which of the three you actually need before writing the posting, since the skill overlap is real but the day-to-day work differs more than the titles suggest. For the broader screening philosophy this series is built on, see how we vet developers. If you’re scoping a hire like this and want a second opinion on what the role should actually cover before you post it, that’s a conversation our team has regularly.