Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

> I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.

It depends on the job! At a small product company, absolutely. Shipping useful features to customers is what you're hired to do. Hardcore CS knowledge is less useful than understanding how to talk to customers and shipping. Interviews should reflect that.

But that isn't all jobs, or all software. For a lot of problems - particularly in systems software or places where performance matters, understanding data structures and algorithms is essential. For example, video game engines, operating systems, databases, LLM inference and training, etc.

I get it - most product engineers don't make use of "leetcode" skills. But absolutely relevant at a place like google. If you don't understand how to reverse a binary tree, I wouldn't hire you to work on Google Chrome or the Go compiler either.

> But a medium+ question risks me not even being able to solve like, like having to use dynamic programming. And that's just humiliating.

What an incredibly entitled thing to say. "Those horrible interviewers asked me to solve a problem that was too hard for me! How humiliating! I failed the interview and its all their fault!"

It would be interesting to get a perspective of how many developers are in these types of roles if you are closer to them than most? My experience definitely aligns with interviews with leet code questions being unrelated to the daily work. From this perspective, it seems that those dealing with these core projects like Go or Chrome have an outweighed impact on others. Eg, it only takes a few people solving those problems to help everyone. Where as from my perspective, loads of businesses need web apps, fairly simple backends, mobile apps etc for their very specific use case where they want to control the whole user experience.

The frustration of being asked a very specific question looking for a very specific solution under unusual time and pressure constraints I think is quite understandable. Not coming from a place of entitlement, but rather frustration that they know with high certainty that they could do well in the position, the question has nothing to do with daily work expected of them, yet its become this arbitrary pass/fail process due to people copying companies that are screening for positions working on Go or Chrome, when they just want a web app. I've been in several interviews, including on the employer side, where another technical interviewer asks these questions as a power trip. It's not helpful, and doesn't even get better candidates. Hence the frustration people are expressing.

> I've been in several interviews, including on the employer side, where another technical interviewer asks these questions as a power trip. It's not helpful, and doesn't even get better candidates. Hence the frustration people are expressing.

Oh I get it. Again, if those skills aren't relevant for the job, stop asking them. At best you're wasting everyone's time. And at worst, you're going to make bad hiring decisions. In one chapter of Thinking Fast And Slow he says people have a habit of taking a hard question - like "Is this person a good candidate?" Instead of answering the question, we subconsciously replace it with an easier question - "Did the person find the solution to my puzzle?". Then, when you've answered the easy question you think you've answered the hard question! But you haven't - they're different questions. Puzzle interviews are a clear example of this cognitive trap.

Generally, nobody is born knowing how to give a good technical interview. But most people are thrown in the deep end anyway, with no training or no guidance on how to do a good job of it. So, as you say, they just cargo cult bad questions that they themselves were asked or go on little power trips. Very stupid and frustrating!

Which is all to say, I hear you and I agree that this is a problem. There's a lot of bad interviewers out there doing lazy interviews.

But.

I also think there are a lot of jobs where deep computer science knowledge is relevant and important. If you don't have those skills, you will (obviously) spend your whole career kept away from those jobs. So you wouldn't even know about them! But they're absolutely out there. React. Chrome. Linux. Sqlite. ChatGPT. NodeJS. HTTP2. LLVM. All of this stuff is made by other engineers. Usually, by engineers who know how to reverse a binary tree. CS questions might be overused in product engineering interviews. But CS skills are still relevant in a lot of very important jobs. Just, maybe, jobs that a lot of people might not be qualified for.

If it's a failure to demonstrate a basic skill that are relevant to the job, then yes, that's entitled. However what was described is much closer to irrelevant trivia. I don't think it's entitled to resent such things being the deciding factor.

Googles issue is a good part of their hiring is generic and the interviewers random

No one knows what your going to be working on

Well, that ended on a weird, combative note. Are you sure that's what I was saying there?

Reply on news.ycombinator.com