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

Sounds like the system worked exactly as intended then. A seemingly smart person got a good job. What's the problem with this story exactly?

If the interview is testing for the ability to learn new difficult things quickly, then it would seem to be successful.

A moderately smart person was selected for a good job perhaps over many many better possible hires simply because that person had the leisure to learn the game. Inefficient. But nice for that individual, naturally.

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.

Apparently they expect people to work for free for more than a month to learn material they then won't use.

In my mind that's a rather nasty practice.

Not that I'm complaining. I'm happy to pick up people that are good at computers but wouldn't be able to pass that hurdle, and probably wouldn't hire anyone that has.

It’s like the bar exam for lawyers. It bears absolutely no relationship whatsoever to the actual job and the work you will be doing. It’s a pointless ritual. And the point of the above story is that the person performed the ritual and then promptly forgot all the words once they succeeded. It illustrates the pointlessness.

It's not a pointless ritual. It tests for determination, grit, and willingness to grind on difficult, frustrating and ultimately value-free tasks.

All crucial skills in the modern technology or legal workplace.

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

I was a lawyer. I passed the bar exam (first try, no less). I practiced. The bar exam does none of what you claimed for it. Now, I offered it here as an analogy, but I am not a software developer. It just sounded akin to what I do know from my own experience and from talking to literally hundreds of other lawyers, law school professors, judges and their clerks. So maybe it’s not a good analogy to software development. I don’t know.

Depends on the situation and job of course, but cramming isn't necessarily always a negative thing. Sometimes you may only need to learn a technology/skill/etc. to accomplish something quickly, but then not need it again.

But yeah in general I agree with you – I just don't think it's necessarily always so clearly a waste of time.

But is there a good way to find the "better possible hires" which doesn't have other significant disadvantages? If you have a convincing method of doing that, many companies would be interested in your ideas.

And by that argument, difficult big tech system design interviews are interchangeable with bar examinations.

> It's not a pointless ritual. It tests for determination, grit, and willingness to grind on difficult, frustrating and ultimately value-free tasks.

This is what people say whenever one criticizes the methodology of any test. They say that the real test was actually the friends we made along the way. The real test was the degree to which you are willing to humiliate yourself, or to accomplish things you don't understand the purpose of, or to accomplish things that you do understand the purpose of but disagree with logically or morally.

We filter for the worst, most damaged, and most desperate people.

I feel like you forgot the "/sarcasm" at the end.

At some inflection point, though, cramming becomes learning. This is in a different place for each individual, but it's true regardless.

Nobody hires anybody other than artists based on whether they can "create an artful and _____ ____". People are hired based on either what the have done, can claim to be able to do, or whom they know.

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.

Yes, ask give interview tasks which are realistic depictions of the actual job tasks.

No, the hiring managers that are into cargoogle culting are not actually that interested in how to do interviewing properly. Not unless, say, google does it and they can copy it.

For them the important thing is that leetcode is a safe, defensible choice because "everyone else does it that way".

Starfighter doesn’t seem to have gotten anywhere

https://news.ycombinator.com/item?id=37985450

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

Having done this prep, I can't tell if this comment is sarcasm. Building real systems makes you a good engineer. Maintaining systems over a long period of time makes you a good engineer. Working with other experienced engineers makes you a good engineer.

Doing this prep you do learn a few things along the way, but it's contrived. You already know what you need to learn, which is often the hard part on the job. It's works as a filter since the ability to learn concepts is important, but it's usefulness continues to trend downwards as it becomes more standardized.

At least you only have to pass the bar once.

I took a similar approach -- took 6 weeks off doing interview prep, then concurrently applied to three FAANG employers. Got offers from all three, the worst of which was a 36% raise over my former non-FAANG job.

"Seemingly smart person getting a good job" is a criteria for filling headcount during a boom, but regresses the industry's maturity by placing inexperienced people into critical roles.

