Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please stop the coding challenges

blackentropy.bearblog.dev

Post reply on HN
Print view View original

431–440 of 493 posts

Re: Please stop the coding challenges

#431

Post by lkjdsklf »

CharlieDigital wrote: post #346
asdfman123 wrote: post #229

Earlier quoted context omitted.

> It doesn't matter if you've actually designed similar or more complex systems You know you've designed more complex systems. The interview has no way of knowing if that's true, or you're an actor following the "I've designed complex systems" script. And acting talent is arguably more common among the population than programming talent.

I think there are ways to tell by simply asking deep questions about the system someone claims to have built, critiquing the design decisions, diving into why this technology over that technology. When I've hired or been a part of a hiring process, I always place emphasis on a candidate's past projects and ask deep technical questions around those. I also always review their GitHub repos if one is provided in the pro…

That type of interview allows all kinds of unconscious bias to creep in which is why a lot of tech companies moved away from it

Re: Please stop the coding challenges

#432

Post by icedchai »

tayo42 wrote: post #202
CharlieDigital wrote: post #72

A small anecdote. A partner of a friend quit their job earlier this year. They then took 4-6 weeks to prepare for each interview with Big Tech companies (4-6 weeks for Meta, 4-6 weeks for Stripe, etc.). Along the way, they also took random interviews just to practice and build muscle memory. They would grind leetcode several hours a day after researching which questions were likely to be encountered at each Big Tech.…

Your absolutely right about the "system design" interview but people act like it's an amazing type of interview. People generally don't even want you to go deep on anything, but you're can't stay to shallow. It's just bsing, yes your absolutely right, it feels like memorizing a script and saying the right words at the right time

Interviewers would be better off focusing on data fundamentals: data modeling, validation, schema design, indexing, sharding/distribution strategies. When you screw this stuff up, it can be very, very hard to fix. The "problems" cascade and build up. Garbage in, garbage out. I've seen databases, in production, with no primary keys or indexes. It is absolutely bonkers.

Re: Please stop the coding challenges

#433

Post by fishtoaster »

vunderba wrote: post #308
fishtoaster wrote: post #195

I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice: 1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work. 2. Do an onsi…

Yeah, I saw that coming a mile away. Don't you remember uni? Students always breathed a sigh of relief when the final exam was a take home project. Now add this to the fact that a vast majority of your applicants are going to be feeding your assignment directly into an assistive LLM. As an interviewer, you really can't win. - If you have a take-home test, people will either complain that it's too involved, and time c…

That's why I offered the choice: different people do well under different circumstances. I figured that it'd allow me to hire a great dev who hates timed challenges or a great dev that hates take-home busywork. In practice, though, everyone like the take-homes, so ¯\_(ツ)_/¯

As for feeding it into an LLM, I go back and forth on that. With their current capabilities, the project is slightly too complex for that to work. You could get a lot of help from an AI, but you still have to put the pieces together yourself. And I'm fine with that! If AI tooling makes you a faster/better dev on a test, I'd expect it to do the same in real work.

Longer-term, though, I worry that LLMs still won't be able to "write the whole thing" for real work, but will be able to "write the whole thing" for takehome tests. And as such, I'll have to figure out how to handle that.

Re: Please stop the coding challenges

#434

Post by dudleypippin »

icedchai wrote: post #428
thatguysaguy wrote: post #261

Earlier quoted context omitted.

Yeah from the title I thought this was going to be about leetcode problems, but this is truly something that comes up regularly. Where are these dev jobs where _don't_ have to figure out some mysterious issue in a barely maintained GitHub repo semi-regularly?

A repo would be nice. I was recently given a 500 meg .zip of "backend stuff" and asked to figure out what's going on. No repository, no history, the read me is useless, the APIs look like they were built by rabid animals...

My favorite description of this sort of setup is "coded by vandals".

Re: Please stop the coding challenges

#435

Post by D-Coder »

emmanueloga_ wrote: post #103

Some problems I see with take-home assignments: * Some companies design take-home assignments that mirror challenges their team has spent years refining, setting unrealistic expectations for candidates to match or exceed that work. Talent is sometimes dismissed over minor differences, like testing styles or even coverage percent. * Working with people is about compromise. When passionate people collaborate on a creat…

