4 ms·
> This is a very basic example, but most students solve it the inefficient way, but in most situations you’d really rather have the ones who did it better. I w
by jschwartzi 8y ago
> This is a very basic example, but most students solve it the inefficient way, but in most situations you’d really rather have the ones who did it better.
I would much rather have the student who solves it the inefficient way but who runs a profiler on their code with a real-world input, determines that their naive algorithm is unacceptably slow for certain inputs, and makes an adjustment to optimize it.
If I'm only ever going to use the first 16 Fibonacci numbers I don't really care if they're brute-force computed recursively. I'd much rather spend valuable engineering time on optimizing something that actually matters. Requiring students to prematurely optimize some ivory tower algorithm as a precondition to working in the real world is precisely why we have a shortage in the first place. You should be training the students to optimize the algorithm when it needs to be optimized, and not just hiring people who've memorized a few very specific algorithms and can bark them on command during your interview.
- hinkley 8y agoMy response would be “just use a loop and get it done so we can move onto the next task”. There are only two pieces of state here. Let’s not drag out the big guns and make something hard to read. Fibonacci is too simple a case to demonstrate the power of recursion, and people have beef with the textbook examples. It has a confounding factors that actually makes recursion an over complicated solution, and not enough factors to make it a good example for dynamic programming. Also it simply doesn’t scale to inputs that only take microseconds to calculate. It’s like those interview questions that leave you with more questions than answers, like “are they bad at interviews or just crazy?”
- jschwartzi 8y agoExactly. It's like a golden opportunity for me to demonstrate some engineering chops and instead the interviewer expects me to just whip out some caching implementation for some nebulous reason because that's what they would have done. If there's a real problem with either of our naive implementations the proper thing to do is to tell us what the problem is and leave us free to solve it.