Ask HN: What are good software architecture interview questions? - SoulMan
======
beat
Not so much a question as an approach, but...

When interviewing senior people, I like to get them going on war stories. "Can
you talk about a project you experienced that went very badly?" is a good one.
It's not necessarily that _they_ went badly, but we've all been on death
marches before (and I absolutely would not hire an architect who's never done
a death march!).

The beauty of this is you can find out how they react to impossible demands
and pressures. What they're proud of accomplishing in dire circumstances.
Possibly what they're ashamed or embarrassed about, or mistakes/lessons
learned (if they're that bold). You can learn a _ton_ about how they talk
about their colleagues! Are they full of praise, or contempt? Do they find
someone to blame, or talk about how someone else saved their asses? You can
also learn a lot about their actual approach to technical decisions - their
taste, for lack of a better word.

You can ask probing questions here, but the important part is to get them
speaking in an unguarded way. Nobody makes it to the architect level in this
field without at least kind of loving the job. Find out what they love. Find
out what they hate. Find out what they regret. Find out any strong technical
biases they have, and why. But most of all, find out how they play with
others. Because the architect's job isn't just to design, but to
_communicate_. You don't just want a technical expert. You want someone that
can value and respect the rest of the team, or they're just going to cause
problems.

~~~
_d8fd
>> Can you talk about a project you experienced that went very badly

I'd like to offer a spin on this.

In my experience, asking a question that demands one to recall specific
details about a painful event in an interview, which is typically a stressful
situation, may produce poor results.

What do you think about giving the candidate an opportunity to get advance
notice of that you'll be asking that question, in an interview, and ask them
to prepare three to five bullet points to discuss? Whether the candidate sends
the bullet points back to you before the interview, or just brings them to the
interview, is beyond the scope of what I'm proposing.

Let's say your trying to assess a 3 things:

* Has Architect been through the meat grinder at all? Bullet points with little depth log a warning, as there has been plenty of time to prepare a thoughtful answer.

* Does Architect talk about failure in a calm and composed manner? Bullet points give ability to ability to recall challenges before stress of interview sets in.

Does Architect trash talk former employer or coworkers? The stress of
interview can erode one's asshole filter, and cause them to be a bit of the
jerk they've worked really hard to not be (speaking a bit for myself here).

To wrap this up, I like interview questions that are functional with minimal
side effects, meaning the person is given every opportunity to provide the
answer you are looking without external pressure or distraction. If you want
to see how a person handles stress, give them a situation that is stressful in
a way it'd be on the job, perhaps leading with "apologies in advance for the
following situation, which is intentionally stressful..."

~~~
bassman9000
> In my experience, asking a question that demands one to recall specific
> details about a painful event in an interview, which is typically a
> stressful situation, may produce poor results.

Stressful and painful are not the same. Every engineer is going to go through
stressful situations. Good ones will learn from them: to minimize the risk of
them happening, and to better cope when they do.

> If you want to see how a person handles stress, give them a situation that
> is stressful in a way it'd be on the job

How is this any better?

> "apologies in advance for the following situation, which is intentionally
> stressful..."

Stressful situations don't send calendar invites.

I'm not arguing one should be an asshole during the interview. I've been
interviewed by clearly hostile engineers. I didn't like it, and it surely
impacted my performance. But real life is like that. Being able to react in a
polite and composed manner to an unexpected situation, and recover from it, is
a superb data point in an interview.

~~~
amorphid
> If you want to see how a person handles stress, give them a situation that
> is stressful in a way it'd be on the job

Mainly because you're paying someone to do a job, not to interview. I've
interviewed a lot of people, and sometimes interviewing just sucks for reasons
that have nothing to do with the interview.

For example, say you're homeless, and you get your first interview in quite a
while. Landing the job means housing for you. The pressure to perform is
enormous, and it's not something you can prepare for. I was homeless for a
bit, and in that situation.

I don't expect to get a job for which I'm not qualified, but it'd be nice if
an interview process allows me to show I can meet the requirements of the
position, regardless of the circumstances of my life situation outside of
work.

I like screening people in for the right reasons, and not screen them out for
reasons that aren't really all that important. And when you have a hard time
getting any qualified applicants, can you really afford to false negatives?

------
patio11
Take an actual problem that your team solved. Distill it down to essential
elements. Wargame out plausible solutions to it if one didn't have your team's
context on your particular situation, particularly plausible solutions which
would be top-of-mind to a smart, stressed person operating under incredible
time pressure. (Your actual IRL solution should probably be one of them, but
don't assume it is the only solution, the most likely solution, or the only
passing solution.) Take insights out of those wargamed answers (e.g. "Ahh,
this is performant", "Ahh, this approach fails loudly when our infrastructure
is in a degraded state", "Oof, this creates a SPOF... not desirable here") and
write them in a list. Group them by theme. Try to have somewhere between 5 and
10 themes.

For each theme on the list; make 3~5 variants of things which show the
insight(s) related to the theme at varying levels of
quality/discernment/depth/etc. Assign an appropriate numerical weight to that
tier of answer. Your list is now two-dimensional; in teaching circles it would
be called "a rubric."

Grade interviews against the rubric. On security, this candidate said X, Y,
and Z, which are elements which most closely match a Good answer; 7 of 10
possible points awarded.

Even better, grade _written notes taken during interviews_ against the rubric.

Now, and this is the brutally organizationally difficult part, stop overriding
the rubric when it spits out point values which imply next steps regarding a
particular candidate that are clearly not what one wanted to do. Instead, fix
the scenario and/or rubric.

~~~
Afton
> Wargame out plausible solutions to it if one didn't have your team's context
> on your particular situation,

My least favorite interview ever, was essentially "Implement this generic
problem that our team had to solve, but you don't have the context of our
infrastructure, and I'll criticize you every time you deviate from the actual
solution we came up with because your solution wouldn't work in our context".
It really felt like a "read my mind" type of problem.

No further point. Just glad to see you point out the relatively obvious point
that you need to evaluate a question for someone who doesn't have your current
context.

~~~
karmakaze
We do this, but in an interactive way, to see the approach taken, additional
context given, adjustments made along the way. This really shows how a
candidate thinks and if they can on-their-feet. Often we will run out of
alternatives before coming to a solution, with many avenues explored. Rarely
we will discover a path that may have worked, possibly even better.

~~~
codr4life
I was put through that once, it sucks. You're completely ignoring all the
wrong turns you took to get there, the number of people involved etc.
Expecting someone to just jump into your shoes and pull of the same trick is
not very constructive. What if you framed the problem wrong? Maybe this is the
candidate that would have helped you come up with a superior solution given
enough freedom and time?

------
pcsanwald
My general line of questioning is as follows:

1) Explain to me a system you built/architected. How it worked, what it did,
etc. I'm looking for a deep understanding around the requirements of the
business, and how that played into technical choices.

2) Talk me through some bugs you encountered or mistakes you made, and how you
course corrected. I try to make a candidate comfortable prior to asking this
and usually tell a quick and horrifying war story from my own career. Here I
want to understand how a candidate processes information and adapts the plan
accordingly. Like mike tyson said, everyone's got a plan until they get hit.

