Hacker News Reader

Comment by SquishyPanda23 | Hacker News Reader

FWIW, I went through the interview process and I actually really enjoyed it.

My attitude going in was that I was evaluating what it would be like to work there, and I treated the interviewer as a coworker solving a technical problem, where I was taking the lead.

The questions I got were pretty much exactly the sort of hing you see on LeetCode, but I hadn't seen any of the questions before. I know from studying for other technical exams that once you reach a certain number of practice problems, pattern recognition takes you a long way.

I had a similar experience at Facebook. Everybody was super nice, they all wanted you to do well, and they all responded well to being enthusiastic and genuinely interested in the problems you're solving.

View on HN

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

Getting the interviewee to a solution was not part of how I was trained to interview at Google.

> You can't show any weakness solving a problem, less they offer you a "helpful hint" and record a black mark against you.

This is really the crux of the problem. And the definition of 'hint' becomes real blurry at times.

What's crls?

Initials of the authors of Introduction to Algorithms and a way to refer to that book.

Here’s the thing: patterns you will spot doing Leetcode problems are almost useless for anything else. The only purpose for working enough problems to see those patterns is to have more successful interviews.

I personally think we'd be better off if there was more focus on these puzzles and less focus on 'cultural fit' - but that's just me.

If nothing else, interviewing is an important part of your working life. To get a competitive job, you are probably going to have to practice something. I personally can get a lot more excited about competing on puzzle solving abilities than competing on social skills or social protocols, even if those puzzles might not be used very often once I'm at work.

(I'm not saying algorithms are completely unrelated to the work we do- I'm saying that even if they were, i'd still prefer to be tested on puzzles than to be tested on social skills)

I mean, the subtext here is that we're all getting interviewed for jobs we don't know how to do. All companies have their own infrastructure and their own way of doing things; you can't hire people with experience on that companies codebase unless you want to limit yourself to ex-employees. So all companies are interviewing to try to figure out who could learn how to do the job in question, and that's... pretty difficult to do.

This is absolutely true.

But one interesting side effect of the interview process is that everybody at a place like Google or Facebook or Amazon has a non-trivial understanding of efficiency.

lol, let me introduce you to the new gmail ui

My experience at facebook was being told I could use any language, choosing the language my preferred project was implemented in... and then having the interviewer repeatedly and incorrectly argue with me about syntax trivia.

Reply on news.ycombinator.com