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.

JavaScript master Douglas Crockford once said that software is the most complex thing that humans have ever created. It’s made up of intricate bits and bytes pieced together like virtual puzzles. These insurmountable calculations help us achieve extraordinary feats, like routing human beings to the uncharted craters of Mars. By the very nature of the burgeoning computer science discipline, “we’re dealing with things that are on the edge of what humans can handle and more complicated than ever before,” said renowned computer scientist Donald Knuth.

While no one programming legend can possibly accomplish any big feat solo, there are programmers worthy of fame for their supreme productivity. Every so often, leaders of new revolutionary tools make an explosion in the field that reverberates across generations of new programmers.

But what’s even more interesting is that some of the highest-achieving programmers — who can make sense of such unfathomable complexity — can’t foresee a lucidly bright future ofprogramming. Several accomplished computer scientists share a grave concern of the shift toward our more fragmented web. Tools that act as layers, like frameworks and packages, are created to help programmers be more productive, but some experts fear they’ll actually have the opposite impact long-term.

If the foundation of the modern world is built on software, then deconstructing the toolkit of today’s software leaders can help us not only become better programmers, but develop a better future. Contrary to popular belief, greatness isn’t exclusive to unreal legends. Culture critic Maria Popova puts it most eloquently when she says, “Greatness is consistency driven by a deep love of the work.”

After researching stories on and conducting in-depth interviews regarding seven programmingpioneers, from computer scientist Donald Knuth to Linux’s Linus Torvalds, we uncover productivity patterns common to achieving greatness and pitfalls of which to steer clear: There’s never been a widely used programming tool that was created by just one lone wolf in a cave. Sure, Jeff Dean is the trailblazer of the famed distributed computing infrastructure upon which Google towers. Peter Norvig may be immediately associated with JSchema. David Heinemeier Hannson’s pride and joy is the Ruby on Rails framework. But each of these creators had support for their groundbreaking inventions.

Teamwork is the foundation of an empire that lone wolves simply can’t sustain. It’s why Google, home of world-renowned engineers, doesn’t tolerate lone wolves on campus. It’s the antithesis of “Googliness,” and software development in general, for two core reasons.

First, the mere proximity to other engineers fuels greatness. When Rob Pike worked at Bell Labs, well before making waves on the Unix team, he recalls fond memories of hovering around clunky minicomputers with terminals in a machine room in the Unix Room. “The buzz was palpable; the education unparalleled,: he said. “The Unix Room may be the greatest cultural reason for the success of Unix as a technology.”
Folks like Ken Thompson and Dennis Ritchie (authors of C Programming Language) would code, sip coffee, exchange ideas and just hang out in the Unix Room. It was this necessity of convening in a physical room that helped turn Unix into what it is today. Since the proliferation of PCs, however, proximity to each other isn’t as rigid in modern programming. Going out of your way to meet with smart engineers, however, is a timeless essential contributing to greatness.

Just ask Jeff Dean, the famed Googler who often is referred to as the Chuck Norris of the Internet. As the 20th Googler, Dean has a laundry list of impressive achievements, including spearheading the design and implementation of the advertising serving system. Dean pushed limits by achieving great heights in the unfamiliar domain of deep learning, but he couldn’t have done it without proactively getting a collective total of 20,000 cappuccinos with his colleagues.

“I didn’t know much about neural networks, but I did know a lot about distributed systems, and I just went up to people in the kitchen or wherever and talked to them,” Dean told Slate. “You find you can learn really quickly and solve a lot of big problems just by talking to other experts and working together.”
Second, every great coder, with however pristine a track record, must check in their code for a peer review. Pivotal Labs, the company behind the software-scaling success of Twitter, Groupon and a dozen other high-growth Silicon Valley startups, requires the freedom for any coder to look at any code. It’s simple: If code is too dependent on one person, your business is susceptible to dire wounds.
Even the great Guido van Rossum checks in his Python code, and Thompson checks in C code. Linus Torvalds, author of the biggest collaboration Open Source Software project in history, says he actually judges coders — not by their ability to code — but how they react to other engineers’ code. As a bonus, reading others’ code also can help you become a better coder. You often can see things in the source code that are left unsaid in the office.
Knuth would wholeheartedly agree. “The more you learn to read other people’s stuff,” he said, “the more able you are to invent your own in the future, it seems to me.”

When Collaboration Goes Awry

Collaboration is generally a solid learning tool, but can be catastrophic when injected at the wrong time. Hansson has seen too many Open Source Software (OSS) projects fallen victim to premature collaboration. That’s why, for the first 1.5 years of RoR’s life, Hansson had commit rights to the framework. And it took another 4.5 years before he felt comfortable collaborating with another framework to produce RoR version 3. Even then, it wasn’t easy for him.
“I’ve seen plenty of open source projects being pulled in a thousand different ways because you allow collaboration to happen too early before the culture and vision is established enough so that you can invite enough people safely into the project without them spoiling it,” he says in a Developer’s Life podcast.
Plus, the truth of the matter is, many programmers simply enjoy blasting through code alone. Solo coding is faster, short-term. You don’t have to worry about communication mishaps. And things are generally more uniform. Engineer Ben Collins-Sussman once asked a room full of programmers:

• How many of you work solo? …Crickets…

• How many of you LIKE to work solo? Nervous laughter and raised hands spread across the room.

