Preface

Motivation

I've always been intimidated by technical interviews. Because I don't have a CS degree (I have 4 classes left of my online masters degree at my undergrad alma mater, Georgia Tech, but it's been a few years since I've taken classes and I've got 2 years left to finish. So hopefully I will soon), I had to teach myself data structures and algorithms, on a foundation of a very primitive understanding of programming and computing in general and a not much better understanding of even more foundational linear algebra and mathematics (B.S. in Industrial Engineering doesn't go deep into this). Ramp up was very frustrating and only recently do I feel like I've gotten to the point of being fairly comfortable with data structures and algorithms and with certain technical interview formats.

One difficulty I've had in these interviews is that I struggle to figure out whether to solve a given problem in the functional paradigm or imperatively. Some problems seemingly lend themselves more to the latter (ex. 2d matrix questions with a lot of indexing and element swapping) and others end up being a one liner in the former, where they'd be considerably more difficult to reason about in the latter in terms of tracking mutable state in your head, for example. Because most technical interviews are timed, if i can't come up with a clever one liner that isn't completely unperformant, I'll usually just try to push out functional programming from my brain as much as possible, so as not waste time deliberating on how to incorporate it, and just focus on solving the problem imperatively.

Taking a step back; unless you're interview for an explicitly functional programming role writing Haskell, Clojure, functional Scala, etc., interviewers frankly prefer you stick with the imperative paradigm, just by virtue of the fact that they themselves may not have a strong functional background.

So I'm writing this, as much in an effort to help myself explore functional data structures and algorithms in general, applying them to more brain-teaser/whiteboarding style interview problems, and just generally better delineating the strengths and pitfalls of both approaches to various problem domains, as I hope that such explorations can help you as well