3) If you had to build the system again today, what would you do differently?
I'm looking for an awareness of how technology has evolved since they designed
the system in question, as well as what didn't work well over time from an
operational perspective (e.g. we didn't burn off time series data over time so
table index rebuilds started to take forever, etc). I want to make sure the
candidate supported the system they designed over time, and felt the
pain/benefit of their decisions. I usually specifically ask the candidate at
the beginning to pick a system they built and supported for an extended period
of time.

I also ask about areas of technical expertise, and areas where the candidate
feels less strong technically. For the former, I make sure they have the kind
of expertise they claim, and for the latter, I want to see how they
communicate with team members that are expert in those areas (and how they
gain familiarity with new technologies).

~~~
BurningFrog
I just don't remember enough of old projects to answer these questions in any
detail.

~~~
pcsanwald
I solve this by being very clear with candidates ahead of time (i.e. days
before the interview) about generally what I'm going to ask, and I've never
had a candidate tell me they couldn't recall at some some relevant details
from a project. I am generally asking about experiences that were impactful
and the lessons learned, not trying to test someone's recall ability.

~~~
BurningFrog
That helps. I've had questions like that sprung on me, and I just don't have
any prepared war stories to talk about.

I try to look forward and not dwell on the past. Or maybe that's how I
rationalize bad memory. Either way, when asked about details of something I
worked on 8 years ago, I don't have much to say.

