Hacker News Reader

Comment by MichaelGG | Hacker News Reader

Writing code is just another type of conversation. Sure, you're going to ask many questions. Having a candidate code a bit in front of you, going back and forth, provides a lot of info.

As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A proper conversation, including code, will quickly sort out if the person just memorized a one-line Haskell quicksort, or actually knows what they're talking about.

View on HN

Do you actually find people that expect candidates to implement quicksort?

I've certainly implemented it, but there's no way I have it memorized, it's not an obvious algorithm at all. I'd be flabbergasted to be asked to implement it from memory with no warning. It seems clear to me that one would be testing for if the person happened to have looked at the algorithm recently, not if they were competent.

As long as you don't want to do it in-place, it's actually very easy to code.

It's not such an arcane algorithm. Choose a pivot element, (say) p. Rearrange the array into left_sub_array + [p] + right_sub_array such that all elements of left_sub_array are no greater than p, and all elements of right_sub_array are greater than p. Then recursively sort the left and right sub-arrays.

If you don't remember this, it's OK. If I was the interviewer I'd still give you the description above and see if you could implement it. Most candidates cannot.

In college ("computer science part A",using Haskell) we played out the various sorting algorithms we learned in class, with students holding up a number (to determine sorting order). Neat to actually experiencing the slowness of bubblesort vs. mergesort/quicksort ;) We repeated the performance in front of a local mall - I can't recommend trying something like that in a crowded place from that experience.

I think expecting recent CS graduates to implement a basic sorting algorithm or binary search, etc. (say, in a garbage collected language they know well) is reasonable, for people with actual work experience I think it makes less sense and the focus should be on more recent experience if relevant to the job.

Yeah doing a binary search in an array is pretty standard. What I was asking though is quicksort since that was mentioned. It's not obvious by any means how it works and I recall that early reference implementations had bugs that were unknown for years even though widely used. It really sounds to me like asking someone to implement the FFT in an interview. What are you really testing for when you do that?

I used quicksort as an example of something that one could conceivably memorize in Haskell (only 80 chars) with no clue to the functionality.

I was referring to any sort of "memorization" - just talking and watching someone code should make it clear if they just recently read an article about an algorithm, or if they actually understand it.

Reply on news.ycombinator.com