
Solving dynamic programming interview problems - otasevic
http://blog.refdash.com/dynamic-programming-tutorial-example/
======
rsp1984
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 candidates).

In my experience these kind of interview questions have a very poor
information by time ratio. They are poor on information because they may give
you an idea how well the candidate can do on puzzle questions but not so much
how the candidate would do on actual real-world assignments. And they are
especially poor on the denominator (time) because you are probably going to
spend at least 1h with the candidate before you get past the obvious stuff.

Also I guess about 70% of (pre-qualified) candidates would outright fail the
question, so if you let this influence your hiring decision, given that the
question is really quite "puzzly", you're inevitably going to miss out on a
lot of talent (the kind that does well on actual work assignments).

~~~
hn_throwaway_99
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 information about the candidate, is _how capably they are
then able to turn the algorithm into actual code_. With many folks you can
basically tell them the entire recursive steps that are necessary and they
_still_ can't translate this into workable code. "How fast can you turn
algorithm into code" is one of _the_ critical skills for all developers, and
these kinds of problems give me good insight into that skill.

~~~
acadavid
> 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".

------
btilly
Speaking as someone who finds DP problems easy, I'd not figure it out from
this approach. The way that I'd think about and tackle it in an interview is
this:

1\. Write a recursive solution.

2\. Memoize.

If you can solve it this way, then you have a DP problem. Of course this
forces you into the top down (aka recursive) approach. But in an interview,
"easier to reason about" is all that matters.

Also the tradeoffs in section 5 has a mistake. Memory can and frequently does
go either way. Top down can let you recognize which states you never need to
think through. But a bottom up (aka iterative) approach can let you discard
memory after finishing an iteration. The memory savings from that can be
considerable.

~~~
blackflame7000
Is recursion really worth the loss of clarity? Almost always no. The more
clever you are in your code, the less likely anyone will ever see it (or want
to).

~~~
jacquesm
Recursion is usually clearer that iterative because it assigns names to the
work being done. I find that much easier to read. Better yet: when you can
state your cases separately. That's even more readable.

~~~
blackflame7000
I don't think you represent the average coder. I'm willing to bet most people
if shown 10 recursive and 10 iterative solutions to the same problems would
admit the iterative approach is more intuitive. Especially since with a for
loop you can control the number of iterations which has a number of
optimization benefits. Now if its just while loops vs recursive then there's
not much of a difference, however that is not the case.

~~~
joefkelley
You might be able to trace the execution of the iterative code more easily,
but in my experience it is often much less clear _why_ that produces the
correct result and _how_ that code was written in the first place.

