Hacker News Reader

Comment by swatcoder | Hacker News Reader

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.

View on HN

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.

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

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

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.

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

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

Did you study CS before you went into the workforce?

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

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

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.

Reply on news.ycombinator.com