Please stop the coding challenges

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

> 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).

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.

> 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 have to admit that with the new perspective, there's a reason why I'd probably hire the newbie who's done this over the experienced engineer who hasn't (and maybe continues to dismiss it). The two gaps are not equivalent. In my experience the newbie will probably cover many of the necessary bases on the job fairly quickly with mentorship. I can also appreciate that 9 years of practical experience didn't help me cover DS&A or system design. I doubt that any kind of mentorship would've helped me either. Learning this stuff is a grind, plain and simple.

A newbie will also make mistakes that I can understand. I can see them pick a heap, or a linked list because it's the algorithmic sound choice for the problem. Then I can point out that for the specific use case, an array might not be as efficient, but it's a good trade-off to simplify the code. They will understand this. But an engineer that indiscriminately reaches for arrays and hash for any situation is a different story. Exponential inner loops for big searches, huge recursive calls. Those things show up in code written by experienced coders IRL. You click on a button and wait 5 seconds for the response.

I'm not sure who's faking it until they make it, but based on my own experience, I'd say that perhaps I successfully faked it for 9 years.