By Praveen K Jha, Principal Architect, GlobalLogic
Summary
Hiring a good software architect has always been and still is one of the most important decisions for an organization that has anything to do with software development, testing, deployment, or related streams. The interviewer is required to evaluate not just the soft skills, including soft technical skills, but also the on-ground hardcore demonstrable architectural skills. This blog post talks about each of these areas and how to assess during that short discussion with a prospective candidate. Some of the soft skills and soft technical skills aspects may be used by Talent Acquisition (HR) members as well when they first happen to speak with potential candidates over phone or video. The blog post also tries to put together a few sample points for discussion with a potential architect based on the length/duration of the conversation with a candidate.
The titles
Different software services and product organizations happen to have different titles or designations for software architects. A lot of times, the title may not really give away what a software architect may actually be doing or expected to do. I am sure we have all come across titles like Technical Architect, Software Architect, Systems Architect, System Designer, Solutions Architect, Network Architect, Technology Architect, Application Architect, Integration Architect, Business Architect, Data Architect, Enterprise Architect, Security Architect, Cloud Architect and a number of other titles. While each one of them may have specific job descriptions that may be confined to a specific domain, area of influence, skillset, etc., the general skills do not vary a lot.
While most software and IT organizations in the services sector may wish to hire architects with a broader set of skills, understanding of a wide technology horizon, and most importantly, fitment as a generalist, interestingly, a lot of software product organizations may like to hire architects for very specific needs and hence they generally prefer specialists. So, in my opinion, we should not get carried away by the title or designation for a job position that may have been posted by an organization. As an interviewer, it is best to go through the job description to better understand what will be expected of a particular job position rather than assuming certain roles or responsibilities based on job titles and then, wrongly, interviewing candidates according to that (mis)understanding. This article especially focuses on hiring a software architect in the product development team. Hiring a network architect or a system architect or, for that matter, solutions architect is not absolutely too different in general, except that the specialization around infrastructure, solutions, or technology stack may vary widely.
The hiring managers and the problem with job descriptions
Probably, one of the characteristics of most software architects, including myself, that I have observed is being an individual contributor. The vast majority of software architects are likely going to be (obviously) working with the teams but may still be a loan worker when trying to sort out problems and create blueprints of a system (more on that later). A side effect of this characteristic is that the job description for a job position of a software architect is likely going to be written by someone who may have asked for inputs from one or more existing architects on various teams. This person, in most cases, is the hiring manager who may also have added a lot of other bullet points as a must-have, nice-to-have, and bonus-points on the job description before sharing it with the talent acquisition group (HR) for posting on job sites, social media sites, etc. The problem is that most of the job descriptions for a software architect that gets posted on social media sites or job sites are just way too lengthy and may have wish-list items as a part of the same. As an interviewer, it may be helpful if we directly speak to the hiring manager or existing (junior or senior) architects of the team for whom the job posting has been done. The job description may not be very helpful in some cases when it asks for all the must-have skills and qualities that seem just way too perfect to be found. So the question is, what really are the skills an interviewer should be looking for?
The Recruiters
In the vast majority of the cases, when an architect gets hired after having undergone multiple rounds of discussions, at least one architect would have been involved at some point during these conversations with a prospective candidate. When beginning to hire, recruiters are the first point of contact for a candidate. So, for an organization, it makes sense to spend some time making our recruiters aligned with what to look for. One of the things that generally works for me is to directly talk to the recruiter and tell him or her what am I looking for in the candidate. I also try to explain the job description in terms of technology or architectural expectations. However, one of the best things a recruiter can do is to perform a basic fitment screening of the candidate. We generally help the recruiters with a set of screening questions that they can ask the candidates when they speak with them after the candidate’s resume is selected. For solutions architects, these screening questions could be as simple as “How do you keep yourself updated on the latest in technology?”. If the candidate talks about various well-known technology and architect blogs, subscriptions to well-known reports, or even following some of the well-known technology companies, the candidate gets a thumbs up. Similarly, questions like “Can you explain to me in the simplest terms the architecture of any sub-system that you may have recently designed?” should elicit a response so that recruiter can at least understand what the candidate implemented. A good architect in product development should be able to explain to all kinds of audience – from CTO, CEO to a developer, manager, and recruiter. I also encourage my recruiters to ask questions about security, OWASP top 10, and some basics of cloud engineering. Some of these questions have straightforward answers where we don’t expect open-ended responses from the candidate. Recruiters also share the candidate’s responses along with their feedback with the panel members.
The Interview
When interviewing for software architect roles for product development teams, when the discussion with the candidate begins and introductions are done, I ask if the candidate can describe the architecture of any system or sub-system that they may have designed, which was challenging for them or they enjoyed doing it. If we do this over remote video calls, I let the candidate share their desktop screen if the candidate is comfortable doing so to be able to explain better while drawing the design. When the discussion happens in-person, a whiteboard becomes a great tool to discuss and talk about the “what”, “why”, “how” and “where” of the various components and component boundaries. In general, an architect is expected to be very comfortable putting the designs on a whiteboard or documents that show how the architecture addresses not just the functional requirements but also the non-functional requirements (NFRs) like security, performance, availability, scalability, etc.
We also expect the candidate to be able to explain it well enough to make the (lack of) domain knowledge an ignorable fact. Domain knowledge is definitely important but as a software product or solutions architect, the expectation is to be able to switch to different business domains and still be able to apply the architectural knowhow to do it right. Good architects generally do not take a lot of time to learn new domains. Some of the choices of technology stacks can be driven by a specific business domain but otherwise, it should not matter.
I also tend to ask them or suggest alternative solutions to the approach that a candidate may be describing on the whiteboard or on the shared desktop screen. It’s important to see how a candidate responds to alternative approaches. Good architects may counter-question, discuss, and actually evaluate the alternatives for its pros and cons. Not-so-good architects may just outright reject the possibility of alternative solutions or may just continue to emphasize that the solution they have sketched out is the best.
We also note if the candidate really knows the technology stack that he or she is talking about. For example, we come across many candidates who may just throw jargon around cloud services (AKS, AKV, EKS, S3, EC2, APIM, etc.), security (XSS, XXE, etc.), styles (BFF, pub-sub, REST, blackboard, etc.) or design patterns. When you see a lot of jargon in the discussion, it’s important not to fall for those. We ask the candidate, for example, to talk about how would they ensure that RESTful APIs are being developed by the team under their guidance. If they fail to mention about standard maturity models and can’t differentiate between REST and RPC, we know that we are dealing with a jargon-architect.
I also prefer scenario-based questions. It’s very important that we present a scenario based on what the candidate knows and various skills noted in the resume. We should not try to fit a candidate into an unknown scenario only because we need that as part of our job description. If the candidate is able to cover the scenario well enough, can explain the design aspects reasonably well, can talk about communication across modules, sub-systems, can foresee the security threats to some extent, likely we may be speaking to a good potential architect to join our team. However, if the candidate keeps digressing, keeps talking about various options but does not detail out any of them, can’t relate to risks, and cannot talk about trade-offs – we may just be wasting our as well as his/her time. It’s best to politely wrap up the discussion and preparing for the next candidate.
I would also expect a software architect in a product development environment to be current on various architectural styles and patterns. So it is only natural to ask the candidate to explain various architectural styles and patterns. You can probably choose a couple of them and ask which ones may be used under what scenarios. Try to go deep into any one of the chosen pattern that the candidate may be comfortable in and may have demonstrable experience. For example, if the candidate claims to have worked and implemented microservices, it’s wise to ask about SAGA, correlation ids, troubleshooting aspects in terms of logging/tracing, etc., security and deployment mechanisms.
Defending an architecture/design is as important as considering multiple alternatives. Many a time, even a good architect may not be able to defend a design well enough and may just go on backfoot and begin to accept whatever you may be suggesting. That’s a warning sign even if the candidate has otherwise fared really well. This is because we do not want an architect who goes back on his/her design the moment a question is raised pertaining to the design recommendations. Likely, all architects in your team are going to be facing all kinds of stakeholders, including customers, at some point. It is not a good trait in an architect if one is not able to defend the design and falters at the slightest questioning. We want to hire good architects who consider various options, evaluate the pros/cons of all options, talk about those and if those options are not good enough, defend the decisions while still defending the original proposal in terms of design and architecture. The architect should be able to convince the audience why a given architecture really meets all the needs and protects all concerns.
When we talk about convincing, there are several other factors that come in. Soft skills are something that all architects are going to need to have – a lot of it. The tone when your architect speaks with the team, the reasonings used during the discussions, the authoritative aspects (or the lack of it) during brainstorming sessions and debates, and being able to convince others in favour of a design or proposed architecture – all of these are very important. Eventually, all of us are human beings. A software architect, even when it’s likely an individual contributor role, will need to interact with teams on a daily basis. They will need to talk to team members, clients, managers, IT infra professionals, security folks, and their counterparts in different roles quite frequently. So it is very important that we see if the candidate is good at communication. Is the candidate excited when talking about various design options? Does the candidate sound confident? Is the candidate using a lot of fillers during the discussion? How does the candidate respond when counter questioned? Watch the candidate’s tone and choice of response when you suggest alternatives. While all of these are important, we also need to keep in mind that we can’t expect someone to be an expert at everything. It’s always reasonable to be open for “some” leeway. After all, everyone can improve if given the right opportunity and guidance.
As an architect, we also need the candidate to do a lot of code reviews, assess the system state, conduct advisories, document reports, conduct interviews, guide junior technology team members and be their mentors, present to small and large audiences, evaluate the open-source and off the shelf software packages, read through large codebases and write quite some good code. So it’s imperative that we evaluate the candidate on some of the most important ones if not all (it’s impossible to evaluate someone on all aspects). Some of the most important ones that I focus on are being able to write code, mentoring, and evaluating software packages.
Every architect should be able to write code. The code that an architect writes should generally be one of the best that the team writes. An architect will likely need to get the initial structure of the codebase right, translate the proposed architecture in the document to the code structure in the IDE that the team is going to use. So it’s very important that the new architect that we hire writes good code, understands unit tests, the importance of various development methodologies, CI/CD and DevOps, and the importance of maintaining quality when reviewing codebase. We are not looking for someone who does coding even 50% of the time – that may be just too high of an expectation from an architect. Any candidate who can demonstrate good coding knowledge, understanding of a couple of programming languages, and can code even 10-15% of the time, or even occasionally, that should be acceptable. We do not, however, necessarily want to mandate that the candidate be current on all language features.
Mentoring is another aspect where you may wish to ask scenario-based questions and try to gather if the candidate’s mentoring approaches are good that fits your organization’s culture. It should neither be too radical nor too lenient.
When talking about the evaluation of software packages, see how the candidate decides to choose or discard the packages. Is the sole criteria number of stars or forks on the GitHub repository? If that’s so, it may be a warning sign. You’d like to hire candidates who do not just get influenced by the number of stars and forks on an open-source repository, but one who can download, look through the code quality, assess open issues, look at the package backlog, run through security features and can assess the maintainability of the package. It is not too uncommon to find a team who selected an open-source package that has a license that may not be suited for a customer or another open-source package that just did not have enough developers on the team to maintain it or the package has been lacking all security vulnerability fixes for months or the reported issues remain open and nobody responds to those for weeks. An architect should be able to assess on a 360-degree before one decides to choose and go ahead with a certain package and only after conducting all the due diligence.
Conclusion
Easier said than done. A half an hour or even one hour window may be too short for evaluating a candidate on all of these aspects, but you do not necessarily wish to put a checkmark against each. The potential is important, not the credential. I hope the guideline will be helpful for many interview panel members as well as for the candidates.
Happy hiring!
