Interviewing architects
October 12th, 2008 by Jiri
I will soon be saying ‘I just came to tell you that I’m going’ (maybe I’ll even try to do that in French) to my current enterprise architecture role and the great city where I’ve now spent almost two years. But before that happens, I need to hire myself a replacement.
Choosing a good person for the job is important from many angles, so it is worth getting it right. That’s why I like to read on this subject and always look for opportunities to refine my interviewing technique.
The difference between hiring employees and contractors
The main difference this time around is that I am looking for someone to work as a permanent employee, which gives the whole selection process a slightly different perspective:
- When hiring contractors, I am looking for relevant knowledge, skills and experience directly related to the job at hand. Life is too short and project cost per hour too high to be getting someone up to speed on SAP CRM functions, intricacies of ADO.NET, or developing their project management skills. My main objective is to get the work done as quickly as possible.
- On the other hand, when recruiting permanent staff, you are starting with an assumption that the person will stay around few years. During this period, there is going to be at least one generational change in the technology area of choice and the person will participate in a number diverse projects. This means that the candidate needs to have roughly matching skills, but more importantly, he or she needs to be able to learn and adapt to change.
Knowing what you are looking for
After the first round of interviews I’ve done at the end of September, I had a phone call with a lady from a recruitment agency supplying our candidates quizzing me on our criteria for short listing one person over another. After a while, I came up with something as follows:
Firstly, I rank the candidates allocating a number of points to various skills and experience categories. Obviously, the type of things you are looking for are job related and will differ between Java developer, technical manager or network architect and it is not my point to cover them here. For instance for my replacement, I allocated the points as follows:
- Up to 30 points - technical & architectureal knowledge (ten per category: application technology, infrastructure and security/continuity, focus on real world experience, extra points for knowledge of formal methods)
- 20 points - getting things done (personal effectiveness in the given context)
- 10 points - delivery experience (worked through all delivery stages from project inception to deployment and operations)
- 10 points - sales experience + consulting skills
In addition to that, I checked for few (dis)qualifiers:
- capability to adapt to change;
- systematic approach to problem solving;
- communication skills;
- personality and working traits compatible with a role.
The real trick for doing an interview is how to find all of these in below two hours. This require to know pretty well what you are looking for and use a mix of different interviewing techniques to check for only the things you are after. I now aim the interview to cover three areas: skills and experience, job compatibility, and few other general things like problem solving, flexibility and professional interests.
Skills and experience
Unless you are in show biz, it’s not a good idea to hire someone just for their personality. When hiring architects, technical and other subject matter skills do matter and that’s why they are the first thing I check. I do this normally through the ‘talk me through your CV’ approach, digging deeper into relevant responsibilities or technical skills using STAR Interview Method.
Job compatibility
When I was interviewing developers last time about two years ago, I was impressed by my co-interviewer pulling out a list of several personality-oriented questions. For a while I enjoyed using them to grill the candidates, but since then I learnt to do this sparingly as it is way too easy to make someone feeling really bad by pushing without finding too much. Sure you will probably learn how they cope under a pressure, but unless this capability is essential for the role, the chances are you are losing time in an interviewing that you can spend on more worthwhile subjects.
So rather than pressing the people with tough questions, I now prefer to quickly go with them through a list of more general questions looking at how they think, motivate themselves and at their working habits. These questions will help you confirm the candidate will be able to do the job, but also that he / she will be happy to do it, which in turn influences their staying power.
Problem solving, capability to change and professional interests
When I started preparing for my recent interviews, I reviewed and used a subset of Steve Jones’ excellent Questions I like to ask at interviews. Steve has some very good pointers that will help you find out about the candidate’s professional side that you are unlikely to understand through other ways of questioning.
Be prepared and quick
As I mentioned there are quite a few things to find out, so the key is to be really prepared and if you move through the process swiftly. I have found out that if I stay focused, such interview can be done in just about two hours.
I don’t have any statistics, but I do believe that if you listen and observe carefully, you get a better all-round view of the candidate and can make up your mind on both his short term and longer term suitability for the job.
As a parting thought, I think it is worth approaching interviewees as if they were your friends or colleagues. Job hunting is not the one of the most pleasant life experience and the chances are it will be you sitting in the interviewee chair next time around.
Hmmm…. Pity you posted this after our chat in St-Cloud
Big trouble is that architect’s (and especially enterprise architect’s) function is not yet as “transferable” as C# developer’s or a project manager’s.
In the absence of a wildly-accepted industry-standard definition of EA making sure that you have some common understanding of the sheer term of “EA” is unfortunately enough not a futile precaution…
[…] Last time I gave a broad outline of the template I use to interview architects. As the interviews are now […]
[…] StrategyDriven Podcast Special Edition 24 - An Interview with Jim Champy, author of INSPIRE! : StrategyDrivenInterview Techniques - The Truth | Irish Job News - News on Jobs for IrelandInterview with Nicholas C. Zakas | JavaScript WorkshopEnlightened Self-Interest » Blog Archive » The Art of The Interview QuestionJiri’s Notepad » Blog Archive » Interviewing architects […]