Do they cargo cult the same process? I do see similarities in the interview process, so maybe that's somewhat true, but in my experience there's a ton of variety. Different companies have different formats, different questions, focus on different aspects of my responses, and I'm sure make hiring decisions wildly differently.

Some places have phone screens, and some don't. One company gave an easy leetcode problem as part of the phone screen, while in another case, one person actually spoke characters over the phone to me ("LinkedList", "left angle bracket", "String", "right angle bracket"). Some give take home questions. Some do a code review interview. Some dig into my resume during an interview, and some don't. Some companies had multiple interview sessions where I was asked the same question about my resume in each session by different people (wasting time). And so on.

So in general, I can and have passed over companies based on their hiring process.

I’ve interviewed at hundreds of places all within SV - I can say quite confidently that they’re almost all the same. There are some minor variations but they’re almost all completely forgettable by the end of the day. If they have something truly novel - it’s usually very off putting and requires intense amounts of unpaid labor… which you can’t take with you to other interviews.

The variations you’re talking about are quite minute. Whether someone asks you about your resume or asks you about your most technically challenging project is all relatively mundane stuff.

You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.

Every company cargo-cults or should we say - follows best practices or industry wide processes - in something.

No company has thought through every little bit of their system and processes because no company has the time to be completely original, just like no human idea only has ideas that they thought up themselves instead of borrowing a bunch of ideas from school, books, and overheard conversation because they sound right.

It is better to not know and explore than adopt a bad process because you overheard it in a coffee shop.

It's ok to not have an answer.

You have personally used at least one tool, language, or framework without reading its code or understanding it beyond a surface level. You've done this because some text on some website claims it gets the job done. And you probably do this every day (e.g. your OS, your phone, your microwave).

People cargo cult because there isn't enough time to exhaustively research every topic from scratch. Civilization exists because we blindly trust whatever methods seem to work, and then iterate on them.

I'm going to put the definition of cargo culting here since we seem to have lost it:

> Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collects.

Installing an app from the store is not cargo culting. Playing with a new framework is not cargo culting. Trying a new order at the donut shop is not cargo culting.

several points, I agree installing an app is not cargo culting, however following the same interview process as many other companies do is not 'cargo cult programming' while I would agree it is cargo culting of a sort.

the problem really is that results for interview process does not seem to reliably add up to anything, there are no reasons behind any interview methodology in the traditional cargo culting sense because there is no interview methodology really founded on reason, it's mumbo jumbo all the way down.

But back to my original point some posts up, everybody has at some point taken something on faith as a best practice that works without understanding why.

Some examples where cargo cult programming are concerned are adding unnecessary comments to self-explanatory code - but how about also one I've had requesting the removal of explanatory comments from code because the code should explain itself (comment was something like, have done it this way instead of what might seem like the more reasonable way ..example code.. because of a bug in Safari that means X happens, etc. etc, if you want to removal or change to better method please check that Safari works now and this place actually wanted it removed because they preferred not to have comments in code!)

