On the job interview... Composition

In this talk, we’re going to pretend we’re on a job interview, and have been given a single starting function. Using only this function, we have to build up many more functions. Can we pass the interview and get the job!?

Transcript

1. On the job interview… kyle simpson
2. Hello, welcome to Inter-Dot Web Solutions! I’m Maria, and I’ll be conducting your technical screen interview today.
3. Thanks, I’m excited to be here and ready to jump into the technical interview!
4. Let’s jump right in, then. I’m going to give you a single function, and we’ll use that function throughout the interview.
6. Can you tell me what this function does? Can you write some code that uses it?
8. Fantastic, well done! Now, what if we wanted to compose more than two functions, like this?
10. Could we do that by using ONLY the “composeTwo” function?
12. Great. But is there another way you could use “composeTwo” to express the composition?
13. …hmmmm…
14. Ah! Function composition is associative, so we can do this instead…
16. Indeed, nice. “f”, “g”, and “h” functions all produce the same output. But are they the same kind or shape?
17. …hmmmm…
18. We can use equational reasoning to substitute the definition of “composeTwo” inline, and compare.
20. What do we know about the differences between how “f” would execute compared to either “g” or “h”?
21. “f” will have a call-stack depth of just 2, but both “g” and “h” will have call-stack depth of 3.
22. You’re doing great! Now let’s add in a fourth function as part of the composition.
24. Seems like it’s going to become very cumbersome to keep nesting calls to “composeTwo” as we add more steps to the composition.
25. Any ideas on how we could define a “compose” function using “composeTwo”, but which can compose as many functions as we need?
26. I think so.
28. Can you explain that?
29. Looping through the function arguments in reverse, and for each iteration defining a new “f” that is the composition of the previous “f” and the preceding function argument.
30. Instead of looping through the function arguments in reverse, could you loop forward and still compose?
31. Associativity to the rescue, again!
33. Wonderful. And just like before, what are the differences in shape of these?
35. But now the call-stack depth is 4 for both “g” and “h”, whereas it’s still just 2 for your “f”.
36. These loops you’ve written, they look like reductions to me. Can you express them with reduce utilities?
38. Impressive! And the shapes of these functions?
40. Same shapes, respectively. And same call-stack depth of 4.
41. Interesting. Instead of loops, let’s try recursion.
43. Yet again, same shapes and same call-stack depth of 4.
44. Huh. Usually linear loop-based algorithms end up with lower call-stack depth than recursive algorithms, but not here.
45. Any idea how we could make a definition for the general “compose” that doesn’t have the higher call-stack depth?
46. …hmmmm…
47. I think the problem is that by using the “composeTwo” function, we’re lazily deferring the actual function calls.
48. Instead, if we eagerly compute each intermediate composition result, and then pass that onto the next, it should keep the max call-stack depth at 2.
49. OK, that sounds good. Can you do that with loops, reductions, AND recursion?
51. Amazing. But what are the shapes of those functions?
53. The loop and reduction implementations are now call-stack depth of 2. But the recursion one is still call-stack depth of 4.
54. Perfect. Well, I have to say, you breezed through this technical screen interview. We’ll be in touch!
55. thanks! kyle simpson