Would you like to receive similar articles straight to your inbox?

The Unhealthy Obsession with Tree Questions

Why do engineers love to ask fundamental linked list and tree questions in interviews when you rarely code these problems in real-world development?
It’s evolved into a rite of passage. Every engineering candidate, from fresh-faced grads to authors of crucial open source contributions, solves fundamental data structure problems on the spot for interview screenings.
It’s how it’s always been done. But it makes sense. This ritual has sustained itself over the past few decades because it’s a fast, reliable way to spot smart candidates who can think deeply. Plus, it’s better to hire for ability to solve timeless fundamental problems than hire for knowledge based on transient tools. Hence, each of the top 10 technology companies in the Fortune 500 have asked engineering candidates core computer science concepts, including tree or list-related programming questions within the last few years:
Tree obsession
When front-end developer Stephanie Friend graduated from Cal Poly with an engineering and liberal arts hybrid degree, it had been a while since she sat in a lecture hall to learn about linked lists. It’s a good thing she blew the dust off her old data structure books and practiced challenges online before interviewing at one Silicon Valley startup in May this year:

“I had an interview with 6 different engineers on the same team, and 5 out of 6 interviewers asked me to solve a different linked list problem for a web development position,” Friend says.

So, why the need to ask 5 different linked list questions on 5 different occasions for 1 company? Some argue that you can’t be a great programmer unless you have these fundamentals down pat. Others say that CS fundamental knowledge is a good predictor of other useful programming knowledge.
It’s why most programming interview prep books, in even as early as the 2000s, have chapters dedicated solely to basic data structure and algorithm problems (e.g. 1, 2 and 3). Plus, data structure and algorithm questions make up the bulk of upvoted questions on CareerCup, a job prep community. You might be a little puzzled why we’re criticizing these questions, considering tree and linked lists challenges are some of the most popular on our own HackerRank platform.
But there’s a big flaw with companies that aren’t preparing candidates sufficiently before an interview and then relying solely on academic CS fundamentals to weed out unqualified candidates. Data structure and algorithm fundamentals are just one part of what makes a great engineer. Depending on the need, managers should also look at other crucial components, like technical experience, hard-to-acquire knowledge, design and debugging skills to comprehensively assess a candidate.
While fundamentals are crucial, using data structure questions as the be-all end-all filter for great programmers can be detrimental for talented engineers who don’t have CS degrees or who earned their CS degrees several years ago. By placing a heavy emphasis on fundamental knowledge–without properly preparing candidates–companies can create a bias toward recent CS graduates. As a solution, interviewers need to empower candidates with preparation material to reduce the number of great programmers who are rejected.

The Real World vs. Programming Interviews

A typical programmer, even at a top tech company, would rarely implement a data structure like a binary tree from scratch. So, many devs might be out of practice with this by their next interview. The most famous recent example is Max Howell, the author of HomeBrew, a celebrated  program management system for Macs. This year, Howell applied for an engineering position at Google and was rejected because, as he claims, he couldn’t “invert a binary tree” during the initial interview.

While we can’t definitively say why Howell didn’t get the job (it could have been a number of factors that interviewers don’t reveal), it’s likely that he could have performed better if he had known to brush up on those fundamentals by practicing online. After all, he’s an extremely accomplished and smart engineer. So, there’s a chance he was a classic false negative candidate.
The obsession that top tech companies have with data structure problems can also be unfair to engineers who never sat in a CS class a day in their lives. If you don’t have a CS degree, it can be difficult to gauge how much you need to know to clear the initial bar during interviews.

“While these questions can help select talented developers, they become highly problematic when somebody doesn’t have proper tools to prepare and doesn’t understand what is expected. A candidate might feel they need to read an entire algorithms book, which wastes their time and results in less time actually practicing problems.” says Gayle Laakmann McDowell, tech hiring consultant and author of Cracking the Coding Interview.

Although many great candidates get rejected because they failed to adequately prepare, it’s actually not that hard for smart developers to learn or re-learn the fundamentals. It’s part of why companies are fine with requiring them. Today there are a host of online resources to help you practice data structure questions. McDowell, who’s passionate about teaching programming, once successfully taught a student the required basics in just 2 hours. Another one of McDowell’s students was a self-taught programmer with a degree in music and learned and practiced enough of the fundamentals to land a job at Facebook.
But not everyone’s fortunate enough to have McDowell coach them individually. Self-taught students and experienced programmers are left to fend for themselves, leaving many of them annoyed and confused about the purpose of such fundamentals at dream company interviews, like Google and Apple (complaints evident here, here and here).
The best companies also test for other important factors that make a great engineer. For instance, discussing a technical project that a candidate is proud of can reveal knowledge, passion and ability to communicate well. Again, fundamentals can be very easy to learn if you know how much to prepare.

The Root of the Obsession

