←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 2 comments | 15 Nov 24 15:32 UTC | HN request time: 3.79s | source
Show context
CharlieDigital ◴[15 Nov 24 16:21 UTC] No.42148313[source]▶
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.

This paid off and they accepted an offer for L6/staff at a MAANG.

Talked to them this week (haven't even started the new role) and they've already forgotten the details of most of what was practiced. They said that the hardest part was studying for the system design portion because they did not have experience with system design...but now made staff eng. at a MAANG. IRL, this individual is a good but not exceptional engineer having worked with them on a small project.

Wild; absolutely wild and I feel like explains a lot of the boom and bust hiring cycles. When I watch some of the system design interview prep videos, it's just a script. You'll go into the call and all you need to do is largely follow the script. It doesn't matter if you've actually designed similar or more complex systems; the point of the system design interview is apparently "do you know the script"?

Watch these two back to back at 2x speed and marvel at how much of this is executed like a script:

- https://www.youtube.com/watch?v=4_qu1F9BXow

- https://www.youtube.com/watch?v=_K-eupuDVEc

replies(14): >>42148339 #>>42148377 #>>42148639 #>>42149124 #>>42149251 #>>42149406 #>>42149518 #>>42149554 #>>42149705 #>>42149979 #>>42150271 #>>42150314 #>>42151333 #>>42151610 #
mekoka ◴[15 Nov 24 16:56 UTC] No.42148639[source]▶
> IRL, this individual is a good but not exceptional engineer having worked with them on a small project.

Have you worked with them since they went through this regiment? Doing a DS&A coding problem regiment + system design will change you as an engineer. You might be surprised how good they've become.

Also they say they've forgotten. But if they were able to get that position, they probably could do medium level leetcode problems. So, I'd doubt they've forgotten all of it. I'm pretty sure they'd still be able to solve easy level problems, which most people can't solve off the cuff. They also probably still know the complexity of a bunch of essential backend operations (search, sort, array and hash lookups, tree & graph traversals, etc).

replies(2): >>42149049 #>>42149071 #
swatcoder ◴[15 Nov 24 17:39 UTC] No.42149049[source]▶
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 bright enough to fake it until they make it? Maybe, but that's not going to be the case for many of the countless placements that were made like this, and hints at why both product and software quality is in bad shape these days.

replies(3): >>42149272 #>>42149545 #>>42149609 #
1. sanderjd ◴[15 Nov 24 18:00 UTC] No.42149272[source]▶
Yeah, in some ways I like "system design" type questions, because at least it's pretty creative and more like what I do at work than writing some little algorithm with a custom data structure.

But on the other hand, it's also not a very strong signal for my years of experience working on and designing portions of systems. I've never actually done "design a system from scratch", because every system that is big and complex evolved from some smaller and less complex system.

So the kinds of questions that come up in these system design interviews are best answered in real life with "I dunno, I'd pick something simple and refactor it later if it becomes a bottleneck".

"What kind of database would you choose for this?" "Whatever we're already using in production for other things." "How would you model this data?" "As simply as possible, so that we can get it out fast and start learning things."

But these are not interesting answers in these interviews. I have usually found myself saying "well, in real life, I would advocate for simplicity and iteration, but for the purposes of this interview, I'm happy to discuss potential trade-offs in technology selection, architecture, and data modeling".

But I think it's easier to study up on the "right" answers to the architecture and modeling questions, without spending a lot of time learning how to start simple and when to evolve toward complexity, etc.

replies(1): >>42149975 #
2. ratorx ◴[15 Nov 24 19:23 UTC] No.42149975[source]▶
I think the context is important in the question. I’d argue that a system design question is optimally answered differently depending on the size of the company and the scope of the internal tech stack.

Doing more of the design up front is important in a big tech environment almost all the time because:

a) many different possible infrastructure (eg. databases) are already at your fingertips, so the operational cost to using a new one is a lot lower. Also, cross-organisation standardisation is usually more important than this marginal extra local operational cost.

b) scale makes a big difference. Usually good system design questions are explicit about the scale. It is a bit different to systems where the growth might be more organic.

c) iteration is probably way more expensive for production facing systems than in a smaller company, because everything is behind gradual rollouts (both manual and automated) and migration can be pretty involved. E.g. changing anything at all will take 1 week minimum and usually more. That’s not to say there is no iteration, but it is usually a result of an external stimulus (scale change, new feature, unmodelled dependency etc), rather than iteration towards an MVP.

Now, a lot of this is pretty implicit and it is hard to understand the environment unless you’ve worked in a different company of the same scale. But just wanted to point out that there is a reason that it is the way it is.

Source: SRE at Google