Live data from Hacker News

Show HN: Every problem and solution in Beyond Cracking the Coding Interview

news.ycombinator.com

81–90 of 114 posts

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#81

Earlier quoted context omitted.

Principal Engineer level shouldn't even be tested on leetcode. There are far more important things to know about that candidate.

Some basic level of leetcoding should be fine to verify that the candidate can at least code and is not only a bullshit artist who jumps from one position to the next, failing upwards. I had some interviews, not at the principal level, we had a couple of candidates who were very good during the informal interviews, they could hold a conversation about technology, but they couldn’t code the simplest of problems. I kno…

I don't doubt you in the least: I've also seen BS artists who got through interviews without being able to so much as write a for() loop.

But I've never seen anyone fail upwards as far as a Principal/Staff Engineer level. Last time I interviewed at that position, no one even asked anything about code. They were more concerned about my position on architectural choices, pros and cons of various approaches, knowledge of applicable standards and regulations (I'm in the medical device field), mentoring and team leadership issues and how to resolve them, etc.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#82
Long ago, some dotcom, founded by students who'd never worked, used their own idea at the time about what software development is about (i.e., Stanford first-year CS problem sets). And since that company had a lot of money (for different reasons), a lot of wannabe companies tried to mimic whatever they did.

Today, CS student's idea of an industry interview has turned into an extortion racket cottage industry, with people not only selling ritual prep books, but now also selling mock interview rituals with techbros who got into the best-paying companies.

Youse has a lovely career potential; its would be a shame if somethings was ta happen to your job interview.

What more does it take to realize this is very time-consuming and expensive theatre, and terrible metric for hiring good software engineers.

And if you're an employer who doesn't care that students spend many hundreds of hours rehearsing for the interview theatre, to the exclusion of getting more experience building things, and that your interviews aren't actually selecting for software engineer aptitude, what happens when the hire takes that same misaligned hoops-jumping mindset to their work.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#83
post #46
post #40

'Principal' developer at my last place spent 100 consecutive days grinding leetcode. Shortly after had an interview where they made him do a leetcode test live and he failed it. The whole thing is broken.

It's a whole separate skill to be able to code with an audience, let alone an audience who is judging you. I could forgive a non-technical interviewer not knowing this but surely someone who is a dev themselves understands the very real performance anxiety. It's bonkers why we do this to people— the best I've seen is the in person talks about their experience, architecture, problems they've encountered and how they s…

[deleted]

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#84

I think the reason leetcode problems are still popular is because they test whether a candidate is willing to work hard (‘grind’) on problems that don’t even matter. A lot like what actually goes on at a FAANG company.

Hard disagree. At FAANG companies, working on problems that "don't matter" is exactly how you get a "Meets Some" or worse at your next perf review. These companies are obsessed with measurable impact - you need to show clear business value, user metrics, or revenue impact. Spend 6 months grinding on irrelevant work and you'll be on a PIP in a blink of an eye

>working on problems that "don't matter"

Usually low level engineers don't have a say on what projects they get to work. They show impact by completing whatever projects were handed to them and hope/pray those projects take off and become visible to upper management and/or tied directly to revenue.

The grind aspect is real though. 99% of FAANG engineers aren't building the next google maps or LLM, they are doing Enterprise CRUD + ELT + jira tickets. Companies like Meta and Amazon have enormous workloads and thus a grinder is preferable.

After a few years of experience, CRUD and ETL can be done while sleepwalking so the only missing component is someone willing to grind, e.g. someone who will spend 100 consecutive days doing leetcode

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#85
post #44
post #22

Thank you for this. Some people are critical of coding tests but I do this there is a point: namely to weed out people who can't code. Am I the only one that interviewed people with lengthy resumes full of programming experience and when I asked them to do a simple programming exercise they fell flat on their face? I've seen experience in C, gave them take home two hour exam and they couldn't even get anything to com…

> namely to weed out people who can't code. You don't need Leetcode style tests to weed those out. Much simpler problems will do it.

