This article originally appeared on Forbes.
For nearly as long as companies have hired programmers, managers have asked developer candidates to solve fundamental algorithm and data structure problems. And for nearly just as long, developers 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 developers. 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 balance trees and other basic CS fundamentals for most roles. Everyone knows that the best strategy for screening candidates is to test for the skills that are most relevant and important for the job. But simple algorithm questions, like balance trees, actually play an important role in uncovering what developers can and can’t do. If you dig deeper, developers 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 balance trees and other 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. Developers 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 co-founder of Interview Kickstart.
Balance Trees and CS fundamentals help you build fragile products
If you don’t test for balance trees and 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 developers 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 developer 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 balance trees and 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 balance 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 developer doesn’t revise fundamentals:
“A more senior engineer building a parsing engine might not understand how she / he can leverage graph theory or trees. They 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 balance trees and 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 to fill, 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 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 developers or folks who are self-taught will need to prepare. The class 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 balance trees and other CS fundamentals on the job couldn’t be further from the truth for most companies. Well-designed basic algorithm and data structures challenges are a good way to gauge your depth of technical skills for sustainable products.