In the world of software engineering, the choice of programming languages, frameworks, and technologies is constantly evolving. As a result, hiring engineers who have experience in different tech stacks has become a common practice for many companies. However, this practice also raises questions and concerns about the potential challenges and advantages of hiring engineers who work in predominantly different stacks. In this blog, we will explore the insights shared by experienced engineering managers who have experienced hiring engineers from different tech stacks.
One of the main concerns of EMs that are hiring is the potential cross-skilling cost and time it may take for engineers to become productive and efficient in a new tech stack. There exists a general discomfort in jumping across stacks due to the learning curve involved in becoming proficient in a new stack. However, many people share their positive experiences of transitioning from one stack to another and highlighted the value of prior experience in a tech stack. According to them, engineers with prior experience can quickly contribute to key development initiatives and even bring fresh perspectives and ideas from their experience in a different stack.
One thing to note is that the ramp-up time for engineers changing stacks can be influenced by the tech stacks they are coming from and going to. For example, moving from one object-oriented programming language to another may have a shorter ramp-up time compared to moving from a weakly typed scripting language to a strongly typed functional language, or vice versa. The mentorship abilities of the company and the patience of the manager are important factors that can impact the ramp-up time for engineers transitioning to a new stack.
We must also emphasize the importance of evaluating candidates based on their problem-solving skills, coding mindset, and attitude, rather than just their experience with a specific programming language or tech stack. Testing candidates with problem-solving puzzles or pseudo-code on a whiteboard can reveal their ability to think critically and logically, which are skills gained after years of experience and practice. This approach focuses on the candidate's ability to adapt and learn, which can be more valuable in the long run compared to their familiarity with a specific tech stack.
The attitude and mindset of the candidate are crucial factors to consider during the hiring process. Hiring for attitude and providing time for the new hire to learn the stack can be more effective than hiring for specific stack expertise. While a new language or tech stack can be learned, a positive attitude, willingness to learn, and a problem-solving mindset are qualities that are harder to teach. Therefore, hiring engineers with the right attitude and mindset can be a good investment for the team and the company.
In addition to evaluating the candidate's attitude and mindset, it is also important to provide a supportive onboarding experience for engineers who are transitioning to a new tech stack. The ramping time should be built into performance reviews, delivery expectations, and other relevant processes. This ensures that engineers are not penalized for being hired for a stack they need to learn and gives them the opportunity to learn and grow without feeling isolated. Pairing on tickets as they are ramping on the stack is also suggested as an effective way to facilitate the learning process and ensure that the new hire feels supported by their team and manager.
Another important aspect to consider when hiring engineers who work in different stacks is their willingness to learn and adapt. As long as the candidate is willing to learn, it should not be a showstopper. Having a growth mindset and being open to learning new technologies and stacks is crucial in the rapidly changing world of software development. Engineers who have experience in switching stacks in the past may even bring invaluable insights and perspectives from their previous experience, which can benefit the team and the organization as a whole.
It's also important to set realistic expectations and provide support during the ramp-up period. If you have control over ramping/hiring expectations, make sure the ramping time is built into performance reviews, delivery expectations in the first few weeks, etc. It's important to ensure that engineers who are hired for a stack they need to learn are not being penalized for it. Advocating for time and resources for coaching, guidance, and pairing on tickets can help new hires feel supported and integrated into the team, instead of feeling isolated or overwhelmed.
Hiring for a specific stack is only relevant if there is a genuine need for an SME (subject matter expert) in that stack. Otherwise, senior engineers should be expected to pick up whatever stack is needed for the job and mentor junior engineers in developing competence in that stack. If there is a lack of confidence in hiring engineers who are not SMEs in a particular stack, it may indicate a larger issue with developer ergonomics, mentoring, and training within the organization.
Hiring engineers who work in different stacks can bring both advantages and challenges to a team or organization. While experience in a specific tech stack can be valuable, it is not always a strict requirement for hiring. Good engineers can ramp up and adapt to different stacks with time and support. It is important to set realistic expectations, provide adequate support during the ramp-up period, and prioritize a candidate's willingness to learn and adapt.
A growth mindset, good problem-solving skills, and attitude are often more important indicators of a candidate's potential than their specific experience with a particular stack. By fostering a culture of continuous learning and adaptability, organizations can create diverse and resilient engineering teams capable of tackling various challenges and driving innovation. So, when considering hiring engineers who work in different stacks, it's important to focus on their overall skills, mindset, and potential contributions to the team, rather than solely relying on their previous experience with a particular tech stack.