> Everybody was super nice, they all wanted you to do well
I had the same experience. Afterwords I thought I did pretty well because I got to a solution to all the problems eventually.
Later when I discussed not getting the offer when a friend who works at Google. He said they try to guide the interviewee to a solution before the time limit. Which is reasonable, you want the interviewee to feel more confident and not get tilted by messing up just one question. However in hindsight the interview is a lot less enjoyable. You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you. The interviewer is there to smile and act like your colleague solving a problem while all the while making a list of why your a bad problem solver.
I'm not that bitter though. The interviewers that asked me questions actually related to the position I was interviewing (embedded software) did actually feel fun and collaborative. I accept that if I want to interview well at companies that employ these types of interview processes I will need to do every problem in CLRS (or at least more than zero).
I haven't been on the interviewing side, so I can't really comment on some of this.
But the impression I got as the interviewee was that every question ramped up in difficulty. The slope of the ramp-up depended on the question. So maybe in your case, you didn't get as far on the difficulty ladder as other people that were interviewed.
I was pretty shameless in asking for hints when I needed them, but it was typically of the form "I see this tradeoff here, and my gut says to do X, is that reasonable?" I'm sure some of that counted against me, but I was blunt about what I needed to make a decision and solve the problem, and I think overall that reflected well on my ability to problem solve on a team.
I would definitely not recommend doing every problem in CLRS. I would recommend doing just about every problem in Cracking the Code Interview (because they have nice answers), and then getting into a rhythm of doing LeetCode problems every day until the interview.
"I see this tradeoff here, and my gut says to do X, is that reasonable?"
YMMV with interviewer, but personally, this is the type of thing that gets positive feedback from me - someone who understands and explains the tradeoffs involved.
Also, fair warning: LC has its uses, but it is not the same as an interview.
Yes, ramping up in difficulty is certainly a thing.
In both my experience taking a Google interview and conducting a lot of interviews at my own company, I agree that a good question is open ended. For example "write memcpy" is trivial to get sometime working but can lead down many paths when discussing performance and computer architecture.
What gave me trouble, besides being rusty with algorithms, were some trade offs I would never make in the domain I'm familiar with. In my day job my microcontroller has 192KB of RAM, so limiting the amount of data collected to fit is important. I never get to the point where I have to worry about my simple algorithm not scaling to GB of data. Another odd idea was doing lots of speculative computation to reduce the latency of a system.
All of these algorithm things can be studied and after failing a couple of interviews you can start to understand what the interviewer is expecting and how to clarify assumptions.
I do question what sort of company you build if you screen for people who can write code on whiteboards. There is no giant mono-whiteboard where all the software engineers check in their code, so the interview process is not related to what people actually do for the job. On the other hand I have interviewed hundreds of people and I don’t feel like my questions do much better with the same one hour slot given to me by HR. The whole situation is inefficient for everyone.
I had the same experience. Afterwords I thought I did pretty well because I got to a solution to all the problems eventually.
Later when I discussed not getting the offer when a friend who works at Google. He said they try to guide the interviewee to a solution before the time limit. Which is reasonable, you want the interviewee to feel more confident and not get tilted by messing up just one question. However in hindsight the interview is a lot less enjoyable. You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you. The interviewer is there to smile and act like your colleague solving a problem while all the while making a list of why your a bad problem solver.
I'm not that bitter though. The interviewers that asked me questions actually related to the position I was interviewing (embedded software) did actually feel fun and collaborative. I accept that if I want to interview well at companies that employ these types of interview processes I will need to do every problem in CLRS (or at least more than zero).