←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 1 comments | | HN request time: 0.21s | source
Show context
CharlieDigital ◴[] 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 #
keiferski ◴[] No.42148377[source]
If the interview is testing for the ability to learn new difficult things quickly, then it would seem to be successful.
replies(1): >>42148456 #
CharlieDigital ◴[] No.42148456[source]
Is "cramming" the same as "learning"? Is knowing the chemical reaction between an acid and baking soda the same as being a world class patissier? Many of these exercises are like "demonstrate that you can make this dough rise" but not actually considering "can you make an artful and delicious pastry"; the two are totally different.

The most surprising thing when asked about their experience was that most of the details have already been lost before even starting the role.

replies(3): >>42148871 #>>42149037 #>>42149207 #
agentultra ◴[] No.42149207[source]
You can only get so far as a pastry chef knowing the recipes. Understanding the chemistry does take your craft to a higher level.

I’m never really surprised that there are so many security vulnerabilities out there. Tons of software is completely half-assed: slow, error-prone and inefficient. The market supports it because VCs keep pumping out companies that throw spaghetti at the wall until something sticks. And it has had an influence on the kinds of skills we optimize for at the hiring level.

The problem I see isn’t that we’re trying to hire better developers. It’s that the tests we use are misaligned. Getting into a MAANG with all these hazing rituals and then you get stuck resizing the corners on buttons or editing XML configuration for some ancient system is a waste of time.

But so is hiring programmers that only understand frameworks.

replies(1): >>42196934 #
1. StartupSage1111 ◴[] No.42196934[source]
Totally agree! the pastry chef analogy is spot on. It feels like hiring tests are often misaligned with the actual work. Instead of abstract puzzles, we should focus on role-specific challenges that reflect real-world tasks. And yeah, hiring people who only know frameworks without the fundamentals just adds to the problem. How do you think we can shift that balance?