The problem with this story is that people need to work with and rely on this person for responsibilities they're not yet qualified to meet. In some cases, a "smart person" will be able to grow into the role, but the road there is long and messy, which becomes a frustration for colleagues, supervisors, clients, users etc.

Because of the prolonged boom we just went through, the industry -- especially at FAANG's -- is now saturated with smart, naive people trying to fake it until they make it, leading to a gross decline in quality and consistency compared to where we have been and might otherwise be.

Recall this anecdote the next time someone mentions "meritocracy" in the context of tech. At best, only a limited population gets to participate.

> Yes, ask give interview tasks which are realistic depictions of the actual job tasks.

I think this is exactly what a lot of companies try to do when interviewing. Depending on how much time they want candidates and interviewers to spend on the task, this ranges from leetcode-style problems to bigger coding challenges (possibly with some debugging or collaboration involved).

What would you suggest concretely?

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.

Back when I had a job hiring people we created problems we could walk people through and see what they figured out on the fly/what they knew but didn't know they knew. That was what I was taught whiteboard problems were, not this lame leet code. But I grew up with both parents in 1980s/90s Santa Cruz tech. The current scene adopted the practice but made it exclusive when it was intended to be inclusive (because there wasn't a huge talent pool back then so they were looking for people they could grow into developers).

One of my hires was a physicist who didn't know any of the jargon and had a look of terror when she first started on our whiteboard problems. Once we led her to a comfortable spot and she got into it she started talking about tools she made to help with her physics work with zero dev knowledge (she was shocked when we called her tools software, she was like, but it wasn't REAL software, we were like hate to break it to you, but that was not only real software you wrote, but crazy impressive). The white board problems were a tool to highlight potential.

I get that these big companies just want drop in widgets not people and that is what they are searching for, I just think it's funny they are using something that was created for the exact opposite purpose.

Part of me is kind of glad I'm too old to be one of the cool kids and have no hope to land a job that does these sorts of code challenges.

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.

interview followed by paid internship/probation. watch them work on your real system. Keep them if they're good.

> We filter for the worst, most damaged, and most desperate people.

These are probably the best candidates, from the perspective of a manager who is concerned with stability and not rocking the boat, at the cost of results and workplace quality.

It's very mild compared to postgraduate education. Or getting a degree in general. That's years!

That's what companies already do.

Are you suggesting that any coding interviews and challenges are simply removed from the existing processes? That just means you end up with more candidates to choose from, which doesn't sound helpful at all if your goal is to end up with better hires as the comment above was suggesting.

It took forever. Literally tens of thousands of dollars of opportunity cost, with a lot of risk of having nothing to show for it.

