Hacker News Reader

Comment by beagle3 | Hacker News Reader

One of the interview questions I've used in the past is "reverse a linked list".

Indeed, you (almost) never need to reverse linked lists in practice - but you often need to chase references of one kind or another (database, pointers, etc.) and do some manipulations on them that would result in a different list. If you have 20 data points, it doesn't matter what you do, but if you have 100M or 10B points, it makes a great deal of difference whether you do O(n), O(n log n) or O(n^2) or O(n!).

I think this is a good question, because it is an abstract version of the kind of problems that any non trivial code has to address. It is easy to describe, and easy to solve if you know what you are doing. I don't use it anymore because it's too common to be useful.

And yet, through the years I've gotten the feedback[0] that it is "far detached from real work", "tests how good I did in school rather than how good I am" and various other comments -- and almost always from candidates who did poorly; I've never gotten this feedback from anyone I would consider competent.

[0] I try to get feedback through whoever referred the candidate, whether it's the friend-of-acquaintance, or the recruiter. I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter).

View on HN

> I think this is a good question, because it is an abstract version of the kind of problems that any non trivial code has to address. It is easy to describe, and easy to solve if you know what you are doing. I don't use it anymore because it's too common to be useful.

This is precisely the problem the OP is talking about. When's the last time you ever did anything as low level as reversing a linked list? It's a solved problem, and something an employee would NEVER do in your company, let alone search for the optimal solution in 10 stressful minutes while you breathe down his neck.

> And yet, through the years I've gotten the feedback[0] that it is "far detached from real work", "tests how good I did in school rather than how good I am" and various other comments -- and almost always from candidates who did poorly; I've never gotten this feedback from anyone I would consider competent.

Major red flag. I don't mean to be rude, but this sentence comes off as very arrogant.

> I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter).

Why? Because they're in a lower caste? If you can't handle direct feedback, you're a terrible manager.

>This is precisely the problem the OP is talking about. When's the last time you ever did anything as low level as reversing a linked list? It's a solved problem, and something an employee would NEVER do in your company, let alone search for the optimal solution in 10 stressful minutes while you breathe down his neck.

The thing about such things is I know I can do it. But maybe it'll take 5 minutes, or maybe an hour. Maybe I'd attempt to do it differently given an unfamiliar scenario for which to be doing this in the first place; maybe I've never done this specific task in this specific language, and I'll take some extra minutes figuring out how pointers or references work in the language I'm using in the test. Maybe I've recently enjoyed some momentum on high level concepts (i.e. I produced software that fulfills a business need) and it'll take me a while to refocus my attention on low level implementations.

Engaging one's brain carries some very variable overheads. If you just give me 5 minutes and watch me write every single line of code and comment about it while I'm doing it, then it's just not going to happen.

You guys do realize that reversing a linked list is not 'solving a difficult programming puzzle'? Seeing the number of applicants that can't read lines from a file (in any given language), I'd say this question is adequate if you want to employ someone with programming experience.

You're right about that particular exercise. I kind of used it to make a more general point.

Indeed. For the record, I let people take however much time they need, if they get stuck I ask them to discuss their approach, etc. I'm not looking for the solution (as parent said, it is a solved problem), I'm looking for evidence of problem solving skills. And you can demonstrate them, even for this question, without actually being able to write down a working solution. (I don't want to go into everything here, but one of the things I look for is people who consider the case of an empty list - critically thinking about special cases is an important trait)

That said, work environment often has some kind of time constraint. If one can't solve any of the (simple, abstract, representative) problems that I pose within a 2hour time frame, it is possible that they are not a good match. And unfortunately, I rarely have the leisure to hire someone for a month to prove otherwise.

[from a comment of yours below]

> You're right about that particular exercise. I kind of used it to make a more general point.

That may be true for others, but my interview questions are all of this mold: abstract, with a short and simple (but not trick-required-here) solution, close to (an abstract version of) a real world "business problem".

I agree that technical interview questions (much like many aspects of life) put the wrong kind of stress on some and puts them at a disadvantage. But, and I always ask this[0], what alternative do you suggest?

[0] The answers so far have been essentially either "no idea", "let me prove to you on my terms" (which, when broken down, is rarely economical for either side or at all possible), or "just trust me on this"; I find none of them satisfying.

Then I'd say you have some pretty decent justifications for your approach. I'd take the negative responses you got as constructive rather than inflammatory: if it made you review your justifications and think again about whether approach is fair, then they did their job.

In many ways, writing on the Internet is much like the interviews we are discussing, especially in a place such as this, which has so many highly opinionated experts. I get why you got hostile responses to your post, but I also get what the reason for writing that post was. In person, the exact same words would not have lead to such a high-strung feeling as one gets when posting about anything controversial on the Internet.

On the Internet, if you go out on a limb, someone will always cut the branch.

> When's the last time you ever did anything as low level as reversing a linked list?

It's a topic covered in a sophomore-level data structures course over just a few days. If a college sophomore can pick it up that quickly (and "sophomoric" is a word for a reason), it should be no problem for a seasoned programmer to (re-)learn it in a couple of hours.

How about in 10 minutes at a whiteboard while the interviewer waits patiently to judge you?

> When's the last time you ever did anything as low level as reversing a linked list? It's a solved problem, and something an employee would NEVER do in your company

I think that misses the point. A linked list is a simple data structure that needs little explanation, and yet uses indirection in a way that can get you into trouble. As such, it is a great toy problem to asses a person's ability to work with linked data. Reversing a list, is similarly, very simple to explain, and a quite rudimentary operation.

So if I'm trying to asses basic ability to manipulate data in code, it seems much simpler than trying to give them a real-world linked data structure and have them do a real-world manipulation on it.

The real problem is the assumption that this is a 'solved problem', i.e. that a) there is an one-true-way algorithm out there, and b) that is what the interviewer wants you to know (i.e. know in the sense of knowing a fact). That is true of too many interviewers, and that is the problem.

I can imagine setting that as a question in an interview. And I wouldn't be interested in 'the algorithm', I'd want to see that someone could figure it out easily. If someone came in and clearly had just learnt it, it would tell me nothing. I would immediately ask them something else to take them out of their rote prep. But if someone came in and couldn't figure it out, why would I think they'd be any better on 'unsolved problems'? In terms of being able to manipulate data, it isn't much beyond Fizzbuzz.

The 'it's a solved problem' attitude smacks of leftpad thinking to me.

Exactly. As an interviewer I don't get any data if you have an algorithm memorized and throw it on the board. I'm trying to assess critical thinking and problem-solving skills, I've voted to hire many people who clearly had never seen the problem before, didn't get a working solution in the time we had, but demonstrated great problem-solving approach.

