151–160 of 178 posts
"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…
Earlier quoted context omitted.
Yeah, that was more or less the point of the post. For applicants, don't feel nervous, it's a silly game just to see if you know some of the puzzles. For people hiring, go ahead and use this as a first-pass filter, but realize that it's easy to game (by someone who's trying hard and learning, so there is a positive signal in that). It's going to be important to go through and work with them for a period of time in a…
In all my history of interviewing people, I've always found there's almost no info to be had in correct answers to any kind of question. You learn about a candidate once you guide them into territory where the fail. Both where that line is, and how they handle the failure tells you a lot. (Caveat: Make sure you're keeping it on the fail/no-fail edge, and you treat the candidate with respect. The point is not to show…
Earlier quoted context omitted.
I'm sure I agree with everything you're saying here, but it carries a whiff of tautology. You lose the benefit of middle-insertion in a list if you have to seek, but part of the point of using an array is not having to seek ever. Anyways the only thing that moved me to comment is the general inferiority of linked list data structures compared to arrays, which are what Ruby (sensibly) uses.
I'm reading this thread and kind of tearing my hair out. One theoretical case where lists beat arrays is seeking to the middle (once) and inserting 1000000 items in that one spot. If you want to test if lists can ever be useful in Ruby then you want to test the case that they are theoretically useful. Your test is a theoretical dead heat as arrays and lists both perform O(n) in it. All you learn is that arrays are fa…
Like I said, we're way off the rails here.
Earlier quoted context omitted.
Essentially: It is not common for doctors to be asked to locate the interviewer's mouth, ears and thumbs. If an interviewer asked that kind of thing, you'd really have to suspect that he couldn't tell a good doctor from a bad one. But programming interviewers do need to ask this kind of thing. So you really have to suspect…
The problem isn't that we're asking doctors to locate their mouth, ears, and thumbs. The problem is that the resume and candidate pipeline is so crappy, that the interviewer cannot be sure if the person sitting across the table is a doctor, or a plumber, or a carpenter, or an accountant, or maybe a bum off the street. My interviewing life would be a lot easier if there was a firm guarantee that every candidate knows…
Scary but true: There are plenty of experienced doctors who couldn't pass a medical Fizzbuzz. My supervisor at my last teaching hospital, who has been treating patients for at least five years, failed the Fizzbuzz question I asked him. ("What's that other class of antibiotics you can't give patients with penicillin allergies?", if you're wondering.)
(There's also a few stories of people faking medical licenses and working as doctors for years before anyone noticed [1], but those are probably too rare to worry about.)
1: http://www.sueddeutsche.de/panorama/hamburg-falsche-kinderae..., couldn't find an English language link, sorry.
Earlier quoted context omitted.
I'm reading this thread and kind of tearing my hair out. One theoretical case where lists beat arrays is seeking to the middle (once) and inserting 1000000 items in that one spot. If you want to test if lists can ever be useful in Ruby then you want to test the case that they are theoretically useful. Your test is a theoretical dead heat as arrays and lists both perform O(n) in it. All you learn is that arrays are fa…
"We" didn't know that already; there was an implicit argument that there might ever be a point to building a linked list in Ruby, which, no. Like I said, we're way off the rails here.
There are problems where a linked list is theoretically better suited than an array. Your test is a problem where they are theoretically evenly matched. The interesting question is: do the benefits of native code etc, that you get when using an array outweigh the costs that you incur for using a non-optimal data structure for a given problem? To answer this you would need to come up with a situation where a list should be faster if the array and list were both native or both higher level ruby implementations. Then compare the actual running times to see what impact native code vs ruby code has.
All your test shows is that in a problem where neither data structure has an advantage in complexity, i.e. they both perform in O(n), the one backed by native code is faster. My assertion is that is a pretty boring thing to discover and "we", or most people, would guess that anyway.
Earlier quoted context omitted.
Probably. All I meant to say is that on MRI, you might as well give up on reference-based linked lists; they just don't work at scale. In rbx, you're saying 1000.times { list.insert(500000, 666) } actually beats 1000.times { array.insert(500000, 666) } I really should be taking rbx way more seriously.
All I meant to say is that on MRI, you might as well give up on reference-based linked lists; they just don't work at scale. I think that, sadly, this is true of almost any well engineered data structure. MRI's overhead is so vast that even if you perform an operation at, say, O(n) with the logical solution, using a naive built-in or iterative technique with retrieval of O(n * n) will be faster up until the often rat…
Earlier quoted context omitted.
I think this conclusion is wrong. The fact that FizzBuzz exists actually means that programming interviews are awesome: with most other professions, you would end up hiring a candidate equally as incompetent as the programmer that failed FizzBuzz.
No. You do not have to ask doctors or lawyers or taxi drivers fizzbuzz levels of questions. If applicants for doctors jobs were as incompetant as programming interviews, you'd have to ask applicants to location the ear on the human body. Doctor applicants aren't that incompetant, programmer applicants are.
Earlier quoted context omitted.
Wow, that sounds painful. So do people not use things like graphs or trees in Ruby due to perf? I actually used to do Python development -- about 13 or so years ago, but had to quit due to perf just being abysmal for applications intended for customers (and started focusing on C++). Is Ruby today similarly bad for apps that make heavy use of data structures like trees/graphs as Python more than a decade ago? EDIT: Up…
13 years ago. When the Pentium II was around. This is what I don't get about questions about linked lists. They're so utterly irrelevant in 99% of startups today, where knowing how to lay out your classes and methods for maintainability is so much more important than any trivial and pointless performance gain. The complexity of solutions is at such a higher level now than it's ever been and yet we're still worrying a…
With that said, a lot of startups (and web apps in general) are effectively consumer CRUD apps w/ nice images and transitions. Perf generally isn't important until scale becomes an issue (and until then you're main perf bottlenekck is some DB and/or network code that someone who cared about perf wrote).
So I agree. It makes sense to use effectively a domain specific language/framework like RoR when you're in that domain. And linked lists may not be applicable. But I'd still be weary of hiring people for whom reasoning about them is off-limits.
Earlier quoted context omitted.
I think this conclusion is wrong. The fact that FizzBuzz exists actually means that programming interviews are awesome: with most other professions, you would end up hiring a candidate equally as incompetent as the programmer that failed FizzBuzz.
No. You do not have to ask doctors or lawyers or taxi drivers fizzbuzz levels of questions. If applicants for doctors jobs were as incompetant as programming interviews, you'd have to ask applicants to location the ear on the human body. Doctor applicants aren't that incompetant, programmer applicants are.
Earlier quoted context omitted.
You just have to make the problems so diverse (not necessarily hard), that genuinely understanding the solutions is the easier strategy than rote learning.
Can you give me an example of a question that isn't located in glassdoor.com and is "diverse but not hard". As far as I'm concerned, the bar is already ridiculously high to the point where I feel like the only people that get jobs are the ones who randomly get lucky enough to get 3 or 4 interviewees that ask easy questions. There are people I know personally that have gone through every single one of the 1000+ Google…