The Architecture Interview¶

Architecture interviews assess the candidates’ ability to work and think at the “whole-system” level.

Architecture is not just for senior-level engineers. Junior engineers should understand how the pieces they’ve worked on fit into the overall project, even if they might not know how to design the system from scratch.

Ask them to select a complex system they’ve designed/worked on, and have them explain to you how the major pieces fit together.
Get some sort of boxes-and-arrows diagram. What you’re looking for is the ability to communicate the components of a complex system—not any particular diagramming methodology. (It’s a good sign if they naturally gravitate to the whiteboard; if not, prompt them.)
Find out what parts of the system they worked on, and how their pieces interfaced with the others.
Dig deep into pieces they worked on, but also dig into pieces they didn’t work on. It’s a great sign if their knowledge extends beyond their own areas of responsibility.
What were the requirements for the system? (You may not need to ask this—better engineers will slip requirements into the discussion along the way.)
Propose a requirements change, and discuss how they’d adapt the system to the new requirements.
Why did they make the design choices they did? What were the trade-offs? (If they didn’t design the system, can they explain the decisions that were made anyway?)
Looking back, what would they change about the design? What parts worked particularly well or particularly poorly?

Using a Design Problem

Rarely, you may come across a candidate whose previous projects just aren’t complex enough for a meaningful architectural interview. In this case, you can give them a design problem. But this is not ideal, for several reasons:

It’s tricky to find a good architectural problem where candidates can grok the requirements quickly and fit the design and discussion into a reasonable time.
It’s extremely high-stress for the candidate. Some highly-qualified candidates just won’t do well on a design-problem interview.
Since you’re not talking about a real system, you can’t explore what went wrong or what they would change.

If you must use a design problem in an architectural interview, here are some tips:

Deliberately underspecify the requirements. Do they ask you to clarify requirements, or do they just make assumptions?
Give them time to think about their design—at least 10–15 minutes—before forcing them to explain it to you. Offer to leave the room so they can think (and draw at the whiteboard).
Pick something you’ve worked on before, so that you know the parameters and pitfalls. (But make sure it’s general enough that the candidate can understand it. And don’t expect the candidate to immediately intuit something that took you weeks to figure out.)

Next: The Coding Interview