Tech talent hiring knowledge & best practices straight to your inbox!

How to Build High-Performing Engineering Teams

build high-performing engineering teams

This is part 2 of a 3-part series based on a conversation between HackerRank’s CEO and Co-founder, Vivek Ravisankar and Atlassian’s Head of Platform, Mike Tria, on engineering management. 

This post discusses how to assess developer candidates and build high-performing engineering teams. Catch part 1 and hear Mike’s advice on building key engineering management skills here.

HackerRank’s CEO and co-founder, Vivek Ravisankar, and Atlassian’s Head of Platform, Mike Tria, are both developers who have built and lead engineering teams. Drawing from their experiences, they share which interview assessment methods spotlight the right candidates—and common mistakes first-time engineering managers make.

How to assess individual contributors and managers

When hiring new grads, junior developers, and even senior developers, it’s the industry standard to evaluate a candidate's skills with a technical assessment before extending an offer. But developers disagree about whether companies should require seasoned individual contributors (ICs) and hiring managers to code during the interview process.

For developers who have 10+ years of experience and a robust portfolio, the request to invert a binary tree on a whiteboard can be insulting and irrelevant. When it comes to take-home challenges, developers who work full-time don’t want to spend 3+ hours completing a lengthy assignment.

During the hiring process at Atlassian, every IC and hiring manager goes through some form of technical vetting, but the type of assessment differs for each role. 

Assessing individual contributors

Since ICs are responsible for the heavy lifting on high-stakes projects, Mike believes every IC should receive a coding evaluation. “On the IC track at Atlassian, everyone from the junior dev to the top-level architects are expected to write code,” says Mike.

His reasoning? He’s seen first-hand moments when ICs with rusty coding skills struggle. “When they jump in on a problem that might require them to be the one that innovates on a solution, they’re unable to do it. So, we test for that, for every single level of engineer.”

Assessing engineering managers

For engineering managers, Mike says there’s a different type of technical assessment for each level of seniority. A first-level manager is required to write code. Managers at higher levels are required to show their experience with architectural and system design questions. 

Mike doesn’t assess more senior managers’ coding abilities for one simple reason: engineering managers require more than a technical skill set. Instead, managers need a mix of strong soft skills and technical skills. Some of the crucial soft skills include team-building, active listening, communication skills, and a sharp business acumen.

According to Mike, if the manager has a proven technical foundation, they shouldn’t be required to code during the interview. “You can bring in a VP who hasn’t coded in 8 years, and you might be completely comfortable with them representing the team because they’re current on the technology, they understand architectural principles. And that’s sufficient for them.”

Mike asks questions focused on systems design and real Atlassian technical problems to accurately assess a candidate’s skill level. “The technical problem could be related to improving one of Atlassian’s products, like: ‘How do we solve this storage problem?’ or ‘How can we deliver a better performance to our users?,” says Mike. “We’ve failed managers that have managed 100s of people at well-known public companies because they were not able to pass these. So technical matters, but coding specifically for managers after the first [level] we don’t do.”

Atlassian’s take on role-specific assessment questions

To provide a candidate-first experience, more companies are positioning their technical assessments to give candidates a preview of the day-to-day work they’d see on the job. While this approach is beneficial to both the candidate and the employer, it’s hard to scale. Larger companies might not have the time or resources needed to create an assessment specific to each role they’re hiring for.

At Atlassian, they use generalized real-world problems in their assessments. “We will do coding based on a similar set of problems, and those coding problems tend to be grounded in problems we actually have at Atlassian.”

Once Atlassian stopped asking brain teaser questions and focused on problems they face in their products, they were able to better identify the best-fit candidates. It also paints candidates a clearer picture of what their day-to-day would consist of—a huge benefit for candidate experience. 

While Mike promotes real-world problems in assessments, he advises teams to keep a reasonable time limit on the assessment. Sending multi-day simulation problems might work for junior candidates who just graduated from a college program. But, Mike says assigning a multi-day assessment to candidates who are working full-time is a big ask. “Outsourcing your job to a candidate during an interview can be a really hard thing to ask and it limits your pool.” 

Common mistakes first-time engineering managers make when building teams

With 13+ years of experience leading engineering teams, Mike has noticed several common mistakes new engineering managers make when building teams. Here are the top 3 team building missteps first-time managers should avoid:

Hiring people just like you

The most common mistake is hiring candidates who hold the same values, work styles, personality, and interests as the manager. While it’s natural to connect with candidates who are just like you, focusing solely on  those candidates negatively impacts the entire direction of your team. “If you end up bringing in people who are just like you, you’ll end up with a team with blind spots you can drive a truck through, and you’re going to make big mistakes when the time comes,” Mike says. 

Atlassian conducted in-depth research on the values of balance & belonging, and creating diverse teams. All of this research points to one consistent fact: diverse teams are the teams that win.

Not setting clear expectations for their team

Another mistake Mike sees new engineering managers make? Not outlining clear task and performance expectations. Even if your team members display leadership and project management skills, it’s still the manager’s responsibility to check in with the team and communicate expectations.

“It’s very easy to have a team and give them a ton of autonomy,” says Mike. “If you don’t set any expectations of what you expect as a manager, they’re just going to go off-road quickly. Your job is to give them expectations.”

Not giving your team enough autonomy

On the other end of the spectrum, some new managers don’t give their team enough autonomy. In order to build a high-performing team, you need to create space for your team to tackle problems in their own way. Making room for each member of your team to introduce a new process or offer a different perspective gives them a sense of ownership and responsibility. 

According to Mike, the combination of diverse hiring, outlining expectations, and giving your team freedom to work in their own way is the formula to building high-performing engineering teams. “Hire the right people, ideally a diverse team,” says Mike. “Setting expectations of what success means for that team, and give them the room to do it.”

Tying it all together

Every engineering leader faces a learning curve when it comes to building and leading teams. Learning how to assess every type of developer, choose candidates who bring a different perspective to the table, and communicate expectations, while also encouraging autonomy, are skills that take time to hone and perfect. But the more experience you gain in each of the above, the closer you’ll be to mastering the art of building high-performing engineering teams.

Would you like to receive similar articles straight to your inbox?