It gives both the employer and the candidate a chance to evaluate each other in context.
As an employer, you get to see how the candidate performs on two different real-world tasks, as well as how they interact with existing employees.
As an employee, you get to see what the company is really like to work with. No amount of whiteboarding can deliver that.
And at the end of the day, if that relationship feels good, both parties can choose to continue onwards towards full employment.
On the other hand, computer science trivia, by which I mean "implement Dijkstra or quicksort on a whiteboard", is a very poor means indeed by which to test for the ability to do real-world work in a real-world context.
Sure, it's valuable to have a broad understanding of algorithms and data structures. But whiteboard interviews on those types of problems only tests how well you would do competing in an ACM (Association for Computing Machinery) challenge, not how well you can deal with "here is a totally new-to-you problem that lacks a precise solution, now work productively with a team to solve it under the constraints of an operating business"
[1] https://builttoadapt.io/the-developer-hiring-process-is-brok...
[2] https://blog.jonrshar.pe/2016/Dec/05/pivotal-interviews.html
For the day-in-the-life, I got to work on real problems that I would be solving, in the manner of working that Pivotal espouses, with the colleagues I would be working with, in the environment that I would be working in.
I think that these interviews are particularly suited to Pivotal's model of working (in particular the pair-programming) and are probably less suitable elsewhere.
"We believe coding is a social activity. In fact, we’re testing you to see how social you can be around coding."
That makes the process less suitable for other types of working environments.
Probably activity is valued higher than progress.
They are certainly not looking for Knuth, who would likely fail the interview.
The other statements don't ring true for me, but I understand it's just your viewpoint.
But the generalisation is just stupid.
But I expect to go into interviews and have people demand a different rain dance, now that everyone is talking about DP. They like mugging people with 'so big it has to be out of core' stuff, which is a good way of finding out who went to the right grad school algorithms course. :-)
A cautionary tale about being overly clever-clever I suppose.
You are right about that, at least according to that article here:https://news.ycombinator.com/item?id=18942572
That guy trained on a well known website to solving minor coding issues and then (that's the important part) practised solving them in mock interviews to real persons.
Maybe that could help you.
You can practice all you want to get better, but no one in the corporate world is saying "I need you to code bubble sort, and I need in the next 45 minutes" and then proceeds to stand over your shoulder the entire time.
As for wasting a lot of time, what more reliable method is there that takes less time than a leetcode-style problem? Surely there are more reliable methods, they probably don't take 30 minutes or less though.
DP is the epitome of how absurd these interviews have become and now people are getting asked 2 of these questions in pre-assestment stage.
Jokes on them when they stop getting good devs and start getting good shortterm greedy puzzle solvers.
Hyuck hyuck hyuck
DP problems represent the next rung of the ladder, are somewhat less familiar. And most importantly, satisfy an interviewer’s possibly sadistic impulses by presenting a problem that has an easy 2^n solution. ;)
Sarcasm aside, I think this is just the inevitable result of the systemisation and gaming of the whiteboard interview.
Among the problems it solves are:
* Shortest path in a graph (aka Bellman-Ford's method) [1], A* path finding [2]
* Approximate string matching [3]
* Viterbi algorithm for hidden Markov models [4]
* Earley parser [5] for context free grammar parsing
* Dynamic time warping [6]
* Finding the base of a strong generating set for permutation groups [7]
I'm consistently surprised that DP crops up in so many places. While most people won't be required to implement the above list in their day-to-day programming life, it's quietly in the background as a fundamental algorithm.
Dynamic programming is one of the few algorithms that, in a "natural" way, reduces a problem that is naively exponential to one that is polynomial. For example, try counting where 2^T random walkers lands in an array starting from the middle after T time steps. Naively, this would require 'simulation' of 2^T but with DP you can do this in O(T^2) (assuming addition of atomic integer types is "free" and there's no overflow on count) using DP (by summing a 'count' of random walkers at each time step, at each bucket in the array).
[1] https://en.wikipedia.org/wiki/Bellman%E2%80%93Ford_algorithm
[2] https://en.wikipedia.org/wiki/A*_search_algorithm
[3] https://en.wikipedia.org/wiki/Approximate_string_matching
[4] https://en.wikipedia.org/wiki/Viterbi_algorithm
[5] https://en.wikipedia.org/wiki/Earley_parser
[6] https://en.wikipedia.org/wiki/Dynamic_time_warping
[7] https://en.wikipedia.org/wiki/Schreier%E2%80%93Sims_algorith...
I think they ask about it on interviews because it’s basucally a proxy for “did you get good grades in graduate level courses”. At a top school, undergrad courses should be close enough. Of course, they could just look at your transcript, but maybe you cheated.
There are people who did only the multiple choice questions and moved on to the video conf interview. At least they can skip DP question for some people, so probably not an emphasis.
I’m an embedded developer too, and I end up reaching for DP every year or two. I think I probably use it _more_ because I’m in embedded: if I was willing to accept harder to analyze memory requirements and runtime performance, which I almost always am outside of embedded, most things I’ve solved with DP I could have more swiftly solved by composing algorithms and data structures from the standard library.
It's an IQ test.
It measures cognitive intelligence. Does it predict overall success? No.
For the dp problem, you need to have experience with dp problems, experience with general algorithm problems (from the acm-like programming challenge side specifically), and generally be good at applying those in new situations. Unless that's your actual previous work, it doesn't measure intelligence in any way.
Best know doesn't mean good. Any occupation also fails:
> for minimally-skilled activities, athletic strength (manual strength, speed, stamina, and coordination) are more likely to influence performance.
https://en.m.wikipedia.org/wiki/Intelligence_quotient
Also, that's a predictor for "any" job. You can do better if you know exactly what job you're interested in. Do a sample of work that's very close to the real one and you'll have a better prediction.
And the funny thing is, I work as an embedded developer and actually have to look up a topic or two from CLR at least once a year for work stuff (which is not very common). But DP? I've never needed it or used it. Why the emphasis in it then?
It feels a lot like software interviewing is just a bunch of rain dances and cargo culting and those that know the dance get through the hoop. I guess I'll have to order Elements of Rain Dancing from Amazon and get to practicing.