What an arrogant comment.

> The people who actually know this blindfolded are in demand because we're useful on large projects with novel systems architecture

> Thankfully, there's lots of other jobs out there where all they're looking for is a warm seat, closed jira tickets and happy customers

As if there is no in between and only your specific type of job is in demand. Why are you so condescending towards any role that doesn't perfectly match your interests and skillset?

I guess product-focused developers, partner engineers, embedded engineers, etc are all useless because they're not working on "large projects with novel systems architecture".

In any case, this is also a false dichotomy. See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode: https://news.ycombinator.com/item?id=27312674

I didn't read his comment as condescending. He said the world needs both engineers and plumbers. The world needs more plumbers than engineers, that doesn't mean that plumbers are useless.

Your example is not a good one because 1 month of practice would not be sufficient for most people to get into FAANG. See: the guy who grinded Leetcode for a year and failed to get into Google (though he did get into Amazon). If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise.

He classified his work as engineering and everything else as plumbing. That is condescending.

> If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise

That's the point. That person should be pretty damn familiar with LeetCode questions, yet they still had to grind for a month and they're scared of it.

> He classified his work as engineering and everything else as plumbing. That is condescending.

Most real world programming work kind of is plumbing though? We take data from over here and put it over there. We build pipes. And for good, sensible reasons, most of the pipes we make use standard fittings (REST, JSON, etc).

This is the whole point of this thread - you don't need to be good at leetcode questions to do this sort of work. I agree with that and I think we're all on the same page here.

Leetcode tests something else. That other thing is also a real skillset. I hear you that calling it engineering is condescending. But I still wish we had a good name for it..?

no... i’ve worked with a fair number of leet code all stars at startups and they are rarely capable programmers in a product development sense (taken in isolation). I would say the reason the plumber vs engineer analogy is condescending is the implication that non algo work operates with well defined problems and criteria and rarely requires any engineering. my experience has been the opposite. To solve problems effectively and pragmatically it requires understanding the system constraints in addition to the people constraints. Generally speaking even identifying the key problem and constraints is a relatively rare skill, much less selecting a solution that fits the people, budget, and timelines. I’ve since realized it’s that most software developers — algo skills or not — are simply not great engineers. Having accomplished anything rigorous like leet code helps (demonstrates diligence and effort), although it is still no substitute for a history of shipping working software and personally even if i’m tasked with interviewing a candidate using an algo whiteboard, i don’t do it.

Engineers are rarely good plumbers.

Huh? Who said there's no in-between? Or that other jobs aren't in demand, or valuable? I mean, you explicitly quoted text from me saying "there's lots of other jobs out there" - aka, other skills are in demand.

To be explicit, I love that there's so many engineers out there who are keen to do product work, or work as partner engineers or whatever. Thats really important stuff!

I personally prefer to spend my time with interesting data structures. And as luck would have it, lots of engineers really struggle with data structures and algorithms. So I do that work instead whenever I can. Why is my love for this stuff such a threat to you?

And sure, real roles usually don't have us doing one thing all day. Very wise. But, so what?

> See this person's comment about being a PhD compiler and algorithms student yet still struggling with LeetCode

PhD candidates are humans too, like the rest of us. We all struggle at some things. Algorithms are hard. Getting a PhD doesn't magically change that.

And what point are you trying to make in bringing this up? Do you think that nobody is good at, or enjoys leetcode style algorithm / data structure puzzles? I'm walking proof that thats wrong.

> Thats really important stuff!

Based on your previous comment, I don't believe you.

You describe your own work as "large projects with novel systems architecture". Large (Important), novel (New and difficult) and dealing with architecture (Complicated and important).

