> 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.
> 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.
> 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.
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.
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?
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.
> 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".
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?
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.
>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.
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.
> 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.
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.
"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.
> 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.
> 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.
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.
>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.
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.
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...
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.
> 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.
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.