Interview Techniques

Introduction

This post will explain a little bit about a particular type of interview: an architecture interview. It’ll breakdown what it is, why using whiteboards isn’t necessarily a bad thing to use in an interview context, as well as understanding a bit about what it is we’re looking for from a particular candidate (in this post the information will be related to interviewing someone for an Engineering Manager opportunity).

What is an architecture interview?

An architecture review can be a few different things depending on the context of the interview and the type of role being applied for.

Typically, for a software engineering role, a candidate will be asked to design a system architecture based on the interviewer’s given requirements.

Note: this is typically carried out on a whiteboard, but pen and paper is sufficent too (although harder for both candidate and interviewer to share and discuss over).

Whereas for a more senior role, like an engineering manager (or even a director of engineering), the format will change to one where the candidate is asked to present a system architecture they’ve been involved with.

The reason for the switch around of formats is that generally the more senior roles won’t necesarily be controlling the system design (they’ll have input, but generally speaking this would be the responsibility of individual teams), and so what you’re trying to gauge from that type of interview is an understanding of whether they have a solid technical grounding, because their other skills are of a bigger priority.

Is one interview all it takes?

No. To clarify: when interviewing a candidate, you won’t give them a single architecture interview and call it a day (i.e. make a decision). There are many interviews that need to happen before you can make such a decision:

• Architecture
• Organizational
• Team Values
• Executive
• Cross-Discipline
• Team Managment

Note: the above are based on a ‘Director of Engineering’ day of interviews, but you’d have similar formats for varying engineering roles.

Aren’t whiteboard interviews bad?

In summary: no (at least they’re not inherently bad).

When you say “whiteboard interview”, people generally tend to cringe and think of past experiences of being told to solve X problem using Y algorithm, and writing out chunks of pseudo-code with pen and paper.

But let’s be honest, that rarely correlates to the actual work you typically end up doing, and so to describe that format as “wrong” would be correct †

† although, as with everything, it can depend on the role you’re hiring for of course.

For me, that type of whiteboarding session is a problem. Whiteboard interviews of that nature, the ones that have you jumping through hoops to perform some kind of mathematical trickery are at best useless, and at worst very stressful. They’re also likely to result in a candidate leaving unenthused and saying bad things about the company and its interview process on social media.

You should not be having whiteboard interviews consisting of questions of that kind. Whereas architecture interviews are (in my experience any way) about more about discussing ‘high-level’ concepts, and demonstrating ‘practical’ problem solving skills which are applicable at many different levels of experience, and useful in many different situations.

If structured (and presented) correctly by the interviewer, a whiteboard interview (such as an architecture interview) can actually be fun for both the candidate and the interviewer, and be an enlightening experience rather than a stressful one.

How should an architecture interview be handled?

The goal (for any interview) is to allow the candidate to shine, and to present themselves in the best light that they can. Even if you decide they’re not right for the role or the organisation, you want them to walk away feeling good about themselves and what they did that day.

To hopefully achieve that goal, we want the candidate to feel relaxed and that they have everything they need before the interview begins (do they need a toilet break? do they need a glass of water? make sure you ask and that they’re comfortable).

Next, tell them the agenda. Just as an example it might go something like:

“We have 90mins and then you move to your next interview. So I reckon we should spend five minutes introducing ourselves and what we do here (the teams we work in etc), and then the next hour chatting about the problem to be solved (or the architecture you’re going to present), and then after that it’s up to you: we could either use up the rest of the time by having you ask us questions – anything you like, or we could do that for 15 minutes and the remaining time you can have back to relax and we can show you around the office a bit”.

Doesn’t have to be exactly like that, but basically you want the candidate to know what’s going on (no surprises or ambiguity). So, you might also want to make sure the candidate is ok with you taking notes (my memory is terrible and so much happens during an interview that you want to be able to go back over your notes to be sure you’ve taken everything into consideration).

As far as the actual ’test’ portion of the architecture interview, remember that people solve problems in different ways to you so be open-minded when critiquing their design.

Lastly, and most importantly, when dealing with a software engineer (i.e. you’re giving them requirements to fulfill as part of the design), make sure you’re working with that person. Help guide them when it looks like they might be losing their way, you don’t have to outright tell them the answer, but you can ask leading questions that should otherwise help kickstart their thinking down a better path. You’d do this for any colleague you work with, so afford this person the same respect and kindness.

What are you looking for from a candidate?

Well, for me, it depends on the role. I’ve carried out quite a few ‘Engineering Manager’ interviews recently and so they’re the most prominent in my mind so I’ll use that as my measuring stick (but just remember, none of this is set in stone and is open for interpretation and tweaking/evolving).

So below are the high-level perspectives I’m looking for, and taking notes on. But realise you won’t be able to incorporate all of these into your single architecture interview. It wouldn’t be practical, nor would it make sense to do that (especially if you have multiple interview formats for this candidate). These topics are more generally applicable.

• Communication:
  • are they ‘remote aware’? I’m generally interviewing remotely, so when there are other interviewers in the room (in real life), it’s often the case I’m not interacted with in the same way as others.
  • do they use gender appropriate language?
  • do they communicate clearly and circle back to questions they forgot to answer?
• System:
  • are they able to describe the history of the project, its reason for existing, the value it’s supposed to offer, the teams and other comms involved?
• Architecture:
  • is it a good design? fundamental but just be aware that in most cases this becomes a subjective opinion, and so unless there are some horrific consequences to the design, then it’s not actually something to worry too deeply about.
• Risk Management:
  • Is the system fault tolerant? What scenarios were considered?
  • Were risks identified (if so what were they)?
  • How were those risks managed/mitigated?
  • Was the risk monitored?
• Observability:
  • What telemetry system was used to gather data?
  • What types of instrumentation is in places (logging, metrics, both or other)?
  • What monitoring tools are in place?
  • See also this post about monitoring best practices.
  • How is on-call handled (is there a culture of responsibility or is there a centralized operations team looking after things)?
• Strategy:
  • What teams were consulted/impacted?
  • Who were the stake holders, and what were their involvement?
  • How was the system proposed and communicated?
• Distribution:
  • Is the candidate used to working within a large multi-region organisation where teams are distributed across many different time zones (are they used to those types of challenges)?
• Organisation:
  • What is the structure and hierarchy of their current employer? Is it fairly flat or lots of layers and red tape? Maybe it’s “goldilocks” (i.e. just right)?
  • Has there been any restructuring of the teams (why), and how was it communicated, how was the changes received by staff?
• Awareness:
  • Was the candidate actively thinking about things outside of just the technical aspect? Were they thinking about, for example, the costs associated with the architecture they were designing and how to reduce those costs whilst trying to still solve the problem at hand?
• Team Management:
  • How does the candidate handle 1:1 meetings, build relationships and give feedback?
  • How big is the team(s) they manage, what conflicts have they needed to resolve, and how?
• Organisation Feedback/Inclusion:
  • Does their current employer provide staff the means to give them feedback and to understand the health of their organisation?
  • If so what are those tools and what has their effectiveness and impact been?
• Diversity:
  • Is the candidate thinking about diversity and how to improve it in the hiring process?
  • What tools do they use to help with that goal?
  • Are there any community programs they support or host?
• Interest:
  • Is the candidate excited to work for/with us? What about our organisation do they like the most? (this isn’t a deal breaker, this is more out of interest)

Anything else?

I don’t know, but maybe you could let me know on twitter if there’s anything I’ve missed or should be doing differently. Feedback appreciated.