Or how about this one which I am old enough to have done: putting your script tags in the head of the document because this was a best practice (before async and defer attributes, I'm talking 1999-2000 here)

Hell many of the best practices around CSS usage have depending on the year been the exact opposite of some other earlier best practice. And many frontend developers do it because they don't have the time or evidently the inclination to really learn CSS.

Hey, many best practices regarding CSS at various times are based around the fact that frontend developers don't want to learn to use it.

Now you might say those are not really examples of cargo culting, but I think they are somewhat close - if you are using a naming convention to avoid learning how something works then you don't really know why you are using the naming convention because the purpose of that convention is to keep you from that knowledge.

anyway getting off track here, I just think that saying you are not going to work at a place that has cargo culted its interview process does not tell you anything about the overall quality of the place, because everyone has cargo culted something, just like many fine developers when setting up their React projects have said oh, everyone uses Webpack we'll do that as our build process - they know they need a build, but why Webpack? They don't really know (me neither, every time I've ever encountered Webpack I've always ended up wondering why!? Generally the answer is because that's what the tutorials had, everyone used it, they didn't give any thought, but now we're stuck with it)

A simple test: Do they hire like Google but manage their programmers like a sweatshop (ie Scrum)? Then they are just cargo culting. Companies like Google at least gives its engineers a lot of responsibility and freedom you'd never get in an Agile shop.

a) plenty of agile shops give you more freedom than Google does. Following Agile methodology really doesn't mean what you think it means; and b) please don't casually "ie sweatshops" when talking about something that is clearly not that.

Do your developers have to work in 2 week sprints and forced to work on tasks split into sub 1-day part so they never have any real autonomy? Then you aren't giving your developers more freedom than Google. And if you aren't working like that then you aren't doing Scrum.

Google gives even junior developers multi month projects to own, manage and complete. No Scrum shop gives developers that level of autonomy, not even to senior developers.

So to me the time I've spent working on Scrum projects feels like a sweatshop compared to how I could plan and structure development at Google. At Google I am free to collaborate with stakeholders, build prototypes and get feedback etc, as I see fit to complete the project. Or not do it when I don't feel it is needed, the important part isn't how I run the project but that I run it well. If you don't give your developers that level of autonomy then I'm not sure why you'd care much about developer competence at all. (I quit Google a few years ago though due to how the company was changing, but I'll never join a Scrum development team again)

"And if you aren't working like that then you aren't doing Scrum"

I kindly disagree. You seem to have worked at a very stressfull place. In my experience that has nothing to do with it being "true scrum TM" or not. In any case, happy for you that you got out.

Always this "if you have any complaints about Scrum then you aren't doing it correctly" with no explanation how you'd fix the problems I talked about.

Also the leetcode interview is cargo-culted from big tech companies like Google and Scrum is cargo-culted from big tech consultants. They don't fit well together, having both means your company just picked the most popular/simple way to do each part without considering why Google uses that interview or tech consultants uses Scrum. If you want your engineers to work on problems similar to at Google then you wouldn't use Scrum, and if you want your engineers to work on similar problems as big tech consultants then you wouldn't use the leetcode interview.

Scrum does not mean "no freedom" or "no autonomy" it just says lets think about what we're going to do and try to follow a plan for the next week or two. Of course the individual software developer should be the one responsible to forming, adapting, and updating this plan (and it definitely should contain " collaborate with stakeholders, build prototypes and get feedback etc,") (of course, there is some level of 'commitment'. As in other project management systems, you should try and do what you said you'll do).

If as you say, you had no autonomy/freedom, this has nothing to with scrum, that's just regular bad management.

Sanity check: Would your manager complain if you stopped doing Scrum? If yes then you don't got that much freedom. If no, then I can see it being fine. It can work fine if nobody outside of it depends or uses the Scrum process, but then the company isn't doing Scrum, just the team doing it internally. This lets the team adapt and stop doing Scrum when it no longer fits their problem etc, that is the agile way. My point was just that if a company uses both the leetcode interview and the tightly integrated Scrum process mandated on teams then that doesn't make sense.

Edit: And a job ad where they say you should be well versed in Scrum I take it as they will force Scrum on me regardless if it makes sense or not, because I doubt a team just doing Scrum for themselves would put that in a job ad. Companies loves putting this in their job ads though so it is very easy to spot which companies works like this.

"You can't stop using scrum without your manager complaining" is not the same as "zero autonomy".

In every Scrum team I’ve personally worked on (admittedly not a huge sample size), it was OK for a senior engineer to say that their work for the next two weeks isn’t scrum-able so they’re going to mark themselves as having no capacity this sprint.

Yes, and my point was that juniors at Google have more freedom to go and work on different things than seniors have in a typical Scrum team. The description for the junior role (level 3) at Google says that they go off and work on individual projects lasting no longer than 3 months. Having a project for a month or two isn't an exception, it is expected from juniors. Then as you advance levels you get more and more freedom, and as a senior IC you are basically a free agent expected to be able to find things to improve, write a design for that, sell it to the higher ups on the product, and then go and build it, possibly get a junior to build it instead as a few months project, possibly get headcount and set up a team to maintain it etc, on your own.

I'm not saying that this way is strictly superior, but you undeniably have way more freedom under it than Scrum.

You're in the scrum cult dude, get over it.

Scrum is like communism, it doesn't work, stop obsessing over it.

If a company is really following scrum, then the developers are creating and managing their own tickets

Yes, nobody else could write tickets that reliably takes less than a day other than the team. The problem is that your day to day structure gets decided by a brainstorming session held every other week, that might make sense in some contexts but mandating that every developer has to work that way is exactly what I mean that you aren't allowed to have any responsibility.

To me it seems like Scrum was designed to make developers have as little individual ownership/responsibility as possible while still being able to produce relevant code. I see the merit in that, you don't have to tell me why minimizing individual ownership/responsibility could be a good thing. But I strongly believe that individual ownership is necessary to properly capitalize on the creativity of individual talent, otherwise its mostly wasted.