The bummer is that you're right, it actually is worth even this much investment, because these companies do pay extremely well. But it's still horrendously inefficient, because the companies are getting a very small improvement to their signal to noise ratio, at this great cost (which, notably, they don't bear).

I don't suppose you got a good job because you had the leisure to spend 4 years in college? Or 4 years in high school?

Yeah that's how education works.

Someone working at billion dollar VC funded outfit should understand the cause of making smart but speculative bets.

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

The problem is not everyone has the chance to work on super-scale systems. So what are you going to do? Weed out anyone with the potential to become great at that just because they've never had the chance to try?

Demonstrating the ability to learn, even if it's just scripted, should be good enough. Granted, they might get passed over by someone with actual experience, but the lack of real experience shouldn't be a deal breaker. It's fine as long as the employer has realistic expectations of the employee.

although its a different paradigm that I’m used to, I agree with this general concept

if you provide utility to the market, you shouldn’t need credentials or a corporate ladder to climb to prove it, it should be immediate compensation no matter how disparate

so despite how coveted tech compensation packages are at this tier of company, a seemingly smart person getting a good job after doing a contrived aptitude test does meet that criteria. other people outside the field (and within) have difficulty passing it and don't have the cognitive ability to study for it, or the financial stability to prioritize studying for it

I also agree that a less contrived aptitude test would be better

How is one supposed to get a job that requires years of practical experience if all jobs require years of practical experience?

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

Yes, and they should also be able to understand when the system that creates those smart but speculative bets is creating deadweight loss, and identify that as a problem.

BTW, I have personally made this bet in the past (though I didn't put 3 to 4 months into it...) and it was indeed an excellent bet to make. But benefitting from a system does not preclude identifying problems with it.

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

One of the main questions I ask in interviews is basically "we have a data pipeline with goal X and constraints A, B, and C. How would you design it?" Depending on how they do, we'll discuss various tradeoffs, other possible goals/constraints, and so on.

This is based on a real system I designed and have been maintaining for ~5 years, and is also very similar to other systems I've run at previous jobs.

About half the candidates complain that it's not a realistic question.

You may remember these details from the GP comment and my own:

> L6/staff

> higher-level engineers

Traditionally, one would work up to senior roles over the course of one's career, often by pursuing internal opportunities to learn and exercise new skills within one's current role before applying for new roles that rely on those now-practiced skills.

Placing into senior roles because you did well at Stanford, spent a couple years writing CRUD apps, and then grinded puzzles for a couple months is inevitably something that happens when the industry needs to fill more senior roles than there are engineers with suitable experience, but it's not a healthy phenomenon and definitely shouldn't be treated as the norm.

In the US this doesn't work well outside of college internships. Most tech workers don't want to shift to a new employer with a probation period. We already live under an "at will" employment relationship so employers can let you go anytime and workers can leave anytime. To have real value to a probation period for workers, we have to guarantee its harder to fire you past the probation period.

Sure. Why is it a worthwhile comparison?

I don't like the "state of the art" of tech hiring but I think this thing you say can be said to any of us in our jobs and that's not fair.

We all part from the same place (understand me: from the standpoint of the hirer, I know we have different vital stories). They open the position to all of us and want to be impressed. The one that makes it, gets the job.

It is the best way? Absolutely not. Is it unfair? No.

If you talk to hiring at some of these companies, it is intentionally designed to be this way so that it is fairly meritocratic.

In other words, anybody, regardless of what university they went to or what courses they took out what advantages or disadvantages they had, can learn this stuff in a couple of months if they have what it takes for the role. And because the skills are so standardized, the process is pretty differently objective.

It's not expected that they'll actually use the specific skills in the job. But it shows they can learn skills of that type and then perform them at a high level in a stressful interview situation. Which is a great signal for whether they can learn the skills needed for the specific project they wind up on and perform in a high stakes deadline scenario.

I'm not defending the system, but I am saying there's a clear logic behind it.

In this example, we're talking about an L6/staff role.

If the role is correctly staffed, nobody should have to be looking over that person's shoulder questioning data structure choices and algorithm efficiency regardless of what the person's background is.

It's absolutely the case that there are people with 9 years of experience who are not prepared to meet the needs of that role. There are people with 19 and 29 and 49 years of experience that fit into that bucket. Practice alone doesn't get you there.

But as you note, as a rule, you expect your bright, leetcode-grinding "newbie" to need mentoring and oversight to compensate for their propensity to rely on shallow theory where they don't know better from experience. That's not someone a team wants in a L6/staff role either!

For high level roles, you need bright, curious people who are experienced but not rigid. Admittedly, there's only so many of them, but when you start having to fill those roles with people that don't meet each of those criteria, you can't be surprised when the team's morale and output suffer. Which is exactly what we see as an outcome of the recent boom (and each prior one), because you end up having the blind lead the blind through the minefield of engineering.. and that's going to be messy no matter how clever or book-studied those folk happen to be.

That’s a false dichotomy. I’ve never felt the need to do the DS&A grind for one of these roles and I would never dream of writing the ungodly inefficient code you just imputed to my peer group.

I'm from the Bay but I've never heard "Santa Cruz Tech" before. Its always been a sleepy beach/uni town to me. Have any interesting anecdotes?

> Exponential inner loops for big searches, huge recursive calls. Those things show up in code written by experienced coders IRL.

The thing is, those things are easily fixable after the fact. A bad architecture is not, and without practical experience designing systems in the real world, you don't have those instincts to guide you towards the correct choices because you haven't made any mistakes to learn from.

Well it shows that you are ready to invest a lot of your own free time into being recruited there - i.e. you'll be a loyal and hard worker. And that you're smart enough to learn it all. So I would say it has a character + IQ component to it.

Of course 95%+ of it will usually be useless in your real-life work, to solve most of those problems in the time given you need to know the problem and the optimal solution to it so basically memorization with little thinking.

If you're getting a PhD solely for a job in marginally related part of industry, that's on you. The experience is useful if you're doing it for right reasons, instead of as a proxy ritual to boost your CV. There are more efficient ways to do the latter.

This will strongly favor people who believe that that they cannot get a good job, because if a candidate has multiple offers, why would they choose probation vs regular job?

(Note I am saying people who "believe" they cannot get a good job. This would be people who worry a lot, people with unusual experiences that other companies avoid, and under-performers who got fired. I am sure there will be some great hires in those groups, but likely less than during regular hiring)

Assuming it's reference to Santa Cruz Operations.

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

Did you also post this in another comment recently (yesterday?)

leetcode doesn't help either. it's just cargo culting at this point.

Even with probation the cost difference between saying no at interview and firing them during their probation is enormous.

The thing I think is funny in all this is that hiring a new manager is fraught with a high amount of risk (more so than an engineer), but they don't have nearly the level of hurdles to get over. Does the company interview past employees of the manager? Did the manager applicant have alcohol, drug issues, or weird sexual things he did to his direct reports or others? Or, instead, would you enjoy his presence on a golf outing?

I know one manager who had issues with all three got hired at Google. So. Think of the poor HR person that will have to clean up that mess.

I think you missed the part where you describe their current experience.

If he was even considered for L6 staff, then his on resume credentials already justified him at L5 Senior or L6 Staff.

The interview performance is what pushed him over the edge into L6.

It seems like you think they don't deserve a staff level position?

Not to share here. I was at boring places my parents had the interesting experiences but those aren't my stories to share.

It had lots of small industry specific solutions, lots of hardware/software tied together solutions (so a large 'tech' community where 'tech' was the title for hardware technicians that hand built/designed/produced the hardware devices/circuit boards/etc). I'm surprised you never heard of the Santa Cruz software scene. Some examples:

Victor Technologies (specifically Victor 9000 Computer)

Texas Instruments had a fab/facility there.

Digital Research had a presence (CP/M, PDP)

Seagate

SCO

Borland

EMU Systems (hardware music samplers) (lots of cool musicians used to visit their facilities)

(current) Antares (Auto tune/music tools)

(current) Plugin Alliance (music tools)

(current?) Plantronics

But mainly it was smaller obscure companies. For example Parallel Computers working on parallel computing early on. IDX working on radio tags in the 80s. Triton doing sonar imaging with SGI boxes.

It was very much it's own sub-scene with people who picked it for lifestyle so a bit different mindset (more hippie, schedules around the tides so people could surf, everyone going to the Wednesday night sailing races together). I was just a kid but it seemed cool. And it was open and friendly (I always had summer jobs as a kid starting from duplicating floppies for CP/M or PDP software as a 10 year old). Plus just a cool vibe. I remember next door to where my mom worked going and talking to Lorenzo Ponza (inventor of the pitching machine) when I got bored of playing Trek or Rogue on the VAX at her office (she was a workaholic always working weekends and dragging me along) or skating the ramp (for the stoner tech(nician) crowd) in the parking lot.

Since when is studying, practicing and preparing, gaming the system?

Is reading a book on software engineering to become a better programmer also not allowed?

I feel like people want these jobs to be distributed "fairly" based on "natural" ability/talent.

But it has never and will never work that way.

    > If he was even considered for L6 staff, then his on resume credentials already justified him at L5 Senior or L6 Staff.

I don't want to put anyone down here, but working experience with this individual says "probably not".

Yep. I get why some companies would want to use it to select for that. It's just funny because it's so much the opposite of the original purpose of white board problems/old school tech scene culture.

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 profile and I will ask them deep questions about their repos, why they chose this tech or that, interesting pieces of code, design tradeoffs they made, etc.

> Since when is studying, practicing and preparing, gaming the system?

Fair question.. the problem today is the emphasis on studying and practicing irrelevant things like memorizing algorithms. That's become the paved short-cut to well paying jobs so naturally people do it. To the point that even the people doing the hiring have forgotten what it meant to be actually qualified, not just a leetcode memorizer.

If you need to hire a musician for your band, do you pick the person who has spent six months practicing a handful of chords to perfection, but possibly doesn't know anything about composing songs or jamming with the band? Or do you pick someone who has been composing and playing live shows for 10+ years?

The first one is just academic memorization that has some value, but very little. The second one is real-life experience that's worth a lot.

I have zero musical skills but even I have managed to learn to play a couple songs on the piano by sheer memorization of which buttons to press in what sequence. If you ask me to play one of those songs it might seem like I know what I'm doing even though I'm completely incompetent in music. That's the equivalent of hiring for software roles based on leetcode memorization.

> It’s like the bar exam for lawyers.

At least lawyers don't have to take the bar every other year for the rest of their careers.

Systems Design is IMO the most useless part of those interviews.

Interviewers are just trying to find someone who would design a system the same way they did. They used a queue? They want you to add one. They used serverless? Better say the word "Lambda" somewhere. They hate serverless? Ooops better stick to regular servers.

In the end yeah, it's about following a script, but also reading the room.

As you climb the engineering IC ladder your responsibilities involve larger and larger tasks and timescales. It's not possible to measure whether someone can make the right decisions about the architecture of a service as requirements change over years in a 1-day interview. Anything that isn't "be the engineer maintaining this service for 1 year" is going to be a proxy for that, which can be learned and gamed.

What would be a "proper" interview in your opinion?

> Not that I'm complaining. I'm happy to pick up people that are good at computers but wouldn't be able to pass that hurdle, and probably wouldn't hire anyone that has.

You're looking for people who feel like they can't be bothered to learn some of the science and fundamentals of their craft? And you'd actively oppose hiring people who have the determination to go the extra mile? You'd actually discriminate against people who know how to use basic data structures and algorithms, and have that enriched landscape of knowledge to apply to problems that might come up?

Fortunately for you, there are lots of these people available to hire who felt like they are too good to put in the work.

I'm not saying that the data structures and algorithms knowledge is needed to do most software engineering jobs on a daily basis. But for lots of jobs, hiring people with a demonstrated willingness to dive in deep and learn things that aren't necessarily easy or fun actually can be a very good thing, because a lot of engineering problems require a similarly difficult dive into some aspect of specialized domain knowledge.

> They said that the hardest part was studying for the system design portion because they did not have experience with system design

Your friend is not alone, and I don't understand what separates us. Even when I was early career, system design was my favorite.

My biggest issue is performance anxiety when there's a concrete problem to solve that I've never seen before, so coding sessions are absolute hell. Inability to focus, forgetting approaches I've known forever, etc.

Ask me to do system design though, and it's generally freeform, I can talk about different approaches, deep dive on the fly, and draw a nice diagram or many nice diagrams, and interviewers love me and think I'm smart. I've had interviewers who were suspicious after my bad coding performance try to nail me on esoteric implementation details but because I have actual, hard-earned experience I can pretty much explain any approach in my niche and then tell you all the tradeoffs. I can also quickly code up examples, etc. Never had a bad feedback on this portion.

Something about the complete detachment of the coding problem from real life is such a huge mental block and I am continuing to fight it 15 years into my career, after dozens of similar interviews.

They passed over all the people who didn't study hard enough on random word problems, and then practice those types of problems sufficiently such they could hammer out a solution in under 20 minutes. Multiple aspects of the "leetcode interview" require practice outside of work experience for many people, despite them being great problem solvers.

   > ...it's usefulness continues to trend downwards as it becomes more standardized

I think this is a key point that a lot of commenters in this thread gloss over. That as the questions become more "standardized" and "predictable" (leetcode being a prime example), the results of using these questions tests for something, but that something is not what necessarily makes a "good engineer".

The system design questions are probably even worse because the expected responses are so templatized -- even more than leetcode.

I actually think we should keep the system design interviews because they are closer to what I've actually experienced and researched in service of my work.

The leetcodes feel completely unrelated.

I don't think its common for people to try to "memorize leetcode."

Most interview loops at places that do algorithm interviews are 2-3 rounds and each round will have up to 2 questions. Its very very unlikely the interviewee will only encountered questions they have memorized.

More likely, the interviewee encounters questions similar to ones they have solved and they know the pattern around solving, then are able to apply their learned skill to the new problem.

Similar to your music analogy: you can absolutely be a strong guitar player in a band if you just memorize a few different chord shapes and can apply them up and down the fretboard to different keys (lookup the "CAGED system").

Did you study CS before you went into the workforce?

And thanks to modern CPU design, they are often actually faster than more complicated data structures.

I know in interviews they are looking for the solution that is the most efficient by big O standards so that’s what I use

But big O is often just not a reflection of actual performance on modern computers

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

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.

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

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

Unless you move.

You're speaking from a position of great privilege where putting in a month or two of free labour doesn't impact your life much, maybe because you have money, or because you don't have kids.

Whether someone demonstrates a willingness to dive in deep and learn things I catch with an entirely different technique, like putting them into contact with a new programming language.

Filtering out people with experience from "FAANG" will likely get rid of some people that think they are "too good to put in the work", because they have that line on their resumes. And those I've met were absolutely insufferable and incompetent.

The idea of it being positioned as meritocratic is hilarious to me. As if having a process outside of the leetcode question bank will lead to any more bias. I'm generally of the belief that an interview process should be standardized in an attempt to reduce bias, but I disagree that it needs to be something people can study for to the extent that leetcode questions can be studied.

I've interviewed people with leetcode questions where my co-interviewers made the candidate's confidence in presenting the correct answer the tipping point for hiring (with women mostly being targeted in this category). Bias can happen in any process, and with "culture" frequently being a consideration it's hard to tell what should be justified. Meritocracy in the tech industry is mostly a joke outside the overachieving outliers.

Actually I put in that work myself, while working, and while raising kids. It took me a lot longer than a month or two. It took a ridiculous, embarrassing amount of time.

> And those I've met were absolutely insufferable and incompetent.

I understand this last part, and annoying and insufferable people absolutely do exist. But consider that you may be generalizing and discriminating against a pretty big pool of people using a small sample size, and give some of those people a chance-- as long as they're not being insufferable and are treating you the way you want to be treated. Those people exist in FAANGs too.

No way. If someone has worked in one of those companies and tells me about it, then they're tainted by it, similar to how they would be from having worked at Raytheon or whatever.

If they have the sense to try and hide their "FAANG" background I might consider them.

A lot of companies do do it this way but the ones that set leetcode problems are deliberately avoiding setting realistic interview tasks.

If you think leetcode is representative of real life programming you're probably a college student.

Thanks for the response! No, the only one that rings a bell is Plantronics (recently changed hands/title) since you pass it on the way to the Santa Cruz Costco.

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?