5 ms·

After running a whole lot of coding interviews, one thing I've noticed is that people that take a functional approach to solving problems more typical end up ha

After running a whole lot of coding interviews, one thing I've noticed is that people that take a functional approach to solving problems more typical end up having a hard time. Mostly because the functional style is more difficult to debug.

toastal 5y ago
Because they didn't use state? Can you elaborate what you mean?
- gilbetron 5y ago
  I haven't really figured out the "why", but the observation is that people that start using the typical functional portions of a language (map/reduce/whatever) are more likely to get bogged down if the code doesn't do what they expect. And this is even for people that seem really good at it.
  - sulam 5y ago
    This is because creating the exact right abstraction for the job is time consuming. It may pay off later, and your typical FP person is fairly convinced that it will in terms of being able to be confident you got things right without having to test a lot of basic shit first (types tend to replace tests). This is not suitable for the typical interview format.
    - deleted 5y ago
      [deleted]
    - gilbetron 5y ago
      That theory seems relatively sound. I'm digging more into functional programming again, because I think reading code needs to be easier than writing code, or at least reading code should be as easy as possible, and maybe it can meet that need.
  - deltaonefour 5y ago
    Debugging functional code is a bit different and not everyone picks up this skill. That's why functional code tends to be harder to debug and people who pick up this skill will take longer in debugging it. The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.
peheje 5y ago
I'm still a newb to F#, but did a few Advent of Code 2021 in it. Once I learned to do a log function that logged/dumped input to a file - and then returned the input - it was trivial to stick this log function anywhere in the pipes or folds or wherever to get a view of the program state. I would then use the "Send to repl" feature to fire off single pieces of my program expressions to get instant feedback on the code I was writing. Long before the entire program was run in whole, each part had been run many times. If you're in a classic whiteboard interview sessions you are robbed of this possibility. That's unfair because it's a big part of working with F# (I would guess other functional programs as well). You might feel you "pay" a bit in avoiding mutable state and having everything as an expression, but you gain so much in return, but you gotta use it! I guess my argument is that a whiteboard situation might favor an imperative style, where you would write, compile, run and not use repl throughout development?
phillipcarter 5y ago
This can also be a classic case of why coding interviews are often a poor approximation of real world tasks. Imperative (and especially dynamic) languages typically make it easy to get something "working", but it can take many iterations or lots of unit tests until it's robust enough to be worthy of handling a production load. That time spent futzing around with it isn't often capturable in an interview. If it is, chances are the interview isn't asking something representative of real-world scenarios, or it's taking a very narrow slice of one where someone's approach is going to change a lot of they're not just working in the narrow slice. Functional (and especially typed functional) languages do make it harder to get something up and running, but they tend to have a nice side effect that if the compiler is satisfied, it won't need more work. That usually happens because you can capture the domain in a type declaration that the compiler requires you to account for all cases of. And if you're missing something, it's easy to adjust because the act of adding another case to your domain makes your compiler point out exactly where else to update your code.

toastal 5y ago

Because they didn't use state? Can you elaborate what you mean?

gilbetron 5y ago
I haven't really figured out the "why", but the observation is that people that start using the typical functional portions of a language (map/reduce/whatever) are more likely to get bogged down if the code doesn't do what they expect. And this is even for people that seem really good at it.
- sulam 5y ago
  This is because creating the exact right abstraction for the job is time consuming. It may pay off later, and your typical FP person is fairly convinced that it will in terms of being able to be confident you got things right without having to test a lot of basic shit first (types tend to replace tests). This is not suitable for the typical interview format.
  - deleted 5y ago
    [deleted]
  - gilbetron 5y ago
    That theory seems relatively sound. I'm digging more into functional programming again, because I think reading code needs to be easier than writing code, or at least reading code should be as easy as possible, and maybe it can meet that need.
- deltaonefour 5y ago
  Debugging functional code is a bit different and not everyone picks up this skill. That's why functional code tends to be harder to debug and people who pick up this skill will take longer in debugging it. The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.

peheje 5y ago

I'm still a newb to F#, but did a few Advent of Code 2021 in it. Once I learned to do a log function that logged/dumped input to a file - and then returned the input - it was trivial to stick this log function anywhere in the pipes or folds or wherever to get a view of the program state. I would then use the "Send to repl" feature to fire off single pieces of my program expressions to get instant feedback on the code I was writing. Long before the entire program was run in whole, each part had been run many times. If you're in a classic whiteboard interview sessions you are robbed of this possibility. That's unfair because it's a big part of working with F# (I would guess other functional programs as well). You might feel you "pay" a bit in avoiding mutable state and having everything as an expression, but you gain so much in return, but you gotta use it! I guess my argument is that a whiteboard situation might favor an imperative style, where you would write, compile, run and not use repl throughout development?

phillipcarter 5y ago

This can also be a classic case of why coding interviews are often a poor approximation of real world tasks. Imperative (and especially dynamic) languages typically make it easy to get something "working", but it can take many iterations or lots of unit tests until it's robust enough to be worthy of handling a production load. That time spent futzing around with it isn't often capturable in an interview. If it is, chances are the interview isn't asking something representative of real-world scenarios, or it's taking a very narrow slice of one where someone's approach is going to change a lot of they're not just working in the narrow slice. Functional (and especially typed functional) languages do make it harder to get something up and running, but they tend to have a nice side effect that if the compiler is satisfied, it won't need more work. That usually happens because you can capture the domain in a type declaration that the compiler requires you to account for all cases of. And if you're missing something, it's easy to adjust because the act of adding another case to your domain makes your compiler point out exactly where else to update your code.