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.
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.
Did they say that they don't even want to listen to O(n^2) solution?
I didn't get further along in that process because of that stupidity and have never even considered them as a place to work since, and I am an SRE/PE these days.
If the naive solution is O(n!) then describing an O(n^2) solution is perfectly acceptable.
Unfortunately my DP was really bad so I knew right then I'm going to flop. And flop I did.
For me the two weakest points are DP, and coming up with the right O() estimate for an algorithm that I just created on the whiteboard, and am looking at it for the first time in my life. Would love advice on how to get good at both.
For Big O notation? Just think about how many times you're iterating through things (in the worst possible case).
e.g. Got two nested for loops each going to N.. we're going to loop N on the outer loop, so and each iteration of the inner loop we go through N times? that's N x N so O(N^2).. (easy example obviously).