I think we may have disagreement on what Leetcode means in this context -- but it has to be complicated and varied enough that simply memorizing the solution is not sufficient. It being interesting is a bonus for other parts of the technical interview.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#86
post #34

Earlier quoted context omitted.

You are not the only one. I've interviewed probably 1000's of engineers and it is striking how often one runs into candidates that can't code... or ones that operate at a level far below what you would expect.

Meh. There is a world of difference between 1337code problems and anything one encounters in the real life. Judging someone by that 1h slot on a domain they haven't worked on for decades doesn't paint the right picture. It does tell a lot about the priorities of the company though, so there's that.

I think it paints part of a picture - obviously you shouldn't hire just based on top score in an algorithmic interview. But if I interview someone for a JOB WRITING CODE with decades of experience and they refuse to write code and can't explain the difference between a linked list and an array, that's a good argument for reconsidering hiring them...

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#87
post #36

Earlier quoted context omitted.

I used to agree with the anti-Leetcode sentiment like the OP, but changed my tune fairly quickly once I started doing actual production-grade software engineering that goes beyond just simple CRUD and realized the things that Leetcode tests are applicable everywhere. It just kinda clicked one day for me and I started passing Leetcode assessments. Sure, some interviews are pretty hard and some algorithms/data structur…

I am the OP. Please understand that I am not against coding problems in interviews. Anyone who has done any interviewing will tell you that a surprising number of supposedly qualified applicants cannot code at all (usually because they have been doing project management for too long.) And if you have a specific industry need to invert a binary tree or fill 8 containers with 32 differently sized boxes or whatever then…

So I agree with both things you said here - besides filtering those that can't code at all, you learn a lot by working through the problem with the candidate. And vice-versa. "30 minutes to bash their head against a problem" is not a good interview process.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#88

Cracking the Code Interview is a great book and excellent for practice and brushing up. But I have found leet-code questions terrible for actually interviewing candidates. A lot of them boil down to whether the candidate knows the specific trick or can regurgitate the memorized solution. (Maybe I am just bitter because I have more than once bombed a leet-code interview myself) I interview a lot of people and my go-to…

I disagree. Many of the leet code problems can be solved by thinking them through and coming up with a solution without ever seeing the problem before. If the candidate gets stuck, the interviewer should act as a partner and offer occasional hints in case some sort of trick is involved.

Maybe we have different things in mind when we say "leet-code questions".

I don't know why leet-code style interviews would discourage the things you mentioned.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#89
post #20

Earlier quoted context omitted.

And therefore you aren't allowed to criticize it? If what you are making is built upon a joke of a premise that should be criticized.

You are allowed to criticize it but you can't fulminate and you can't go on some generic tangent, just like pretty much always? It's both in the Show HN thing https://news.ycombinator.com/showhn.html and the site thing https://news.ycombinator.com/newsguidelines.html

How is criticizing the premise of something a "generic tangent"? If the premise behind something is bad the whole thing is bad.

Evaluating something obviously needs to account for the context it exists in. In fact talking about this particular Show HN is impossible without implicitly or explicitly taking a position on the hiring process. If the current hiring practices were good, having resources to succeed in them would be beneficial and praise worthy. Otherwise they only help to strengthen a broken process, although obviously it might be beneficial to individuals to game that process (which further demonstrates the problems with that process).

I don't see how you even could substantively talk about this post without evaluating the hiring practices it presupposes.

Re: Show HN: Every problem and solution in Beyond Cracking the Coding Interview

#90

Earlier quoted context omitted.

Leet Code style questions are a shorthand assessment for two things: 1. Raw mental horsepower 2. The ability to just repeatedly do focused learning, aka just grinding And sure, it probably does favor #2 these days - but that is a critically important skill. You can trade one for the other, but everybody has some amount of both, and these questions figure out, roughly, your computed aggregate score of these. They have…

Why is 2, the ability to grind/memorize random problems, important for any company? I can't think of any company I've worked at, where that would be useful during my day to day work.

You don't think rote learning is a desirable skill of candidates that employers look for?

Can you think of anything we do for, say, the first two decades of our life, that could send this signal?

Post reply on HN