Reflections

[sgharms]

I think these are good, but I have some insights from my recent interview rounds.

---

Palindrome Syndrome

I think that the "can you code it" is the baseline. I think there are additional questions that should come up:

• Why might you prefer iterative over recursive (memory depth)
• What's the memory footprint of the various implementations? Can you implement a solution that could work in constant memory space? (hint move from pointer from left / right ensure they match and move down till they overlap or cross)

Fibonacci Challenge

For frighteningly small numbers, a recursive situation will detonate the machine (per above).

Spreadsheet Savior

That was fun. Here might be a good chance to ask if they can theorize about the runtime.

Here was my impl:

data
.map( row => row.sort() )
.map( row => (row[0] - row[row.length - 1]) * -1 )
.reduce( (i,e) => i +e )

For (the number of rows = n) We execute a sort operation (n log n; usu.) in JavaScript We find two elements with constant lookup (0 and -1) Arithmetic is constant Reduce is n

So I think O(n) here (pls get a 2nd opinion here). Whtever the case, even if we're not at O() discussions, they should be able to notice they're (say) doing a redundant work (if applicable).

[DanielSeehausen]

I want to second steven's points above! In place vs. not, iterative vs. recursive. While an explanation of iterative vs. recursive will be redundant for many of these problems (the same explanation will be appropriate across the board for the most part), in-place vs. not is crucial to include if we are teaching interview questions.

[howardbdev]

Really appreciate your feedback guys. We are looking for guidance here - how much/detailed of a solution and explanation should we be providing and going through - versus just making basic points and encouraging students to self-study further (in order to keep these down to an hour).?

[sgharms]

My take:

They should already know how to code so the focus shouldn't be on the code itself.

I think you should provide solutions but offer choices.

Here's a solution (recurisve) but for number > 100 we're going to detonate the machine, how might we fix that solution-iterative solution-in-place-memory-swap (probably only for C or similar..but, y'know)