~~~
Anasufovic
Yeah, my mind just seems to just abstract it all just into the lessons learned
decoupled from its origin. The story is something I can rarely recall. But I
was always more into talking about ideas rather than trading stories.

~~~
BurningFrog
Yeah, that describes me better than I could!

------
terryjsmith
As with any interview, I like to make it as personal as possible. Tell me
about something you have architected and why you've architected that way. I
will ask probing questions about why you chose this stack, this database tech,
this integration layer, questions about security concerns, areas for
improvement, what you learned and would've done differently, etc., etc. This
also allows you to see the interviewee's excitement and really turns the table
to put them in a comfortable position where they are the most knowledgeable
person, which makes for a much smoother interview. If that goes well, I may
turn to some specific tasks or problems we have faced or are facing and
discuss at large how those might be addressed, again really focused more on
brainstorming than any "right" answer.

If you don't have any projects or work to talk about, the interview is
basically over as I don't see much value in talking about cookie cutter
problems.

~~~
corysama
This is great stuff. A fun bit to add is "That thing you made, if you had more
time, how would you make it better? How would you make that version better?"
And, so on until it start to get a little ridiculous.

------
ChuckMcM
For me, the single largest differentiation between "senior programmer" and
"software architect" is whether or not they can see the actual problem. The
catch phrase is "see the forest for the trees" but in software it is
recognizing you're in a forest and then understanding forest type issues. I
was on a team that was nominally building a "video encoding protocol" because
that is what they were asked for but the problem they were solving needed a
remote procedure call protocol.

Happens all the time, a person wants to buy a waterproof computer, but really
what they want is to see the results of a program while they are in a
rainstorm. Or they want a "website for managing inventory" but they really
want a way of tracking employee theft. So architects listen to the problem
statement(s) and think about what is in play, will ask some clarifying
questions and then reframe as the _actual_ problem statement. A senior
engineer will ask evaluation level questions (how fast, how much memory, etc)
and come up respond with a solution to the stated problem.

A _bad_ software architect will not be able to stop abstracting and will start
with a 50,000' view and then float into orbit. A "good" software architect
will add in the business or operational constraints to the problem and
articulate where the ceiling is and why.

~~~
SoulMan
>single largest differentiation between "senior programmer" and "software
architect"

I am glad that you brought this up. My question was more from a perspective of
distinguishing senior engineer vs architect interview questions. There is only
a limited time in the interview. Shouldn't an architect be also asked the
senior engineer questions in addition to the ones discussed here. Especially
my our org setup they are also hands-on and individual contributor to the code
base. One solution could be to restrict the 1st couple of rounds of an
architect interview to senior engineer questions only . Fair ?

~~~
ChuckMcM
If you don't mind I'm going to go a bit 'architect' on you :-) Do you need a
software architect or do you need a senior engineer. Interview questions are
about finding out if you should say 'no', by definition if someone is called
in for an interview you've tentatively said yes to them for the job you just
want to know if you should change that to a no. So the problem set is
understanding if the applicant in front of you will be able to do the job you
need done.

Your comment that "in our org ... they are also hands-on" is the an echo of
the Joel Spolsky 'architecture astronaut' type. Someone who spends all day
architecting and none of their time coding. But here is the thing, at the end
of the day its about how much product the organization ships at the end of the
day and whether or not that product had does the job it needs to do right? So
there is some nuance there to consider.

