Why Should Senior Engineers Balance Trees in an Interview?

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

programmableweb_640

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.


This article originally appeared on Forbes.


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 hiring managers 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. Designing Impactful Challenges

1a. The Challenge Checklist

Step 2. Setting Expectations, Warming Your Candidates

Step 3. Calibrating After the Screening

 

Please share this article:

14 Replies to “Why Should Senior Engineers Balance Trees in an Interview?”

  1. I don’t even know how to start. What is said in this article IS basically nonsense. If you expect your employee to know random algorithms by heart you are nuts, and even more, that does not even prove that they are good programmers. The key is to ask about concepts. How would you solve this problem, what would you do, what data structures would you use. That, if you want to test real CS knowledge. The same way that making a candidate write code in the interview is nonsense, asking them to execute an algorithm manually using only memory is just not the way to go. I suspect that HackerRank has interest on this to start to be valued.

    1. That’s what India is all about – know the things. Fact is, indians don’t know how to create things. I don’t have any problem if such interviews are being used to know the thinking process, and interaction, but asking a senior engineer to solve tree algorithms, in half an hour, that too alone, is absolutely ridiculous. Work places don’t work the way interviews happen.

  2. This is kind of BS. The premise of this post is that the ability to understand the internals of a black box is not a learnable skill. This inherently divides your hiring market into two sectors: people who understand algorithmic design and people who can only program. You’re assuming that it’s impossible for developers to go from the right side to the left, and that’s why companies shouldn’t bother wasting their time and effort on candidates who are basically some immovable stone-hard archetype of the hacker or the programmer-philosopher.

    I ask algorithmic questions in my interviews because I want to see how people react when confronted with changing specifications and how well they can articulate their thought process as they solve a problem. I don’t ask algorithmic questions expecting people to solve them to their full completion. I want to gauge what types of tradeoffs and compromises they’re willing to take, I want to know what types of risk takers they are. In my experience, memorizing interview guides and being an algorithmic wizard at USACO is as good of a predictor of becoming a good engineer as mastery of basic newtonian mechanics is a predictor of becoming a good aerospace engineer.

  3. “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.”

    Testing and backups would have also helped…

  4. “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.”

    Testing and backups would have also helped…

  5. The most important question you should be asking yourself after reading this article is “do I really need engineers or do I need a coder?” Unless you’re in a technically innovative environment, you likely don’t need engineers in the way most pop-hacker thinkers act like you do, and this article is not written for nor is it applicable to you. Here’s what I’d suggest. Sit down and make a list of the things you’d like an applicant to accomplish in the next year, then share that list with the candidate. Ask if they’ve done anything similar. Ask how they did it. Ask how they would tackle the problem. You’ll learn a lot more useful information about a candidate than through algorithmic tests.

  6. If I’m not mistaken, the actual interview question was to invert a binary tree on a whiteboard. That’s assuming the context of this article is the debate over Max Howell’s rejection at Google. I also know that Google has done numerous studied that reveal these types of question do not actually verify a person’s ability to deliver production level code in a team environment.

    In Max’s case, these tests are meaningless. He’s the leader of highly visible, highly used open project. His work speaks for itself in the form of Git commits, which anyone can review. He’s a public figure with a proven track record. Asking him to solve these types of questions are meaningless; he has a public track record that can verify he has solved complex problems and worked with others.

    These types of questions are useful for determining how willing a person is to challenge themselves. I think more developers should practice them to boost problem solving and creativity. But, as Google has proven, the ability to solve these problems does not translate into on the job experience.

      1. It is not about any issue with them. It is about attacking their superior mindset. Majority of Indians have no idea about work ethics, problem solving and producing things. Working in foreign countries at the labor and infrastructure of others don’t make indians superior or great.

  7. I really liked your article , your article is very
    petrified me in the learning process and provide
    additional knowledge to me , maybe I can learn
    more from you.

  8. The fact is hiring process is broken, and nobody really has hard data or conducted research to prove that a certain interview method, or asking a certain question helps to select engineers that will show a certain performance characteristics in the job. Everyone is actually hiring with what they think is the best method according to their company’s culture.

    There are many interview methods besides white-board coding:
    https://www.recruityourninja.com/different-technical-interview-methods-explained/
    Each meets a different need of the employer.

    Tech companies prefer white-board coding when the job requires CS fundamentals and when the element of scalability and performance is critical for the job, and rightly so, as explained in the article. 2nd reason is the company has a large amount of applications: when it is necessary to filter out bad candidates really hard, nevermind letting go a few good engineers who did poorly due to nervousness, etc.

    If you don’t meet the above condition, using white-board coding in interviews is plain wrong. Trying to conduct interview preparation class for candidates is even more wrong (doing so will let bad candidates pass!)

Leave a Reply

Your email address will not be published. Required fields are marked *