[isubasinghe]

I don't want to work with someone who doesn't know basic DS&A too.

But why care about this stuff for basic JSON shifting positions? Accenture asked me to solve a leetcode hard, I closed the web page.

On top of that, these interviews don't really represent what your actual problem solving skills are. I know plenty of smart people who chose not to interview for big n simply because of the interview process.

[codalan]

Exactly.

Just because someone doesn't want to waste their time studying up for irrelevant leetcode problems doesn't mean they don't know DS&A, either.

It more important to know when and why to use a certain DS to solve a real world problem (along w/ associated algos), since most people are doing application level development work, which means most people are using abstractions of DS&As, rather than implementing them from scratch.

If I needed to implement a DS&A from scratch, it wouldn't be from memory. I would consult the CLRS book and make customizations from there.

I believe the reason leetcode interviews have lasted so long is because FAANG engineers won't abandon them. By gatekeeping the interview process and making the barrier to entry so high, they can artificially inflate their salaries and bonuses by claiming scarcity of talent.

I think if a lot of these companies did a reassessment of their staffing, they would realize they've been overpaying many of these engineers for jobs that talented non-leetcoders could do for half the salary/bonus.

If you really want to know where a dev stands in terms of ability, assign them an open-ended project with a mostly open-ended timeline. Only consider candidates who complete the project and have a working solution, then consider things like

1. Did they unit test their code? 2. Did they use source control and share back a link to their repo? 3. Did they create a flexible, scalable solution?

etc.

And for a bonus: Schedule a pair-coding session with the strongest candidates. Throw out some requirement changes that will require changes to their code. How would you do X differently? Then code it with them.

That will give you an idea of how well they work with others.

I know the above sounds time consuming, but I am guessing that 70% of the candidates for a position will get washed out when they can't complete even a basic solution.

[immigrantheart]

There is a middle ground where we can go from "I don't know anything about DS&A" to "lets invent the next approximate algorithm for this scheduling problem we have".

Even for basic JSON shifting, low effort high gain in performance matters. Do you want to work with someone that doesn't know to use a hashmap instead of nested for loop just for a simple memory vs space tradeoff?

Software engineering is complex enough, and code reviews aren't foolproof way of making sure you aren't screwing up, and nobody has time for detailed code review anyway. You end up have to trust the coder most of the time. You have to trust the coder is competent, smart, and responsible enough and not just "not my job" mentality.

[isubasinghe]

Yes but leetcode test beyond the performance implications of data structures. They require you to practice those kind of problems.

Counter point: Performance is mostly irrelevant for like 90% of companies in this day and age. Even iterating through a million items is quite fast.