I certainly believe that anyone who considers themselves to have software
architecture skills, should also be able to do anything a senior engineer can
do caveat a deep discipline/subject matter engineer[1]. So interviewing for
senior engineers will also get candidates who show architecture tendencies,
and you will recognize them because of the questions they ask. If you want to
provoke those questions then leave some of your coding or puzzle questions a
bit ambiguous to see if they let their ideas play out or if they are sticking
with the task.

Here is the thing though, you can have lots of really good programmers and all
they need is a bit of structure around where they are going so that together
they can make something awesome. That needs an architect who is spending all
of their time keeping everyone on the same page, and if changes need to be
made, moving to the new page. If your programming team is fairly senior and
just "gets it" and will work out amongst themselves which parts need to fit
with the other parts, then you just need another senior engineer like that. In
my experience though group 1 is more common than group 2.

[1] There are irreplaceable senior engineers who have become so deeply expert
in a particular technology you don't want them to do anything but own that
code.

~~~
SoulMan
>needs an architect who is spending all of their time keeping everyone on the
same page Now here is he problem, the org needs someone like that but again
the expectation is to contribute equally in the implementation during every
sprint as his hours are accounted for sprint velocity. In this case I can't
hire someone who does not write a complex sql or merge two linked list in code
etc .

Most of th programmers are so young in this part of the world that Anyone
having more than 9 years of tech would expect an architect position and there
are high chances that is not actively programming in his previous company and
thus it becomes nesssary to eveluate coding skills

~~~
ChuckMcM
Be careful you don't set them up to fail. Measure team power not individual
power. Do you really care if they spend time writing code or not if the team
is getting more done?

------
rb808
You should make sure they've actually stayed around in their companies a few
years to see how it actually behaves. I've seen a bunch of architects that
regularly move on to the next hot project, before the old one is properly
completed. The architect never sees all the problems that come from their
grand ideas so they dont get to learn what is practical. There is a big
difference between architects that know all the hottest tech and buzzwords,
and an architect that can deliver a reliable and maintainable platform.

~~~
alistairSH
I wish I could triple up-vote this. I've worked with a few architects who were
great at envisioning fantastic, pure systems that looked great on paper. But,
were nearly useless at actually building these systems and making them work in
the real world.

That might be ok if the role is a pure R&D role, where they're "playing
around" with the latest technology and ideas. We have some of those positions
at my current employer. But, it's not very good for an architect who will be
embedded with a team of developers.

------
mbrodersen
I have interviewed and hired software developers for many years at different
companies in different countries. Which has given me the opportunity to
experiment with different questions and correlate that with outcomes (how good
the people I hired or recommended for hiring turned out over the next 5
years). And I have now narrowed the questions down to 4 types of questions
that really filter the good developers from the not so good: (1) Ask the
candidate to dive into all major groups of software development
(DB/UI/Testing/OS/...) and see how deep the candidate can go (2) Ask the
candidate to come up with a _practical_ solution to a NP complete _real_
problem (usually an optimization problem) (3) Ask the candidate how he/she
would approach investigating and solving a specific _real_ problem for a large
_real_ system (usually a mobile-server-DB system) and (4) how they would
architect a system given a list of _real_ use cases. Candidates that do a good
job of answering those questions are highly likely (as in 95%) to be
successful if hired. They don't have to come up with a perfect solution. What
is important is how they approach the problems and what kind of possible
solutions/investigations they come up with and their reasoning behind it.

------
OliverJones
An architect's role often has an economic as well as a technical part to it.
So, it's important to find out whether your candidate has a strong loyalty to
a particular vendor stack. Ask.

After you've had a conversation about a project in the candidate's track
record, ask some pointed questions:

\-- what would you lose in performance and functionality if you reworked that
project to run on cheaper infrastructure? (By that I mean such things as
"standard edition" rather than "enterprise edition" of DBMSs, open source vs.
paid licenses, etc.) This is a good way to get a handle on the candidate's
economic reasoning ability.

\-- what was a significant performance bottleneck in that system? How did you
address the problem?

\-- with the benefit of hindsight, what parts of that system would you say you
overdesigned? underdesigned?