Since the initial boom in software engineering back in the 1980s, data structure and algorithm questions have been the common way to test candidates. The earliest engineers with growing teams carried CS degrees, and they knew that algorithm classes were a great place that required deep thinking. So, engineers of the 80s created this interview process that resembles algorithm classes. And it works accurately enough. When searching for talent, these questions are fast enough to answer in less than an hour and help interviewers gauge a programmer’s intelligence. It’s certainly not the only way to filter candidates for smartness, but–again–it works well enough.
McDowell theorizes that there might be another reason why companies expect knowledge of data structures like linked lists and trees: It’s hard to find enough algorithm questions that don’t involve these.

“Companies test algorithmic problem solving skills because they believe that people who are smart will generally do good work; they’ll find good solutions, write good code, and so on. I suspect companies continue to expect knowledge of data structures like linked lists and trees (which developers rarely directly use) because it’s hard to find enough algorithm problems that don’t cover this knowledge. And, since enough people have CS degrees, and it’s easy enough for those who don’t to learn this material, it creates a pattern where it’s okay to expect that knowledge,” McDowell says.

Companies deem this system effective because successfully answering algorithm questions are a positive indicator of success on the job. As McDowell says, it means they’re smart and they’re likely to do better work.
However, companies that don’t prepare candidates well enough aren’t giving them a chance to perform well at these fundamental questions. Most companies recognize that some good candidates will be rejected through these questions, but they’re okay with the drawback of missing out on good candidates. They figure, it’s better to reject a good candidate than hire a bad one. The veteran engineer Joel Spolsky, and author of the Trello software, once penned this common hiring philosophy in detail back in 2004:

“It is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees,” Spolsky says.

There might be some validity in the cost per bad hire in Spolsky’s outlook, but rejecting too many good candidates will dramatically increase the cost and time to hire — and ultimately, restrict company growth. All companies should be concerned with this.

Interview Prep is Not ‘Cheating’ and Necessary to Fill Empty Positions

About 10 years ago or so, companies were somewhat more wary about giving candidates preparation material before an interview. It was sometimes considered taboo or even “cheating” because they worried candidates might memorize problems and regurgitate knowledge in the interview.
But that mindset has slowly started to shift as the shortage of talented developers has intensified. In a 2013 survey of over 1,500 senior IT and business executives, more than a third identified availability of talent, employee turnover and labor prices as a business concern.

“Jobs postings will be listed for months without finding a good candidate,” former Zynga software engineer and founder of Appurify, Rahul Jain told TechCrunch.

Given these concerns, it’s actually in a company’s best interest to help candidates with interview prep by giving candidates a chance to practice solving CS fundamental problems. It’s simple: Better prepared candidates lead to fewer false negatives. Plus, most engineers can easily distinguish between someone who’s just memorized answers and someone who can truly solve a hard problem.
The best tech companies realize that it’s actually beneficial to both engineers and companies to give candidates a fair opportunity to put their best foot forward. This is especially true given the obsession with fundamentals that most engineers don’t usually revisit since the good old college days. It’s also a good way to skip the anxiety-ridden phase of the interview and get to other meatier questions that are just as important in assessing candidates, like culture fit and collaborative skills.
Googler Steve Yegge is one engineer who realized candidate preparation is an effective solution to the talent shortage early on. Back in 2008, he “secretly” blogged engineering interview tips for Google candidates in hopes that more of his interviewees would succeed:

Time passes, and interview candidates come and go, and we always wind up saying: ‘Gosh, we sure wish that obviously smart person had prepared a little better for his or her interviews. Is there any way we can help future candidates out with some tips?’
Google doesn’t know I’m publishing these tips. It’s just between you and me, OK? Don’t tell them I prepped you. Just go kick ass on your interviews and we’ll be square….

As late as 2008, people were so against offering candidate prep that Yegge even considered publishing his tips under a pseudonym to avoid upsetting people. Ultimately, his desire and need for better prepared candidates outweighed the risk of earning negative sentiments. This is also a huge reason why McDowell also left Google to start her empire of interview prep about seven years ago. As a software engineer at Apple, Google and Microsoft, McDowell interviewed one too many ill-prepared but smart candidates. She wanted to teach and help more engineers become better interviewers; thus, CareerCup was born.
The best tech companies are starting to realize that the more preparation, the better interview-to-hire rate. For instance, today Facebook hires McDowell for a weekly 1.5 hour class for candidates exclusively for interview prep. She walks Facebook candidates through the problems and even offers tips along the way. Facebook found so much success in this recruiting strategy that they doubled the frequency of her class. Today select top-tiered tech companies, like Pinterest, Google, Airbnb and Twitter, send at least an email that points candidates to resources for better preparation and practice for fundamental CS challenges.
More companies should look at why they’re rejecting great candidates and how they can reduce false negatives to help grow their team more successfully. Empowering smart candidates by setting more realistic expectations for candidates about the interview process is one way to accomplish this.
This decades-old process of testing engineers’ intelligence through fundamental CS questions may be sufficient to identify great programmers. But this process should come with a mechanism (at the minimum an email with links to resources) to help candidates practice these fundamental challenges for the interview. By helping candidates prepare, companies can more easily identify great developers and reduce the bias against older and nontraditional candidates. They can also focus on other important components that are crucial in evaluating strong engineers. This ultimately reduces hiring costs and fuels company growth — a win for the company and the candidate.
Do you prep your candidates before quizzing them on trees and linked list questions? 

