Skip to content

Instantly share code, notes, and snippets.

@trueskawka

trueskawka/takehome-fp-interview.markdown

Forked from pchiusano/takehome-fp-interview.markdown
Created March 24, 2018 01:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save trueskawka/4f19f32071d9325c132802c52c8f3777 to your computer and use it in GitHub Desktop.
Save trueskawka/4f19f32071d9325c132802c52c8f3777 to your computer and use it in GitHub Desktop.
Download ZIP
FP interview
Raw
takehome-fp-interview.markdown

Take-home functional programming interview

This document is licensed CC0.

These are some questions to give a sense of what you know about FP. This is more of a gauge of what you know, it's not necessarily expected that a single person will breeze through all questions. For each question, give your answer if you know it, say how long it took you, and say whether it was 'trivial', 'easy', 'medium', 'hard', or 'I don't know'. Give your answers in Haskell for the questions that involve code.

Please be honest, as the interviewer may do some spot checking with similar questions. It's not going to look good if you report a question as being 'trivial' but a similar question completely stumps you.

Here's a bit more guidance on how to use these labels:

  • 'trivial': need at most 15 seconds or so of thinking for each part of your answer you actually write down, and your answer is immediately correct (example - the answer is one line of Haskell, and you immediately can write it out without having to think much)
  • 'easy': need a minute or two of thinking for each part of your answer you actually write down, with minimal futzing around after (example - the answer is one line of Haskell, but you have to look some things up first, think through some things, then write down your answer, which maybe isn't correct at first, but you quickly fix any mistakes)
  • 'medium': need a few minutes of thinking for each part of your answer you actually write down, and possibly a few minutes of iteration fixing mistakes after
  • 'hard': need more than five minutes of thinking for each part of your answer you actually write down, and possibly lots of time iterating, revising, and restarting. Possibly need to go off and learn about a whole new area of FP you've had little exposure to previously.
  • 'I don't know': you don't know

If there's things you don't know but want to quickly learn because you're a go-getter, please go right ahead. Just be honest about that, and indicate how you tried to learn what you needed for the question and how that went ("I read 20 different blog posts and the last one finally made it click!" or "I asked someone in IRC and they walked me through it" or "I read some chapters of a book and got stuck, then stopped because it was taking a long time").

Lastly, try to RELAX and take your time. Don't feel like you have to crank through it as quickly as possible or answer all the questions in one sitting. Don't worry about precisely timing yourself or anything either.

General areas:

  • Nuts and bolts
  • Reasoning about types
  • Knowledge of common functional structures
  • Library design
  • Knowledge of various deeper areas in FP

The questions

  1. Sum up a [Int], using explicit recursion. (nuts and bolts)

  2. Write a function to reverse a list, including its signature. If possible, use one of the fold combinators, rather than explicit recursion. (nuts and bolts)

  3. Implement filter for lists. (nuts and bolts)

  4. Implement filter and takeWhile using foldr. (nuts and bolts)

  5. Implement functions with the following types: (reasoning about types)

  • forall a . a -> a
  • forall a . a -> (a, a)
  • forall a b . (a -> b) -> a -> b
  • forall a b c . (a -> b -> c) -> (a,b) -> c

  1. Give the Monad instance for Maybe. Explain the meaning of liftM2 for Maybe. (knowledge of functional structures)

  2. Give the Monad instance for (->) e. Explain the meaning of liftM2 for (->) e. (knowledge of functional structures, reasoning about types)

  3. Implement a function with this type: Applicative f => [(f a, b)] -> f [(a, b)] (nuts and bolts, knowledge of functional structures, reasoning about types)

  4. Implement a function with this type: (Traversable t, Applicative f) => t (f a, b) -> f (t (a, b)) (nuts and bolts, knowledge of common functional structures, reasoning about types)

  5. Give an Either-like data type whose Applicative accumulates errors. (knowledge of functional structures, reasoning about types)

  6. Does data Pair a = Pair a a have a reasonable Applicative instance? If so, what is it. What about Monad? (knowledge of functional structures)

  7. Design a parser combinator library. Assume all input is in memory, as a string or Text. Give the basic parser data type and the implementation of all typeclasses through MonadPlus. (library design)

  8. A smattering of questions, many of which don't have right answers, but give some sense of your depth of knowledge of the field:

  • Give your take of the current status of the discussions around monad transformers vs extensible effects in Haskell and/or other languages.
  • Type theory - link to a paper or book you've read and liked on type theory. What did you like about it?
  • What is FRP? What's an influential paper in the FRP space?
  • What do you think of Conal Elliott's approach of 'denotational design'? Do you have a design methodology you can articulate?
  • What are some approaches to dealing with variable bindings in a compiler implementation?
  • What's a good reference for describing how to implement the runtime for a lazy language?
  • Pick a library by Ed Kmett. Describe what it does and the key ideas behind it, enough to show that you understand it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment