The problem with this is that there's usually a gap (often a very large gap) between what an employer wants (or thinks they want) and reality.

Often employers will put out a massive shopping list saying they want a rockstar developer who knows everything and has a hundred years of experience when they really need a recent graduate who knows git ok and can write a bit of java. In a similar vein I could easily see employers looking at the questions on your site and putting in unrealistic expectations for the company culture.

Anything to do with naming is going to be doomed to bike shedding (https://en.wikipedia.org/wiki/Law_of_triviality). The only way to avoid the kind of problem you mention is to have one person come up with all the naming rules and to enforce it.

You're right to think it's important because it'll make maintenance significantly easier than having 3-4 disparate naming schemes. However, there's no way that you can get a group of people to agree on a single naming scheme. Everyone will have their own idea which will make complete sense to them but to no one else, and they'll argue for hours about this. There's no easy solution, even though it should be trivial.

PIPs? RTO? You work for amazon, right?

If you want to work remotely and your director wants people back in the office then they'd probably want to get rid of you rather than having a remote worker other people could point to and say "but he works remotely, why can't I?". If that's the case then your manager could have put you on a PIP so you'd come under unregretted attrition rather than regretted attrition.

Managers can get judged on how many of their reports leave the company/team and if the company wants them to stay or not. If the manager can get rid of someone on a PIP then that looks good for the manager. Maybe this is what's happened to you in this case.

Switching every 2-3 years? Sounds about right. The only time I've stuck around longer was if there was a really good reason (like an RSU vesting schedule). It seems as though most companies will prioritise getting new people in rather than retention of existing staff. The other issue I've seen is that sometimes people who stick around at the same company for a while get a bit institutionalised and have difficulties switching to another company. Where I'm currently working in all hands meetings there's usually a work anniversary section and some people have been at the company for over 30 years. I just couldn't imagine that.

My last few jobs have only lasted 6 months though. One of them lied to me in the interview and when I started it turned out I was doing nothing but dealing with legacy systems. Another had some interesting problems which meant I had 3 managers in 6 months. Then I got an intern who couldn't program because he was related to one of the senior guys in the office.

Anyway, in terms of interviewing, personally I tend to just prep a few months before I start looking. Just do a load of leetcode, read up on some system design crap, that kind of thing. It all feels like a bit of a farce to be honest because everyone asks the same questions and by now everyone knows what will be asked and what the standard answers are. It's just a case of being able to memorise the standard answers.

There's nothing new in this post. The idea that there's a generation of people who grew up programming because of the cheap computers they owned is exactly why the raspberry pi foundation was set up. So maybe there'll just be a generation that didn't grow up with programming and they'll be the exception.

But beyond that, this guy really needs an editor. Just to chop down half of the wall of text. He does have some good points though.

It’s an open secret that the industry has no idea how to teach people to program. Computer Science degrees famously don’t prepare programmers for the job of programming

This is depressingly true. I had an intern last year and he was utterly hopeless. So I went and looked at the syllabus for his course and it was no surprise at all. It didn't cover anything that would be relevant to the industry. It barely covered programming at all. I poked around at a few UK universities looking at their syllabuses and only found one that sounded better than useless.

What I would say is that a lot of people seem to choose to do a CS degree when they should choose a software engineering degree. About the only use a CS degree might be would be to get through data structure/algorithm sections of interviews.

Something I'd ask the recruiter, long before the interview, would be "do you use safe agile?". The only place I worked at that did safe agile was awful and everything about safe agile was a nightmare.

I like this kind of simple question. It often reveals a lot. Something I've done in the past is to ask "what's the best thing about working for this company?" and after they answer that I ask "what's the worst thing about working for this company?"

I've found being direct like that can often get some useful information.

Even if HR is supposed to answer that I'd still ask the people doing the work. Often HR have a rose tinted view of things compared to the reality that the developers see. I remember having an exit interview where I told HR how bad things really were and they just refused to believe that it was real because no one had told them.

As for financial stability, I'd rather look at things like crunchbase or some finance website just to find the details. I've found a lot of people working for a company will put a positive spin on everything because they'll often be trying to convince themselves they've made a good choice to remain at the company. Essentially, it's a sunk cost fallacy.

This may be the case. They've gone from "this should be easy" to "oh, we never thought about that" pretty quickly.