I almost exclusively give candidates realistic tasks (slightly modified real world tasks) and give them under realistic conditions (free access to google, candidate's own laptop preferably).

It perplexes me. What do you gain by not doing that?

Research mathematicians are made in large part in the process of taking classes with tests for several years. Why don't they just ask the students to write papers if that is the end goal?

The tests, homeworks etc. are largely production of papers, on a lower scale perhaps, and interspersed with notes, but as far as I know not multiple choice nor mere reciting definitions or trivial algorithmic execution as most of the stuff is not concrete. I'm not a maths student so my maths tests are of the latter variant.

Whether you can give real-world questions depends a lot on the domain. If you're using popular open-source tools, you may be able to test a candidate on the ability to complete standard tasks with them. But what if you're using tons of proprietary software and working in a specialized domain where you expect people to learn on the job? That was the case where I used to work (quant finance). We need programming questions that assess candidate's general ability rather than anything domain-specific. The linked-list question is a perfectly fair non-domain-specific question.

>But what if you're using tons of proprietary software and working in a specialized domain where you expect people to learn on the job?

Then use it in the test! If you're judging people on how well they pick up proprietary software, give to them and make them do something with it.

My tests usually involve giving the candidate exposure to some software/module or other which they were not previously familiar and I judge them on how well they can work with it, applying general programming knowledge they will actually use day to do in the process.

But then, more likely than not, your testing how long it takes someone to learn your stack, and not how well they can solve problems once they're using your stack.

(or in other words, total time taken to do n tasks is mn + b, where m is the efficiency when using your stack, and b is the time taken to originally learn your stack. b is relatively large, so with n=1, that's a very different thing than with n=100.)

"But then, more likely than not, your testing how long it takes someone to learn your stack"

It tests how long it takes somebody to learn a small part of it, certainly.

Would that not be relevant for a job where you intend for them to learn your stack?

"not how well they can solve problems once they're using your stack."

A properly structured test could (and, clearly, both of our cases, should) accommodate both - to begin with, the ability to find their bearings in code with which they are not familiar and subsequently to solve problems within that context.

I usually do tests like this that last 45 minutes.

My edit more clearly explains the issue:

>or in other words, total time taken to do n tasks is mn + b, where m is the efficiency when using your stack, and b is the time taken to originally learn your stack. b is relatively large, so with n=1, that's a very different thing than with n=100.

For clarity, I work at google and I'd argue that for all but the most trivial problems, it would take even a good candidate more than 45 minutes to get their bearings. Most new hires do multiple days worth of codelabs before sitting in their desks.

In my experience the time it takes for programmers to get their bearings isn't necessarily about the triviality of the problem - it's usually about how decoupled/isolated the code you are working on is.

Sure, but my point is that it really doesn't matter when everything is unfamiliar. Imagine I put you into a situation where you're using piper, bazel, gflags, and protobuffs instead of git, make, argparse, and json, its going to take time to get your bearings no matter what. You'll have to figure out 2-3 new syntaxes.

Sure, you can limit scope, to things with 1-2 files where everything is handled for you and no data transfer between systems, building, or commiting required, but then we're getting into a class of problems where your limited to relatively simple, logical issues with very well defined APIs, a class of problems that data structures fit very, very well.

Time and (therefore, because interview time is limited) thoroughness.

A simple task on a linked list takes two minutes to explain and five minutes to solve. The kind of task someone might do for me day-to-day have a whole bunch of context, and require knowledge or explanation of architecture and data configuration. I don't want to spend more than a couple of minutes explaining the problem, just to test whether they can program their way out of a paper bag.

>A simple task on a linked list takes two minutes to explain and five minutes to solve. The kind of task someone might do for me day-to-day have a whole bunch of context

>The kind of task someone might do for me day-to-day have a whole bunch of context, and require knowledge or explanation of architecture and data configuration.

Did you think I wouldn't have to face this problem too?

If you can't decouple one relevant chunk of code from your software sufficiently to be able to give it with a minimum of context to an interviewee then I'd have serious questions about the level of coupling in your codebase and, by extension, your programming ability.

Thank you :D it always comes down to a pissing contest.

It's okay, we're very unlikely to work together. Feel free to keep doing it your way, and I'm not going to worry about a random HNer impugning my coding ability based on a comment about interviewing style.

No hard feelings. Honestly, I'd have a much harder time hiring if half the rest of the industry wasn't irrationally cargo culting Google's hiring practices.

Ah, I see, then I don't think you read the GP post, or I wasn't clear enough, since that is exactly a point I made.

Also, if you're only giving real-world work tasks, do you screen at all for basic competence first? I ask because I suspect we're talking about different things.

Also 2 (edit), does your work only involve one kind of task? How do you assess the breadth of their basic understanding without using simple problems? Are your programmers doing very repetitive stuff?

>Also, if you're only giving real-world work tasks, do you screen at all for basic competence first?

I've done both with and without. I honestly found it hard to make judgments about what effect what I was doing was having on the hiring funnel though.

If you're talking about that rather than later stage hiring then yes, I agree it's a different kettle of fish.

> Did you think I wouldn't have to face this problem too?

Yes you would. You would not faced that problem on the first day of job and you would be expected to take time to learn during first days/weeks of the job (depending on complexity).

Also, once you will have that context and understand architecture and data configuration, the task will boil down to "reverse the damm list" or "write one epic sql query" or alternatively "read this epic sql query and refactor it away for christ sake".

> The real problem is the assumption that this is a 'solved problem', i.e. that a) there is an one-true-way algorithm out there, and b) that is what the interviewer wants you to know (i.e. know in the sense of knowing a fact). That is true of too many interviewers, and that is the problem.

These "solved problems" are the result of countless hours of research by computer science experts with masters and Ph.D degrees. For those of you who studied computer science in college, you likely had lectures where the teacher or TA walked you through the process of resolving each of these algorithms.

Unless you are hiring for companies like Netflix, Cloudflare, Google, etc. where you basically need to invent new fields of research in computer science, expecting a programmer to "come up" with the same solution in 10 minutes a team of CS experts solved after many hours of research might be a little unrealistic.

> These "solved problems" are the result of countless hours of research by computer science experts with masters and Ph.D degrees.

We're talking about reversing a linked list, right?

This is the second time I've had this kind of surreal conversation on HN (the first was summing a list of integers), and I confess I am completely baffled. We are talking about reversing a linked list.

I absolutely expect somebody with a even minimal programming competence to be able to perform simple manipulations on interconnected data. And I can't imagine a much simpler manipulation, taking into account the connections, than that.

Knowing the difference between a problem that you can solve intuitively, And one that requires hours of PhD research, is also a good skill to have.

Yeah, dont worry about him. I fully agree with everything you are saying.

