Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: