[PragmaticPulp]

Interviews are only partially about testing your body of experience. They're also supposed to test your aptitude and ability to grow in the future.

If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.

[zerr]

Err, but why do you have to prove it for every next job?...

In reality, it's a legal way for:

1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.

2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget.

Keep in mind that CP != CS.

And CP is not everyone's cup of tea. It is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science the same way as e.g. Physics or Biology use Math.

[PragmaticPulp]

> why do you have to prove it for every next job

Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

> Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.

In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a new college grad with zero years of programming experience. They're significantly easier after you've been programming for 10 years.

> Making switching jobs harder - for every next job one has to prepare again

Companies aren't going out of their way to make it harder to hire good employees into their own companies.

Leetcode isn't an industry-wide conspiracy. Companies are using it because they believe it's a good filtering mechanism for candidates. When the Big N companies have higher rejection rates than Ivy League universities, they can afford to be selective.

> Keep in mind that CP != CS.

The problems are designed to test CS skills.

How else would you suggest reorganizing the interviews to test for CS skills?

[zerr]

> Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

Yet, they copycat each other on this.

> after you've been programming for 10 years

...as I said, you're not desperate enough, so you become picky how you spend your time.

> Companies aren't going out of their way to make it harder to hire good employees into their own companies.

Lowering the churn rate has a higher priority.

> The problems are designed to test CS skills.

No, these problems are designed to test CP skills. Even Norvig admits it has nothing to do with being a good dev/hire: https://www.youtube.com/watch?v=DdmyUZCl75s

> How else would you suggest reorganizing the interviews to test for CS skills?

How Caltech, MIT, Harvard, ETH, etc... test for CS skills? Certainly not with CP riddles - unless you take a CP course, which indeed is a separate [optional] course at some of those universities for interview preps specifically.

[bradleyjg]

Very few companies to need people that have very strong CS skills. CS skills are mostly useful for doing CS. For example designing and analyzing an algorithm that’s more efficient than any other algorithm at sorting integers with an average of 10^40 digits on a three tag Turing machine.

While CP skills also aren’t terrible useful for most companies, they are closer than CS skills. What’s really needed are software engineering skills but unfortunately our most prestigious institutions think it’s beneath them to teach that.

[bosswipe]

I've been programming for 10 years and I'm pretty good at it, at every job I've had I get lots of praise and recognition and accelerated promotions. But I have a hard time with leetcode problems and have failed several interviews because of them. It's not that I can't learn the leetcode tricks, it's that I don't have the motivation or the time to drill for months on them so that I can retain all the tricks.

I don't have a CS degree so I think that might be the difference, I didn't get to spend four years thinking about algorithms and data structures. Leetcode interviews are a form of gatekeeping that CS degree people use to filter out non-CS people.

[shloosh]

I also don't have a CS degree, and got hired at a FAANG company. If you want to quickly get up to speed on the data science basics, check out "Cracking the Coding Interview" by Gayle Laakmann McDowell. Her YouTube videos are also useful. Certainly, there are other methods, but this is one that I found useful.

[indecisive_user]

>Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.

But even two teams within the same company often don't trust each other's interviewing practices though.

Transferring from one team to another often requires doing the same algorithm interview that new hires go through, even though you were good enough to get hired in the first place and are ostensibly a better engineer than when you started with the company.

[jkcorrea]

#2 doesn't make sense, though: If I'm company B, trying to poach from company A, it would be in my best interest to make the leap to applying/interviewing less difficult, not more for employee's of company A.

Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

[strbean]

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

They have been caught doing so in the past. [0]

[0]: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

[pandaman]

FAANG don't really want to poach each other that much, as a sibling comment says, they had been already caught in the illegal non-poaching collusion. But even without any such collusion active they undestand that people would jump back and forth between these comapnies, ratcheting TC up every jump.

What they need is that somebody who passed the interview believed it was a lucky break and would not tempt fate trying a similar interview at another company. If they considered the interview just a filter, they probably would not be so lenient with letting people to apply many times and even encouraging this.

[kkkiiiooo]

> Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent

This is a proven reality, and has been out in the open for a long time.

[BurningFrog]

Then a few links to those proofs should be easy to produce?

[bretpiatt]

On this same thread https://news.ycombinator.com/item?id=24182126

[BurningFrog]

Yeah, I know about that one. Wondered if anything new had come to light.

This was 10 years ago and involved 8 companies.

Concluding from one crime that they all do it, and that's just what those people are like, you can't trust them etc, is an impulse we all do well to resist.

Of course, concluding that nothing like this will ever happen again is also naive. The incentive to cooperate is certainly still there.

My impression is that since the 2010 case, wages have gone up dramatically in that class of companies. There are also more big companies with owners who aren't pals from before. I think. Just guessing, relly.

[jkcorrea]

> If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

So by that logic, why not just create some game for candidates to master. If all you're testing for is "how much they want it" and how quickly they pick up on some arbitrary system that they'll never use in their actual job, then the subject shouldn't matter, right?

[barry-cotter]

> So by that logic, why not just create some game for candidates to master. If all you're testing for is "how much they want it" and how quickly they pick up on some arbitrary system that they'll never use in their actual job, then the subject shouldn't matter, right?

You have reinvented the Chinese civil service examinations, congratulations. More generally the higher stakes a test gets the less the subject matter matters. If you make admission to Harvard or Cambridge based solely on interpretation and knowledge of pre 2000 rap it won’t be long until the same people who would have done well on a test of English literature are intimately familiar with Tupac.

[Icathian]

They already have. And at the time it was being developed and gathering momentum, some plausibility as a thin defense of it was helpful. Why go through that process again now when the existing system is already firmly in place?

[bosswipe]

There's no reason to believe that being able to learn leetcode tricks is a better sign of aptitude then being able to learn good software engineering practices.

[read_if_gay_]

> it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.

But you already have your reward, right? I’m not sure how much ambition is left after you actually get the job.

[username90]

Promotions can double your salary or more from that level so people are plenty motivated.

[read_if_gay_]

So can job hopping. In fact, IIRC staying at the same company earns you less money than finding a new job every two years or so.

[lowiqengineer]

That’s definitely not true at companies without incentive systems.