Is it bad interview practice to have candidates write a linked-list implementation?

Question

Reading this site and SO I've seen many stories of interview questions and answers saying a candidate had to implement a linked list from scratch. Usually this is a "gimme" exercise for programming role candidates like writing FizzBuzz. The idea is that if the candidate can't do this, they can't program and should be rejected almost immediately.

However, I can't help but think this could be a poor practice for the following reasons:

• Modern higher level languages like C# and Python natively use lists extensively; writing your own linked list object would be only required under unusual circumstances and even then probably ill-advised.
• Lower level languages like C++ have standard libraries with iterators/list containers and objects.
• In light of the first two points, coders can go years without even thinking about implementing a list (linked, doubly-linked, etc) themselves. Some may not even really see such things since college days.
• Computing power also isn't the factor it was years ago, so efficiency via pointers isn't the issue it used to be (in general).
• A simple web search of something like "linked list example" would bring up plenty of code examples that could just be memorized and spat back out, not really indicating the true competence of the applicant.

I should say that using a linked list to lead to open-ended questions/discussions of candidates' problem solving/critical thinking abilities is mostly likely a really good interview practice. Any way an interviewer can really see what an applicant is like and how they think is massively beneficial.

I think this binary approach of "no linked list code, no job" for programmers working on a desktop or web application is a bit outdated. It could also be quite harmful; a candidate who can't remember how to properly work with the head of a list could be an otherwise excellent coder and co-worker and be lost in the mix. Thoughts?

EDIT: There are many (good) comments suggesting that whether this is a good or bad question to ask depends on the context of the job. I strongly agree, so let me rephrase this question: Implementing a linked-list is a common interview question for a wide range of coding jobs, similar to questions like FizzBuzz or writing a recursive function for calculating factorials. Does this question have enough utility to be used commonly for evaluating programming candidates across the board? Or should considered a bad question to ask except for "Senior Developer, Embedded Linked Lists Team" positions?

Answer 1

If answering the question tells you what you want to know about a candidate, then it's a good interview question. If it doesn't tell you that, it's a bad question.

Easy questions like FizzBuzz do serve a specific purpose. If a candidate can't code FizzBuzz, they simply can't code and you can end the interview early. I'd rate implementing a linked list only slightly harder, but it can start a conversation about data structures in general that will reveal a lot.

Just remember that no single interview question will tell you everything you want to know. You really need to have a group of questions ready. You should ask questions in a sequence from easiest to hardest so you can find the limit of what the candidate knows. If you ask one question and they nail it, you still don't know what else they do or do not know.

---

Regarding your edit:

Does this question have enough utility to be used commonly for evaluating programming candidates across the board? Or should considered a bad question to ask except for "Senior Developer, Embedded Linked Lists Team" positions?

I think it is a good general purpose question that could be used for evaluating practically any programming candidate. It just needs to be part of a larger group of questions. It would be a good ice breaker for many types of position (even if the candidate can't implement a linked list from scratch, maybe they can explain how they've used one before and what the key functions are), or the beginning of a long sequence of more advanced questions for the "Senior Developer, Embedded Linked Lists Team" position.

Answer 2

I have missed out on jobs purely because my mind blanked on simple puzzles like this. I've also done brilliantly on such puzzles in other interviews -- I know how to implement a linked list in a non-pressure environment. I've never had a complaint about my abilities from someone I've worked with, so maybe I shouldn't think that I've missed out on jobs, I should think that they've missed out on me.

So yeah, I think it's a questionable practice at best, but I do understand it. I have also considered the possibility that it's not the fault of the question but the questioner, for making it a high-pressure situation.

Personally, I prefer to ask open-ended questions about a problem the candidate has already solved -- recently, if possible, and covering both coding and process problems. If they can bring code-samples, fantastic.

Answer 3

One has to define the programming job type. If you are in the business of developing compilers and algorithms, questions about such things should be expected. If you are in line-of-business type applications and you expect the candidate to do CRUD applications, then, may be the knowledge of the concept (without writing a program) is sufficient. Today, the knowledge of different technologies required to get the job done specially in the LOB type of applications supersedes the need for neat algorithms.

Answer 4

My answer is "It depends". I would ask this question if a candidate has listed C or C++ on his resume. Asking to implement a linked list is a good test for the understanding of pointers which is absolutely essential for a C or C++ programmer.

