Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LINQ Ruined My Favorite Interview Question

scottchamberlin.tumblr.com

Post reply on HN
Print view View original

121–130 of 218 posts

Re: LINQ Ruined My Favorite Interview Question

#121

Post by EpicEng »

llambda wrote: post #8

I hate to be the bearer of bad news, but I think there may be even simpler solutions to this problem: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) The above is a Clojure one-liner example that I believe satisfies the original problem. So while LINQ may have simplified from the C-language family solutions he had seen, it's clearly possible to take it one step further with the…

I like how you snuck in "modern languages (like Closure)", as if C# is not a "modern language". Both languages have their place, but let's not pretend that Closure is somehow superior for all applications.

Re: LINQ Ruined My Favorite Interview Question

#122

Post by ajanuary »

lubomir wrote: post #28

The LINQ really is much more succint, but the original code did not set the bar very high. Why should one write a 12 line comparing function when using 'b.value - a.value' would work pretty much the same (unless C# really requires comparison to return -1/1 instead of any negative/positive integer, which would be fixed by a sign function).

Or do:

  private static int CompareKVPByCount(KeyValuePair a, KeyValuePair b)
{ return a.Value.Compare(b.Value); }

Or even:

  kvpList.Sort(kvp => kvp.Value)
But that would probably be straying into authors "list of language features I've completely ignored for the last 5 years"

Re: LINQ Ruined My Favorite Interview Question

#123

Post by scrabble »

moomin wrote: post #13

I hate to be the arrogant know it all on Hacker News, but seriously, if you're writing c# and not using LINQ all the time, you need to catch up. I'm tired of seeing people answer interview questions with anything _other_ than LINQ.

I answered a phone interview question once with LINQ -- it was about combining string arrays while avoiding duplicates.

The HR interviewer followed up my answer asking about runtime and memory usage. While these are good questions, I got the feeling they didn't want to receive an answer using a single line of LINQ.

Re: LINQ Ruined My Favorite Interview Question

#124

Post by ajanuary »

recursive wrote: post #102
MatthewPhillips wrote: post #35

Earlier quoted context omitted.

The most annoying thing about LINQ is that they use the SQL language. So unless you use C# and LINQ all of the time it's hard to figure out what functions translate to the ones used by every functional language in the world. I wish they would at least alias map, reduce, some, etc.

You really only have to figure it out once. And for users not familiar with the "standard" names, I think linq's naming is actually more intuitive.

tbh I don't think either are particularly intuitive in a "can guess it" sense. Both are intuitive in a "oh, that's what it's called, I can remember that now" sense.

Re: LINQ Ruined My Favorite Interview Question

#125

Post by carlob »

shill wrote: post #19
llambda wrote: post #8

I hate to be the bearer of bad news, but I think there may be even simpler solutions to this problem: (take 10 (reverse (sort-by (comp first rest) (frequencies (string/split ... #"\+s")))) The above is a Clojure one-liner example that I believe satisfies the original problem. So while LINQ may have simplified from the C-language family solutions he had seen, it's clearly possible to take it one step further with the…

Oh, we can use our favorite language in our new job? Here is a Python solution. from collections import Counter Counter(s1.split(' ')).most_common(10)

In a similar spirit, but without libraries and with a programming language designed 25 years ago.

    Commonest[StringSplit[string], 10]

Re: LINQ Ruined My Favorite Interview Question

#126

Post by wiredfool »

CanSpice wrote: post #115
jkrems wrote: post #25

Earlier quoted context omitted.

It looks like collections is part of the standard library: http://docs.python.org/2/library/collections.html . I think this disqualifies your JS solution, as long as doStuff isn't some fancy nodejs core module I missed.

"Sorry, we're stuck with Python 2.3.7 and collections isn't part of the standard library."

"""Thank you, I think I've heard enough. I don't think continuing the interview would be a productive use of time."""

Re: LINQ Ruined My Favorite Interview Question

#127

Post by rhizome »

untog wrote: post #107
rhizome wrote: post #89

Earlier quoted context omitted.

Isn't it kind of axiomatic that any question that provides for a concise and measurable solution will eventually be refactored into a library? It seems like kind of a weakness in these kinds of "programmer" questions, that they all regress to trivia. Why not an open-ended business problem and/or deliverables-type question? I'm sure that would speak more to the daily job, where I've never heard of someone being tasked…

Surely the 'trivia' in this instance is knowing the names of libraries, as opposed to be able to think through programming concepts? Just like math homework back in the day, the teacher didn't do it to check your answer, they did it to check how you arrived at your answer.

My memory of the math homework you describe brings up two images: geometry proofs and story problems. Never did I have to explain multiplication when doing my times tables, nor quadratics.

Re: LINQ Ruined My Favorite Interview Question

#128

Post by klipt »

cben wrote: post #76
untog wrote: post #42

Earlier quoted context omitted.

I think the point still stands though, when you think of it as an interview question. The point is to get to the bottom of how the candidate would process such a query themselves, not to test their knowledge of the core libraries of their favourite language. I feel like that's what the post author meant when he said that LINQ had "ruined" the question- because it kind of does the same thing.

collections.Counter.most_common() uses heapq.nlargest() which is slightly more efficient than a full n*log n sort. But implementing a heap correctly from scratch is I guess outside the scope the OP intends for the interview question. I would expect a good candidate to: 1. know that a heap is optimal here (remembering whether Counter uses it is optional) 2. express reluctance to implement it from scratch because surel…

> collections.Counter.most_common() uses heapq.nlargest() which is slightly more efficient than a full n*log n sort.

Creating a heap is O(n) if I remember correctly, so that may well be the most efficient solution.

Re: LINQ Ruined My Favorite Interview Question

#130

Post by tolmasky »

gecko wrote: post #109
tolmasky wrote: post #98

My main problem with LINQ is that it seems to perform terribly on mobile. I was looking for map/reduce/etc type functions for C# in Unity, and thought I found it with LINQ. To my dismay, LINQ creates so many crazy intermediate objects to pull off its "laziness" that our GC high water mark was being crossed all the time. I went and just reimplemented everything from underscore.js in C# and got way better performance.…

It's not mobile; it's old versions of Mono having a completely shit GC. Do you know whether Unity has upgraded to SGEN yet?

I don't believe so, I know we had to use the same pool workarounds that everyone seems to need due to this issue
Post reply on HN