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.
I was wondering if anyone else had any questions they always asked the interviewer in the "we'll give you five minutes at the end to ask us questions" bit in interviews.
Personally I always ask what the staff turnover rate is. Mainly because in my first dev job I was one of four people who started on the same day. One of the other guys left after two days, I left after six weeks, and another guy left after two months.
Another I'll be asking after my current job is if they have a mainframe. I've now worked at three companies with mainframes and they all were old corporations where they were outsourcing loads of stuff to unhelpful companies (often IBM) which generally meant lots of headaches.
I started working for a big corporation about six months ago. Turns out a few months before I started there was a new CTO hired from a startup. This CTO has been on a hiring spree and basically hired all of the technical staff of the startup he came from (to the point that they're suing the company I work for).
All these people from the startup have their own office, away from all the corporate offices. And they're writing something (that they won't reveal) in what they refer to as their bunker. The best we can gather is that they're coming up with modern equivalents of all the backend services. This would mean that everything the devs do in the office I work in will be redundant.
I have the feeling that within a year or so (maybe less) there'll be mass layoffs of all the existing devs. Am I being paranoid?