Comment by godot | Hacker News Reader

Comment by godot | Hacker News Reader

Parent Full thread

> Right now, preparing for these interviews is really gatekept – either you need friends in big tech willing to help you practice, or you have to pay hundreds of dollars for one-on-one sessions.

So I'm probably not your target audience (I haven't had to interview for a software eng job for at least 7-8 years), but from my past experiences in these interviews from that time, system design is typically the most sensible part of the interview process and it really does just test if you have experience solving those problems, or if you're less senior, if you can think at least through the problems logically. There are even pretty good system design interview books written out there. What do you think is gatekept about this?

Leetcode took off as a trend because it wasn't easy for company interviewers to come up with good coding questions, partly because the daily work of most software engineers in most companies simply don't involve much tricky programming. System design is the opposite, most software engineers have to work on system design in their daily work and most companies can simply ask system questions very related to their companies' problems.

Looking at it from this lens, I'm not sure what a leetcode for system design adds in value, that a system design interview book doesn't already give.

> Looking at it from this lens, I'm not sure what a leetcode for system design adds in value, that a system design interview book doesn't already give.

What does leetcode for code add if you can read a book about algorithms?

Rhetorical question, obviously. Practice makes perfect, reading about practice doesn’t. Interviews are not even close to what an engineer’s job looks like, so interviews need to be approached just like any other skill you need to learn i.e. practice.

> What does leetcode for code add if you can read a book about algorithms?

Quite a bit actually.

Even if one is familiar with various algorithms, many questions rely on some sort of critical insight or intuition that is difficult to unlock within that short span of time, and most importantly, satisfy the constraints of the problem being asked*.

Unfortunately, said insight can differ based on the problem, which is why the "Leetcode grind" is a thing; it is a process to train yourself to see the plethora of problems that may be asked.

* As an anecdote, I was implementing autocompletions on top of a text editing component for a personal project some time ago. While I was able to come up with an initial solution involving a binary tree, working out the individual cases allowed me to understand that my approach couldn't have been used as is. Upon some research, I found that there exists a similar thing called a "rope", although there's no way I could have come up with this solution in the context of an interview and would have been disqualified.

Reply on news.ycombinator.com