Collaborating is a necessary evil for many of the greats, like Norvig, who is now Director of Research at Google. Norvig makes the observation that too much collaboration is also not as effective. “If you’ve got two good programmers,” he says, “it’s better for them to work independently and debug each other’s work than to say we’ll take 50% hit just for that second set of eyes. 10% of the time it’s good to sit down and have that shared understanding. But I think most of the time, you’re not going to be as effective.”
For collaborating on a project that lacks a clear vision, unlike that of Hansson, it’s good to figure out what the problem is together. Once you have an idea, great programmers divvy up the work; leave them alone to burn through the code and sync up during review. The best collaboration happens by creating a solid feedback loop, where you can catch one another’s errors before you’re too far into the project.

John Carmack, known for creating Doom, was also very wary of adding more programmers to his process of achieving his vision of great games. There was a time when Carmack wrote the majority of the basic program, he says.

Now, we’ve got lots of situations where, if something is not right, it could be like, “Oh that’s Jan Paul’s code, or Jim’s code, or Robert’s code.” It’s not so much a case where one person can just go in and immediately diagnose and fix things. So, there is a level of inefficiency.
Again, there’s a limit to what a lone wolf can do. Doom 3 required a lot more features, which meant more programmers. Carmack found this to be a double-edged sword. So, it’s manageable, he says — and necessary — in achieving a grander vision.

Jack Of All Trades And Master Of One

Most — if not all — of the seven legendary programmers had at least one thing in common: They mastered one well-defined domain, primarily using one language to carry out their work. Jonathon D. Tang pointed this out in a recent Hacker News comment, and it rings true. Knowing your language inside out is key to optimal performance. So, “read the reference, read books that not only show you the mechanics of the language but also debugging and testing,” Norvig advises. Being able to memorize the common calls for your language of choice can help expedite productivity.

Enjoyed this piece? Subscribe to our free newsletter to get new articles in your inbox. 

The post Legendary Productivity And The Fear Of Modern Programming [TechCrunch] appeared first on HackerRank Blog.

First…What’s the Root of the Issue?

Before rolling up your sleeves, take a step back and think about what might be at the root of the issue. “After waiting a moment, check any relevant logs which may hold clues to what the problem is. Depending on what’s found there may be a simple solution. If not, it’s time to debug,” says Tim Henrich, founder of Turret.IO.
Most of the time, bugs (or errors) usually fall under one of three major categories:

• Logic
• Runtime
• Compile-time

Logic errors are the trickiest because, quite simply, there is a problem with what your program is trying to do even though it is syntactically correct. “These [logic bugs] are hard to find because they usually aren’t errors you can look into from the compiler or interpreter,” says Jameson Quave, president of JQ Software and author of Developing iOS 8 Apps in Swift.

Logic Errors: Set Breakpoints and Inspect Values

“Whether you’re using a debugger, like GDB from the command-line, or using an IDE, like IntelliJ, setting breakpoints and inspecting the values of any stateful variables is your first step,” Quave says.
He says it’s extremely helpful to familiarize yourself with your debugging tool and then see how other values change as a result. Jorge Colon, senior software architect and owner of 2U Media, points out that any popular IDE for each language has an interactive debugger. “For instance, if you store the value 9.99 as a price, and then upon inspection, you see that its value is–instead–9, you might conclude that you accidentally stored the value in an integer variable at some point along the way.”
Always write a failing test for broken code for future reference.
Use an automated test to help you easily figure out when the problem was resolved. “So, in the future, you can prevent regressions by running the test again after any changes to the code,” he says.

Runtime Errors: Dig into the Error Code

Getting to the solution for runtime errors is a little more straightforward. “You can usually get enough info on the problem by simply reading the error message, or look into the error code,” Quave says.
Even Quave, a veteran programmer, also suggests going the good ol’ fashion Google route. “Searching for an error message is a pretty quick way to either locate others who have faced the same issue, or documentation describing when and where that message would be displayed,” Quave says.
Stackoverflow is a popular favorite for solutions as well. For more program-specific questions, check out smaller communities, like this Swift forum. Here’s one on Salesforce coding as well.

For Exception Runtime Errors, Consider it a Tap on the Shoulder from a Developer

“Exceptions are raised intentionally by platform developers, usually in anticipation of their APIs being used incorrectly in one way or another,” he says. Platform developers often anticipate common issues and incorporate exceptions in order to help you redirect you to the right path and change what you’re doing.
As a simple example, Quave says, “if I wrote a game engine that I know couldn’t handle JPG files as efficiently as PNG files, I might raise an exception when encountering JPGs, in an attempt to persuade developers to convert to PNG.”

For Compile-Time Errors, Modern Tools Will Tell You the Problem

Compiler errors are similar to that of exceptions runtime errors, but they tend to be a little more abstract. “Learning how to address compiler errors is all about knowing the language well, and identifying what particular line is causing problems,” Quave says.
Whether it’s a syntax error or you accidentally declared multiple objects in the same name, fortunately, most modern tools will tell you exactly what line of code is the problem during the compile phase.
These are just a few of the basic guiding principles that are crucial in solving some of the most common bug errors. So, the next time your hours of hard work come to a grinding halt, we hope these tips can help save you some valuable time.

The post Broken Code? How to Regroup and Swat the Bugs appeared first on HackerRank Blog.