Thank you. I wish to someday walk into an interview and pull out Clojure as my language of choice and write every bit of code they ask me to as a pure function - and then look into the interviewer's eyes and try to decipher if they had seen the eternal light of Lisp yet.
I did an on-site this past Monday. They allowed me to code the homework in whatever I wanted. I used Haskell. We code-reviewed it in Haskell, with a guy there who knows Haskell.
I had that happen to me once. A candidate (college hire) chose to code in Haskell, which I had a passing familiarity with. We offered him the job, and he was definitely a strong hire, and we used Java mostly.
I also got a homework which I could implement in whatever I wanted and knowing they are a Clojure company… I chose OCaml. We did the review of the code, explaining the interviewer enough of ML to make him being able to understand the code and why I solved things this way. Was a fun day, would recommend it.
Follow-up: someone saw the above comment, asked who I was, and it turned out my middle-school friend worked at the company. Interviewing somewhere new now.
I've done this by deriving most of the functional constructs in the language. At the end the guy was finally like, do you know lisp? Most people just don't have the knowledge base and think you don't know what you're doing.
That sounds like a reasonable question to me. If you're rolling your own versions of built-in constructs then you're writing code that's hard for other people to maintain. It's a bad sign when the interviewee writes weird, non-idiomatic code. I interview people all of the time who say that the programming language they're most familiar with is Java but use classic Java 1.4 style iterators to loop over a List. It's a huge red flag.
1. Simple iterators vs Syntactic sugar both pass the same unit tests
2. The 'Java 1.4' style closely matches idiomatic golang code, which has high adoption and maintainability
3. People who want better iterators, also want better everything, leading them to use more progressive JVM languages like Clojure and Scala rather than just waiting for the Java spec to move forward
I don't see a 'red flag', just simple contextual differences
Item 46 in Effective Java is to prefer new-style iteration. I think dismissing best practices is a warning, though perhaps not dire (it could just be ignorance / oversight / the pressure of that interview).
I see plenty of red flags, starting with a developer who hasn't kept herself updated on a technology she uses every day.
Sure, she might be forced to use 1.4 in her job but surely, any developer who's a bit passionate about what they do would be aware of the more modern version of their tool of choice?
If we use 1.8 where I work, I can't really evaluate whether she'll be able to adjust since she didn't make any time to adjust these past ten years.
Rephrased: 'I prefer the 1.8 style and I hire people based on that'.
For interviewing, the 1.4 style is totally valid, works in more environments and achieves the same result. I don't red flag folks who answer questions based purely on small preferences, in the same way I wouldn't red flag you for writing these loops instead of using map / reduce concepts instead.
If this is what you care about, then ask questions that lead the interviewee to demonstrating knowledge of these skills. Demonstrating skill with functional-ish "stream" APIs means the developer is a lot more likely to understand any impl's built on functional paradigms (e.g. Spark, actors, etc.), or at least can pick them up very quickly since the APIs and semantics are quite similar.
A candidate who writes list.stream().filter(...).map(...).collect(...) gets big bonus points in my book. I'll ask them about efficiency, to see if they know when to drop to for-loops. If they write a 1.4 for-loop, I'll ask them to evolve or parallelize it to see if, at some point, they stop adding complexity to their loop and instead switch to a cleaner functional style. Starting from a for-loop and asking to implement some simple transformations like filters, reverse, group by, map, etc., does wonders to separate the wheat from the chaff here.
What about JS with multiple idiomatic styles? I was asked what filter and each do, which I wrote out because they are super small. Easier to show a little code to explain.
Nothing wrong with functional languages, and from my experience an engineer who knows one or two functional dialects tends to be pretty good. Exceptions exist but they are rare. We also give our candidates the freedom to use any language they want. After all, there are only four language families; the rest is mostly syntax.
But I do carve out a special exemption for myself when[+] I interview someone. I kindly request the candidates that they don't use Scala or Prolog.
A buddy of mine, for fun, has learned how to hand assemble X86_64 ELF binaries using a primitive line oriented text editor and arcane keyboard sequences. He's used this technique to bootstrap his own stack based programming language and tools.
He's got an interview coming up, where he can work in the programming language of his choice. I tried to talk him into doing his coding problems in hand assembled X86_64, but he apparently wants to get the job and doesn't want to come off like an arrogant jerk, so it's going to be Python.
ummm.... okaaaaay.... so in past live's I've managed processor validation groups, including at Intel, so if somebody came in and hand-assembled X86_64 code right before my eyes, I'd think "Great! Most people have to learn that on the job." Being able to disassemble X86_64 in your head is a valuable skill, too. For my next question I'd probably move on to asking them how to create a particular pattern of I-cache misses. And for bonus points, write out the bits of pi as a 32 bit float.
Because, IMO, it combines the worst aspects of Java, Delphi and FP family traits in the same package.
Trying to follow what a Scala program does under the hood makes my head hurt. Following the edge cases through a forest of syntactical candy-floss is just too much. The plain Java parts are not bad, but the moment you pull out and nest all the special lispy shortcuts... from that point onwards I need to expend a big fraction of my brain cycles trying to figure out just what the hell the piece of code is actually doing. Or trying to do - because I can't properly trace the subtler logical parts.
And the end result is that, with Scala I do not feel qualified to assess your problem solving approach. Code should be written for computers to run, but for humans to understand.
if you ever care, the wizard book[1] can get you started with a toy implementation of prolog. it's just searching through a big state space, really not much to it. The key idea is unification. PAIP builds up to it in a nice way, and the scheme language spec has (had?) a nice unifier as an example[2].
it's also pretty reasonable to just say to hell with prolog, and go do other fun things with your life. But if you do care at some point, it's not magical. it's just a fancy search.
> But I do carve out a special exemption for myself when[+] I interview someone. I kindly request the candidates that they don't use Scala or Prolog.
What if I offered to teach you basic Prolog for an hour ;)? One of my favorite side projects was playing around with it and seeing how clean and concise it could make the rules for T9-style (this was like ten years ago) predictive text matching, going from digit -> letter.
