Sad to say, this is exactly the sort of magic that, as the conclusion suggests, gets people not hired. Even on this very enlightened forum people argue in favour of less knowledgeable candidates (even with all else being equal).
But the solutions shown in this series are just pointlessly esoteric. I'm not actually sure what the point of this series is.
Typing the technical interview
71–80 of 86 posts
Re: Typing the technical interview
#72> Seize two meaningless constants from the void, and imbue them with meaning. Holy shit
Re: Typing the technical interview
#73Nope. 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
#74Nope. 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 w…
Re: Typing the technical interview
#75Earlier 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.
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
#76Re: Typing the technical interview
#77> Seize two meaningless constants from the void, and imbue them with meaning. Holy shit
Re: Typing the technical interview
#78Re: Typing the technical interview
#79How.. 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
#80Earlier quoted context omitted.
Here's what's going on, as far as I can tell: A "class" in Haskell is a typeclass, sort of like a trait in Rust or an interface / abstract class in OO languages. An "instance" is a specific data type that satisfies the rules of the typeclass. The classic example is something like this: class Eq a where (==) :: a -> a -> Bool instance Eq Integer where x == y = That is, Eq is a class we can apply to any type a, as long…
What's the runtime? Zero by the usual definition, but then again it's cheating.
Well, one.