Yes, it's only a linked list, and reversing it is trivial. The problem comes with the inevitable "OK, now how would you make it more space/time efficient?" question. I've had it countless times, and it's always infuriating because the answer is out there, on google, written by some PHD ages ago. The interviewer himself has read it, which is why he knows, and yet now he expects me to come up with something comparable in a "clean room" situation, usually involving a white board.

Really, those kinds of questions such as algorithm optimization only test your ability to come up with creative solutions in a stressful and time constrained situation. And even then you're not testing that because even the best of us will experience temporary brain paralysis in stressful situations, so you're actually just testing for luck.

And if that's what the working environment is like, fine so long as the candidate knows it's always like that and accepts those conditions (I wouldn't). But if that's NOT what the working environment is like, why are you even testing for it?

Really? Reversing a linked list? It really doesn't take a PhD to do that in O(N) time and O(1) space. I don't remember 'reading' an algorithm, isn't it just obvious that you walk through the list flipping the direction of the links?

Now of course, I'm making a specific point about a specific question. I'm not making a point about all 'algorithm whiteboard' interviews. Maybe you misunderstood the point, and thought I was. But I agree, many of them are utterly bonkers. Nobody is going to intuitively derive Floyd Warshall's algorithm with a whiteboard in 10 minutes. And coding trivia interviews are always pointless. If you can learn the right answers to 'pass' my interview, I'm not doing a very good job, imho.

But for very simple things like basic manipulation of the the simplest possible data structure involving a reference, I absolutely think a minimally competent programmer should be able to demonstrate their ability. Can you reverse it? Can you rotate it? Can you split it into buckets? Can you twizzle pairs? Can you insert in the middle? If you can't do those things with a cons-cell, in O(N), I can't imagine how you would cope with basic manipulations on more complex data.

Where I work, I deal with call processing (the stuff that happens when a call is made between two phones). If I were doing an interview, I might ask "We now have to deal with SIP, which means dealing with SIP messages, which are text based. We use C and C++ in this department, but we're open to other languages depending upon ease of integration. Which languages and libraries would you use to parse SIP messages, and why?"

It's a problem we face (or rather, faced and solved [1]) unlike reversing a linked list (or implementing a Red/Black or AVL tree or sorting data).

[1] Lua (very easy to integrate with C and C++) and LPeg (for parsing text).

TBH, that depends HIGHLY on the context. If I'm not familiar with Lua, do you not hire me? I'd answer "flex and bison" because they're (for me) extremely easy to work with, rest on solid theoretical foundations, have great tools for checking & understanding you grammars, and produce blazingly fast parsers - probably orders of magnitude faster than whatever you do in Lua.

Oh, and the parser code is C, so it integrates perfectly.

I would accept that (maybe with a follow up question if the code generated by flex and bison is re-entrant; I know that the older lex and yacc aren't). I also would accept "I would first look for an existing library that can parse SIP messages in C or C++." I might seriously question you if you answered "I would write code to parse SIP messages in C or C++".

And for the record, flex and bison might be faster than Lua and LPeg, but so far, it hasn't been an issue.

> if the code generated by flex and bison is re-entrant

This has been fixed long ago, you can definitely get reentrant parsers if you need to. Also, I don't know the SIP grammar, but fwiw, I'm able to write an extremely clean recursive descent parser in C++ (1); for simple grammars, it's often an overkill to go the flex/bison route. Also by "writing code to parse messages in C++" someone familiar with boost might be thinking about using boost::spirit. That's not necessarily a bad choice.

(1) Just looked - it's in fact too complex for that; but the point is, the right tools are dependent on the skillset of the person who answers, which may be different from your own/ your team's. Just because you find writing parser by hand daunting, doesn't mean that I do (I taught compiler design at the university, worked on a commercial C++ compiler, wrote many parsers).

Your interview question is good - but the key to it is the "why" part, not the answer of "how would you do it". And it's simply a different sort of question - your question tests the mindset + domain knowledge; The "reverse a linked list" question aims at filtering-out the developers that are not worth loosing time with. A developer that can't reverse a linked list is completely useless in a C++ project (in fact, his contribution is likely to be negative - doing more damage than adding value).

> Unless you are hiring for companies like Netflix, Cloudflare, Google, etc. where you basically need to invent new fields of research in computer science

Hmm. Scratch Cloudflare from that list. We are not 'inventing new fields of research'. We are looking for smart people of all sorts of backgrounds to come work on our stack.

> But if someone came in and couldn't figure it out, why would I think they'd be any better on 'unsolved problems'?

It's an easy problem for sure, and I yet I could imagine many a competent programmer to lock up for reasons that have nothing to do with the problem and everything to do with the situation and sense of pressure they might experience during it.

I haven't worked on shrinkwrap software since 2006. For the last eleven years, every developer role I've had required me to be on call and troubleshoot when prod fails in the middle of the night. If you can't be relied on to do that, there are only certain teams that can use you, and I don't conduct their interviews.

The stress from a interview is vastly different from the pressure of fixing a prod issue.

It's like saying standup comedy prepares you for 3AM calls.

Yep, you have the "far detached from real work" reaction.

Plus, if you consider "you" (or an imaginary candidate you project yourself upon) risk not being able to answer it in 10 minutes because of such the high pressure it would put on you, then it basically means that you did not even try to answer it in your head, or that you were not able to.

But this is the moral equivalent of asking a person who pretends to be a mathematician to do a 3 by 3 figures multiplication. It won't show much if they answer correctly (at least demonstrate a correct method to do it, never mind potential mistakes), but you can easily dismiss them if they fail.

Now programming is a little bit different, because I admit there can be some positions where people can somehow contribute despite being incapable of lots of basic things. It depends on several factors, though, and even then I'm not sure the end result would ever be very solid. But I understand that in some contexts, such people would not be hired...

Wow, it appears my point was completely missed (and I was otherwise painted as a bigot), so let me try to explain better.

> It's a solved problem, and something an employee would NEVER do in your company, let alone search for the optimal solution in 10 stressful minutes while you breathe down his neck.

Actually, just a couple of weeks ago we had something almost equivalent, that involved chasing "pointers" through databases and files. It was for less than 1M cases, but still - any O(n^2) solution would have been infeasible (and an nlogn solution about 20 times slower than an O(n) solution; in this case, it was a one-off, and the difference would have been between 1hr of runtime and 1day of runtime).

> When's the last time you ever did anything as low level as reversing a linked list?

Please re-read what I wrote. I wrote, in fact, "you (almost) never need to reverse linked lists in practice". I also explained that it is an abstract version of a kind of thing that DOES happen often.

> Major red flag. I don't mean to be rude, but this sentence comes off as very arrogant.

Perhaps. For all you know, I'm a dog, but I'll say that I'm soon entering my 4th decade in the industry, I'm well respected, I've hired (and fired) tens of people through the years (and interviewed hundreds if not thousands); and I'm well respected among my peers for having very accurate evaluations of people's abilities. I do not aim to be politically correct.

> Why? Because they're in a lower caste? If you can't handle direct feedback, you're a terrible manager.

No, because I've just hired them, or just didn't hire them; either way, I think it is irresponsible to trust the statement of a person I don't actually know and who may either hold a grudge or want to please me right now. I meant to say "direct immediate feedback", which is perhaps better wording.

After I know a person, I ask them (and usually get) the most direct and raw feedback I can get.

> it was a one-off, and the difference would have been between 1hr of runtime and 1day of runtime).

What's wrong with 1h vs 1d for a one-off thing? Your effective delivery time would be close enough to equivalent after all the administrative BS and customer expectations, and a naive approach piss simple to verify.

If it was going to mean the difference between 1h and multiple days, here's what I'd do:

- Fire up my trusty browser.

- Navigate to google.com

- Type in "reverse a linked list"

- Evaluate all of the solutions I find and pick the best efficiency / verifiability match to solve the problem in a reasonable amount of time.

Are you going to test that in an interview question? No, you're going to effectively "whiteboard" me, asking me to reinvent the wheel on the spot. And I'm going to resent you for it.

> but I'll say that I'm soon entering my 4th decade in the industry, I'm well respected, I've hired (and fired) tens of people through the years (and interviewed hundreds if not thousands); and I'm well respected among my peers for having very accurate evaluations of people's abilities. I do not aim to be politically correct.

And I'm in my third decade in the industry, all the respect, blah, blah, half a million lines of open source in the wild. So what? You can make the same mistakes over and over in any industry and never think to question if you're doing it wrong. This is ESPECIALLY problematic when it comes to people skills.

> No, because I've just hired them, or just didn't hire them; either way, I think it is irresponsible to trust the statement of a person I don't actually know and who may either hold a grudge or want to please me right now.

It's the PERFECT time to ask them, because it's fresh in their mind. A skilled interrogator can get information despite the subject's frame of mind. I'm actually surprised that you assume everyone you accept or reject is either going to be a sycophant or hold a grudge.

You WANT them to talk while the frustrations they encountered are still fresh in their minds. That's the most raw feedback you'll ever get.

You really do need to start treating them like human beings.

Wanna know how I evaluated potential game devs in person? I asked them what dev environment they were most comfortable in, gave them a computer hooked up to the internet and a picture of a tweetie bird, and said "Make the bird jump. Use google to look shit up." Worked amazingly well.

> Are you going to test that in an interview question? No, you're going to effectively "whiteboard" me, asking me to reinvent the wheel on the spot. And I'm going to resent you for it.

Unfortunately, the real world business problem that needs to be solved is not "reverse a linked list", but rather "discover the relationship between the widgez and the widgix that the customer is after". That relationship, once you understand the problem domain, can be discovered by (doing something quite but not exactly like) reversing a linked list. And unfortunately for you, a google search for "discover the relationship between the widgez and the widgix" yields nothing. If you can't (do something similar to) reverse a linked list, you can't deliver the solution.

And it's fine you are going to resent me. I do not want to employ anyone who thinks "reversing a linked list" is an inappropriate question in a technical interview.

> What's wrong with 1h vs 1d for a one-off thing?

I was just giving this for completeness - in this case, it doesn't matter. But if it is 1h vs multiple days, or it happens often (say, every 3 hours), then picking the correct solution -- which your method will NOT generate -- is actually important.

> It's the PERFECT time to ask them, because it's fresh in their mind. A skilled interrogator can get information despite the subject's frame of mind. I'm actually surprised that you assume everyone you accept or reject is either going to be a sycophant or hold a grudge.

I ask again, have you hired people? because the "skilled interrogator" mindset makes me think you haven't. I've just negotiated with a person, whom I've had less than 2 hours to know. If I don't want to strike a deal with them, I want to be fair and tell that to them as soon as possible, at which point the vast majority of them just want to move on (and I happily oblige the very few who do want to continue the discussion). If I do want to strike a deal with them, we start the salary negotiation phase, at which point (assuming they are interested) they have a vested interest in me offering them as much as possible; which some people express by trying to please. These things are often subconscious.

I do not assume anyone is a sycophant or holds a grudge. But I do assume, at that point in time, that they are not exactly objective; and I cannot, in fact, calibrate their response since I don't really know them.

> Wanna know how I evaluated potential game devs in person? I asked them what dev environment they were most comfortable in, gave them a computer hooked up to the internet and a picture of a tweetie bird, and said "Make the bird jump. Use google to look shit up." Worked amazingly well.

Sometimes, you can do that. Often, you can't. Especially if the person has no experience in the field they are interviewing in.

"Here's a stock exchange API, write a bot that makes markets" is super simple for someone from the field, and would take hours (perhaps days) of grokking for someone who isn't. And making a bird jump would not necessarily tell me someone is apt for writing trading software.

> I ask again, have you hired people? because the "skilled interrogator" mindset makes me think you haven't.

Wow... Just wow... You've let a big part of your personality slip out with that one.

> And making a bird jump would not necessarily tell me someone is apt for writing trading software.

And now we're getting into absurd arguments.

You believe that a technical interview ends with skilled interrogation of frustrations and I'm being absurd.

> Unfortunately, the real world business problem that needs to be solved is not "reverse a linked list", but rather "discover the relationship between the widgez and the widgix that the customer is after". That relationship, once you understand the problem domain, can be discovered by (doing something quite but not exactly like) reversing a linked list. And unfortunately for you, a google search for "discover the relationship between the widgez and the widgix" yields nothing. If you can't (do something similar to) reverse a linked list, you can't deliver the solution.

How does testing a candidate on how to reverse a linked list help evaluate his ability to understand that the implementation is an appropriate solution for a given problem?

It doesn't. A different question will give me indication about that.

What reversing a linked list does tell me is, once the solution IS arrived it, that this person can implement it. And I repeat again, I treat this as an abstract version; real world problems often have solutions with many corners and are seldom if ever "Eureka! i just have to reverse the list".

Another real world problem I just recall is analogous in many ways to a "git merge" which requires tracing through a huge DAG. In these kinds of things, even if you realize that it's a git-merge, it is often not possible to generate a git repository just so you can run git-merge and observe the result.

There are two independent skills: abstracting a problem, and solving an abstract problem. I test for both but the linked list question only addresses the latter.

> There are two independent skills: abstracting a problem, and solving an abstract problem. I test for both but the linked list question only addresses the latter.

The problem (heh) with this is that, unless one is actively doing research on improving an existing technology or method, all abstract problems that might come up are already solved.

Every solution is one search in google away (including your git example) so there's no point to it. Paraphrasing someone else: if the time spent in coding a problem is expressed as mx + c, m is the time spent in figuring out what the problem is and c is integrating a solution. That c tends to be insignificantly small.

Frankly, as someone holding a degree, if you were to interview me and asked me to reverse a linked list, I'd do it, laugh in your face, and walk out.

On that point, interestingly, in your earlier examples of people you got feedback from, you didn't mention the most significant one, the one more likely to point out the problems in your process and that would give you actually actionable feedback: the people who rejected the job offer.

> the people who rejected the job offer.

Didn't happen many times, I did ask for feedback, but rarely got any; mostly along "your interview was fair, but I prefer a different offer I received". Which is what I would expect - unlike what some people in this thread expect, the candidate is maximizing their revenue and future benefits; saying anything nontrivial after rejecting the offer is not helping towards either, and potentially harmful.

> Frankly, as someone holding a degree, if you were to interview me and asked me to reverse a linked list, I'd do it, laugh in your face, and walk out.

That's good, actually. Means we have a culture mismatch, identified early. Win win.

> unlike what some people in this thread expect, the candidate is maximizing their revenue and future benefits; saying anything nontrivial after rejecting the offer is not helping towards either, and potentially harmful.

I had already noticed a very strong reality distortion field in your other comments[0] but this one is just weird. I have been a candidate, most people in this thread have, exactly why their saying what they'd do is not a reflection of what a candidate might do? For instance, I cannot conceive why saying "anything nontrivial" matters in regards to revenue and future benefits. I've done it before (probably not "laughing in their face" but, then again, I have yet to meet an interviewer with such a clear misplaced arrogance) and so far, rejecting a company and giving feedback has not hurt me in any way; they have no impact on my future because I rejected them.

For that matter, how did this even address what I said? I see not how it isn't a non-sequitur, other than you believing that you have a strong enough pull in the industry that you could badmouth me into not getting a job if I rejected your offer and told you it was because your interview was terrible. Of course, that is not the case.

> That's good, actually. Means we have a culture mismatch, identified early. Win win.

Yeah, no, that wouldn't have been deduced from that interview; one could get a culture mismatch by exposing the applicant to the actual company during the process. What I said would only bring to light that your interview process is terrible and doesn't actually account for people who aren't desperate for getting the job (which, in itself, explains why you think everyone you hire is a sycophant, they probably have to).

Of course, I understand your inability to see that it might be a problem with you specifically; no, it must be that the interviewee has a problem with "the culture" of the company.

[0]: For instance, there was no majority saying that the creator of homebrew "was in the wrong" regarding his tweet. At most, there was an even split, although there was far more complaining about interview processes like yours.

> other than you believing that you have a strong enough pull in the industry that you could badmouth me into not getting a job if I rejected your offer and told you it was because your interview was terrible. Of course, that is not the case.

It is obvious our different experiences give us different views of the world. I would just add that I have seen this happen, mostly in business settings. A lot of people take things personally.

I don't particularly take things personally myself; it's all business or math to me. But when I was younger, I used to give brutally honest feedback about everything, and there were a couple of investment opportunities that it cost me (and I cannot say that it created others). I learned to play the politics game as I matured. I hate the game, yes, but I needed to start playing to break a glass ceiling.

> Yeah, no, that wouldn't have been deduced from that interview;

No, it would have surfaced immediately. I try to hire people whose attitude is more of the "yes, I can do anything that's needed. But why?" rather than "I laugh in your general direction since I think you are wrong".

> with you specifically;

Me and google. And facebook. And hundreds of other companies. You are entitled to your opinion that e.g. Google's culture is the problem.

Which is not to say my company is as successful as google. Just that I share the idea that culture fit is important. I recommend reading "Peopleware" if you haven't yet -- they have some empirical anecdata for that.

Also, I'm amused at how my "I prefer to ignore noisy data" comment (which is all my comment said, explained several times) was taken to mean "I think everyone's a sycophant or crybaby". I think it reflects on the readers' ability to consider that I'm calibrating my stats differently than they expect, or rather lack of it. And I calibrate it that way based on decades of interviewing -- I didn't start that way.

"If it was going to mean the difference between 1h and multiple days, here's what I'd do: - Fire up my trusty browser. - Navigate to google.com - Type in "reverse a linked list" - Evaluate all of the solutions I find and pick the best efficiency / verifiability match to solve the problem in a reasonable amount of time."

And now we're getting into absurd arguments. End of interview. Thank you for your time, but I don't think this will be a good fit.

Im not sure I agree with the premise that interview questions like that that may never come up in the job are useless. To me it doesnt matter. They are easily solvable and any competent programmer should be able to solve them.

Of course I think more relevant questions are obviously better.

> When's the last time you ever did anything as low level as reversing a linked list? It's a solved problem, and something an employee would NEVER do in your company, let alone search for the optimal solution in 10 stressful minutes while you breathe down his neck.

I need occasional semi ad-hoc datastructures and manipulations like that. The requirement is never "reverse the list", but it is often something like "this api here needs input in opposite order and data happen to be in list". I would not see reverse the list as something specially unusual.

> I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter).

