Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

How to Get Hired (or Promoted) as a Software Architect

Cristian Bojinca

This article is taken from Cristian Bojinca book How to Become an IT Architect and is reproduced here with permission from Artech House.

So far, this book has given much of the information required to make a decision and then to prepare yourself to become an architect. Starting with what it means to be an architect, what kind of architect jobs exist, what background and skills the architect needs, and what deliverables he or she would produce, it has slowly guided you to a point where you have all (or most) of the knowledge required to become an architect and you are actively planning to change your career and become an architect.

How to Get Hired (or Promoted) as a Software Architect

Becoming an architect does not necessarily mean that you must leave your job and start looking for a new one. Most of the time, people transition successfully into architect positions within the same organizations. This is a win-win situation for both employer and employee. The most important asset you have when employed with the same company for a long time is business and culture knowledge. Organizations try to retain long-term employees by offering them promotion opportunities because they have demonstrated that they can successfully do the job but also because they possess business knowledge and intelligence.

Many organizations have a slogan in some shape or form stating that people are their most important asset. When  something is important to you, you usually take care of it. Some organizations try to keep people happy in their jobs either by providing training or promotion opportunities, growing the people in the current role or in a different one. If this describes your organization count yourself lucky. You must work hard, but at the end of the day (or after a few years) your long-term goals will be realized. For the purpose of this book, we will consider that your long-term goal is to become an architect, one of the “big guys” who make the difficult decisions that influence the long term development of the application, infrastructure, business, or the whole enterprise.

If you are not one of the lucky ones and your organization only looks at you as disposable asset that can be replaced at any time, things are more challenging. If you still want to fulfill your dream of becoming an architect, then you need to start thinking about leaving the company and finding a job as an architect somewhere else (hopefully where your skills and loyalty will be more appreciated). I know it is not easy and it is a lot of hassle to move to a different job (especially if you have been in the current one for a few years), but there can be quite a few rewards when you find a better fit.

Show Them What a Great Asset You Are

Regardless of whether you are promoted or apply for a new job elsewhere, you must look at your situation from the employer’s point of view. Try to wear their shoes (not literally) and prepare yourself with the answers that the employer needs. Apart from the obvious, being prepared and having the right background, skills, and competencies to do the work, what extra quality, the proverbial “cherry on top,” should make them hire you instead of somebody else? All (or most) of the candidates who apply have what they need to do the job, but being picked as a successful candidate might be because:

1. You have confidence in yourself. As Theodore Roosevelt said, “Believe you can and you’re halfway there.” Some people might argue that confidence cannot replace knowledge, experience, and other factors enumerated next, but having confidence goes a long way. Interviewers (usually) do not know you, but seeing how confident you are in your abilities to do the job will put you halfway there. This must be backed by knowledge and experience (and any sign that you might lack them would make you quickly lose the interviewer’s trust), but showing that you are confident in yourself and you can do the job is one of the best ways to actually get the job.

2. You demonstrate that you already understand the job (even before you start) including not only the obvious (e.g., produce the architecture deliverables) but also its challenges. Read and reread the job description and try to find clues about hidden challenges. For example, perhaps the architecture team does not have a strong foothold in the organization or the senior management is not yet convinced the organization needs architecture (or another architect) because they do not really see the benefit. Some of these issues might come up in the interview and you have to steer your answers and demonstrate that you have successfully dealt with this kind of issue in the past and helped your organization to solve them.

Behavioral questions are a great way to show this. Many people look at them as a necessary evil but they are actually a great way to sell yourself by using the clues mentioned before to tailor your answers and demonstrate that you can deal with these kinds of situations. Nothing gets you closer to the job than planting the idea in your interviewers’ heads that you can do the job from day one. One might ask how you can do this as you do not know anything about the team, the culture, and (not much) about the organization. However, none of the other candidates (unless they are internal, which is a different topic) know anything about these either, so even knowing a little bit or inferring this from these clues will put you in front as the main contender.  Even if you do not have a lot of architecture experience, read a lot and try to understand how the problems you dealt with can be translated into architectural problems. For example, if you are a lead developer and you designed a certain application, stretch your thinking and be prepared to show how you can provide the architecture for the entire system based on the nonfunctional requirements.

