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

Typing the technical interview

aphyr.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Typing the technical interview

#61

Post by menssen »

Nope.

This is a polemic against people who don't know Haskell. Previous iterations were the same except Clojure/Lisp.

Aphyr/Kyle is a genius, and one of my favorite people on the internet. But this series is the WRONG way to attack the code interview, which deserves to be attacked, BUT.

Some of us face real challenges about how to find common ground with interviewees. Because you know you're smarter than those questions is not a reason to discount them.

I will sacrifice ALL my HN points to say this is bullshit. Bullshit written in decent prose, but still bullshit.

Re: Typing the technical interview

#62

Post by harpocrates »

marcosdumay wrote: post #44
_qc3o wrote: post #33

Earlier quoted context omitted.

Any sophisticated enough type system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Prolog.

It's quite formally specified. Seems to not be very bug-ridden either. But maybe somebody should code a non-backtracking operator extension for GHC. This way, next time he could claim Haskell is a dynamically typed, interpreted, lazy and not-pure language.

> It's quite formally specified.

Haha, that's a good one. Haskell, unlike SML, is _not_ formally specified. If only, if only... sobs

Re: Typing the technical interview

#63

Post by borp_borp »

zellyn wrote: post #55
borp_borp wrote: post #45

Jesus christ, what the fuck is with this guy's tumblr.

I am laughing so hard right now. Aphyr is the origin of "It’s San Francisco. Everyone’s into distributed systems and BDSM." https://circleci.com/blog/its-the-future/

Too bad the dicks around here are all about flagging a bitch.

Re: Typing the technical interview

#64

Post by jldugger »

geofft wrote: post #54
jldugger wrote: post #53

Earlier quoted context omitted.

Yes, and that functional language is LISP, as demonstrated by the parentheses and Cons operator, and a few other things I probably didn't catch. I suppose it's less educational, and more just a meta-level trolling.

I don't think it's actually Lisp. Lisp is essentially an imperative language; you use functional concepts, but you're telling the computer what concrete thing to do at each step. This is just asking it to resolve types in a type system, using whatever algorithm it likes to satisfy the type constraints. Note, in particular, the complete lack of algorithm to solve the actual n-queens problem: just the constraints.

Fair enough, I pretty much nope'd out after the "Haskell is a dynamically-typed, interpreted language" bit, scrolled to the end, and saw some LISP-y output.

Re: Typing the technical interview

#66

Post by mrkgnao »

menssen wrote: post #61

Nope. This is a polemic against people who don't know Haskell. Previous iterations were the same except Clojure/Lisp. Aphyr/Kyle is a genius, and one of my favorite people on the internet. But this series is the WRONG way to attack the code interview, which deserves to be attacked, BUT. Some of us face real challenges about how to find common ground with interviewees. Because you know you're smarter than those questi…

I doubt Aphyr/Kyle is one of those people who would know how to simultaneously rotate five binary trees using only one pointer off the top of his head (or whatever). The point of this series isn't that it's an attack on people who aren't comfortable with Haskell type magic (or the extremes of Lisp or JVM classloader-fu): whatever made you think that?

Now if you mean that making fun of the coding interview itself is wrong because there exist people who either interview people for a living or people who are job-hunting right now, and this makes light of their troubles, well, that's different. I disagree, but it's still more sensible than "lol you dont know Haskal, nub".

Re: Typing the technical interview

#67

Post by mrkgnao »

jldugger wrote: post #49
Wazzymandias wrote: post #47

I honestly have no idea what's going on, but his writing is humorous.

As far as I can tell, this is an article teaching functional programmers LISP, using the framing of a LISP programmer who trolls a technical interviewer by writing LISP-like Haskell libraries with which to solve the n-queens problem.

This is closer to using the type system to simulate something Prolog-like, where typeclass membership is like a predicate.

Re: Typing the technical interview

#68

Post by imh »

menssen wrote: post #61

Nope. This is a polemic against people who don't know Haskell. Previous iterations were the same except Clojure/Lisp. Aphyr/Kyle is a genius, and one of my favorite people on the internet. But this series is the WRONG way to attack the code interview, which deserves to be attacked, BUT. Some of us face real challenges about how to find common ground with interviewees. Because you know you're smarter than those questi…

I really didn't read this as an attack or polemic on code interviews. It's just a fun parody. Like how the TV show Silicon Valley some times pokes fun at actual Silicon Valley, but isn't an attack on it.

Re: Typing the technical interview

#69

Post by mrkgnao »

occultist_throw wrote: post #7

How.. beautiful. Like I said earlier in the "half-dead chicken thread", the occult is a quiet and powerful force in computer science and related areas. With things like neural networks and learning functions, we're approaching the ultimate. In this case, it was only a handful of lines of a functional language that could solve the N-Queens problem.. Of course, mixed with a bit of Lovecraftian lore and Norse magic. It'…

Is this an HN novelty account in the making?

Re: Typing the technical interview

#70

Post by mrkgnao »

jcrites wrote: post #52
jldugger wrote: post #49

Earlier quoted context omitted.

As far as I can tell, this is an article teaching functional programmers LISP, using the framing of a LISP programmer who trolls a technical interviewer by writing LISP-like Haskell libraries with which to solve the n-queens problem.

I'm not a Haskell expert (and I skimmed the article), but I believe the article is about designing a simple method of computation that runs on top of Haskell's type system and that operates via type inference. The answer at the end is evaluated by asking Haskell to print out the type of the variable "solution", and the answer is encoded within that variable's type (rather than its value). In Aphyr's meta-language, "v…

  PeanoEqual(a,    b) =    # a and b are both nonzero
     PeanoEqual(a-1, b-1)  # so recurse
Subtracting Peano literals would involve some constraints in the type, so shouldn't that be (a+1,b+1) for typing purposes?
Post reply on HN