More experience and credentials you have, the higher expectation is desired, which leads to higher pressure to solve that problem in the best case possible.
I've been coding since 14 years old, got a degree in Computer Science, haven't been back to school in 5 years, and most of my work just comes to me as second nature. If I have just small doubts of my abilities, I just cannot perform. Which happens during interviews.
> "I can reverse a linked list even in my dreams."
> "I was not able to finish the coding"
are to my mind incompatible. Are you absolutely sure the issue is not that you haven't practiced enough? Bear in mind that it is a fairly trivial data structure.
If it's intuitive then where was the pressure from? And if you had 20 minutes there wasn't much of a time constraint.
The last sentence is counter to your original post, which was that because of this part of the interview you didn't get the job (which is possible, but I'm still skeptical).
I'd spend some time practicing "mini presentations" where you take a problem like this, and pretending like you're in that situation. Code on a whiteboard (or some paper on the wall). Think out loud so the interviewer knows where you're at. Practice how to write code for someone else to read, and so you have an idea of what patterns or anti-patterns you exhibit.
LinkedList toInvert;
LinkedList out;
Either iterate through toInvert and call out.push_front(...) on each element or (if the operation may be destructive) do while (!toInvert.empty)
out.push_front(toInvert.pop_front())
All this should not take more than 5-6 lines - should be doable in 20 minutes. Also: these two lines surely could also be written under pressure.If the linked list is double linked, I'd ask whether the reversing has to be called often in the code. If yes, you could add a direction flag to the linked list, which tells in which direction the iterator will iterate. This makes the iterator implementation a little bit more complicated, but makes the reversing O(1).
Collections.reverse(myLinkedList);
Absent a demonstrated performance issue, there's no reason to even consider writing and tuning a new version. There's a debugged performant library. The first engineering tool is to apply is Google, not a whiteboard.Twenty-five years ago It might have been faster to write such a routine than to find it in a library. I found `Collections.reverse()` in under five minutes on StackOverflow and I suck.
Your "sound judgement" argument is orthogonal to my "being able to reason about fundamental data structures". I doubt most people will need to manually re-write list operations. Most people will need to reason about fundamental data structures.
Ultimately I guess I just find it impossible to believe that basic coding skills are no longer relevant to a large number of commenters here, and that using a "but I can find it on teh Googs" is a reasonable response to "please write a few lines of trivial code that operate on a trivial, but fundamental, data structure".
~ Single or doubly linked?
~ How is the data structure implemented (e.g. is there a header structure and to what does it point)?
~ What does "reverse" mean? mutate in place? create a new list? and if I am to mutate it in place, why?
~ Reversing a linked list is O(n). One implementation us pretty much as good as another. It doesn't really differentiate on insight into the problem.
~ Winding up in a situation where reversing a list is critical smells like bad design...a stack/queue would have been a better choice upstream than a queue/stack.
But though all that may make for interesting conversation, "with a library call" is the only professional answer to "How would you write a function to reverse a list?"
Most interviewers - in my experience - would then mark you down as a smartarse and the interview will be all downhill from there.
I come from a field where there is an ethos of professionalism, and the answer to "How would you reinforce a strip footing?" is "With rebar."
~ Uncle Bob has a point.
~ Half of all interviewers are below average.
[1] "Bullshit" in the technical sense - when a person knowingly states something misleading or false and openly doesn't care if the person hearing those statements believes them.
The truth is that in a few hours, looking at some of the code base and discussing it is going to give both parties a better feel for the fit of person and job than anything else. The interviewer gets a feel for how the candidate will deal with the mess that is someone else's code and build process and the candidate gets a better feel for the mess they will be dealing with.
Don't PL developers need to implement things like List.reverse() in their new languages all the time?
Rhetorical question, because I know the answer is yes.
Here's an example for Julia: https://github.com/JuliaLang/DataStructures.jl/blob/master/s...
function reverse{T}(l::LinkedList{T})
l2 = nil(T)
for h in l
l2 = cons(h, l2)
end
l2
end
(Note that this algorithm is not an in-place reversal, so it wouldn't have worked for the OP's interview.)The premise of your remark indicates the absurdity of the claim of relevance. An interview for a position responsible for writing a new language in a language sufficiently low level to require a new `list.reverse` would invariably require implementation of a list type as well...what language includes <List> without a reverse?
It's pretty well known that Google's hiring process for SDEs is designed to select for skilled computer scientists--the type of people who could do something like implement a stdlib for a new PL if needed. Then, since they can afford to hire only great all-around CS people, they can just allocate people to projects after the hiring decision is made. Of course not every SDE job at Google requires that level of CS skill, and it's massively wasteful to put most people on projects below their skill level, but they can afford to hire that way just because they're Google.
As a side effect, other companies hiring developers are likely to just cargo-cult whatever Google is doing.
I've had to use linked lists precisely twice in the last 10 years and both times were because I'd been forced down to C for API reasons. Even then I just used the BSD macros and didn't give it a second thought. When on earth would I ever need to reason about them?
In most situations what matters is datatypes, not data structures. That is, queues and stacks, are the important abstractions...and reversing a linked list in non-trivial cases means that:
~ Either a queue was used instead of a stack
~ or vice versa
~ or perhaps a dequeue should have been used.
Does it matter if an ordered bag is layed out in memory sequentially or with links until profiling justifies refactoring? And when you're in Java, refactoring largely going to be a matter of swapping out one set of library calls for another congruent set...and hopefully, all this happens behind an interface.
Using off the shelf components when it makes engineering sense is a hallmark of professionalism. Reinventing linked list functions is, in most situations, a indicator that a person needs close supervision.
"Collections.reverse(myLinkedList);" is the correct answer to "How would you reverse a linked list if it came up in your job?", but is not a relevant answer to the interview question.
Unless you specifically know that taking 20m to reverse a linked list was the reason for not being hired (I'm skeptical), you're just guessing.
While I don't generally ask questions like this, I'd also be wary of someone that can't reverse a linked list in 20 minutes, although it depends on what type of position you're actually applying for.
I also didn't go to a competitive school; I don't know what arbitrary criteria you'd use to decide if I've "done anything special".
I expect coders to be able to code, or at least reason about code, more or less on demand. I'm pretty forgiving about poor whiteboard coding performance since I also suck at it. But even a terrible whiteboard performance can be accompanied by the thought process behind it, and from that, you can discern whether or not the coder knows anything and just sucks at being put on the spot, or if they truly don't know.