Comments (15)

  • Interesting article.
    For all time that I have taken interview, I tend to ask questions that I solved recently – let’s say in past 15 days or so. If a new question took me more than an hour and I expect the same to be solved by a candidate in less than 20-30 mins – it might just prove unfair to him/her.
    But, truth is – I cannot provide a fair feedback without knowing how deep the candidate can go with problem solving. And, if I ever give interview again – I would completely expect very hard questions.
    Also I believe that while problems based on trees might not be the real world problem – real world problems are much bigger and tough to crack (that might just require simpler data structure).
    Though, I completely agree with providing valid guidance to the candidates.

    • Prabodh
    • August 12, 2015 at 6:18 pm
    • Reply
  • IMO it is one of first thinks you learn at university, and it’s so associate with computer science (though programming and CS isn’t same think).
    Another problem is when you ask a average developer to give a question, these kind of questions are safe for him. He will prepare possible solution in advance (so he wont look stupid) and these are questions that his manager will approve as correct (they are so computer related that it should be right). Sad part of course is, that most of the time it’s not job related at all. And even when trees and lists are used, it’s much better to use standard implementation than create your own.

    • ledasl
    • August 13, 2015 at 8:31 am
    • Reply
  • I interned at Google and brought this issue up on a few occasions. I argued that it was bordering on ridiculous to ask people to implement things like self-balancing trees during interviews because we would seriously discourage anyone from doing that in real work. Most employees wouldn’t be able to do it anyway. Some agreed, but I got a strong response once from an employee who claimed to know how to roll his own trees from memory. Also, there are much more clever questions that one can ask to test reasoning abilities without forcing people to memorize non-trivial data structures.

    • Humberto Diaz
    • September 2, 2015 at 11:36 am
    • Reply
  • Ironically, I just completed several challenges on HR using trees.

    • Brandon Theolet
    • September 10, 2015 at 6:02 pm
    • Reply
    • hahahaha, we are going towards ship. Ship is shifting its location…

      • Devendra
      • May 18, 2017 at 6:18 pm
      • Reply
  • Very informative and interesting article Ritika.
    I personally feel that the real world problems which might involve complex data structures and algorithms, are not related to data structures like trees which provide a core functionality in kernels & OS as scheduler algorithms.

    • Akshay Trivedi
    • November 2, 2015 at 2:36 pm
    • Reply
  • That’s why a badge in data structure should exist.

    • Hans Pierre Blanco
    • January 19, 2016 at 5:29 am
    • Reply
  • Thank you, appreciate the info. It could have been organized better (precise) way. Keep it up.

    • Venkateswara Rao Sanaka
    • September 7, 2016 at 6:30 am
    • Reply
  • google showed this as first for some search.
    read this tweet, it might help with something:

    • Manohar Poreddy
    • September 21, 2016 at 5:56 am
    • Reply
  • Is this article aimed at recruiters or candidates? The last line makes it explicit that it is aimed at recruiters.
    I feel like this article is trying to justify why the current system works (understandable, as a change could hurt HackerRank) rather than questioning whether it does work as intended, which would be more useful.

  • I cant agree more. I am a 10+ years experienced engineer and when I try to switch jobs, it is like doing CS grad one more time. Is it possible? Well, with a time taken job already there and a full fledged family with you, it is difficult if not impossible. That is why it is very much inclined towards young bachelors who probably just graduated. See, it is not magic. Even interviewers wont be able to face the music if they are told to do so. Of course, it has very little connection with actual job that one does. Anyway, that said it will be there and nobody will hear our cries. Nobody. Ideally, DS and algos should be tested in some assignment given to somebody with a reasonable time. The real interview should be about how the person designs something from scratch. Again, no body will listen to this.

    • Kaushik
    • December 8, 2016 at 3:16 am
    • Reply
  • Both technical and logical questions are required, but logical should match with person appearing for interview. He should be fine with what you are asking. You shouldnt ask linked list to python guy. He will flip out right there, there goes his hardly earned interview out the door.
    Good practice, I find is interviewer should explain how a certain DS/algo works in basic,
    Now, twist some constraints and ask the person what can be done/what will happen in certain case. This way he can test how a person really approaches problems. One appearing for interview will infact feel welcomed and will be motivated to solve.
    Smart interviewer doesnt need advice, he will look for it himself, idiot ones wont listen. You know the glitch.

    • Devendra
    • May 18, 2017 at 6:32 pm
    • Reply

Leave a Reply

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