This story strikes me as pretty funny. As if he might say "damn, I was hoping you knew. We've been working on this one for weeks!"
Near the beginning of a class, Professor Neyman wrote two problems on the blackboard. Dantzig arrived late and assumed that they were a homework assignment.
According to Dantzig, they "seemed to be a little harder than usual", but a few days later he handed in completed solutions for both problems, still believing that they were an assignment that was overdue.
Six weeks later, an excited Neyman eagerly told him that the "homework" problems he had solved were two of the most famous unsolved problems in statistics.
Reminds me of that :)
edit: Here's a slightly more colourful telling of the story: https://www.snopes.com/fact-check/the-unsolvable-math-proble...
Does anyone happen to know which two problems Dantzig solved? Don't seem to be having much luck on my searches
"In 1951, David A. Huffman and his MIT information theory classmates were given the choice of a term paper or a final exam. The professor, Robert M. Fano, assigned a term paper on the problem of finding the most efficient binary code. Huffman, unable to prove any codes were the most efficient, was about to give up and start studying for the final when he hit upon the idea of using a frequency-sorted binary tree and quickly proved this method the most efficient.[5]
In doing so, Huffman outdid Fano, who had worked with Claude Shannon to develop a similar code. Building the tree from the bottom up guaranteed optimality, unlike the top-down approach of Shannon–Fano coding."
When we started grad school, one of the professors introduced themself and said they thought it was interesting that adaptive optics was being used in astronomy and maybe the same idea could be used to improve microscopy and 7 years later a new phd was born doing exactly that!
Over time, some facts were altered, but the basic story persisted in the form of an urban legend and as an introductory scene in the movie Good Will Hunting.
Or perhaps when you don't know it can't (yet) be solved.
Funny as it is, I would like to think that someone famous for his role in the investigation of the Challenger disaster would never flippantly say that a dangerous situation doesn't matter because "people … could easily be trained to do it safely." The fact that people can be trained to do something properly doesn't mean that trained people won't still sometimes do it improperly.
This is giving me vietnam-style university flashbacks.
I am reminded of this Feynman story:
https://longnow.org/essays/richard-feynman-connection-machin...
> The two problems that Dantzig solved were eventually published in: On the Non-Existence of Tests of "Student's" Hypothesis Having Power Functions Independent of σ (1940) and in On the Fundamental Lemma of Neyman and Pearson (1951).
The interviewer responded with "hold on", and grabbed a colleague, pointed at the whiteboard, and the colleague said "yes! that'll fix it!" and ran off.
I was offered the job that I was clearly qualified for, but I declined. I often wondered how many candidates it took them to fix their bug.
You had to solve it on a blackboard, with chalk, and the intent (I later learned) was not necessarily that you got the right answer, but how you worked through it. Did you just lock up? Did you get frustrated? Did you ask the interviewer to clarify with more data? They wanted to see your thought process.
I was able to answer it (not everyone that got hired did), and when I was done, I looked at the interviewer and asked "Do you write code this way, here?". He laughed and said 'no, no no no'. I told him, I wasn't sure I would want to work there if they did. We both laughed. He ended up being my first supervisor at that company.
Hello Dan! (If you happen to read this...)
Out of curiosity, why?
Sometimes I do give candidates examples of real challenges we're facing. The purpose is not to get anything for free, but rather to see if they're good at coming up with new ideas.
It also gets boring asking the same questions that may or may not have leaked to the Internet over and over.
AITA?
It's a real shame in tech with its (past and present) history of open source work and contributions that can be interpreted as such, especially with many projects nowadays being maintained by billion dollar coporations that can certainly pay a candidate for contributions. But that's a huge beast to tackle.
follow up note: I'm not sure if this[0] comment is parody or unironic, but situations like this are exactly what gives the idea such a bad reputation.
Umm, what?
void merge(int* d,int const* a,size_t za,int const* b,size_t zb)
{
size_t zd = za+zb,ia=0,ib=0;
for(size_t i=0; i<zd ;i++)
{
if(ia < za && ib < zb)
{
if(a[ia] < b[ib]) d[i] = a[ia++];
else d[i] = b[ib++];
}
else if(ia < za) d[i] = a[ia++];
else if(ib < zb) d[i] = b[ib++];
else abort(); // should have i==zd now
}
}
void msort(int* d,size_t z,int const* s)
{
if(z==1) *d = *s;
if(z<=1) return;
size_t h = z - (z>>1); // round up
int* x = malloc(h * sizeof *x);
if(!x) abort(); // out of memory
msort(x,h,s+(z-h));
msort(d+h,z-h,s);
merge(d,d+h,z-h,x,h);
}
// not that this is any *good*, but it does *work*
Nah. You only have to remember the central idea (if you have two sorted "runs", you can merge them into a single sorted run). You draw a quick diagram to explain the idea, you go ahead and write code that does it.
Then you apply recursion, and write down the overall algorithm (subdivide into runs until you can use some other method to sort it, then merge recursively).
Bonus points if you can explain the circumstances when this is useful (when you want to sort data that is a lot larger than your main memory, but you can write it on disk or tape). Which is kind of obsolete today, unless you are again dealing with BIG data (everything old is new again...)
When I do come to having to decide on a sorting algorithm, I can refer to the code and algos and then decide. All I need to be able to do is understand the algorithm when I see it not memorize the differences between quick and merge sort. I’m actively working with multiple Olap and regular db solutions and my teams responsible for keeping 100 billion row tables in the most queryable format and it’s never been possible for me to make such a choice, only on whether I use spark or redshift or snowflake. So what exactly would you achieve by asking this question? The irony is I was rejected by 5 companies for not being technical, accepted by 1 where I’ve been thriving for years now at one of the most technical roles in the org.
These "new ideas" are things you should be paying them for.
Any code problems we present to the interview candidate are _clearly_ made-up examples. Though one of them was simplified from a real-world project we had years and years ago.
They shook their heads and admitted that as best as they could tell there wasn't a solution but they wanted to see if they missed anything. I got the job.
Nothing's more interesting than finding out what people are really up to.
Like is the story even true? How would anyone connect the real person to this post? Is anyone even reading this?
Genuinely curious about anyones thoughts here.