\-- what was a security vulnerability in the system? How did you plan for
security? If you had to do security remediation, please describe it.

------
lepunk
I normally go with: "If you could do it from scratch how would you implement
the infrastructure of X"

X being a currently widely known service (I'm usually going with Spotify).
There is no "right answer" to this question but this shows you how the
candidate thinks and how well they can protect their opinion if challenged

~~~
Mongoose
I think this is a good question, but that it falls prey to the same conceit
that befalls those who claim they could "build Twitter in a weekend". A
picture-perfect sketch of a system can illustrate one's knowledge of patterns
and off-the-shelf solutions, but it won't cover the things that get in the way
of a team building their way towards product/market fit.

You could lead with this question and then jump in with hypothetical
roadblocks to see how the candidate reacts.

Ex:

\- "A network of microservices _would_ be a clean way to implement this. How
would you foresee the operational burden of this impacting a small team?" \-
"Imagine that you build this and it works well, but the product it powers ends
up not resonating with customers. The team now wants to pivot to X. What
changes would you make to the system to address this new problem space?"

~~~
humanrebar
> it falls prey to the same conceit that befalls those who claim they could
> "build Twitter in a weekend"

A good answer would account for the fact that our initial approach to big
projects tends to differ quite a bit from what the the end result is. Agility
of architectural design is generally underrated in my experience.

------
civilian
The ORCA card system in the Seattle area is a great architecture question. You
have a bus/transportation system that has:

1\. RFID cards that tie into

2\. Electronic wallets

3\. The busses are not always internet connected

4\. You need to be able to refill your card either online, or via kiosk.

5\. You also want to be able to refund card balances.

What system can solve this? What drawbacks would the system have? How could
the system be scammed?

Bonus questions are: "6\. The LINK rail allows you go scan your ORCA card when
you get on and get off the train, so you only pay for the number of stops
you're on. How would you include that? 7. ORCA cards also allow for free
transfers-- so if you take a second ride within 3 hours, it will be free. How
would you include that?"

~~~
ben174
Would be interested in a case study on this. Has anyone published anything? My
searches didn't yield much.

~~~
civilian
I'm not aware of anything published about it. My former boss was friends with
an engineer on the ORCA project. :]

------
alphanumeric0
This is specific to my codebase I was interviewing candidates for (heavy OO).
Not all of these concepts are necessary for the candidate to understand, but a
few go a long way towards a great developer experience when applied correctly:

\- SOLID principles

\- The Expression Problem

\- DRY

\- Dependency Injection

\- Composition vs Inheritance vs Delegation

\- Connascence

\- Law of Demeter

\- Invariance, Contravariance, and Covariance

------
luckydude
HN doesn't seem to like mine, but I've always asked "tell me about some
project, can be a tiny shell script, that you did entirely by yourself: the
code, the docs, the install". It has to fit through the filter of nobody asked
you for help, if they sent you a thanks, that's cool, but they need to be able
to install/learn/use it on their own.

If someone is claiming to be an architect and they've never done that, that's
a red flag for me. Kinda like asking a building architect to talk about
framing. You'd be surprised at how many of those guy have never swung a hammer
and they "design" stuff that can't be built. Sort of the same with software,
IMHO.

------
kyrra
As someone else says, it depends on what you define as a "software architect".
A co-worker from a former company that was a "technical fellow" and "technical
director" (effectively an architect, at a 12,000 person tech company), came
over to Google and just has the title of "Software Engineer". From the
companies I've worked at, software architect covers a lot of different job
descriptions.

At Google, more senior software engineers will have a "system design" type
question as part of their interview. There are sample problems for this all
over the internet[0]. For example, you could ask them "Design a URL shortening
service like bit.ly.". When you ask open ended questions like these, there are
so many parts of the system you can dive into that you can really test the
depth and breadth of a candidate's knowledge.

