The Art and Science of Hiring Digital Architects | HCL Blogs

The Art and Science of Hiring Digital Architects

The Art and Science of Hiring Digital Architects
March 14, 2019

The Mythical Beast

The Mythical Beast

The title ‘Architect’ is perhaps one of the most misused titles in the software industry. You probably become an ‘Architect’ because your organization runs out of titles for a senior software engineer or in other cases, an ‘Architect’ is seen as this mythical being, who can do everything from writing code every day while managing the project to participating in an enterprise IT strategy discussion with the CIO. Then there are frivolous terms such as ‘Paper Architect,’ ‘Wikipedia Architect,’ or ‘Ivory tower Architect’ that have evolved largely because of poor understanding and appreciation of an architect’s role.

At HCL, we design applications that can run at ‘cloud-scale’.

Digital Engineering Architects @ HCL’s Digital & Analytics Practice

Since the term ‘Architect’ is so loosely used in the software industry, it is imperative that we have a clear definition of what it means in our context.

HCL’s Digital & Analytics (DNA) practice believes in hiring engineering resources based on their level of expertise rather than their number of years of experience. We strongly believe that number of years of experience is a poor measure of the ability of a person to perform at a certain level. However, the level of expertise of a person in the desired skill provides a much better measure. We use a combination of tool-based automated test and personal interview to assess the level of expertise.

Our Digital Engineering Architects are technology leaders that help translate our customer’s business vision, into a measurably successful technical solution implementation. They engage with the customers from very early stages of a project, create a solution blueprint, and institutionalize the necessary engineering automation culture and discipline to realize the solution successfully. They also mentor and lead the engineering teams they work with, until the teams can independently take the projects forward.

At DNA, we also encourage them to establish themselves as technology thought leaders by speaking at events, writing technology whitepapers, and authoring blogs to build credibility.

Digital Engineering Areas of Focus

We focus on a few key areas of technology. These are relevant to the kind of projects our digital engineering automation architects are routinely involved in. They are as follows;

  • Custom Application Architecture (Mostly Java and C#)
  • Cloud-Native Architecture (Microservices architecture, Microliths, and Monoliths)
  • Cloud-Native Application Platforms (K8S, OpenShift, PCF, and Docker)
  • DevOps Culture and Engineering Automation

To be part of our team, one needs to possess expert level understanding in each of these areas. Let’s break it down to understand what we look for in a candidate.

Majority of the work that we do is Java or C# related. Hence having solid skills in Java/C# design and development are table stakes. Beyond that, knowing any other programming language, such as Javascript, Typescript, and Python gives an edge over other candidates. When we mean Java or .NET, it includes core object-oriented programming, web applications, APIs, ORMs, design patterns, and popular frameworks.

At DNA, we design applications that can run at ‘cloud-scale.’ So, ability to design modular cloud native applications, understanding fundamentals of what characteristics of an application make it a cloud-native, various techniques to scale on demand, how to setup right monitoring for such applications, and ensuring resiliency to create ‘always-on’ systems are critical. To understanding distributed computing, misconceptions of distributed computing is required.

Microservice architecture is a popular cloud-native architecture style. Hands-on experience on microservices architecture development and design experience are required. This style of architecture presents a different kind of challenges and there are various patterns to tackle those challenges. Understanding which patterns can be used to address such challenges is fundamental. Microservice design can be based on domain-driven design principles, and we require a thorough understanding of DDD and the role that it plays in microservice architecture.

In addition to knowing cloud-native application architecture, we also expect a solid understanding of one or more cloud-native application platforms, such as Kubernetes, OpenShift, or PCF. Having certification in one of these is highly preferred. Ability to define which platform is the right choice for a given use case is important.

Finally, we require a good understanding of the role DevOps plays in modern engineering teams for architect hiring. One should be able to define what DevOps means, what should a CI/CD pipeline look like in a modern delivery landscape, what quality parameters and gates should be applied at different stages in the build pipeline, and familiarity with some CI/CD tools are desirable as well.

The Interview Process

Our architect interviews are designed to assess your experience and knowledge in all the above areas in addition to other skills and experience listed in your resume. Our hiring process is made up of a tool-based test and a personal interview.

Our hiring process is made up of a tool-based test and a personal interview.

Step1 – Tool-based problem solving and MCQ

We use industry-standard tools to create customized multiple-choice question tests and online problem-solving tests for Architect hiring. It provides us with a measurable and objective assessment of someone’s expertise.

First, we give a design problem and expect a well-defined, well-articulated solution to the given design. We look for design choices considered before arriving at a particular solution, clarity of thought, and finally how the solution is presented.

Step 2 - Personal interview over Skype or in person

We provide another design problem and ask for a solution. We expect the candidate to walk us through their design thought process. We then evolve the design with the candidate by adding more complexity to the original problem or by restricting certain design choices. Candidates are asked to explain how certain NFRs are taken care of in the solution and will be forced to defend the design decisions.

If candidates can satisfactorily demonstrate their technical knowledge, architecture skills, communication skills, and competent to defend their design choices with solid reasoning skills, they will clear the first round. At this stage, they are invited for an optional in-person discussion before final selection.

We take immense pride in our teams and the value they bring to HCL and our customers. If you think you have what it takes to be a part of this highly energetic and influential architecture power team, you are welcome to apply.

Send your applications to our DNA recruitment team using one of our current job postings: