Hacker News Reader

Comment by eclectic29 | Hacker News Reader

This is just "one" experience, certainly not the norm. Even as an experienced engineer of 15 yrs I'd to solve leetcode (LC) style problems on the whiteboard a few yrs go. For better or worse (depending on whose perspective you see), LC allows companies to judge you based on a common framework of solving algorithmic problems using computer science fundamentals (data structures and algorithms) in a language of your choice. Obviously, the problems vary in difficulty and many are trick problems which is what makes them frustrating, but it's the unwritten sad truth of this industry and I believe it's here to stay _if_ you're vying for very high salaries.

View on HN

I think it makes sense to use LC or something like it. Is there a better way to judge the 100 random developers who've applied to your position?

- They may not have formal education, you can't judge on that.

- They may not have active GitHub projects, you can't judge on that.

- They may not be active on social media or have any kind of fame, you can't judge on that.

- They may not have built anything they can show off like this `Find` app, you can't judge on that.

So what can you judge them on? LC makes that pretty simple: "can they answer some standardised questions about algorithms and data structures, showing that they have at least some basic knowledge of what's going on in computers?"

It's not without downsides, but I also struggle to see a better option that can scale to the armies of devs that Amazon, Google, etc, all hire.

It’s simple: don’t hire devs by the army.

it's not as simple, but sometimes is - as anything in life. You might not be networked well (for whatever the reason) and then you have to cast a wide net or go through hiring agencies to pull in candidates.. it's still going to be an unknown group.

Even if you aren't, it is still going to be roughly driven by how many hours of recruiter/ interviewer time you want to allocate per hire.

How is that an answer? Obviously they need bodies to turn the cranks. The machine must continue!

Especially for Senior Developers I think systems design questions are more interesting. They usually don't just have one right answer and you need to discuss the advantages and disadvantages of the different approaches. They require knowledgeable interviewers of course. Then again, I'm not working in a huge corp, so I don't know if this scales.

> Then again, I'm not working in a huge corp, so I don't know if this scales.

As a grizzled veteran, I LOVE System Design interviews. I love giving them and I love taking them. At large companies, System Design is definitely part of the process. In the world of FAANG, multiple coding rounds with a System Design is common for more junior developers, where a senior interview would have multiple System Design rounds with a single coding round.

> They require knowledgeable interviewers of course. In my round of FAANG interviews, the best System Design rounds were at Google. One was a more typical "design service x" scenario, and the other was "improve and upgrade service y w/out any downtime". Both were related to technology there and were things the interviewers played major parts in designing. Awesome conversations all around and I'd probably do them again just for the fun of it.

The most awkward one was at Facebook. The first design interview was good. It was a little uncomfortable because it was related to technical area I knew little about, but I enjoyed boiling it down to goals & principals and working from there and having the conversation with the senior engineer giving the interview.

The second was given by someone far more junior who was both an inexperienced interviewer and who had clearly not ever designed a system. It was obvious that they were going from a script, so there was little to no discussion or feedback about anything not covered. As a result, I "succeeded" more through guessing what was on the script vs. having an actual system design discussion.

The issue with system design is that it doesn't always have a perfect answer and a lot of things are arbitrary about it. This leaves a lot of bias with the interviewers as to how to interpret the answer and question. This is less the case with Leetcode where there is usually only one or two optimal ways to solve a problem and you can just argue over time and space complexity as a means of what "optimal" is.

System design has a ton of bias in it and it's my least favorite type of interview because of it.

I guess at this point in my career the soft side of system design questions are a good thing. I'm interviewing the team as much as they're interviewing me. The inability to have a soft discussion about something like system design that shouldn't have one right answer is them failing.

The problem is when the companies that are absolutely not hiring "armies" of devs start doing the same thing.

The problem with leet code is what it really measures is how long you have spent on leetcode. Yes, you can solve the problems if you have experience, but you are not going to look as good as someone who had done that specific problem on leetcode and could just write down the optimal answer.

Some of the highest salaries I know are in core ML at big tech or some of the foundational labs like Allen AI. While whiteboard coding interviews are often part of the process, it is generally pretty basic LC.

The crux of the evaluation often revolves around have you built something amazing before? For most new grad folks it is the work done as part of their PhD thesis, but for non PhDs it often boils to amazing past work. And it’s a similar process for more experience folks except the reliance on LC fades even more.

If this works well for cutting edge ML why shouldn't it work for everything else?

Allen AI pays well?! Do they ever hire vanilla engineers or just researchers, applied scientists?

Reply on news.ycombinator.com