You describe other work as "all they're looking for is a warm seat, closed jira tickets and happy customers". Warm seat (Low skill/easily replaceable), jira tickets (No creativity or thinking, just follow the ticket), happy customers (Isn't this important for everyone?).

The difference in tone is massive. It's hard to believe this wasn't intentional.

Do you believe all programming work is equally difficult? I don't.

I graduated alongside some people who work on SeL4. They wrote an operating system kernel in Haskell, then used proof systems to formally prove its correctness. Then rewrote the whole thing in C and mathematically proved their C code is equivalent to the haskell code they wrote. The result is an entirely fully formally verified operating system kernel. This has never been done before, and its a massive achievement. Its a first for humanity.

I'm not sure I'm smart enough to work there. I certainly don't know enough math. I think most programmers I've worked with throughout my career aren't good enough at programming and math to work there either.

I think formally proving the correctness of an OS kernel is more difficult than implementing a B-tree. And implementing a b-tree is more difficult than styling a button in CSS. Knowing how to style a button is a more useful skill. Its important. Its valuable. But I stand by my comment. There are more people who know how to style a button in CSS, and they're given less respect, they're more replaceable and usually less well paid.

And for good reason. My friends on the SeL4 team could probably do my job if they wanted to. I don't know if I could do theirs.

The fact that most of us in this thread aren't good enough hackers to work on sel4 is something we have to live with. It doesn't make us worse people, or less deserving of love. And it doesn't mean our work isn't valuable. It is.

But if all you know how to do is style a button, you are valued less in the jobs market. Some people are actually better at programming than other people. And some jobs in our field are genuinely harder than other jobs. Hard interview questions are asked when they only want someone who's excellent to fill the role. Its absolutely not fair, but thats life.

I think the implicit difference between you and the other guy there is:

He is implicitly trying to say (just my hunch) that a lot of those leetcode interviews don't land jobs that actually need a lot of algos and data sturcutres but are just glorified CRUD boys.

What you are saying is that some jobs are indeed very hard and need some screening during interview to weed out inadequately educated candidates.

I, as a hobbyist, actually agree with you. Hobbyists like us can learn whatever we want to learn, and usually we pick tough topics (for God's sake why would I learn to make a button?) such as compilers, algorithms, operating systems, database systems and such over web development and CRUD, because the formal topics have more FUN, and we don't care about real usage (this is different from you guys -- we don't care if our toy OS get used by anyone else :D).

Damn I'd die for such jobs if they can withstand my stupidity and teach me :D

I think there is a certain lack of imagination you show when you say that having a good, immediately reference able working knowledge of general data structures is a prerequisite of being a good programmer.

I'm not a particularly good programmer, but I think I would never be particularly good in your estimation, because I generally remember where I read something, rather than the matter in detail. This is obviously more efficient, as you always have books available when you're doing actual work, but isn't always that great for extremely broad quizzes over a broad range of subjects.

> This is obviously more efficient, as you always have books available when you're doing actual work

To be clear, I look stuff up all the time too. But the downside of the “I can look it up” approach is that if you don’t have an intuitive grasp on various algorithms, you can’t use those algorithms as building blocks to make something else. Recently I took a btree and instead of using it an associative array I used it as a list of spans. The result let me do arbitrary inserts and deletes at arbitrary locations without linear scanning (like in a linked list) or shuffling other elements around (like in an array).

Most people can’t do that. But that’s ok - you can be an excellent product engineer without this weird knack I have. It doesn’t help me write clean CSS.

In some ways it makes me actively worse at my job. I did some client work a few years ago. I helped write an indexing system for the search box on their website. I wrote a real-time indexer which streamed changes. After I left I got feedback that nobody at the company was able to maintain the code I wrote, because they couldn’t understand how it worked. I should have just written a simple bulk indexer for them in a cron job instead of getting clever with it. My “good programmer” instincts made me a worse contributor on their team.

I think your point is actually a good one. You do need deep proficiency to be able to use data structures creatively. I think your tone is just giving me an aneurysm.

My objection is that somebody who had been working with a narrow intensity in a specific field could be a very capable programmer without having the sort of general proficiency to do well in this kind of interview. That doesn't mean they are a 'product engineer'. It just means they are somewhat specialized.

The question 'what is a good programmer' comes up regularly, and I've seen answers from 'people who can make stuff that nobody understands' to 'people that make stuff nobody uses' to 'people who make stuff everyone understands and uses'.

I guess it depends on how we look at it.

no need to be arrogant: I graduated among the 1% of my class in CS and did not pass FAANG leetcode BS recently. These interviews do not test if you know your basic CS stuff but rather if you can produce code in under a minute. For most of the leetcode questions you need to know the optimal solution by heart so you can reach their ridiculous unwritten interview deadline.

But you're not passing "without grinding", you're just someone who loves the grind. Good for you I suppose but it's nonetheless very far removed from the skills one would actually find worthwhile even on the highly non-trivial, greenfield projects you're talking about (which BTW are quite rare and not what most people are working on). There's a lot more to CS and software/system design than just this l33tcode stuff.

I don't love leetcode. I've spent maybe 10 minutes on the site in my entire life, because I was curious. I learned all this stuff in CS classes 15 years ago, and I've expanded my knowledge since then by playing with this stuff for work and pleasure. Maybe thats what you're calling "loving the grind"? Its not a grind for me, in the same way playing a video game I love, or reading a great book isn't a grind. Its not a grind because algorithms are beautiful.

I know and agree that algorithms knowledge is rarely useful in practice. Most professional programming work is in feature factories. But people who know algorithms well can usually also figure out react. The reverse isn't true.

> There's a lot more to CS and software/system design than just this l33tcode stuff.

I agree, though I'm curious what else is on your list? My favorite interview question was: "Here's some code we wrote with bugs and failing test cases. You have 30 minutes. See how many of the bugs you can find and fix." It takes some work to write a question like that, but its so worth it. I wish more companies invested the time into assessments like that.

> it's nonetheless very far removed from the skills one would actually find worthwhile

I literally found these skills worthwhile in my job just last week. They're usually not useful at small startups or at most product companies. But the field of programming is bigger than the set of things you and your colleagues work on.

> I know how obnoxious this is, but there are engineers out there (hi!) who can pass leetcode style coding interviews without studying because we love this stuff

____

> I don't love leetcode.

Leetcode style coding interview questions != leetcode (the website). I'm sorry if this wasn't clear.

That makes sense now

To me learning algorithms on my leisure time is the epitome of boredom. Not because I wouldn't be able to learn them but because life is finite. I'm happy that you have found your niche but don't look down on people who prioritize getting things done without knowing much about algorithms.

Although I agree that jobs that apply theoretical CS should have it clearly stated. But, contrary to your belief, some seem to just require it for the sake of it. Not because it's needed.

> They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works.

This is obviously a generalization rounded down. Most of my whiteboard interviews were fine, like you’re saying, but some did ask ludicrous puzzles that required specific knowledge of existing algorithms like “largest sum consecutive array”.

>who graduate at the top 15% or so CS classes.

I have totally no idea what does it even mean

is top 15% good?

In $my_country, maybe 2 "schools" of CS are good, the rest is mediocre at best (I guess) so it'd be like 1% is really good

I kinda compare edu with ELO based games like chess or even league of legends

In league of legends top 1% people are somewhat decent, but still nowhere even close to $PRO

>Algorithm and data structure questions are asked because lots of programmers never touch this stuff in their day jobs.

Why not Security then? it's way more important - poorly performing algo can be rewritten, leak cannot be reverted as easily if at all

And the damage of a security issue can be much larger than less-performing code.

Yeah I 100% agree. Ideally in a good interview you want to assess a whole range of things - data structures, security, personal background, systems design, real coding, communication skills, etc. Most people are weak in some areas, and you want to give candidates lots of opportunities to impress you.

Somewhat related to your experience, does anyone else feel that the present interviewing scene is a lot more focused on algorithms rather than data structures?

Many leetcode questions rely on very specific tricks like using a fast and a slow pointer, or two pointers at opposite ends of a sequence.

So one might know about many different types of self balancing trees and which ones are best to implement a database index on disk, but these things do not come up very often in leetcode style interviews, although these are quite real problems in the realm of algorithms and data structures.

To be fair though I do not know how you can test this kind of knowledge in an interview.

> They're trying to filter out candidates who would need to grind leetcode in order to explain how a hash table works

Well if anything they select these people because grinding leetcode does work

Why do they presumably even need to select people who doesn't need to prepare to do a specific job? Is that because at those companies you're supposed to do that kind of work without preparation? I don't think that's anything more than what you think they think.