That's a problematic attitude, in my view. It reads to me that you think you have all the answers already, or at the very least that you view yourself as being superior to people you interview. That lack of humility is troublesome for a number of reasons.

As far as your interview question, do you normally not interview candidates to develop software? Your question is appropriate for a grunt who's entire responsibility is to thoughtlessly code up somebody else's design. It's not appropriate for someone expected to contribute thoughtfully to the engineering of a software product.

> That's a problematic attitude, in my view. It reads to me that you think you have all the answers already, or at the very least that you view yourself as being superior to people you interview. That lack of humility is troublesome for a number of reasons.

I would correct that (if I could still edit) to "direct immediate feedback". What I meant was, if someone I just turned down for a job says "it's stupid", I don't consider that useful data; similarly, if someone I just hired says "This is the best interview question ever", I don't consider that useful data either.

I do ask for, and usually get, direct and raw feedback from people I work with (both those who report to me and those I report to).

> As far as your interview question, do you normally not interview candidates to develop software? Your question is appropriate for a grunt who's entire responsibility is to thoughtlessly code up somebody else's design. It's not appropriate for someone expected to contribute thoughtfully to the engineering of a software product.

Can you elaborate on what you consider "contributing to the engineering of a software product"? and more generally what "software engineering" entails?

I mentioned as explicitly as I can that I do not expect anyone to reverse linked lists. However, it is an abstract question that is not unlike the kind of things that arise in practice, e.g. figure out inverse relationships in data. And gives a good ground for discussion about things like requirements (time, space, correctness, verifiability, boundary conditions, erroneous inputs, etc) -- inside a well defined and (supposedly) familiar context; The same problem in a business setting would require a lot more definitions and would be frighteningly foreign for some people (to digest within an interview).