3. You demonstrate that you are a good fit for the team. Again, some would argue that you cannot do this unless you know the team, but no matter who the team members are, there are certain things that would make you desirable to the team. The most obvious thing is that no one wants a grumpy teammate who is only interested in his or her success and does not collaborate well with others. Having conflicts is inevitable, but having them all the time is a sign that you might have a problem. One of the behavioral questions will most certainly be about a time when you had a conflict with someone (sometimes nicely hidden under the “had to work with someone difficult” form) and you have to provide an answer that shows that you can handle conflict in a professional manner. As with any behavioral question, the answer has to include a real example without focusing on the emotional side. My recommendation is the use of the STAR (situation, task action, result) format, describing the situation or task, the approach (key actions you took focusing on how you resolved the disagreement in a professional and productive way), and the results [happy ending: description of the positive outcome(s) of your actions]. This would make the interviewers understand that you have resolved quite a few conflicts in a diplomatic way and that therefore you are the best candidate to quickly integrate into the team.

One of the worst things is to give the impression that you are one (even if you are) of the geeks who is perfectly able to produce deliverables in his or her architecture ivory tower (isolated from the rest of the project team) but has real problems interacting with others in the team or organization. Somebody who cannot collaborate will only bring problems to the team and organization and will not be able to do the job properly. As explained previously, the architect role is not about being a hands-on coder who sits at his or her desk the whole day but involves collecting information from various stakeholders and selling your product (the architecture) back to them.

4. You are able to adapt quickly to job specifics. This might sound like a reiteration of a previous bullet, but, again, there might be some ways to put yourself at the front:

  • The organization might use a home-grown architecture framework or methodology. During the behavioral part of the interview (or whenever you might have a chance), you have to show that you can quickly adapt and be productive using that specific framework, eventually giving examples of how you already did this in the past.
  • The organization might use legacy applications and technologies and they are looking to you to help them to migrate to a new platform. Again, you should be able to emphasize that you can quickly adapt to this environment, assess the situation, and make a plan to bridge the gap. Give examples of how you did this in the past even if it might be about a senior developer job when you had to migrate from an old programming language to a new one or if you have an infrastructure background when you had to migrate from an old vendor product to a new one.
  • • The organization might have a custom architecture process that is not efficient and needs to be improved. This might be about the way the architecture governance (including compliance, waivers, and so on) is enforced or about architecture checkpoints. For each of these cases, you must come up with examples of how you were able to improve similar processes in your previous jobs. This might be about the architecture or about improving the code review process or the business requirements collection.

5. You can make a connection with your future boss. You two actually click and he or she feels that you are quite familiar. This is another big advantage as you actually break the “new guy” barrier. Try to empathize with your future manager (he or she might be or have been an architect in the past and might have experienced similar problems) and to “walk for a day” in his or her shoes (do his/her work and experience his/her work-related problems). What is that you two have in common and what would bring you closer? It might be about trivial things like common hobbies, but usually it is about working in the same domain for years and being able to understand the joys of the job but also the pains you have to go through.

6. You have the training/certifications and you keep yourself updated on the latest trends in architecture including new frameworks, methodologies, best practices, and patterns. You may note that this is at the end and this placement is deliberate. As mentioned in many other places in this book, being an architect is not only about having the technical knowledge and demonstrating this by taking various certifications but also about having the soft skills required for you to succeed, such as leadership, communication, negotiation, and more (for a complete list, refer to Chapter 5). Obtaining a certification would most certainly put you in front, but the other factors mentioned before will usually have a bigger weight in the hiring decision. To sum up, my advice is to take certifications but not to see them as the most important factor. In my experience, I have seen people who were doing a lousy job as an architect but were continuing to pile up certification after certification thinking that the more they got, the better they would do as architects.

Excelling, or even doing a little bit better, at any of the factors enumerated before would most certainly help you to get the job. There are a lot of other factors that could influence the final decision (such as the hiring manager already having a preferred candidate), but you can only do your best to impress and to convince the interviewers of what a great asset you can be for the organization in the architect role.

Software Architecture Resources

UMLZone: Unified Modeling Language (UML), Software Architecture and Data Modeling

Related software development articles

Chop Onions Instead of Layers in Software Architecture

Simple Sketches for Diagramming your Software Architecture

Communication Tips For Software Architects

Click here to view the complete list of Methods & Tools articles

This article was published in February 2018

Methods & Tools
is supported by

Simpliv IT Courses

Software Testing

The Scrum Expert