Guerilla Interviewing Architects

http://dilbert.com/strip/2001-12-10

Hiring great people is laborious. You have to hunt so hard to find those with the right blend of experience, cultural fit and ambition. Of course hunting is hard only if you are selective about the type of people you want to hire. Great people are hard to find; if you are just looking to add numbers then it is remarkably easy.

Most of the hiring process will boil down to a number of interviews. These are vital to uncover omissions, gaps and bad smells with candidates against your chosen bar. I want to share what I look for when hiring architects. Software architects that is, not those who design buildings for a living. This is a relief because as a CTO I wouldn’t be much good at sussing out building designers. Why architects? Well they are senior and have a major role making decisions about how the software product is built. Poor architecture decisions can result in a failed software product. Or a software product that you will pay for over the next 10 years. It pays to hire the right architects.

Rory on Architecture

What type of architect are you hiring? Which one of the 20+ different types of architect is it you are seeking?

Maybe a Technical Architect?

Broader. Solution Architect?

Too junior. Senior Solution Architect?

More grey hair. Principal Architect?

More holistic. System Architect?

…

There are more, many more.

Specialist: Application Architect

More Specialist: UI Architect

Just Hosting: Infrastructure Architect

Loves abstractions: Astronaut Architect

Focused on system integrations: Integration Architect

King of architects: Enterprise Architect (some say the pinnacle of architects though most of those who say this are Enterprise Architects)

Apps: iOS Architect

InfoSec: Security Architect

Certified: TOGAF Architect

This is a big part of the challenge when hiring architects. There are so many different types. And worse than this one company’s technical “architect” is different than another company. Oranges are often compared with apples. So try and be clear with yourself before you begin about what characteristics and experience level you are looking for.

And be very clear what architecture is and what architects do. You could do worse than visit Wikipedia to begin with,

a software expert who makes high-level design choices and dictates technical standards.

But if you want to go the top of the class with a more considered view of architecture and the role of the architect you should study Rory’s explanation:

An Architect is someone with sufficient experience to make decisions and guide others in the right direction, balancing dogmatism and pragmatism, know that they don’t know everything, understand that they have more they can learn, and above all else understand how they can use others experience and knowledge to guide their decision making.

Joel on Software

Ten years ago Joel Spolsky wrote The Guerrilla Guide to Interviewing. Kinda hard to believe this is TEN years old but it contains some cast-iron advice for hiring programmers. Maybe = No is a golden rule. Smart and gets things done is non-negotiable. Both of these apply to many roles beyond developers. But of course with developers we can ask them to write some code or explain some code in an interview. With architects it is more tricky because you can’t easily ask them to design something.

And yet there are many questions you can ask that reveal so much about how your candidate architects thinks, designs, works and learns. It is vital to see how an architect draws since most designs are communicated as drawings or diagrams.

So what are the red flags that I look for? Once you find red flags you become a Maybe. And as Joel said Maybe = No. But that’s so very negative. There are lots of positive signs you secretly hope for. These signs give you an impression of what the person will be like if they work for you.

Eject, Eject, Eject

Turning down candidates does not guarantee they are bad candidates. Or bad people. It just means they won’t fit in well within your organisation for the role you need. So be very clear what your culture is and where your hiring bar sits before you begin hiring.

Cutting interviews short can give the wrong impression to candidates. You may not give enough time for them to realise that they’ve missed your hiring bar by a distance (without you telling them). It is much easier for everyone if the candidates realise this before you reveal it. And so if you find any of these you should be thinking about pressing the eject button. In a nice way.

1. No architect experience. Seriously. This happens typically because of a failed screening process. Tighten up your screening.
2. Unable to explain what an architect does. Imagine hiring a doctor who didn’t know clearly what doctors do. Would you trust this doctor with your healthcare?
3. Poor communication. If an architect can’t communicate clearly and succinctly to you in an interview this is unlikely to improve in a team. Architects should be able to fluently speak the language of real people (“business people”) and technical people.
4. Hybrid engineer — manager — consultant — architect — do anything experience. The depth of experience is typically missing if someone hasn’t been focused on an architect role. And no depth will mean questionable decisions.
5. No experience at the level applied for. This is common because lots of folks wants to gain a promotion by moving jobs. I prefer to reserve this privilege for staff. External hires are hired for what they have done not what they could step up to do.
6. No desire to learn, evidence of improvement or keenness to collaborate. Software is a fast-moving profession. If you need to hire COBOL programmers then this is less relevant. But architects need to be continually moving with technologies.
7. Thinks Architecture = Selecting Technologies. Technologies are easy to select. How you use these technologies (design) is much harder. And if your candidate architects hasn’t done design or appreciate design then you should walk away.
8. Hasn’t written any code. Ever. Architects cannot make good decisions about software design without understanding code and engineering.
9. Astronaut Architects. But if you stick to the smart and gets things done you can quickly spot the astronauts.
10. Can’t describe drawbacks to technologies or when not to use them. Those architects who have read the website splash page of a technology can tell you all the situations you should use them but not when to avoid them (because websites don’t usually advertise this). If someone can describe when not to use a technology there is more chance they’ve used it.

Remind me, What Should I Look For?

Look for as many of these as can be crammed into one human.

1. Clear, succinct verbal communicator not wafflers.
2. Simple, clearly drawn and explained logical and physical design drawings. Architects who can’t draw well won’t be able to do their role.
3. Experience not theory. Architects love to talk about what they could do — I am more interested in what they have done (and not done) and why.
4. Decisive not procrastinators. No point being a decision-maker if it takes an age to get to it.
5. Considered decision makers not rash decision makers. Are they aware of the technology risks before proceeding — even if they take these risks?
6. Whole stack experience not specialists such as front-end, web, back-end, data and integration only.
7. Greenfield architecture experience not maintainers. Have they experience building a new solution that was started with a blank page. Many architects have only had experience maintaining an existing architecture.
8. Simplifiers not complicators. Does the person strive to make things simpler or are they prone to complicating things?
9. Learners not stagnators. Is the person eager to learn and has applied their learnings?
10. Engineer-Architects not Process-Driven Architects. Architects who are current engineers or have been recent engineers. They need at least to be able to understand and write code. Just remember in a hackathon I’d expect the engineer-architect to be outpaced by any software engineer.
11. Someone who knows what good code looks like, and what a good OO design is beyond just “abstraction” and “interfaces”. Someone who knows what SOLID means (even if they can’t remember what the acronym stands for).
12. Evidence of building others, taking ownership, getting results.
13. Evidence of overcoming challenges.
14. Evidence of influencing senior people.
15. Evidence of self investment, training or learning.
16. Evidence of working with a development or ops team to design, deliver and validate architectural decisions. Including retrospective actions on feedback.

Making Mistakes

And yet there is no guarantee of successful hiring. Even if you follow everything I’ve said you may still reject the right person (no big deal since they will get another job) or worse accept the wrong person (always painful when it doesn’t work out). You have to work hard to integrate new hires into your teams and your culture. But I hope lessons I have learned will help you in your search for the right architects.

We’re always on the look out for great architects who want to work with us to build great software that meets user needs.