How do you interview?

> Can you elaborate on what you consider "contributing to the engineering of a software product"? and more generally what "software engineering" entails?

Actually, not in a space appropriate for an HN comment. Here's a very brief summary: I think in its current state there is very little actual engineering in this industry. It seems to me to consist of a large number of folks who approach every problem like a CSX01 project. It could move toward a more mature engineering footing if there were less focus on CS trivia and more on broader, deeper understanding of systems and relationships between them.

To be blunt, your "reverse a linked list" question is something I consider an example of the Law of the Instrument (https://en.wikipedia.org/wiki/Law_of_the_instrument): every problem is a CS nail to hit with a CS hammer. It's great for exploring the items you note at a very low, narrowly-scoped, and shallow level. It's not so good for gauging actual problem solving ability or engineering ability.

> How do you interview?

Interviewing is a crap shoot, and my methods are at least as flawed as any others'.

Phone screens with a shared editor are the place I ask questions like yours, except I'm not looking for a correct implementation, complete solution or discussion about it: I'm looking to see if they at least have some vague notion of what writing source code entails (even if it's just because they read about it and memorized it).

At the in-person interview I tend to do two things: discuss in depth a project in the person's past and a higher level discussion about something pertinent to their work at the company. For me the latter has varied from details for some feature to be implemented in a real time system to motivating a data exploration approach in the context of developing a data science product.

> I think in its current state there is very little actual engineering in this industry.

Agreed.

> It's not so good for gauging actual problem solving ability or engineering ability.

Also agree. It is not the only question I ask. However, I only want to hire people who, when the need arises, can actually use a hammer. I am perplexed that people find that offensive.

> At the in-person interview I tend to do two things: discuss in depth a project in the person's past and a higher level discussion about something pertinent to their work at the company. For me the latter has varied from details for some feature to be implemented in a real time system to motivating a data exploration approach in the context of developing a data science product.

Agree. However, I also do some technical parts in person/

> Indeed, you (almost) never need to reverse linked lists in practice

And there are thousands of other things that you (almost) never have to do, yet you do, throught the course of your career. When they arise you're not an expert in them, but after some careful research you become one, or become enough of one to say which solutions are better than others for the problem you have. And you'll be able to implement it, support it, and explain it to the people with whom you work.

These types of interviews don't see the forrest for the trees. The problems that you have had won't always be like the problems that you will have. What's important is the ability to solve problems you've never seen before (a graphql request took down the database cluster), not recite known but not widely remembered tasks (balance a b-tree in-place).

Getting to the point where you have to start to worry about Big O is the hard part, not the other way around. And Jesus, I really hope we work in places where if you're unsure about Big O you can ask someone and they'll help you, not judge you.

Edited to add: What these types of interviews say to me is the companies who use them have no interest in their employees growth and education.

> What's important is the ability to solve problems you've never seen before

Most definitely! And that's exactly why I no longer use this question (as I wrote in my original post) -- by now, everyone has seen it.

> Getting to the point where you have to start to worry about Big O is the hard part, not the other way around. And Jesus, I really hope we work in places where if you're unsure about Big O you can ask someone and they'll help you, not judge you.

I disagree. I deal with lots of data (just ordered another 100TB storage the other day; I do that every couple of months these days). Toy solutions that work well for small 100GB datasets often don't extend. Without a good grasp of complexity, it is easy to build solutions that don't scale properly, or cost $100K more in hardware/AWS than they should. I've seen it happen a lot of times. As they say, "a year in the lab can save you a week in the library!". If you don't know that you should go to the library, you're likely to lose that year.

> What these types of interviews say to me is the companies who use them have no interest in their employees growth and education.

Some of us are bootstrapped in a cut-throat market and can't afford to plan employee retention 10 years into the future; And neither are most employees interested in that.

> And that's exactly why I no longer use this question

This matters? Any other question stinks just the same, like my example of balance a b-tree in-place.

> I disagree...

What is it you desagree with? "Getting to the point where you have to start to worry about Big O is the hard part, not the other way around." or "I really hope we work in places where if you're unsure about Big O you can ask someone and they'll help you, not judge you."

> Without a good grasp of complexity...

I don't see how the interview style you seem to advocate finds people who are good at understanding complexity. This comes from experience, the opportunities to have worked on unfamiliar projects, not from reading a how to pass a job interview book.

> Some of us are bootstrapped in a cut-throat market

Some of us work in toxic environments that are hostile to women and people of color but ¯\_(ツ)_/¯, right?

> can't afford to plan employee retention 10 years into the future; And neither are most employees interested in that.

I would wager that everyone is interested in learning something new or deepening an existing skill in whatver job they take no matter the time period. The alternative would be to, which you seem to advocate, take a job, stand still in it for a few years, then wehn you're bored or feel like you're becoming obsolete, read some books on nights and weekends on whatever new trends people ask about in interviews, take a new job, stand still in it for a few years, and so on.

> What is it you desagree with?

"Getting to the point where you have to start to worry about Big O is the hard part, not the other way around."

Or maybe I misunderstood what you meant. I think that unless you are doing mostly "do this and then do that" style programming (e.g. CRUD), you have to be aware of big-O, or you're going to hit a lot of walls. In things I do, anyway.

> I don't see how the interview style you seem to advocate finds people who are good at understanding complexity.

Complexity here being the well defined CS term about space and time, of which big-O is the customary notation: How your resources (time, space, etc) grow with the problem size. I suppose you meant complexity as some measure of cohesion/details/size - in which case, you are correct - this kind of questions do not address it (others in my interview do, though I admit it is much harder to judge one's view of other-complexity in an interview).

> Some of us work in toxic environments that are hostile to women and people of color but ¯\_(ツ)_/¯, right?

Some of us make unrelated remarks, but ¯\_(ツ)_/¯, right? What exactly were you trying to say here?

> I would wager that everyone is interested in learning something new or deepening an existing skill in whatver job they take no matter the time period.

Then you would lose this wager. There are so many people who just want to clock in, do their job, clock out and get paid. Yes, even in technology. And you know what? that's fine; They are not lesser people because of that - they likely care more about hobbies or other things, and would happily quit their job and have fun if they won the lottery.

> The alternative would be to, which you seem to advocate, take a job, stand still in it for a few years, then wehn you're bored or feel like you're becoming obsolete, read some books on nights and weekends on whatever new trends people ask about in interviews, take a new job, stand still in it for a few years, and so on.

Not at all -- but there's a huge difference between "being interested in something new" and "train someone in a new field they are not proficient in" especially when there is no commitment (nor could there be) on their side. The latter costs money to the employer, which some can afford and some cannot -- either way, it is not a basic human right.

> you have to be aware of big-O, or you're going to hit a lot of walls.

Of course you do, along with many other things - many other things that you won't know you need to be aware of because you haven't come across them yet or because they haven't been invented yet. What I said is that it's important to know how to figure these things out, not be able to recite them from memory.

> What exactly were you trying to say here?

You said "Some of us are bootstrapped in a cut-throat market and can't afford to plan employee retention 10 years into the future" To me this is a defeatist attitude. Our jobs are fundamentally about solving problems, and this, like my example, has a solution.

> Then you would lose this wager.

You can't have it both ways. You seemed to say that your preferred interview style selects the best of the brightest, but now it selects people who just want to clock in and out?

> Our jobs are fundamentally about solving problems, and this, like my example, has a solution.

Unfortunately, if resources are limited, you have to compromise. Google's resources are limitless, mine isn't. if your solution is "close up shop and go work for someone who has more resources" then I'm not the defeatist. What's your solution for constrained resources?

> You can't have it both ways

I do try to select for the best and the brightest. I pointed out that some people like to clock (your wording implied everyone likes to learn new things on their job). The best and the brightest who are not Jeff Dean tend to change jobs every few years even if they work for Google. And no, I cannot afford to employ Jeff Dean, I admit. Can you?

> What's your solution for constrained resources?

Which resources are constrained?

Our examples are 1) (yours) cultures that are hostile to employee growth and education, and 2) (mine) hostile to women and people of color. These are solvable problems, even ones as awful as Uber as we're seeing play out. As for what we can do, we can start to hold our industry accountable. When we hear about some unicorn at some absurd valuation, rather than simply applaud we need to ask them about their culture, how they treat their employees and customers, do they have a healthy work/life balance, what exactly are they doing to foster diversity, what's their impact on the environment, does their product actually make the world a better place, are they in service of the surveillance state, and so on. We need to redefine what it means to be successful in our industry.

> And no, I cannot afford to employ Jeff Dean, I admit. Can you?

How did we get here? I said "What these types of interviews say to me is the companies who use them have no interest in their employees growth and education." As I read the thread that follows from this point, it seems like you agree which is at odds with your defense of these types of interviews that started our discussion.

> Our examples are 1) (yours) cultures that are hostile to employee growth and education

