Cohesyve · Practice for candidates
Preparing for a Solutions Architect role? Start by finding out where you stand.
Import the actual job you're going for, run a simulation built from it, and get a scored report showing which of these areas you're weakest in — before you spend weeks studying the wrong thing.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
Solutions architect interviews are long, and they are unusually unforgiving of vagueness. You are being assessed on two things at once: whether you can design a system that would survive contact with production, and whether you can carry a room of engineers, salespeople and executives through the reasoning. Most processes include a whiteboard design session, a deep technical discussion of something you have built, and at least one stakeholder-facing conversation. This page sets out what each stage measures and how to prepare across the weeks before it.
The hiring process, stage by stage
Screening call
Establishes what kind of architect you are — pre-sales, enterprise, or hands-on delivery — plus your cloud platforms, the scale you have worked at, and whether you still write code.
How to prepare: Have a two-minute summary that names the systems you designed, their scale in concrete terms, and your platform depth. Be honest about how recently you were hands-on, since it will be tested later.
Technical deep dive on your own work
You present a system you designed and the panel probes it: why that data store, what happens when this component fails, how you would handle ten times the load, what you would change now.
How to prepare: Pick one system you know completely and can draw from memory. Prepare the numbers — request rates, data volumes, latency targets — and the two decisions you would reverse. Rehearse being pushed on the weakest part.
System design session
A live design exercise against an open-ended brief, usually sixty minutes with a shared whiteboard. Scored on requirement gathering, the shape of the design, failure handling, and how you respond to changing constraints mid-session.
How to prepare: Practise a consistent sequence: clarify functional and non-functional requirements, estimate scale, sketch the high level, then go deep on the one or two components the interviewer cares about. Practise on a whiteboard tool, not on paper.
Stakeholder or customer-facing session
Often a role-play: present a proposed architecture to a sceptical customer or an executive, justify cost, and handle an objection. Common for pre-sales and consulting-oriented roles.
How to prepare: Rehearse explaining an architecture with no jargon, leading with the business outcome and the cost envelope. Prepare answers to the two objections that always come: this seems expensive, and why not just buy the managed product.
Panel with engineering leadership
Covers how you work with delivery teams, how you handle an engineering team that disagrees with your design, governance, and how you keep architecture decisions from becoming shelfware.
How to prepare: Prepare an example where an engineering team rejected your approach and what happened. Have a view on architecture decision records, review forums, and how much standardisation is worth the cost.
What to study
Requirements and constraint gathering
The most common failure in design sessions is drawing boxes before establishing what the system must do. Interviewers usually decide in the first ten minutes.
Distributed systems fundamentals
Every serious design session tests whether you understand what happens when part of the system fails or falls behind, rather than only the happy path.
Data architecture
Data choices are the hardest to reverse, so panels probe them hardest. A weak justification for a data store undermines the rest of a good design.
Security, compliance and governance
In enterprise and regulated environments this is a gating topic. Being unable to discuss identity, network boundaries and audit sinks a candidate quickly.
Cost, trade-offs and communication
The differentiator between senior engineers and architects is the ability to price a design and defend it to people who do not care about the technology.
Cohesyve for candidates
Practise a Solutions Architect assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Your preparation plan
Four weeks out
Rebuild depth in the areas your recent work has let go stale.
- •Choose one system you designed and reconstruct its full diagram, numbers and failure modes from memory
- •Identify the two platform areas you are weakest in and study them deliberately
- •Review the employer's stack from job adverts, engineering posts and their public documentation
- •Refresh your cost knowledge for the platform they use, at least to order of magnitude
Two weeks out
Practise designing live, out loud, against a clock.
- •Run four sixty-minute design exercises on a whiteboard tool, speaking throughout
- •Deliberately practise the mid-session constraint change: ten times the traffic, or a compliance requirement
- •Rehearse the deep dive on your own system with someone instructed to attack the weakest component
- •Practise explaining one architecture with no technical vocabulary at all
The final week
Rehearse pacing. Most design sessions fail on time management rather than knowledge.
- •Time your sequence so requirements take ten minutes, not thirty
- •Do one full mock design session end to end with feedback
- •Prepare your two standard objection answers for cost and for build versus buy
- •Confirm the tooling for the design session and get comfortable with it
The day before and the day of
Preserve energy. These processes are long and the later sessions are usually the deciding ones.
- •Review your requirement checklist once so the opening is automatic
- •Test the whiteboard tool, screen sharing and your second screen
- •Have a blank template ready: requirements, scale estimate, high level, deep dive, failure modes
- •Plan short breaks between sessions and keep water to hand
Questions to expect
“Design a system that handles a large volume of events from connected devices.”
What they're really asking: Do you establish scale and requirements before designing, and do you understand ingestion under load?
How to answer: Get numbers first: device count, message rate, payload size, latency tolerance, retention. Sketch ingestion, buffering, processing and storage as separate concerns, then go deep where the interviewer pushes. Cover backpressure, duplicate delivery and what happens when the downstream store is unavailable.
“Walk me through a system you designed and what you would change now.”
What they're really asking: Was this genuinely yours, and have you seen it live long enough to learn from it?
How to answer: Draw it, give the real numbers, and name the two or three decisions that mattered. Then be specific about what you would reverse and what the actual consequence of the wrong choice was in production. Vague regret reads as a system you did not own.
“The engineering team disagrees with your design. What happens next?”
What they're really asking: Are you an architect who works with teams or one who issues designs from a distance?
How to answer: Describe finding out what they know that you do not, because they usually know something about the codebase or the operational reality. Give a real example, say whether you changed the design or held it, and explain how the decision was recorded so it did not resurface monthly.
“How would you justify this architecture to a customer who thinks it is too expensive?”
What they're really asking: Can you talk about money and business outcomes rather than retreating into technical detail?
How to answer: Lead with what the cost buys — availability, recovery time, compliance position — and offer a cheaper option with the trade-off named explicitly. Show you know the rough cost breakdown and where the biggest line sits. Never defend a design purely on elegance.
“How do you decide between building something and buying a managed service?”
What they're really asking: Do you account for total operational load, or only for the licence line?
How to answer: Frame it around differentiation and operating cost: does this capability differentiate the business, does the team have the skills to run it at three in the morning, what is the exit cost. Give an example of each decision you have made and how it turned out.
“This component fails. What happens to the rest of the system?”
What they're really asking: Have you actually operated systems, or only drawn them?
How to answer: Trace it concretely: what times out, what retries, what queues up, what the user sees, and how the system recovers when the component returns. Name the mitigation you would add and its cost. Mention how you would detect it, since undetected degradation is the real problem.
What to bring as evidence
One system you can draw from memory with real numbers for scale, latency and cost
An architecture decision record or design document you wrote, redacted if needed
A migration or modernisation you led, including what went wrong during cutover
An example of a design you changed after engineering pushback, and the outcome
A cost reduction or availability improvement you delivered, with the before and after
Current platform credentials or recent hands-on work if your role has drifted away from delivery
Common mistakes
Drawing boxes before establishing requirements, scale or constraints
Spending thirty minutes on requirements and leaving no time for the design
Presenting only the happy path and never addressing failure or degradation
Choosing a data store without being able to defend it against the obvious alternative
Reaching for a microservice architecture regardless of the problem
Falling into jargon during the stakeholder session, which is exactly what it tests
Questions to ask them
- ?
Who owns an architecture decision here once it is made — the architect, the team, or a review board?
- ?
What is the most significant piece of technical debt in the estate, and what has stopped it being addressed?
- ?
How close is this role to implementation — would I be writing code or reviewing designs?
- ?
When was the last time an architecture decision was reversed, and what triggered it?
- ?
How does cost factor into design decisions here, and who is accountable for the cloud spend?
- ?
What does the relationship between architecture and the delivery teams look like when a deadline is under threat?
Frequently Asked Questions
How hands-on do I need to be?
It varies more than any other part of the role, so ask early. Delivery-oriented architect roles will test coding or infrastructure work directly; pre-sales and enterprise roles rarely do but will still probe whether your knowledge is current. Being open about where you sit is safer than being caught out in a deep dive.
Do cloud certifications matter?
A professional-level certification on the relevant platform helps at CV screening and signals breadth, particularly in consultancies and partner organisations. It does not compensate for being unable to design under questioning, and interviewers will move past it within minutes.
How much detail should a whiteboard design have?
Start at a level where the whole system fits on one board, then follow the interviewer into detail where they push. Trying to detail everything is the most common pacing error. Say out loud which components you are deliberately leaving shallow and why.
What if I do not know a technology they ask about?
Say so, then reason from the category — if you know how distributed queues or columnar stores behave, you can discuss a specific product you have not used without pretending. Fabricating familiarity is easily detected and it ends the credibility of everything else you said.
Is there any way to rehearse the design stage realistically?
Practising against a clock with feedback is what separates prepared candidates from experienced ones who freeze. Import the role into Cohesyve, run a solutions architect simulation, and you get a scored report on your requirement gathering, design choices and failure handling, plus a study pathway. The free tier gives three assessments with no card.
Practice
What a Solutions Architect assessment tests, and how it's scored →
Career guide
What a Solutions Architect actually does, and where the path leads →
Prepare for another role
Cohesyve · Practice for candidates
Don't walk in guessing. Find out where you stand first.
Three free scored practice runs, a full report on every one, and a learning pathway built from what you actually got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for a Solutions Architect role? See how your applicants perform before you spend interview time.