4 ms·

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

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.

joatmon-snoo 8y ago
"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.
MarkSweep 8y ago
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.

joatmon-snoo 8y ago

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

MarkSweep 8y ago

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.