[0] [https://www.hiredintech.com/system-
design/](https://www.hiredintech.com/system-design/)

~~~
delroth
If I remember correctly, the system design interview at Google is for software
engineers candidates of all levels, not only the more senior ones. I was
definitely asked one of these problems when I interviewed as a newgrad.

------
arethuza
What is the role of an architect?

What architectural mistakes have you made in your career - what did you learn
from them?

What architectural decisions are you proud of - how relevant are those ideas
to other systems?

How much code should an architect write?

Have you been responsible for maintaining a complex system that you didn't
design?

~~~
AstralStorm
1 and 4 is matter of opinion. Too many ways to answer it correctly but
incompletely.

Number 2, 3 and 5 is asking about past jobs and may be even illegal depending
on the applicant. NDAs are everywhere. Rephrase them to be generic.

Number 5 is worthless yes/no type of question as well.

~~~
keyboardhitter
Well, I don't think interviews are always about answering something
_correctly_. It might just be nice to have an applicant's opinion on x y and
z, to spark conversation, gain some insight into their personality and what is
important to them, etc. In my opinion, discussions like that can be
invaluable: sure, someone might have all the technical answers correct, and if
so that is great. But humans are more complex than just being right or wrong.
It's also good to see if the candidate has a similar view on the role they
would be fulfilling.

~~~
arethuza
Thanks - that's what I was getting at. I was in a bit of a hurry (OK in a
conference call) when I wrote those questions ;-)

------
pm24601
At Evernote:

1) Peer presentation - talk about past project

2) System design - design at the high level

3) Debugging - given a failing test fix the code so the test passes.

4) Coding - Straight forward problem to code and create.

For the peer presentation, we are expecting the candidate to be prepared. They
have lots of notice about this portion of the interview. We want them to be
articulate and clear about the technical problems, project management problems
and unexpected issues.

System design - we come up with a sample issue that is easy to articulate
quickly. For example, "we are going to design the first version of Wordpress".
We then ask questions and extend the problem during the interview.

Debugging - we give them a random open source project and we break one of the
unit tests. We then ask the developer to track down and fix the issue.

Coding - smaller scale than the System design question but focused on
determining if the candidate can construct a small program end to end. So this
is not a portion-of-a-program, but rather construct a quick command line
program to do X.

For junior people we drop the peer presentation and add additional coding
questions.

\--------

I liked this interview the best of all the places I interviewed. There was no
"gotcha" and the problems I was asked were relevant to Evernote's business.

Walking out I didn't feel like I did the best I should have, (I have high
standards) but I felt the problems were incredibly fair.

Now that I am at Evernote, hands down where interviews go badly are in the
debugging section.

The peer presentation shows people who have not thought about the "why" behind
their coding / design decisions - and it separates the juniors from the
seniors.

Lastly, we expect and can demand a far higher interview performance because we
tell candidates how to prepare. If they don't prepare, it shows soooo
painfully. For candidates that do prepare we can have a more interesting and
engaging interview that allows us to sell Evernote as a company.

------
nichochar
I once received the question: let's architect a web browser.

This was for an interview for backend engineering at uber, so by no means did
I have any particular knowledge or speciality in browser design. Because I
knew the product very well from a user's standpoint, and common knowledge
about web standards, it was really fun and exciting to figure the architecture
out.

Typically the questions revolve more around: "How would you design
twitter/pinterest/facebook newsfeed?"

~~~
huac
I got the "how would you design a news feed" (and similar) for data science
positions as well fwiw.

------
LoSboccacc
Some of my favs when I was recruiting, all meant to probe attitude more than
knowledge.

What was the worst requirement you had to meet?

Where would you store 100Mb user data? 10Gb? 1000Gb?

Preferred deploy to production strategy?

Worst process you followed? ..what did you do to make it better?

~~~
arethuza
"What was the worst requirement you had to meet?"

Thanks for mentioning that one - it means I get to think of a sensible answer
rather than convulsing in laughter for a few moments. It did involve physical
buttons for "Burger", "Beer" and "Porn".

------
tyingq
Asking them to whiteboard out software design thoughts, risks, etc, for things
we all commonly encounter can be revealing. Things like an ATM, slot machine,
bank of elevators, red light cameras, and so forth.

