Please stop the coding challenges

I kind of agree with you that in practice very few jobs actually require any implementation of textbook algorithms.

The weird thing is that while people keep complaining about the focus on algorithms in the interview context, it seems like nobody objects when it comes to the recommended CS education.

I think there is a deep dissonance when people strongly recommend learning data structures and algorithms as part of CS and software engineering curriculum, but then when employers actually ask about these in interviews there is strong pushback.

I personally tend to think the right balance is in the middle. At least, whatever is taught in a typical software engineering curriculum should be fair game for interview questions.

The “number of islands” problem could be something that comes up in a DSA assignment in college.

I don’t know whether not knowing how to code it up in an interview setting makes you a bad engineer, but those who still remember their college classes got ahead of you apparently.

I often argue and get downvoted in the discussions when I claim algorithms and advanced math isn’t really needed as a prerequisite in the software industry. It’s only when people get gatekept for forgetting things taught in their college classes that they complain. Imagine that.

You’re not alone with this story, other people have shared similar stories. There are even a few very famous cases, like when the Homebrew maintainer complained about being rejected by Google https://news.ycombinator.com/item?id=15713801.

That said, you are making some assumptions. They might be right, but don’t forget to consider the possibility that they’re not, and then think about how to validate your assumptions, and about what it means and how to respond or adjust if your assumptions aren’t right. Also don’t forget to think impersonally about whether the job is the right fit for you. The job with the islands question might be a job for which it will be important to know and write similar algorithms, and based on the experience you describe, it might not be the right job for you. You sound like a full-stack dev, or even maybe a devops or generalist kind of person, and any given job might be looking for a more specific algorithm developer. When the job isn’t right for you, it is not a reflection of your existing talents or abilities, it could mean nothing more than they’re looking for someone with different experience or interest than you have. Being rejected might be best for you, before you know it.

> DSA is rarely relevant to the job requirements

I don’t know what this means. Generally speaking, a basic working knowledge of data structures and algorithms apples to damn near everything in computer programming jobs. I’d agree that most jobs don’t require knowing the subtle differences between parallel mergesort and parallel shell sort, for example. But most jobs that involve programming do require knowing some data structures and some algorithms.

Furthermore, companies are usually looking for well-rounded candidates. If I can hire someone who does full-stack Android and knows a lot of data structures and algorithms, that is better for me than hiring someone who’s great a full-stack stuff but gets stumped if they have to fix a connected components algorithm. Companies want devs who are good at as many things as possible, even when they say they’re looking for something specific.

Keep in mind that you’re competing with others, not being evaluated by yourself on your own merits. Also keep in mind that a single job rejection is nothing in the big picture, many things can go wrong in an interview, so look at the big picture and not individual interview questions.

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.

"Move fast, break people."

That sounds like a really challenging situation, and I can see how it would be disheartening to work in an environment like that. It makes me wonder if part of the problem lies in how companies approach technical growth and team dynamics. For example, instead of just identifying unproductive team members, do you think those people could have benefitted from structured mentorship or training programs? Or maybe clearer performance metrics that highlight where they’re struggling?

It’s also interesting to think about how managers could be supported better. If your old boss had been more engaged, perhaps they could’ve restructured the team or helped those who were falling behind find roles that suited their strengths better. Have you ever seen a company handle this type of situation well, or is this kind of dysfunction just too common?