The post Top 6 Leadership Books to Read in 2021 According to HackerRank’s CEO appeared first on HackerRank Blog.

The post 3 Reasons You’re Not Building Compatible Tech Teams appeared first on HackerRank Blog.

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.

The post How to Build High-Performing Engineering Teams appeared first on HackerRank Blog.

The post Developers’ Take: Collaboration and Mentorship is Crucial in Software Development appeared first on HackerRank Blog.

Success for recruiters starts top down. If you don’t build trust with the engineering leaders, your job is going to be an uphill battle.

Everyone seems to understand trust, but how do you take steps to build it? Here’s a primer on the four pillars you need to know to build trust with engineering managers, VP of engineers, or directors:

1. Open Communication: ‘Speaking Engineer’ with Closed Off Engineering Managers

What is the language of trust? Most technical recruiters that I’ve come across share a common struggle: It’s hard to get engineering managers to open up communication to get valuable feedback, alignment than, say, sales or marketing folks. Without strong communication, it’s almost impossible to do your job well, and earn the trust you deserve.

But it’s a complete myth that engineers are not communicative. In fact, software development is a highly collaborative skill that requires development of communication skills. If you’re feeling like your engineering manager is hard to approach, remember that it’s not a matter of a gap in communication. Rather, it’s a difference in communication style.

Developers are all about efficiency, quantitative thinking and cold hard facts. How can you solve for the fastest, most optimal solution? Approach every interaction with this optimality in mind.

Here are some tactics with examples on how to execute:

• Concise questions and answers.
  Eg. Which programming languages are mission-critical? As opposed to “Here’s a
  candidate who does C++, Java, and PHP. Does he work for you?”
• Reverse engineer your process:
  Eg. Engineers like process. Talk about solutions by working backwards: In order
  to source 15 PHP developers, we should attend PHP Experience, PHP World
  and International PHP Conference 2017.
• Learn their priorities, and relate it back to the technology stack:
  E.g. This Java engineering candidate will help you build the next generation of your enterprise app.
• Be balanced with your emotions:
  Eg. A communication tip from systems engineer  Byron Seastrunk says: If I show too much emotion while presenting to engineers, they think I’m in sales. If I show too little while presenting to business development folks, they think I’m an engineer…”

2. Technical Competency: The Most Crucial Step to Understanding Technical Roles

As the talent acquisition leader, on the onset, you are the face of the engineering team for candidates. I can’t emphasize this enough: Doing the work to truly understand the technical nuances of the people you are hiring is huge.
Average recruiters simply read the job requirements and then use keywords to find people’s profiles that match. World-class recruiters, like Neal, for instance, know that investing a little time upfront to truly understand the technical roles pays off in a big way.

The next time you have an open technical req, ask your engineering manager to host a workshop for your recruiting team. There’s only one goal: Make sure you understand how the technical role at hand impacts the engineering team at large.

For instance, it’s fine to say that you need a front-end engineer with HTML, CSS3, experience with jQuery, and Ruby on Rails. You can scan through resumes, search boolean strings on LinkedIn and find people that seem good on paper.

But what does all of this really mean to you beyond acronyms and technical jargon?

Ask your engineering manager to host a workshop explaining how your engineering team, product roadmap and company mission will benefit from this role. Chances are, he or she will appreciate your taking the time to find the right skills.  

Disclaimer: This exercise is not about learning how to code or memorizing technical specs. It’s about asking “why” at least 4 or 5 times until you get to the heart of what types of candidates will make the biggest impact. As a bonus, this info on the candidate’s impact will come in handy when you’re convincing him or her to join the company.

3. Reliability: Never Underestimate the Importance of Project Management Skills

Before Soham Mehta became a tech interview coach at Interview Kickstart, he was a director of engineering at Box. In working closely with technical recruiters to build and scale his team, he says that one critical way recruiters can build trust is by being killer project managers.

For a hiring manager, hiring has many unpredictable or fluke factors.” Mehta says. “I need to know that my technical recruiting partners aren’t dropping the ball and letting candidates slip by.”

Organization is key. Use a good ATS, and keep a record of everything, which brings us to our final pillar of trust….

4. Metrics: The Shield from the Unpredictability of Hiring