~~~
codr4life
Toy problems get toy answers, you'll learn nothing that way. I couldn't care
less about traffic lights and elevators, and I can code circles around many.

~~~
tyingq
I feel like I learned something through your answer.

------
otikik
\- Tell me about a problem related with software architecture that you find
interesting, and why. Take your time.

\- Tell me some pros and cons of a library or framework that you have used
recently.

\- Here's an hypothetical problem (describe the problem). How would you
approach solving it, from the point of view of software architecture? Please
think aloud and ask questions, the idea here is getting to know how you think,
not necessarily arriving to a perfect solution.

------
KirinDave
Software architecture questions are an interesting topic because unlike
software implementation, you cannot simply give someone a task and ask them to
demonstrate it. Architecture is not just a matter of selecting components,
it's about understanding conflicting roadmaps for multiple teams and available
human talent and technical resources.

My favored approach for it has been to ask people questions that mirror
problems I've been forced to solve in the past at the current venue you're
hiring for. I think this approach has a number of advantages:

1\. You know how YOU solved the problem, so you've got at least some
qualifications to discuss it with authority.

2\. You can answer any and all questions the prospective architect wants to
ask. These questions and their quantity are often even more telling than any
hastily described solution ever could. Do they ask about infrastructure? Do
they ask about expertise? Do they mention specific tooling you yourself
decided on?

3\. This gives them a chance to wow you in a controlled environment. If their
idea for a solution is better than yours, you know you have a very high value
candidate.

4\. This also is a supreme test of technical communication skills. They need
to rapidly get YOU to tell them things by asking questions, formulate an idea,
and then communicate it to you in a way you can understand.

Of course this assumes the interviewer has done some architecture, but I think
that's probably required to do this job right.

Personally, I think all this talk of "war stories" and whatnot is not a very
good idea. If you're concerned about someone's personality and grace under
pressure, you should treat that separately from their technical skills. That
way you can weigh those attributes separately and fairly when it comes time to
decide if you will hire the candidate.

------
siliconc0w
Give them a sample, 'The company you thought you're interviewing for is just a
smoke screen, we're actually a stealth startup for a social network for pets"
and have them diagram out how it might look for a MVP launch, 2 years in, 5
years in. What technology choices, how are they going to launch
internationally, scale to hundreds of millions of pets, how are they going to
achieve sub-second latency for the FindMyPet API, high-availability, do
operational and business intelligence monitoring (and which BI metrics would
he care about), unifying code across multiple platforms, etc.

Most importantly they should light up when they get the question. Like someone
just sat a piece of cake in-front of a fat kid.

