When I was a Junior dev one of the first lessons my boss taught me was to always always speak up if something looked off to me. Maybe I’d get an explanation and be enlightened or maybe I’d actually sniffed out a mistake or code smell. It always seemed like a win win.
But if the entire job is based on “here swallow this bullshit pill before you’re let in the door”, isn’t it going to be hard to get the devs who are allergic to bullshit?
This is exactly the reason why any big enough company is eventually going to s*hit
And why founding team doesn’t stay long in a successful startup.
Doesn't the founding team get to determine the hiring practices?
One of the factors — it’s too risky for a big company not to hire based on obedience.
Maybe that’s what they want, namely a self selection of devs who will be happy and okay inside an org that is filled with bullshit.
Mostly it selects for people who can turn this on when needed, which honestly is a critical skill. Sometimes life is just bullshit, either you're a person who makes that easier for everyone or you're a person who makes that harder for everyone. But an inability to get past it is a red flag.
(if it is not explcitly defined, and there is state based behaviour, it is by definition then implicit)
At the moment I'm trying to overcome the inertia on this issue in the general process/industry sector with child standards from IEC 61508 - 61511 and 62061.
I am guesssing you apply the medical standards IEC 60601?
Or at design of devices at component level then IEC 61508?
Interested to know how it fits in to the overall Functional Safety approach.
This is what makes you successful in some large organizations, unfortunately.
Let's be real, that's exactly what most mid+ companies are looking for.
I'd say it's more a measure of how well you can learn an arbitrary skill. They could change it to solving Sudoku puzzles, grading SAT essays, or wood carving and most of the same people who do well in leetcode interviews would pick up those skills and ace the interviews.
But you don't need arbitrary skills, you need solid development skills to do the job. So they're always going to miss out on people who aren't good at learning arbitrary skills but already have solid development skills. But many big companies seem alright with that tradeoff.
Time is finite. You can learn to write better programs, or grind Leetcode. Leetcode interviews favor the one who can put enough time on the latter.
A better explaination is it's a chain reaction. People who know only to Leetcode enter the industry, and ask only Leetcode questions.