On the other hand, if a candidate does not claim to know C or C++, I would not ask him to implement a linked list, but I would consider asking questions about it. Explain at a high level how a linked list works. What is the complexity of adding an element to the head of the list? The tail of the list? Inserting an element in the middle of the list? When would you use a list as opposed to an array? These are fundamental data structure concepts that, IMHO, every programmer should know.

Answer 5

I wouldn't consider it a bad interview question. A lot of data structure understanding and programming starts with a really good understanding of Linked Lists. That said, there are some caveats:

1) It is a fizz-buzz type question. You are just validating something very basic: Does the person understand a linked-list. Ask it and move on.

2) There is the challenge with linked lists that the languages that are highly suited to showing your understanding of linked-list concepts (e.g., C) may not the same as the language they will be working with on the job. You can demonstrate basic understanding in any language with structures, of course, but asking a candidate to re-implement a linked list in Erlang without using [] isn't the same challenge and won't tell you the same thing about a candidate's understanding as asking them to do it in C. Asking them to do it in C if the job is around Java is also missing the point somewhat.

3) With that in mind and the general challenges of "whiteboard programming," when asking this sort of question I'd accept pseudocode or diagrams so long as they demonstrate understanding of the core principles. I don't ask that people write code on a whiteboard that is syntactically and logically perfect, especially if they can then turn around and identify any logical problems when asked to look at it again. YMMV.

Answer 6

When I was giving interviews, I was often asked for linked list implementations and some algorithms centered around linked-lists. I solved most of them, and some of them required me exercise my neurons a bit.

If I was ever taking an interview, I would go for some sort of a linked-list implementation, not to test how good a person is in coding, but to check how much attention a person pays to details. Anyone can write a linked list, but it is the boundary cases that even some good programmers fail at. Don't ask him: Write a code for linked list in C/C++. Ask him to write a generic linked list in C (not C++), etc.

Twist the problem, and put some other conditions on the linked list, and you'll have a good question to ask. Some people are bound to make mistakes then.

Answer 7

In my about 10 years so far programming professionally (and around another ten years as a hobby), I don't think I have ever needed to implement a linked list. If someone asked me to do it during an interview, I might counter by asking if that's something I will be doing regularly on the job.

For sure, there almost certainly are jobs out there where you will need to write more-or-less-cleanroom implementations of commonly known algorithms - like implement a linked list from scratch. But for most programming jobs, what specific value does it have for the company that a candidate can do it during an interview? Is it really so important in such a setting that the candidate provides a perfect implementation which handles edge cases correctly, reports failures according to common practice in the language or framework, and so on? Or can you overlook that and instead focus on how they actually approach a problem that they perhaps haven't been faced with in 10-20 years?

When I interviewed for my current job, I had very little experience with the technology stack in use at the company. Now, a few years later, I regularly have colleagues come to me and ask questions not just about the products, the implementation of them, and the standards implemented by them, but also about much more general programming problems (just yesterday I was asked what the implications were of a circular dependency in a default constraint in SQL Server in the context of a particular table and its usage in our case - reasoning through it, it turned out that there were no implications in that particular case). I didn't need a brand new linked list implementation for that, either.

Ask questions that are relevant for the work that the candidate is likely to be assigned, and try to get an idea of how they feel about picking up new knowledge. How would they go about figuring out the meaning of some obscure syntax they have never seen? (If you are a C shop, for example, then you might try a question involving trigraphs.) For a programming position, do they regularly read or contribute to forums such as Stack Overflow? If they were asked to perform some task in a programming language or framework they have little or no experience with (say, if you are primarily a Java shop, what about Clojure or .NET?), then how would they approach the problem? Maybe take a real bug out of your bug tracker (might even be one that's long since resolved) and ask them how they in general terms would approach solving it, and be ready to explain the relevant parts of the product in question.

If the candidate can handle business-case-relevant types of problems and has a good attitude toward learning new things, that's probably a much better indicator of fit for that particular position than being able to provide canned responses to well-known questions, whether those questions are about FizzBuzz, linked lists, or something else. Throw in how well the candidate fits with the team and I would think that you are on fairly safe ground.

Answer 8

Of course most people would never need to implement a linked list, but to implement them from scratch one will probably need to handle pointers correctly. They idea is then that having formed a consistent mental model for pointers correlates with the language proficiency, understanding what happens on some (abstract) machine level and the ability to abstract in general.

I am not saying that this would necessarily be the best measure, but only that there is some correlation.

Answer 9

You start out saying that they're 'gimme' questions, but then you point out that people will understandably not be able to do them. I'm confused.

Here's how I think about it:

• There's rarely a need to write one, as you say, so people will have easily forgotten.
• They're not incredibly difficult to write.
• The concepts used to write them can be considered fundamental.
• They're used incredibly often (even if you're unaware of it).