------
MrQuincle
Nice for the reading list:
[http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

Practical overviews of design decisions in familiar open source software. I
wish there were books like that!

~~~
cableshaft
These look amazing, and some really high profile projects as well (Asterisk,
Audacity, Eclipse, LLVM, Mercurial, Git, GDB, MediaWiki, etc). Thanks for
that! I wish there were more books like these.

------
sulam
One of my favorite:

You have written some code you'd like people to be able to reuse. Should you
share it as a library or expose it as a service? Talk me through how you'd
make this decision for a few cases and what the pros and cons are for each
choice.

------
femto113
For architecture I prefer to just ask for input on an actual issue my org is
currently facing. Perhaps abstracted a bit to make answering less of a slog
through details but I don't see any advantage to using some made up scenario.
By using current issue I'm in both a good position to interact on the subject
since its top of mind and get a sense for the relevance of the candidate's
experience and/or their creativity. Also means I don't need any better rubric
for evaluating their answer than "if I'd heard that in a meeting today would I
have thought 'oh there's a good idea...'"

------
joeld42
I ask them to design a structure for a card games that uses a standard deck of
playing cards, and how they would implement shuffle (not the algorithm itself)
and dealing and hands. This is simple. People manage to grossly over engineer
it.

My ideal response would be one struct with nothing but a suit enum and int
value. A deck is just an array of these, as is a hand. But usually people
start with a deck class, then try to reuse that for the hand, discard pile,
etc. Things get complicated quickly, just like in real world problems, and a
good architect can keep that in check while still providing useful
abstractions.

------
nunez
Ask them about a project they did. Let them talk. Ask questions about minor
details that seem interesting and (hopefully) relevant to the position you're
trying to fill _especially_ when part of their explanation is hand-wavy
("yeah, we used Kerberos because that seemed like the right thing to do."
"Why?" "I tried other things. They didn't work." "Why?" etc.)

Ask a bit of trivia about the stack you're hiring for. They don't need to know
the right answer, but their reasoning about it should corroborate with their
experience.

------
paulie_a
I have been through a few recent interviews and the technical questions seemed
like they were from a college exam.

My advice is to see how they operate... Give them a problem, even a vague one,
but then solve it together, have them use google to seek out ideas. See how
the person approaches it, don't expect a bunch of memorized answers off the
top of their head.

The big thing is to see what questions they ask. How will you and the person
collaborate in a normal working environment.

The personality and adaptability are far more important than memorizing the
exact command line or function call.

------
jgalloway___
Looking over their public work experience and perhaps open source
contributions you will already know if this person will be a good fit.

When tasked to interview I have found that asking a question which you know
the candidate will be unable to answer will show you the most-intriguing parts
of their character. Something deceptively simple like a puzzle or logic
problem but scales up quite quickly.

This is when you can learn things about them that they would not put to paper
and thereby determine if they are for you.

------
neeleshs
My favorite way is to start with a very vague design question, with no
expectation of any predefined answer. Then I try to make it a discussion, see
if the candidate asks more questions, pokes around, can think in terms of
abstractions - I don't expect any of it to match my own thought process.

Another question is to pick a project they've worked on, and ask them how
would they do it if they were given a clean slate.

------
nicostouch
Give me an example of a violation of the Liskov Substitution Principle that is
not the canonical Rectangle/Square example.

------
bsvalley
Your question is too broad. Which industry? Which type of products? which
technologies are you referring too?

------
paulkearney
I'd go with:

'What do you expect to be involved in as a software architect and what can you
contribute?'

and take it from there. If you are interviewing for that role then surely what
they do in the context of your organisation is key and open questions help you
understand whether the person is a fit for that.

------
jblow
It's not specific questions that are important so much as the process. You
want the questions to be tailored to the candidate.

See this example:
[https://www.youtube.com/watch?v=cfyWvJdsDRI](https://www.youtube.com/watch?v=cfyWvJdsDRI)

------
technophiliac
How do you communicate your "design" to others (stakeholders, developers, ops,
sec, etc)?

------
drharby
"If you were the size of a quarter and trapped in a blender, how would you
reconcile having a dime-sized 'package'"

I forget the blog, but it was from an unused script off of silicon valley,
interviewing for a new CEO of PP.

------
cromulent
One of the twelve principles of the Agile Manifesto is "The best
architectures, requirements, and designs emerge from self-organizing teams."
Does your style of architecture fit well with self-organizing teams?

------
gayanhewa
One of my fav is to ask their preference on Composition vs Inheritance. It's a
fundamental question that will give you lot of insights on how they view
building applications to last.

------
donretag
Please implement on heap sort on the whiteboard.

Let's face it, we would all love the meaty architecture questions, but most
interviewers are still stuck on the CS101 algorithms.

------
z5h
How could you detect possible plagiarism between documents in a large DB of
documents?

Given such a system, how could you process a document to subvert it?

How would you fix the system?

How could you subvert the fix?

...

------
tootie
"How do you come up with estimates?"

------
itaysk
I've written about how I interview here:
[http://blog.itaysk.com/2016/07/07/how-i-
interview](http://blog.itaysk.com/2016/07/07/how-i-interview)

------
b4xt3em4n
Who pays?

~~~
SoulMan
Yes but only @ 75 percentile .

------
british_india
Tell me about a technology you were initially excited about but that later you
regretted using?

~~~
arethuza
I'd be tempted to reply "All of them" to that question :-)

