There is no standard definition for the “architect” role in the software world. It could have very different meanings at different companies. Some teams think it is a role where you spend most of your time in high-level, abstract system design, while others consider it a hands-on role that exemplifies mastery of specific languages or applications.
There is no standard definition for the “architect” role in the software world. It could have very different meanings at different companies. Some teams think it is a role where you spend most of your time in high-level, abstract system design, while others consider it a hands-on role that exemplifies mastery of specific languages or applications.
Architect, like many other terms such as Big Data or large-scale, leaves plenty of room for interpretation. Here are some general, common expectations of someone in this vaguely defined role, based on a discussion thread on LinkedIn:
Required background and experience
- Architects usually have broad experience in software development
- These people generally have in-depth experience working across an entire stack and throughout the software life cycle
- S/he is knowledgeable of the technical ecosystem around at least one language
- An architect is someone with experience and skills to envision, plan, build and test a complex application or series of applications in one or more environments
Work and responsibilities
- It’s usually implied that an architect will be taking a lead role on a team, and maybe the lead role of several team
- S/he intends to be responsible for the systemic integration and operations of software systems and the applications that are built that will fit within that system
- An architect knows how to scaffold the project so a whole team can work on it without blowing it up
- The architect on the team would assess the available solutions(i.e. libraries and frameworks), impact of their use on existing codebase, environment and available developers skills
- The architect makes the call on which framework(s) to use and should have enough experience to be able to assess competing options
- S/he goes beyond the function level. An architect thinks about a program as a whole, in its current design, and in its future, not yet envisioned, state
- S/he defines build/test/deployment systems so their entire piece of software will be stable and rock-solid
Interview questions
Additionally, here are some samples to give you an idea of what interview questions for architect candidates might look like:
- “Tell me what applications you’ve overseen the building of and what scaling issues you ran into as they grew.”
- “How do you start chasing down a performance problem?”
- “Name the differences between object-oriented design and component-based design.”
Image credit: http://delphibrief.com/