Take a look at the wikipedia page for computing Levenshtein distance:
[https://en.wikipedia.org/wiki/Levenshtein_distance#Computing...](https://en.wikipedia.org/wiki/Levenshtein_distance#Computing_Levenshtein_distance)

The recursive version needs barely any explanation. But ask me to carry it out
by hand and I'm sure I'll pretty quickly get lost. The iterative version needs
a lot more explanation for why it is the way it is, but I also think I could
carry it out on paper quite easily.

~~~
blackflame7000
I mean if you label all your variables i,j, and k and use minimal formatting
or bracketing then I see your point it is harder to read. Whats complicated
about an iteration. If it works properly after the first one chances are it
will continue to work for the millionth one. If you see problems, its because
something is modifying it between runs, but that wasn't a fault of the
iterative strategy, it was the fault of a bad programmer. Conversely, you must
always make sure the stopping condition and all base cases are met during
recursion. Forget one corner base case and you got a rare production bug.

~~~
throwaway37585
> Whats complicated about an iteration

What’s complicated about a recursion?

> If you see problems, its because something is modifying it between runs, but
> that wasn't a fault of the iterative strategy, it was the fault of a bad
> programmer.

> Conversely, you must always make sure the stopping condition and all base
> cases are met during recursion.

You seem to be applying a double standard here.

> Forget one corner base case and you got a rare production bug.

Base cases are usually much easier to reason about.

~~~
blackflame7000
Then why does NASA consider it unsafe for mission critical code?

How about unknown potential stack size?

How about factoring a large number with recursion?

Everything recursive can be transformed to iterative and yea sometimes it’s
not as sexy but neither is a helmet

[https://www.reddit.com/r/programming/comments/3dnsh1/nasas_t...](https://www.reddit.com/r/programming/comments/3dnsh1/nasas_ten_coding_commandments/)

~~~
throwaway37585
> Then why does NASA consider it unsafe for mission critical code?

They also proscribe unbounded iterations (point 2). In any case, NASA’s
guidelines for mission-critical code are not necessarily good guidelines for
general software engineering, given the constraints involved.

It’s also worth noting that recursive solutions are probably more amenable to
static analysis and automated theorem proving.

> How about unknown potential stack size?

If stack size is a problem, try an iterative solution.

> How about factoring a large number with recursion?

Go with iteration.

You keep editing your answer to add more cases where iteration is the way to
go. I’m not disputing there are use cases where iteration is appropriate.

~~~
danmg
> Then why does NASA consider it unsafe for mission critical code?

More like they're using an old Fortran 77 environment which doesn't support
recursive functions.

~~~
dahart
No that's incorrect. Their rules are C guidelines, and they are easy to
Google. You might want to do that before making assumptions.

NASA's rules, the ones being referenced above, are designed for safety. They
require code to be easy to statically analyze and to have absolutely
predictable behavior.

Also to be avoided: memory allocation, unbounded loops, function pointers,
preprocessor macros.

[https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...](https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-
Critical_Code)

~~~
danmg
Most of the numerical code they're going to use is in Fortran, and
interlanguage calling convention and the runtime might pose a problem.

This is in addition to not using recursive functions being pretty standard in
anything embedded. Early computers and embedded systems had very limited stack
space or had calling conventions that made recursion impossible.

~~~
dahart
> Most of the numerical code they're going to use is in Fortran, and
> interlanguage calling convention and the runtime might pose a problem.

The rationale they used for these rules was written down. It has nothing to do
with Fortran. I've offered links that you can read. You're making more
assumptions. If there's C-to-Fortran calling at all, then recursion presents
zero extra difficulty. Once you can make any function call, you can make all
function calls.

> This is in addition to not using recursive functions being pretty standard
> in anything embedded.

It's true that for small embedded devices, recursion is not used often. It's
also true that function pointers and heap allocations and unbounded loops are
generally avoided too. Though, often main() in an embed is a white(true){}
loop. I wouldn't be surprised to see that at NASA.

One could argue that all of these 10 NASA rules represent some standard
practice in embedded code and/or some degree of common sense. They're not
claiming to be new or non-standard or unintuitive or innovative; they simply
wrote down what people agreed are best practices.

------
dub
I have a fantasy. In the fantasy, an interview candidate says "this problem
has an optimal substructure" or "this problem can be broken into overlapping
subproblems" and then observes "reusing the results of overlapping subproblems
to avoid re-computing them is sometimes called dynamic programming"

At this point, balloons and confetti fall from the ceiling as Donald Knuth
jumps out from under the table to hand the candidate an award for being the
first known example of a candidate using "dynamic programming" correctly in a
sentence.

~~~
mirceal
You know you’ve made it when you have Knuth on standby under the table

------
nilkn
Potentially interesting data point: the company I'm at right now has been
pretty successful for over a decade and has, to my knowledge, never once asked
a dynamic programming question in an interview for any candidate in that
entire time. We've managed to hire a lot of great developers and have very
rarely had any real issues.

~~~
yanslookup
Does the company you are at now pay developers the same as the companies that
ask these types of questions? In my experience the companies asking these
types of questions are picky because they can be.

~~~
nilkn
We pay very well for the area. We are not in Silicon Valley, but I know some
of our salaries are higher than those of my friends who are at Google's MV
campus.

~~~
coastal-fiesta
It's not terribly impressive to have a higher _salary_ then a GOOG employee,
but higher total compensation after stock and bonuses would be saying
something.

------
kizer
Step 1. ur problem graph better be a dag

Step 2. ur sub problems better overlap

Step 3. time to table dat dag

Step 4. solve ur problems and build ur table graph the way a dag would : to-
po-lo-gi-cal-ly

~~~
akhilcacharya
I think the DAG approach is a good one, but the problem is its not great for
being applied generally. For me, it's difficult to think of something like the
"House Robber" problem as a DAG.

~~~
et-al
Can someone explain what DAG stands for? Thanks.

~~~
jensv
[https://en.wikipedia.org/wiki/Directed_acyclic_graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)

~~~
et-al
(Thanks)

------
curiousDog
Unpopular opinion, but the best way to prepare for DP problems is to solve the
well known ones and memorize them and their recurrences. Only 2-3 companies
like FB and Goog ask them (well they’re the only ones worth studying DP for
anyway). Coming up with a recurrence on the spot is very hard. The edit-
distance paper was an award winning ACM paper and expecting someone who has
never seen that before to code it up (even the memorized one) is ridiculous.

~~~
steelframe
The best way to perform well in an interview is to have seen and worked on the
problem at some point beforehand.

When I got a job at Google (in a previous life), two of the questions in my
interview loop were ones that I had seen in previous interviews. I kept my
mouth shut about that and faked brilliance in the moment. That is, I pretended
to be stumped for a second, then I created a narrative where I had a sequence
of 2 or 3 "Ah-ha!" moments where I figured out how to refine my solution.

I cued off the interviewer, waiting until they seemed just about to blurt out
a hint, when I raised my hand and said, "WAIT! Maaaybe.... I can use a BFS
instead of a DFS here and label the cells!" Then the interviewer would usually
smile and nod in satisfaction.

Finally, I "stumbled on" the "right answer" and slammed out the code that I
had pretty much memorized up to that point.

Make a stupid game, I'll play the stupid game, and have fun doing it.

For the record, I kicked ass at Google (getting promoted twice) before moving
on to greener pastures.

~~~
bootsz
Yep, 100% this. I recently finished a series of interviews after extensive
preparation and had at least 3 sessions that went something like this.
Practice enough problems and eventually you start seeing them crop up in real
interviews.

Doesn't say much for the usefulness of such an interviewing paradigm but
that's a whole other conversation.

------
2bitencryption
I recently had a programming interview where, at the whiteboard question, I
said "this may be a dynamic programming question, let me see--"

and the interviewer said "STOP! Stop, every time someone says that, they end
up flopping and never getting anywhere. Don't go down that path, I'm telling
you."

I think it had more to do with the interviewer being a poor interviewer,
however.

~~~
hinkley
I got screwed like that on my Google interview. 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).

Interviewer had already decided that somehow the crazy rules I related to him
about the industry I was coming from were somehow personally my fault to he
had fun letting me twist in the wind.

Personally, I think that given how small the industry is, one of the goals of
the interview process should be not to make an enemy of the candidate.
Candidates have friends, and sometimes candidates come back in a few years
after they've gotten more experience or you're looking for different skills.
None of this will matter to Google until they find themselves in a MS-style
hiring crisis in another five years when they aren't cool anymore.

~~~
lalwanivikas
> 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?

~~~
badlucklottery
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 metric.

~~~
ASinclair
Yep. This is how I conduct my interviews. I don't ask trick questions. Many of
my candidates can quickly notice the simple solution but fail to write the
solution in code.

------
triska
I often use the declarative programming language Prolog to solve dynamic
programming tasks, because it is easy to type and helps you to declaratively
express what a solution looks like. After you have expressed what must be the
case in a solution, you can easily enable memoization on top of the existing
code.

For example, here is how you can use Prolog to solve the task from the
article. The following Prolog predicate is true _iff_ a given runway
(represented as a list of "t" and "f" elements) is safe with a given speed:

    
    
        :- use_module(library(clpfd)).
    
        safe_runway(0, [t|_]).
        safe_runway(Speed0, Rs) :-
                Speed0 #> 0,
                Rs = [t|_],
                (   Speed = Speed0
                ;   Speed #= Speed0 - 1
                ;   Speed #= Speed0 + 1
                ),
                length(Prefix, Speed),
                append(Prefix, Rest, Rs),
                safe_runway(Speed, Rest).
    

Sample query and answer:

    
    
        ?- safe_runway(4, [t,f,t,t,t,f,t,t,f,t,t]).
        true .
    

One interesting aspect of this solution is that we can _generalize_ this
query, and also use the same program to answer the question: _Which speeds_
are actually safe for a given runway?

For example:

    
    
        ?- safe_runway(Speed, [t,f,t,t,t,f,t,t,f,t,t]).
        Speed = 0 ;
        Speed = 2 ;
        etc.
    

To enable _memoization_ for this task, you only have to use your Prolog
system's _tabling_ mechanism. For example, in SWI-Prolog, you turn this into a
dynamic programming solution by adding the directive

    
    
        :- table safe_runway/2.
    

This makes the Prolog engine automatically remember and recall solutions it
has already computed.

------
graycat
So, the OP has:

> Dynamic Programming – 7 Steps to Solve any DP Interview Problem

Here I see "any"!!!

Dynamic programming is a huge field from work of R. Bellman, G. Nemhauser, R.
Rockafellar, R. Wetts, D. Bertsekas, E. Dynkin, W. Fleming, S. Shreve, and
more.

E.g., there is, with TeX markup,

Stuart E.\ Dreyfus and Averill M.\ Law, {\it The Art and Theory of Dynamic
Programming,\/} ISBN 0-12-221860-4, Academic Press, New York, 1977.\ \

Dimitri P.\ Bertsekas, {\it Dynamic Programming: Deterministic and Stochastic
Models,\/} ISBN 0-13-221581-0, Prentice-Hall, Englewood Cliffs, NJ, 1987.\ \

George L.\ Nemhauser, {\it Dynamic Programming,\/} ISBN 0-471-63150-7, John
Wiley and Sons, New York, 1966.\ \

E.\ B.\ Dynkin and A.\ A.\ Yushkevich, {\it Controlled Markov Processes,\/}
ISBN 0-387-90387-9, Springer-Verlag, Berlin, 1979.\ \

Dimitri P.\ Bertsekas and Steven E.\ Shreve, {\it Stochastic Optimal Control:
The Discrete Time Case,\/} ISBN 0-12-093260-1, Academic Press, New York,
1978.\ \

Wendell H.\ Fleming and Raymond W.\ Rishel, {\it Deterministic and Stochastic
Optimal Control,\/} ISBN 0-387-90155-8, Springer-Verlag, Berlin, 1979.\ \

some of my work, etc.

Dynamic programming has been and is a major interest of the Department of
Operations Research and Financial Engineering (ORFE) at Princeton.

Uh, "any" seems a bit optimistic!

~~~
hinkley
If I had to guess, I'd wager that the Venn diagram of Dynamic Programming
questions and _interview_ questions is a narrow sliver.

That is, unless you're being hazed, the sort of questions to show up in an
interview might be at the shallow end of the pool.

~~~
thereare5lights
lots of places have a fetish for dp questions

------
scarface74
And most of the interviewers asking these questions just want someone who can
help develop yet another software as a service CRUD app....

~~~
mikec3010
Exactly. I've been a C, C++, and java developer for the past 12 years and
never used Big-O for anything other than a shibboleth to get past the door. A
couple places practically used C++ itself as a gatekeeper: they want people
who are smart enough to program in C++ and survive it's rigorous interview
process, but their main product is filling out forms and routing documents
through a document management system.

~~~
scarface74
I did have to do one algorithm type interview in 1999, but the company was
actually writing cross platform (Windows console, Unix, and MVS) C code where
we had to implement everything from scratch, so it made sense. But unless
you're Google, Facebook, Netflix, etc. where you have to solve problems at a
scale that no one has had to solve before, most of the algorithm style
questions are meaningless in your day to day work.

------
grogers
Great post about how to attack solving a problem using DP. But this is not a
good interview question.

It's a toy problem, not something you'll ever need to solve in real life.
Maybe if you squint hard enough it's close to pathfinding algorithms, but be
serious. I hate questions that aren't remotely relatable to something the
candidate might experience. I get that interviews are short so you need tiny
problems, but making them somewhat relevant will make comprehending the
problem that much easier and give plenty of time for working on a solution.

There's also not much depth to it. Either they can get a naive solution, get
the DP solution, or just can't solve it. Maybe I'm just not creative enough
but the only follow up I can think of is the typical 'how to test' and this
isn't even a good question for that. For me as an interviewer, it is better to
start with an easy problem, and then later on additional complexity. For
example dealing with concurrency, how to generalize the solution for other
cases, etc. These follow ups don't even usually need full code written out so
you can get much deeper since it's faster. Whereas if you start from a
hard/tricky problem and have to keep explaining it and hinting at how to solve
it, both candidate and interviewer feel bad and you haven't learned much.

Not that this is a particularly hard problem, it will fit within an interview
slot if they are on top of things. But it's similar enough to questions I hate
asking/getting (e.g. min of maxes of sliding windows) that I would definitely
never ask it.

------
zawerf
In python you often need sys.setrecursionlimit for the recursive solutions
since the default is really small.

I found out the hard way in a recent Google CodeJam problem[1] that even that
wasn't enough and sometimes you really do need the iterative solution to not
time out. (I still believe that the limits for python for this problem was set
too low since even the iterative solution required hand optimizing of the
memory usage to pass but the equivalent C or C++ solution didn't require any
tweaks)

[1]
[https://codejam.withgoogle.com/2018/challenges/0000000000007...](https://codejam.withgoogle.com/2018/challenges/0000000000007765/dashboard/000000000003e0a8)

~~~
dahart
Yes that, or code the recursive solution in a heap-allocated space rather than
on the stack. It somehow seems easier, safer, and more explicit and
controllable to me to adjust the code & data to use manual recursion with
backtracking than try to adjust system stack limits. Often it consumes a lot
less memory too, since you have more control over what your "stack frame"
looks like; you don't have to store all your local variables for every step.

~~~
akshat_h
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.

~~~
Adverblessly
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<BinTree *> custom_stack;
        custom_stack.push_back(tree);
        long long value = 0;
        while (!custom_stack.empty()) {
          BinTree *node = *custom_stack.rbegin();
          custom_stack.pop_back();
          if (NULL != node) {
            value += node->value;
            custom_stack.push_back(node->left);
            custom_stack.push_back(node->right);
          }
        }
        return value;
      }
    

Did not check this actually compiles etc. but you get the point. Both ways
will give you the same solution in the same way, time complexity, space
complexity etc. but the second one is not bound by max call stack size (only
by max heap size). Additionally, the second one is slightly more space
efficient, since the recursive solution requires saving an entire call frame
into the stack (e.g. stack pointer, return address) whereas the iterative
solution just stores one pointer per stack item.

~~~
dahart
This is exactly right; thank you for providing the example. This is manual
recursion in a heap allocated space.

If you were coding a DP problem, then custom_stack might have a fixed size you
can pre-allocate, and it might also be 2 or 3-dimensional.

For some image-based recursion, your backtracking doesn’t even need to store
real pointers in the stack frame. For example when I’ve written a flood fill,
I can store the return pointer as a one pixel offset in as little as 2 or 3
bits, depending on whether I include diagonal pixels (4-surround vs
8-surround).

------
morazow
I did watch live where Nikola solves this problem,
[https://www.youtube.com/watch?v=kKhnYLpME3w](https://www.youtube.com/watch?v=kKhnYLpME3w).
It covered most of requirements of dynamic programming. For me the interesting
part was coming up with algorithmic complexity (Big-O) of the solution.

------
mychael
Above all else, Dynamic Programming is useful for making yourself feel like a
superior programmer and writing blog posts about it. In 10+ years of working
in this industry, I can't recall using it once outside of interviews.

------
lainga
6 points and already hugged to death...?

    
    
      <h1>Error establishing a database connection</h1>

~~~
jjaredsimpson
[http://webcache.googleusercontent.com/search?q=cache:bP5uFme...](http://webcache.googleusercontent.com/search?q=cache:bP5uFme-168J:blog.refdash.com/dynamic-
programming-tutorial-example/+&cd=1&hl=en&ct=clnk&gl=us)

~~~
otasevic
Thanks for sharing the link while it was down. Appreciate it.

------
bajsejohannes
A tiny correction in the following:

    
    
        if (position + adjustedSpeed in memo and
            adjustedSpeed in memo[position + adjustedSpeed] and
            adjustedSpeed in memo[position + adjustedSpeed]):
    

The middle line is not needed.

~~~
otasevic
Thanks! Corrected it now to remove the duplicate line.

------
braindongle
It's a bad sign when a self-proclaimed authority lifts the definition of the
topic from Wikipedia. Unless said authority wrote the Wikipedia entry, in
which case I humbly apologize.

------
celim307
I just give them a real world issue/bug/feature and ask them how they would
complete it. Obviously im looking for as best an answer they can give me
without knowing my whole stack, but what's even better is if they ask
questions about my stack. Shows they know how to do requirements gathering and
if they ask the right questions.

------
chillee
I think the problem is easier viewed as just a standard graph traversal
(although you can view graph traversals as DP...)

[https://ideone.com/rU5COm](https://ideone.com/rU5COm)

------
hyperation
Is it just me or the Big O algebra at the end doesn't seem right?

~~~
danbruc
What do you think is wrong, I did not notice any really obvious mistake?
Admittedly you would miss the improved bound unless you actually modified the
implementation to abort further evaluation once you reach the maximum speed
that still allows stopping, but I assume that is implied. I also guess one
could even further improve the exponent to 1.25 by taking advantage of the
fact that the maximum speed that still allows stopping decreases from left to
right but I did not actually think it through, it is just my intuition that
you would gain another square root.

~~~
danbruc
Being able to improve the exponent to 1.25 is probably wrong. After thinking
about it more carefully I think you end up with a number of steps proportional
to the generalized harmonic number of order -0.5 of L which seems to be
Θ(n^1.5) but I am not really sure about that.

------
netvarun
Being able to solve dynamic programming problems may or may not get you a job
but it certainly will get you a medal at high school programming/informatics
Olympiads.

------
lalwanivikas
I really wanted to try out your service couple of weeks ago, but turns out you
are only in US. Any plans of opening it for Europe?

~~~
otasevic
Yes, currently it is only available for people searching for jobs in the US. I
would say the answer is yes long-term, but probably not over the next few
months.

------
psychometry
I was excited for the article based on the title, but the example problem
makes absolutely no sense to me.

------
rajacombinator
What kind of companies ask dp problems in an interview? Seems pretty absurd.

------
rikelmens
A blog post Peter Norvig commented. Nice.

------
Karishma1234
I have always found the word DP to be a bit confusing. DP problems are
essentially recursion + caching. I do not even like the word "memoise".

~~~
coastal-fiesta
Indeed, it sounds like someone is just saying "memorize" incorrectly.

~~~
kolpa
That's what happens when you "recurse".

------
mlevental
why are there so many companies trying to "solve hiring". i get it's a big
expense to make a bad hire but how are there like 10 different companies
thinking they have an edge on

1\. existing practices 2\. each other

~~~
otasevic
It's not only a big expense. It is a stressful, biased and highly ineffective
process. There is very little (if any) correlation between performance in
interviews today and work performance.

It's a hard problem that requires people to approach it seriously. And it is
only getting worse with a high growth in number of people getting into tech.

It's interesting to try to solve it.