You assert that, but I have no idea why you would think that. That's why I was perplexed at your statement. Can you elaborate? Non of the examples you give liek work/life/diversity/environment has featured into the discussion, nor the definition of "success in the industry"

> I said "What these types of interviews say to me is the companies who use them have no interest in their employees growth and education."

And I ask again, is, why would you assert that? It seems trivial to you, but I'm completely at loss. All I said was that I cannot, at hiring, offer a 10-year growth plan for a person. It does not mean I do not expect, encourage and help them to grow (quite the contrary).

> You assert that, but I have no idea why you would think that.

Why I would think what? That this is true or that you think so too? As for the latter, because you said so...

* "Some of us are bootstrapped in a cut-throat market and can't afford to plan employee retention 10 years into the future; And neither are most employees interested in that."

* "All I said was that I cannot, at hiring, offer a 10-year growth plan for a person."

* "There are so many people who just want to clock in, do their job, clock out and get paid."

* "The latter costs money to the employer, which some can afford and some cannot"

All of which seems to say to me that a person better come with all of the skills that they could ever possibly need now and in the future because they're not about to get any support from their employer or teammates. Just sit down, shut up, and mash on that keyboard. What you seem to advocate as growth and education is something that a person should do own their own time and at their own expense. People who aren't willing to attend meetups, read research papers, work on side projects, etc. after hours are just a bunch of clock punchers who go through life without contributing much. This sounds pretty horrible to me.

