Live data from Hacker News

Solving dynamic programming interview problems

blog.refdash.com

171–176 of 176 posts

Re: Solving dynamic programming interview problems

#171
post #136

Earlier quoted context omitted.

Yep. We need superman, but we are a bicycle repair shop. Only superman will do, that is the only thing we know for sure.

In another world, everyone is superman and we are looking for a bicycle repair man: https://www.youtube.com/watch?v=54CpPlCnM4I

Hoped someone would get the monty python reference :D

Re: Solving dynamic programming interview problems

#172
post #79

I've done a fair amount of interviews in my professional career, both as an engineer at Google as well as for my own startup. In an eng. interview you want to maximize information divided by time, i.e. you want to learn as much as possible about whether the candidate would be a good fit for the company and spend as little time as possible doing so (because you have other things to do -- such as interviewing more cand…

I very much disagree with this assessment, the reason being that, as an interviewer, the least important part for me is whether or not the interviewee "gets" the problem initially. I have no problem giving the interviewee tons of hints about (a) it's a dynamic programming problem and (b) what the different cases are. At that point though, what I'm really interested in, and what I think tells me a ton of valuable info…

> I don't care if the candidate "gets" the problem

> "How fast can you turn algorithm into code" is one of the critical skills of all developers.

I don't understand this industry anymore. If I have anything to say about software is that solving the right problems is the main skill in an Engineer. Then, figuring out an algorithm is the hard part of solving any problem, turning it into code is usually never as hard (except for technical nuances) and especially, not how quickly it becomes code. Not sure how someone can value "how fast can you turn algorithm into code" over "understanding/solving the right problem".

Re: Solving dynamic programming interview problems

#174

Earlier quoted context omitted.

> You should not be blamed for assuming, when talking to Google, that the O(n!) or O(n^2) solution is not even worth talking about. So I flopped around on O(n), O(nm) and O(nlogn) solutions after trying to whiteboard a recurrence relationship and giving up on O(1). Did they say that they don't even want to listen to O(n^2) solution?

I'd be super surprised if they did. Google interviewers usually encourage you to spit out an easily-verifiable O(n^2) (or even worse!) solution as fast as possible. That way, if you get stuck and honestly can't finesse a faster solution, you can code that up and provide a code sample. People still try to fake their way through the process so being able to code up something close to a compilable function is a useful m…

Yeah, this wasn't a coding question.

Re: Solving dynamic programming interview problems

#176

Earlier quoted context omitted.

Any examples of code for this approach? From what I guess, you are implementing some kind of assembly like approach with explicit saving of stack frame, but I am having a hard time imagining it as being easier.

Not OP, but they probably mean something like the following toy problem (in C++): struct BinTree { long value; BinTree *left; BinTree *right; }; long long RecursiveDFSSum(BinTree *node) { if (NULL == node) { return 0; } return (long long)value + RecursiveDFSSum(node->left) + RecursiveDFSSum(node->right); } long long IterativeDFSSum(BinTree *tree) { std::vector custom_stack; custom_stack.push_back(tree); long long val…

Thanks! I was getting confused between stack data structure, function stack and stack space and had gotten to a weird mix in my head. The example cleared it up.
Post reply on HN