Comment by ekidd | Hacker News Reader

Comment by ekidd | Hacker News Reader

Parent Full thread

I've interviewed people in the US, and the first time I asked candidates to reverse a linked list, I was shocked by the results.

Candidate A had a long track record of success, at least on paper. He was obviously motivated, responsible, and likable. He had done a lot of hardware work, and claimed to be a decent (but not top-notch) C programmer.

Candidate B was straight out of college, and he had a weak résumé. We suspected that he had some coding talent, but he didn't have much experience, and we had no idea whether or not he was reliable.

We were leaning heavily towards candidate A. He interviewed brilliantly and seemed like a good fit. Then I asked him to reverse a linked list, and he responded, "Do you have a copy of K&R? I don't remember what kind of braces C uses for functions." After about 30 minutes, he was still trying and failing to find a solution.

When I asked the same question to candidate B, he shrugged, and wrote out a correct solution without stopping to think. So we hired candidate B, and he did excellent work for us for years.

And this is not a one-time incident. It's amazing how many people can bluff their way through an interview without knowing how to sum the numbers in an array. Résumés are full of lies, phone screens are hard to do well, and references are hand-picked by the candidate. So I'm a big believer in coding questions.

I also believe in coding questions but the linked list question in this situation wasn't a good one to use for both candidates.

Why? Well of course the kid straight out of university would answer a question on data structures correctly, he probably did the class for that only a few months prior.

In your example, Candidate A was obviously a no-hire after not even knowing what braces a C function uses but a lot of people similar to Candidate A who can actually code are being presented with questions about linked lists and similar structures no-one who has written code for years would remember, let alone use in their daily work lives.

I want to say again, I'm 100% for coding questions but I think they should reflect more on the type of work you need the candidate to do in the job rather than some academic examples you feel you must ask just because Microsoft/Amazon do.

I completely disagree. If you view data structures as something that you "remember" from your university days, then you are more of a "tool user" than a programmer. No matter what a candidate has managed to accomplish using their IDE and copy/paste adventures, if they can't reverse a linked list on the spot they are a blindingly obvious "no-hire".

This should be the sort of thing anyone looking for a programming job should be able to do as the programming equivalent of muscle memory.

No not really, most professional developers, even using languages with little to no supporting libraries/APIs rarely, if ever, have to write code to reverse a linked list. Of course, given the question in an interview a decent programmer should be able to reason their way through the problem. This is not what I am debating. As a curiosity, I might wish to understand the inner workings of an STL map container, but 9 times out of 10 in a professional environment it is more appropriate that I understand how it should be used, it's pro's and con's and all it's supporting functions. However, even the most novice of programmers can find those answers out with a quick search online.

I guess I just don't like questions where you are required to remember facts you no longer use rather than reason your way through problems you might encounter in a real job.

Here's the thing -- I (and a great many people I've worked with, interviewed, and was interviewed by) don't believe things like reversing a linked list are facts. They're basic skills that are either present or absent.

If you aren't able to do such basic things correctly on the spot, I simply can't trust you to check in complex/highly concurrent/etc code that works. As an IC developer I don't want to deal with your code or clean up your mistakes. As a manager, I can't trust you to write code unsupervised.

This quote in particular would be a massive red flag and probably the end of an interview: "it is more appropriate that I understand how it should be used, it's pro's and con's and all it's supporting functions". In most companies, what's being sought is not someone who can just use the tools as appropriate. It's someone who can develop new tools and solve problems for which there isn't a pre-canned answer available. If you don't know how to solve the problems for which trivial answers exist, how can anyone expect you to be able to reason through truly novel and difficult problems.

The sort of attitude you're espousing is perfectly fine for large ERP/custom corporate app/corporate website/etc programming work. It's just not what people in the valley are doing.

I understand what you're saying but feel we're comparing different things. Yes, in an interview saying the thing you quoted would obviously be a red flag, and something I would never say. I understand the need in interviews to impress using your problem solving skills. However, I believe that in your day to day job as a programmer, that quote is more appropriate - that you understand how particular data structures should be used rather than it's inner workings. In this case, if we assume that the reason you're being interviewed is so you can do well at the day to day stuff, then my quote makes more sense.

I get you though; you want someone who can solve many new problems but it highly unreasonable to put a programmer in an unrealistic situation like an interview and expect them to perform just as well as they would on the job. Unfortunately I have no answer on how to improve the interview process but it still bothers me that a better way hasn't been found.

Not many people even use linked lists anymore anyways, unless they are programming low-level things and even then it is often more efficient to use a growable array, something like List<T> in .net or vector in C++.

Reversing a linked list is not about how linked lists work. It is a very simple question which verifies that a person knows what the pointers are and how to use them, can write simple loops which manipulate pointers and can handle simple things such as 1 element lists, 0 element lists etc.

I wouldn't consider reversing a linked list a data structures question, it's a coding question. Everyone knows what a linked list is and that you have to iterate through it and flip the "arrows". The tricky part is being able to maintain all the pointers and know how to order your operations and handle any edge cases. That's what questions like these are supposed to check for, can you actually articulate into code a solution that you understand on a high level in your head.

It's absolutely a data structure question. You have to know what functions are available to you from within the data structure.

For instance, in a singly linked list you only have the function "getNext()" and "getHead()"; in a doubly linked list, you have additionally have the function "getPrev()" and "getTail()". If parent asked me this question in an interview I'd probably jokingly say "well, you didn't specify doubly or singly, so I'd just call getTail and then getPrev until I was done!" And then I'd write a recursive function for a singly linked list because everyone likes recursion.

How could you possibly answer this question if you didn't know what a linked list was? If you never took a data structures class, you probably used "lists" but you have no idea what the bare bones construction is. Just using lists doesn't mean you know how to write one from scratch.

If for some reason you don't know what a linked list is, you can always ask.

I think it's about admitting when you don't know something just as much as it's about being able to reason through the problem and give a correct answer.

All else equal, I'd much rather hire someone who didn't know what a linked list was, but asked and answered correctly, than someone who pretended to know and limped their way through the problem, even if they did eventually give a correct answer.

Linked lists are so fundamental, not knowing what they are is a big red flag. Anyone with even a modicum of curiosity about this field, college educated or not, should know what a linked list is, its complexity, and how it is structured.

I meant it's not a data structures question in that it doesn't ask anything particularly prodding into understanding deeply something intricate about a data structure. I assume any CS student knows what a linked-list is and can figure out that it has a getNext() function. It's more about coding than understanding a linked list.

but a lot of people similar to Candidate A who can actually code are being presented with questions about linked lists and similar structures no-one who has written code for years would remember, let alone use in their daily work lives.

Your reference to "remembering" is entirely irrelevant. What is relevant here is whether the candidate can reason through the problem - and more power to the candidate if s/he's been out of school for N years. What I strive for with technical questions is not to find out how well the candidate remembers their Knuth( although finding someone who actually read Knuth is nice ) - it is to determine how well they think through problems. And with no offense intended, if you can't at the very least come up with some ~3N complexity stupid-but-it-works stack-based solution to the problem of reversing a linked list, you probably shouldn't be a professional developer.

No offence taken, I do actually know a lot about linked lists, trees, graphs and so on. Partly from past experience, partly from reading technical articles and partly because I've researched the type of questions asked and therefore brushed up on these questions.

I guess the main argument I have is that I don't believe these are the best way to find out if a developer will be good at the position being offered. But I can't think of a better solution (other than getting them to work a trial period) and others seem to like this way of doing things. Therefore I will learn and adapt, which is the way of programming anyway :)

Reply on news.ycombinator.com