If you’re not confident in your metrics, there’s likely a bigger issue with your process. Metrics are the best way to speak the same language as your engineering manager (re: #1). Sit down and review…what are the items that you can quantify, benchmark:

“Make a spreadsheet for metrics and watch them like a hawk,” Mehta says. This is essentially how engineers manage their projects: By breaking down each piece and then measuring its performance.

It’s how you can identify interesting patterns, learn what’s working and where you need to double down.

Read more: 5 Steps to Screening Developers with Impactful Coding Challenges 

For instance, when Soham was at Box, he had a strong feeling that certain proxies, like schools, weren’t the best way to measure skills. So, he asked his technical recruiting partner to keep a look out for seemingly weak resumes that still had strong indications of skills otherwise, like a Github profile or other project-based achievements.

“There was a candidate which all other teams passed on, but my recruiter caught,” Mehta says. “He came from an average school, but had strong footprint of shipping great stuff. He impressed some of our best engineers in the interviews and got hired.”
That engineer is still at Box working at the core, most integral teams.
Of course, it’s hard for a technical recruiter to know or understand what to look for without walking in an engineering manager’s shoes. It’s why most people, again, fallback on the same proxies, like strong resumes, to hire talent. But the really great technical recruiters can build a strong foundation of trust with open communication, strong technical competency and reliability.
Big thank you to Soham Mehta for contributing to and reading this piece.

Blane Shields is the Head of the Customer Success team for North America at HackerRank. His team focuses on making sure that our customers are happy, providing best practices to ensure they find efficiency in technical hiring and success with the HackerRank platform.

The post The 4 Pillars Recruiters Need to Build Trust with Engineering Managers appeared first on HackerRank Blog.

We identified a triad of functions that HackerRank should embody: a place where people could learn new techniques, share their skills with others, and compete for prizes. “Learn, Share, and Compete” – leading to an overall fun experience.

In the months that followed, we have honed our focus, made mistakes, learned from those mistakes, gained an incredible (and growing!) core of active users, expanded our scope, and experimented with myriad features, most of which are active on the site today. Most of the assumptions that surfaced from that initial brainstorming session proved accurate, although they did not all manifest the way we thought they would.

As a product designer, this process has been thrilling. There have been situations where agile development has worked seamlessly, and times when agile was not the best solution. Overall, there are a few lessons that really stick out.

Act on instincts, question impulses

Agile design involves pushing a Minimum Viable Product as quickly as possible, but it’s easy to get caught up in the process. The art of agile, I’ve found, is having a solid roadmap and coherent understanding of your product so that you can confidently and quickly make product decisions based on your instincts; the goal is to let these instincts validate your impulses and not the other way around.

Instincts are the natural, intuitive thoughts that come from knowing your product and its users. Sometimes they manifest as sudden epiphanies, sometimes they evolve over time.

Impulses are the result of snap judgements or reactions. For example, someone says, “your product sucks,” so you quickly react to address that individual’s criticisms.

Whether its a sudden great idea, a suggestion from an active user, or something you saw work somewhere else, impulses can be positive forces. It’s important, though, to take the time to step back and see whether the idea fits in the larger picture. Agile workflows depend on flexible products, but a big-picture scope is still necessary to keep short-term goals on track and to minimize distractions.

Sometimes, slower is faster

There’s a delicate balance between forward momentum and stalled progress in an iterative environment. It’s very easy to find yourself chasing your tail as you push change after change without any measurable results. Like all good things, agile design is a means to an end. You should never move quicker than your team is reasonably able just for the sake of moving fast.

A great mantra I’ve heard carpenters tote time and again is perfectly suited for agile development: Measure twice, cut once.
If you take the time to do something right the first time, you’ll eventually save yourself time (and a lot of pain and effort) down the road. Being agile is a mindset, an exercise in obtaining the maximum product value for the least procedural cost. It should not be viewed as a fixed set of rules.

Maintaining fixed deadlines is the principle of agile development that I have struggled with the most. Sometimes the “right idea” comes the day before the deadline is up, or unexpected issues arise. The idea behind this practice is sound, but every rule has an exception. A List Apart articulates this well:

“‘Best practice’ suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1. This is sound advice but should not be taken too literally: some stories will take longer to design than these arbitrary timeboxes. Designers should use their intuition and experience to flag up potentially complex stories in advance, giving themselves increased lead time. It’s bending the Agile rules, but should be encouraged if the product benefits.”

Getting Real About Agile Design, A List Apart (emphasis mine)

As the industry and users adjust to value good design, the agile workflow will need to become to flexible to consider the differences in workflow between designers and developers. At HackerRank, our teams work closely together throughout the process, and design has been prioritized since the beginning. The core point is perfectly expressed in the quote above: the rules, and their exceptions, should always be weighed by the value they bring to the product.

Embrace change

From a design perspective, an agile workflow is a world apart from what I have been used to. On past projects, I would take considerable time planning, prototyping, and adjusting a design before it ever went live. At HackerRank I have almost exclusively switched to designing in the browser. This has ended up making me more productive, and is surprisingly liberating.

Once I have my design templated, it is quickly picked up to be integrated and shipped. This has the very cool byproduct of increasing trust across teams.

Since we’re not spending weeks hashing over wireframes and pixel-perfect Photoshop mockups, the strategic team places a lot of trust in me, as the designer, to represent the product goals through a beautiful visual design. I trust my development team to take my design and implement it as I envisioned. This causes us to work closer and have a better understanding of what each team is working on.

A downside to this fast-paced environment, however, is that often ideas must be cut back or even dropped in order to keep the product moving forward. Furthermore, it is far too easy to react to feedback with short-term solutions that have not been fully vetted.

When we first launched, I was acutely aware of the daily and weekly fluctuations of our user base. After finding myself investing too much energy into user requests that did not fit well without our larger vision, I realized that iteration should be used to fix issues and improve the product, not simply to shuffle change around. All good things take time to grow.

I keep a bucket list handy, now, so that I can record good ideas as they come and file them away for later. Sometimes these ideas fit well into a product push, others are on standby – cool features that we will be pushing in the near future. Many will never be made live.

I think that’s my favorite part of the agile workflow: it really is product-centric. Since pushes need to be made quickly, we have to point our focus to the attributes that bring the most value to the product. Ego and personal taste are pushed aside.
It’s not surprising that the movement to embrace content-driven design is occurring in parallel with the advent of agile development. Both represent the prioritization of content over clutter; of product over process.

It’s definitely an adjustment, and something that is not perfect for every team or project. However, after experiencing the rewards that we have reaped from this workflow, in the project as well as internally as a company, I absolutely welcome the change. Ultimately, the greatest benefits fall to our users, which is really the best result we can ask for.

The post Lessons and Surprises From an Agile Process appeared first on HackerRank Blog.