Hacker News Reader

Comment by hardware2win | Hacker News Reader

So basic data structures and their Os, trees, proficiency with strings, sorting and recursion?

It doesnt feel like something really hard

The issue isn't telling people about basic things like you learn in a CS major - it's about taking random problems and solving them on a whiteboard without any errors (syntactically or otherwise) while explaining the solution, alternative solutions, and figuring out any gotchas that they love to throw in less than 20 minutes. An easier one would be something like this - https://leetcode.com/problems/combination-sum-ii/

By the time they've stated the problem and you went through the usual gotcha questions - you've already lost 5 minutes of the <20m you have.

It's just very intense and allows for very little margin of error. You have to be exceptionally on your game and used to solving these types of questions outside of an interview in <10 minutes.

I’ve been solving leetcode questions for a few months now. Primarily for fun because coding interviews aren’t really a thing in my country (salaries comparable to the US aren’t either).

It is a really interesting exercise and as you mentioned, there is a world of difference between knowing the basics and actually being able to solve those kind of problems on an interview level. It’s not uncommon for me to check the first test cases, submit my solution and then be screwed by the one edge case I did not think about.

Doing all of this in a 20 minute interview seems insane to me. I occasionally check out commonly asked FAANG questions on Leetcode and how people actually solve these kinds of problems in such a short time while communicating with an interviewer is beyond me.

Very important callout about the time.

Solving the problems alone in your personal environment is a completely different experience compared to being judged on the spot + knowing the person interviewing you is determining whether you get a 2x compensation boost + you need to solve the problem in 15 minutes and a single mistake in your reasoning steals precious time that you may not be able to recover.

I was comfortable solving mediums in about 30 minutes before I committed to my Facebook interview. I was devastated to find that not only is 30 minutes more than the 20 minutes they give me before moving on to another question, I was so stressed that my thinking process was significantly slowed.

I've seen some very bad interviewers that will fault you for non-perfect solutions, but most will have some sort of reasonable leeway in what they will take as a solution.

This experience varies too much for the individual. I've been given almost no leeway with all of my interviews. Most of my peers are in a similar bucket but I will admit - I seem to get some of the worst experience out of my peer group. I am often given more LC hards than my peers and still rejected even if I give multiple solutions with optimal complexity. At this point, we all suspect it's due to superficial factors but can't obviously do anything about it.

Some people I know who are URT would not even have to solve the problem to get a passing grade. Some know this and actively take advantage of it (and good for them) but others are blissfully unaware and are shocked when they find out that what they experience isn't the norm.

What is URT?

UnderRepresented Talent.

Given your clear technical expertise here and on Twitter, I would argue that you might just be performing better than most people, so "most interviewers" are more reasonable with you specifically.

I appreciate the confidence in my abilities, but I meant this more as a “good interviewers are ok with you making syntax errors (I mean, you usually don’t have a compiler) and minor issues with your code”. In fact I actually prefer to ignore off by ones and other annoying bits to ensure the interviewer understands that I know what I’m doing with the general algorithm, then go back and do a pass where I ensure these are correct to preempt a “can you run this on some input for me/how would you test this/why do you think it is correct”. If you indicate what you’re doing as you do it “this might be off by one, I’ll fix this bound later” it has usually worked for me. Not to discount your point; I can’t speak for everyone’s experiences of course, but this has been mine.

Take a stroll through LeetCode and you'll see that the hard part isn't memorizing all the "good approaches", it's understanding when to apply each and also whether you need to pull out parts of the algo or apply multiple.

Many of the questions don't have obvious solutions unless you've answered similar questions multiple times (or you have good recall and recall a pattern after seeing it just once), or you're able to tease out the "real problem" from the obfuscating English.

Reply on news.ycombinator.com