> * Many companies fail to provide specific, actionable feedback after candidates spend hours on assignments.

AthenaHealth in Watertown MA, this is you, you miserable pricks. Didn't even send me a "No thanks" email.

Re: Please stop the coding challenges

#436

Post by 3np »

mekoka wrote: post #234
swatcoder wrote: post #143

Earlier quoted context omitted.

No home study grind on puzzle problems is a substitute for years of practical experience, which is what most teams actually hope for in their higher-level engineers. The point is not that the friend didn't pick up some implicit knowledge or become a sharper engineer than they were before grinding, it's that by exploiting the screening strategy, they got placed into a job they're not truly qualified for. Are they brig…

> No home study grind on puzzle problems is a substitute for years of practical experience, which is what most teams actually hope for in their higher-level engineers. Perhaps. I had 9 years of practical experience myself before going through that grind (leetcode + system design) some years ago. It is no substitute, but you don't come out of it the same engineer. You read, write and understand code differently. Also,…

> I'd say that perhaps I successfully faked it for 9 years.

Sounds like it. IME >90% of everything you encounter is typically covered in university DS&A introdoctory courses and the grind would be part of the studies. The good news is it's never too late to start again.

Re: Please stop the coding challenges

#437

Post by CharlieDigital »

icedchai wrote: post #432
tayo42 wrote: post #202

Earlier quoted context omitted.

Your absolutely right about the "system design" interview but people act like it's an amazing type of interview. People generally don't even want you to go deep on anything, but you're can't stay to shallow. It's just bsing, yes your absolutely right, it feels like memorizing a script and saying the right words at the right time

Interviewers would be better off focusing on data fundamentals: data modeling, validation, schema design, indexing, sharding/distribution strategies. When you screw this stuff up, it can be very, very hard to fix. The "problems" cascade and build up. Garbage in, garbage out. I've seen databases, in production, with no primary keys or indexes. It is absolutely bonkers.

The thing with the system design script is that it seems so Rube Goldberg. Why not just ask the important bits?

Re: Please stop the coding challenges

#438

Post by Valord »

Drew_ wrote: post #420
plantwallshoe wrote: post #360

Earlier quoted context omitted.

What do you mean “gaming the system”? The companies ask that candidates learn how to solve algorithm problems and the candidates do it. I would call it “everyone playing a game they agreed to play by the rules they agreed to play with.” And I don’t know what you mean by “it’s no longer about skill.” It still takes a lot of skill to be able to solve hard algorithm problems, even if you took a course on how to solve th…

Tech interview preparation mostly boils down to rote memorization not really what I would call “developing a skill”. You just cram enough until you can pattern match any kind of DSA or system design problem and apply the solution you memorized. Once you finally land the job, you’re free to forget everything. Then you begin to develop “real skill” on the job.

This

Re: Please stop the coding challenges

#439

Post by John_Cena »

alkonaut wrote: post #406
skydhash wrote: post #389

Earlier quoted context omitted.

Why not discuss a problem you have? You're obviously hiring for someone to solve your problem. Looking to check if they can code (in a specific language) seems like the XY problem.

Because they aren't familiar with or enthusiastic about the code I give them, they could be about code they have written. It's the classic "describe one time you did something poorly/well"-question, but with code. I want to see them critique some code, or explain what's so great, or why it ended up the way it is. Reasoning about a problem i have (even showing some code) is also a good part of an interview. But it's m…

I would like to just be asked. I can't post my code on github but I can talk about my projects at length.

Re: Please stop the coding challenges

#440

Post by nitwit005 »

agentultra wrote: post #154

> When was the last time you had to debug an ancient codebase without documentation or help from a team? All the time. 300-400k SLOC in C++. Legacy in the sense that there were no tests of any kind. Little-to-no documentation. Solo developer at the tiny company. Fix bugs and add features while keeping the system available to the tens of thousands of users. A more recent example: here’s a patch for a critical feature…

I've twice gotten a job because all, or all but one of the previous team members left. Not a lot of help to be had.

Surprisingly, both jobs were fine too.

Post reply on HN