Hacker News Reader

Comment by bradlys | Hacker News Reader

> All things considered, spending 50-100 hours of your free time solving problems on a free website at your leisure is really a small price to pay.

The problem is - it's not 50-100 hours for most candidates to pass. I've done well past 400 hours of interview prep and never received an offer from Big N. I tried the consistent 1-hour or so a day for months thing - it isn't guaranteed either. Want to emphasize this point to - it isn't like I can't do the problems. I've solved most any problem I'm given - it's that it just doesn't fucking matter. Whatever bias the person has is what they will evaluate on - the problem solving is merely a formality.

View on HN

Statistically it’s bound to happen that some interviews don’t work out. Sometimes the problem just doesn’t click, or you have a bad day, or you get unlucky and 1 interviewer is being extra strict and unfair. I have both passed and failed interviews at most of the FAANG companies.

Some of my coworkers will usually apply at all the big companies at once and say pass 2-3 out of 5 interviews.

However if you consistently can’t get through an interview loop without an offer despite having studied the basics and repeated attempts there may be something wrong that you are not catching in your interview prep.

Shoot me an email if you’d like some feedback, would be happy to do a dry run and see if I can spot anything obvious. I’m at @cosmin on Github, you can find my email address there.

I don't think it's just about solving the problem.

It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code)

  - how you test your code after you finish coding

  - what clarifying questions you asked to tease out a concrete question

  - what edge cases you thought of and how you handled them

  - how you handle bugs if they appear in the code

  - what solutions you presented and what their tradeoffs were, and why you decided to use a particular solution

  - whether your code was idiomatic

  - whether you used clean abstractions

  - maybe also comments and variable naming

... and probably others I'm missing.

I don't deny that interviewers have their biases, but I would hope that your interview performance is the major factor in whether you received an offer. There are plenty of people at Google and Facebook who haven't majored in CS at a top school.

From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from actually writing best-practice code.

As a counter point, I was in an interview loop recently with a candidate that ended up solving the question eventually, but didn't hit a lot of the bullet points in the parent comment (asking clarifying questions, edge cases, abstraction).

After discussing feedback from other interviewers, it was apparent that the same considerations were lacking in multiple interviews, and so the candidate got a no hire decision. For any single interview it probably would have been okay to omit these things, but when there's a negative pattern across multiple interviews, that's when it really hurts your chances.

How do you expect to convince the interviewer that your solution was correct without tests? How can you debug your code properly if you end up with a spaghetti mess instead of using a clean design?

Testing and debugging vary from site to site. Most of the ones I've used run your code against a hidden suite of tests to check all possible edge cases. This would otherwise take up a very non-trivial amount of time in the session. Actual debugging is also not possible on all of the sites -- usually the most you can do is litter your code with logs, which is far from a clean design.

No one is guaranteed a job at Big-N companies.

It's important to understand that Big-N job offers or rejections aren't a perfect indicator of a person's programming ability.

The interview process isn't perfect. It's not designed to be perfect, because that's an impossible goal. In reality, Big-N companies have so many applicants that some of them have higher rejection rates than Ivy League universities.

At this scale, the goal isn't to admit any and every qualified candidate. The goal is to select for the best of the best and minimize false positives, even if it results in a large number of false negatives.

Why are you complaining about the problem solving / leetcode culture if that's not what has kept you out of the Big N?

Reply on news.ycombinator.com