"10 years" and "the costs" are just rhetorical attempts to set the bar so high to say that it's just not possible or too unreasonable to care about lifting up your teammates. This is easily provable false simply because of the companies that do this already no matter the tenure of their employees and at very little cost.

As for the former, I say there are far more important skills that an interview should focus on rather than if someone can recite the pros and cons of different sorting algorithms and their Big O costs because this is easily teachable. But when you don't care about growth and education, or just simply teamwork and collaboration, you want to know if candidates already have the answers to the problems they'll encounter, which, of course, is totally ridiculous to me.

> I don't, in general, trust direct feedback from someone I turned down (or hired, for that matter).

Would you please share where you're working so we can avoid applying?

(I understand the sentiment, and I deserve it for the wording that I cannot edit now -- but, copying myself from other posts:

because I've just hired them, or just didn't hire them; either way, I think it is irresponsible to trust the statement of a person I don't actually know and who may either hold a grudge or want to please me right now. I meant to say "direct immediate feedback", which is perhaps better wording.

After I know a person, I ask them (and usually get) the most direct and raw feedback I can get.

You miss the point. Everyone has something interesting to teach you. Listen to the sages and the sycophants alike because there's no profit in closing yourself off.

But in this case we have all the people who didn't make it to the NFL complaining about the NFL combine, and how in actual football they don't have to bench 225 pounds.

> I've never gotten this feedback from anyone I would consider competent.

You may not have gotten it personally, but some very smart people have given precisely that feedback regarding those sorts of questions.

https://twitter.com/mxcl/status/608682016205344768

On phone now, so can't search but ... there were a couple of threads on HN when that tweet was made, and IIRC the majority actually didn't think he was in the right.

Being smart and being a good fit are not equivalent. Linus Pauling was definitely smart - and most definitely wrong about quite a few things (most famous was his statement that "there are no quasi crystals, only quasi scientists", a derogatory remark about Dan Shechtman who later got a nobel prize for those quadicrystals)

The tweet isn't a counterargument that disproves your premise; it's a data point you seem to be unaware of. Certainly there are smart people who think your question is fine, but if you think that the people who disagree are mostly incompetent, I think that's a defense mechanism.

Put it this way: if I decided someone was incompetent as a programmer based on some criteria, and then I later found out that that person wrote Homebrew, I would take a pretty hard look at the criteria, and how strongly I believed in its predictions.

With all due respect for Max Howell, his response is a defense mechanism. "invert a binary tree" is an ill defined question (maybe he was joking, I don't know), perhaps he didn't even understand what he was asked and didn't bother inquiring. He was not told WHY he wasn't accepted - it might have been for displaying a "rock star better than though" attitude which some places reward but Google does not.

I do not disqualify people who cannot reverse a list (as long as they demonstrate critical thinking skills and reasonable capability). I do disqualify people who get up in arms like Howell did, and I dare say this tweet does show Howell to be a bad match for many teams, regardless of his technical skills; He is likely not a competent team player. (As much as can be inferred from the tweetstorm that happened 2 years ago, and as much as I can remember it).

Howell's actual competence or the particulars of his interview are out of our scope. His tweet could have been a petulant defense mechanism or it could have been eminently justified; we have no way of knowing. (And if we're paying him due respect, let's leave out speculation about rock-star attitudes or his competence as a team player entirely please.)

All I'm talking about is the predictive power of the "please rejigger this data structure" interview question, and how much faith people place in it. I mean, if someone looks at the Howell thing and says, "well, any interview can have false negatives, but questions like this are still good predictors of competence", I'd certainly have no argument with that.

But a lot of people looked at it and said, "Nope, if he failed a question like that then he's not a competent programmer, regardless of what he's built". When someone says that, they're implicitly claiming that "passed an interview question" is a better predictor of programmer competence than "built and maintained one of the world's more popular developer tools". Doesn't that strike you as a pretty extreme amount of faith to put in an interview question?

> But a lot of people looked at it and said, "Nope, if he failed a question like that then he's not a competent programmer, regardless of what he's built".

The responses I remember (memory bias possible) were along the lines of "well, he might have built that but is not a good match for google if he failed a question like that".

I have actually calibrated my interview in the past on friends, colleagues, employees and students, and I know that it has predictive power for the kind of work I do (which does NOT include, e.g. CRUD or the simple if-then-query logic which is often referred to as "business logic").

With respect to Max Howell - I will, indeed, leave speculation out, but will say that the attitude he displayed on twitter would disqualify him from a lot of places, regardless of his technical merits. (And as for the real reason he was disqualified - it was pure speculation on his side).

The response that stuck in my memory was from Jonathan Blow (whom I greatly admire, apart from the following), and amounted to "then you're not a very good programmer".

Personally, I strongly suspect that the predictive power of interview questions depends ~90% on the knowledge and experience of the interviewer, and the specific questions aren't that important. I reckon the disconnect here is that you and JBlow are judging things as the guy had failed the interview question as you would have administered it. And it's possible that that's roughly the case, but it's also possible that he failed the interview as administered by a bad interviewer - who, say, cut him off after the first trivial error rather than suggesting he check his answer for bugs, or whatever.

As such, I take no issue with data structure questions per se, I just find it hard to buy this idea that they're massively predictive - compared to, say, having shipped lots of good code for a long time.

> With respect to Max Howell - I will, indeed, leave speculation out..

This would read better if it wasn't followed by speculating where the guy's qualified to work (based on memories of a tweet from three years ago!) and then speculating what he does and doesn't know about an interview he was in.

> This would read better if it wasn't followed by speculating where the guy's qualified to work (based on memories of a tweet from three years ago!) and then speculating what he does and doesn't know about an interview he was in.

The process at Google (of which I'm not intimately familiar with, I admit, but I have read a lot about) is such that if you are rejected, you are very rarely told why (I know of one case in about 30, and it was an offer that was rescinded based on some bureaucratic reasons). It might have been the reason, for sure; but it is extremely unlikely that this is what he was told, thus I infer speculation on his side. By accounts from Googlers I know (and some who commented on those threads at the time), it should be considered truism, not speculation, that he was not told the reason.

Also, I'm not speculating about where the guy is qualified to work. I was referring to several places I know for sure (some high profile, mostly in finance) where such a rant on Twitter is enough to disqualify you (and get you fired if you're already employed). I don't know Yelp specifically, but it seems like one of those places[0]

[0] http://fortune.com/2016/02/22/yelp-employee-ceo/

> It might have been the reason, for sure; but it is extremely unlikely that this is what he was told, thus I infer speculation on his side.

Nobody's suggesting HR sent him a letter - presumably he formed his conclusion based on what was said in the interviews. It may be that he did so unreasonably, as a defense mechanism, and it may be that whatever was said left little doubt why he wouldn't be getting an offer. All we know is that he felt there was enough information to form a conclusion, and the principle of charity compels us to assume that such may be the case.

Honestly, I'm not trying to pick an argument or anything here. I just think your confidence judging this guy's character and hirability and so on is way out of whack considering that it's based on a three year-old recollection of a tweet.

I'm astonished how you've been treated in this thread. You've actually mananged to convince me that reversing a linked list is a good interview question!

Because it's considered very rude by normal people.

For a hypothetical example:

I've spent a day for your interview. I aced it. I was told there is somebody better. I was then asked to waste more time in form or feedback.

Same goes for references. In fact, from a real life example:

My company needed an entry level technical writer. I referred them this kid with a fresh comp sci degree, eager for a job. Reviewing code: yay, he thought he made it. Got turned down because they wanted only a rockstar entry level, technical writer. Then chose to not get one.

So, given everything, because I'm a polite person, I'd rather not answer than tell them they are delusional and rude.

I think this is a great question and tests basic programming knowledge. It's similar to the parallel parking portion of our state's driving test. Most people don't parallel park enough for it to be a factor in daily use but it's a good way to test overall knowledge and control of the vehicle. If you can parallel park, it's a good indicator that you can do other things safely as well.

From your submissions you seem to be keen on sorting algorithms and some low level programming, so I'd say you are somewhat biased on what programming skills are important, while I wouldn't even necessarily disagree with it, depending on the specifics of the job to interview for.

My replies to dodge the question would be: That's not a question, that's a command.

> I don't use it anymore because it's too common to be useful.

I've found that having common questions used across many interviews allows for more objective direct comparisons. I like this one in particular because even if they solve it quickly, you can move on to questions about cycles in the input.

What do you use now?

It was never my only question.. I vary through the years.

Another favourite of mine is basically "implement a very sparse 100Mx100M matrix". Thought process much more important than result. (important things to consider: access time, storage size, static vs. dynamic, use cases, adversarial coordinate selection).

I actually consider the "cycles in the input" question a bit of a trick question -- I calibrated the test on people I knew were good, and no one who didn't know it already was able to come up with "the trick" in reasonable-settings-for-interview-time, and not many were able to come up with any O(1)space O(n)time solution.

The discussion with those who don't know the solution is useful, of course.

> The discussion with those who don't know the solution is useful, of course.

Agreed, the discussion on these questions is the whole point, not whether you can come up with a "correct" solution (and I tell candidates this up front).

I generally draw a small example input with a cycle, and ask what their list-reversing solution will do with it, which I feel makes it much less of a trick question. "Can you work out what the code you just wrote will do with inputs that don't meet the assumptions you made?" seems like a fair thing to ask anyone who will be required to write code that handles untrusted data.

By linked list, do you mean a doubly-linked list?

Wouldn't that make it (even more) trivial, since you can just traverse from the tail backwards? Assuming it has a tail pointer, of course.

Yeah, I suppose so. I only asked because reversing a singly-linked list just seems like a PitA.

Reversing a singly-linked list is actually easier: you take each element off the front of the old list and put it onto the front of the new list.

I thought this guy was being sarcastic?

Reply on news.ycombinator.com