I think that makes them good questions to ask. If you're worried about them pre-studying for the interview, then throw in a list. Have them write it circular and ask what the asymptotic running time of their implementation is. Or have them write another common and/or quick data structure... A binary search tree? A queue (FIFO)? A stack (FILO)? A naive (O(n)) priority queue? Lots of people I know think that a BST is O(log n) just because it's a tree.

If you're looking for someone who will be working at the metal, and needs a very solid foundation in data structures... these may even be far too trivial for the candidates you're looking to hire.

This assumes, of course, that you want a dev who has the basics/fundamentals of data structures and their position would benefit from those fundamentals. If you want someone who can throw together an asp page in seconds, interview for that. The point is not to pick an interview question because everyone else does, but to pick one that measures the skills you're looking for. Personally, I think data structures questions are good, linked list or no.

Answer 10

Does this question have enough utility to be used commonly for evaluating programming candidates across the board?

No, absolutely not. Depending on how it's phrased, what it will tell you will range from "this candidate knows how to design a linked list" to "this candidate can program a linked list in language X". If you ask for pseudocode, it will tend more toward the first. If you ask for an implementation in a particular language, you will get more into their understanding of the language (especially with C and C++, where you can deal with pointers and references and structs).

I'd even go so far as to say that it's not possible to evaluate all candidates using the same questions. You need to tailor your interview questions to assess the skills that you are looking for in the position.

If the person is going to be in a position to write code, I'd think about including an algorithm and/or data structure question, as long as it was relevant to the position. I'd try to pick something that might have been discussed or used before. I'd also focus on things other than just the implementation of said algorithms and data structures, such as the running time and memory consumption (things like big-O notation). These concepts are relevant to not only creating the data structure, but also choosing which implementation is best suited (such as an ArrayList versus a LinkedList for example).

Answer 11

I dont think for a regular programming job should be a question that eliminates a candidate. But its a good one to see if you are dealing with a really senior programmer or someone who just has been monkey coding forms for a lot of years. And even so, it shouldnt be a fundamental criteria for choosing a programmer. Maybe is a great programmer with bad memory and hasnt read the words "linked list" on years (or doesnt remember the name) but still can do good apps.

So, as some said, if is going to be a job that need to work with linked list and a lot of fancy algorithms, etc.. then ok. Is if for the usual input data on a form, validate and show is kinda useless and unfair.

Answer 12

I think that this is a bad example of an interview question, but for a different reason. A linked list is such a simple concept that to know what it is is to know how to implement it. If the person doesn't know what a linked list is, then you have to explain how it works, and in doing so you give away the answer without discovering anything about whether or not they know how to solve problems. So the question is reducible to "do you already know what a linked list is and how it works?", which tells you nothing useful about their suitability as a programmer.

Answer 13

Writing a linked-list implementation is a good interview question, because it will reveal a lot about the candidate's way of coding:

• Does he know what an API is? Can he use other people's code? Can he write code so other people can use it?

• Does he know what a Linked List is? Does he know Collections, Data Structures, Algorithms?

If he doesn't even know what methods a Linked List should offer, you know he probably never used one, or knows when to use one.

• How does he handle the problem? Does he start with an analysis first, a small specification, some tests beforehand? Or does he just start hacking away happily?

• Does he handle edge cases? What about removing the last node from the Linked List? What if someone tries to add a reference to the linkedlist itself to the linkedlist, and then deletes the whole thing?

• Does he handle exceptions? Each programming language has their own conventions for handling exceptions: in Java, you'll expect a LinkedList to throw a NoSuchElementException when you do a getFirst() on an empty list. Other languages might return undefined, -1 or a constant.