Why Should Senior Engineers Balance Trees? The Case for CS Fundamentals in an Interview

Image by Ales Krivek

For nearly as long as companies have hired programmers, managers have asked engineering candidates to solve fundamental algorithm and data structure problems. And for nearly just as long, engineers have debated the validity of these challenges in job interviews (2005, 2015).

The argument is: If I’m never going to balance a tree on the job, why would you ask these fundamental coding questions to gauge my skillset? At first pass, this can be infuriating for senior engineers. Who’s going to remember basic tree-traversal from computer science (CS) courses when you’ve been using easier, faster standard libraries for years?

But what’s not as emphasized as often is the value of basic CS fundamentals for most roles. Everyone knows the best strategy for screening candidates is to test for whatever’s important for the job, but simple algorithm questions actually play an important role in uncovering what engineers can and can’t do. If you dig deeper, engineers who can’t complete basic algorithmic code challenges in an interview are actually less productive hires in the long run.

You Get Unqualified Hustlers with Quick Wins

If you don’t test for CS fundamentals, you’ll risk hiring programmers who are only good at gettings things done in the short-term. They can put together decent code using APIs and build a glowing portfolio. But if you ask them why their program works the way it does, they’d see opaque black boxes. It’s like they’re assembling parts together without a toolkit.

Over the past several years, there’s been a sharp boost in the number of APIs and standard libraries. For instance, Salesforce, alone, has over 3 million applications in its third-party app system. Look at the sharp rise in APIs in the last 10 years, according to the ProgrammableWeb

The uptick of these neat packages make it easy for programmers to get by without revisiting the fundamentals. And that’s fine if you just want to hustle, get a quick win and build a stunted product.

But most–if not all–accomplished programmers, from Donald Knuth to Ken Thompson, value the importance of knowing why code works in building revolutionary products. For instance, Knuth’s 1968 masterpiece The Art of Programming, was the first time coders could understand why algorithms work the way they do. “So my book sort of opened people’s eyes: ‘Oh my gosh, I can understand this and adapt it so I can have elements that are in two lists at once. I can change the data structure.’ It became something that could be mainstream instead of just enclosed in these packages.”

Testing for algorithms and data structures also tests for lifelong curiosity. Engineers should be “continually interested in keeping themselves up to speed, in revising the fundamentals and taking on intriguing programming problems. Those are the people I want to work with,” says Soham Mehta, CEO and cofounder of Interview Kickstart.

You Build Fragile Products

If you don’t test for CS fundamentals, it’s going to be really difficult for you to provide for your growing base of customers. When scaling out architecture, you have to understand how components work on a simpler, more fundamental level before applying them across multiple machines. If your engineers open enough logic-related bugs, you could lose valuable customer information or create bottlenecks, resulting in a slow customer experience.

This happened to Ben Sigelman, an ex-Googler who founded a company called LightStep, which builds monitoring and performance tools for developers of large distributed systems. He recently worked with a well-intentioned engineer who decided to use Redis for scalable, consistent and durable storage. But Redis is best as an in-memory data structure server and does not — and can not — scale well when placed into its “AOF” consistency mode. In that configuration, Sigelman says it’s much slower and less resilient than true distributed databases that append to cluster-level file systems. He makes a solid point:

“Formal CS training would have triggered a ‘too good to be true’ alarm, well before [the engineer] deployed it, and irrevocably lost user data in the process,” he says.

You End Up Reinventing the Wheel

If you don’t test for CS fundamentals, optimizing your codebase is going to take a lot longer than it should. Opponents argue that smart programmers use standard libraries to save time. Why reinvent the wheel when someone else has already solved this problem for you?

But, remember, we’re not asking advanced algorithmic interview questions because you’ll be writing algorithms from scratch on the job. We’re testing basic knowledge of fundamentals to ensure you’re not just relying on other people’s code, Stackoverflow or Google. Otherwise, when you need to scale and optimize, you’ll waste a lot of time trying to figure out optimal solutions. It’s not just about memorizing how to implement algorithms. Learning the trade-offs between algorithms is valuable in boosting efficiency. Simply testing candidates on knowledge of where trees fit in relative to sets or maps or linked lists is valuable in and of itself.

Gayle Laakmann McDowell, founder and CEO of CareerCup and author of Cracking the Coding Interview, offers a great example of what happens when a senior engineer doesn’t revise fundamentals:

A more senior engineer building a parsing engine might not understand how she can leverage graph theory or trees. She could spend hours reinventing the wheel, only to come up with something less optimal in the end.”

It’s the same for debugging. The most efficient way to debug requires fundamental knowledge of how components behave with one another. Someone who doesn’t really know how things work might put in logging everywhere in hopes of catching errors by trial and error. A better way would be to systematically isolate issues by spotting patterns in the errors. You can only do this if you know the system and its algorithm.

It’s especially important if you’re not quite sure which specific tools you’ll need. If you’re building a long-lasting product, it’s crucial to test for timeless fundamentals that will be the foundation of future programs. “The breadth-first search algorithm, for instance, was invented in 1959 as the solution to the shortest path in a maze, but it’s still indirectly important to programmers today through some layer of abstraction. ” says Dr. Heraldo Memelli, who oversees all of the code challenges at HackerRank.

Programming tools come and go, but fundamentals are forever. The assumption that you don’t need to know CS fundamentals on the job couldn’t be further from the truth.

But the Interview Can’t be ‘One-Size-Fits-All’

Of course, you can’t rely on general CS questions — alone — to hire for every role. The coding challenges you select have to be appropriate for the role you need filled, and basic fundamentals are one bar that should be cleared.

Leo Polovets has had a lot of experience in designing great screening processes as the second non-founding engineer at LinkedIn and engineer at Google. He offers a solid example:

“For a backend candidate, you might give them a problem where they need lists, sets, and hashmaps, and you want to make sure they use the right structure at the right time. For a front-end candidate, a good question might be to asks them to do some basic DOM manipulation. These could be 10–20 line programs, but they’ll still reveal a lot about what the person can and cannot do,” Polovets says.

More Companies Should Prepare Candidates

The reality is, algorithm and data structure interview questions should be really easy — as long as you have some warning, good prep material and context for what interviewers are really want to see.

Algorithmic coding challenges aren’t designed to evaluate how well you think on your feet. In fact, if you’re pop quizzing your candidates on algorithms, you’re most likely turning away really great people who happen to test poorly. The best tech companies are preparing their candidates as much as possible to create a stronger, more successful talent pool.

Facebook invests in teaching an interview prep class for all of their candidates. They realize that senior engineers or folks who are self-taught will need to prepare. It covers exactly what kind of algorithmic coding challenges they plan to ask and explain why. Of the three phases of Facebook’s technical interview, one is called “Ninja,” which screens the ability to solve tough coding challenges, like sorting algorithms. Any engineer who applies to Facebook has to do really well on these interviews. It’s one of the key reasons why Facebook has a world-class engineering team.

The assumption that you don’t need to know CS fundamentals on the job couldn’t be further from the truth for most jobs. Well-designed basic algorithm and data structures challenges are a good way to gauge depth of technical skills for sustainable products.

If you like what you see, please subscribe to our blog to get a quick note when we occasionally write thoughtful, long form posts.

________________________________________________________________

To help you create better code challenges, analyzed hundreds of code submissions and spoke with several interviewers to create this in-depth guide:

Step 0. Before You Do Anything
Step 1. Design Impactful Challenges
1a. The Challenge Checklist
Step 2. Set Expectations
Step 3. Calibrate After the Screening

Originally published at blog.hackerrank.com by Vivek Ravisankar on February 17, 2016.