Isn't that the opposite of innocent until proven guilty?
And you're someone who's tech-savvy.
Most people are going to see ".com" and think "Website" not "Program". So if suddenly a .com file is downloaded there's at least a chance they might stop and wonder what's going on.
I run into this issue all the time - We get Bug bounty reports constantly because $SecurityResearcher put "example.com" into the "Company Name" field, and we sent them an email saying "Thanks for signing up. We hope you find $OurProduct useful at $CompanyName. "
When the email turns up in their Gmail inbox, Gmail "helpfully" turns the plain text "example.com" into a link to https://example.com - so $SecurityResearcher reports it to us as a vulnerability in our platform because "we" are linking to example.com - except we never did, and we have no way to tell Gmail, or Outlook, or any other platform to stop doing that.
Services we pay for, directly, also do this - Notion and Slack are two I can think of immediately. I have to fight them to stop turning my mention of some file into a link to a random domain. (e: Maybe Slack has stopped doing this, perhaps - in testing it didn't do automatic linkifying for messages to myself)
This was bad enough with .cs, .ts, .js., .json and so forth - but having a .zip link appear in the middle of documentation on how to do something with a zip file is a recipe for disaster.
I've had a document saying "please download package.zip from the build artifacts site" - which was then auto linked to https://package.zip - and anyone not paying attention might expect that it was a link to the build artifacts site.
Of course the need the work...that is why they applied for a job...
I find this whole thread really enlightening. As someone who has been trying to move around in tech in the Bay Area, outside of Amazon who hired en masse, most companies have had 6-8 interviews as a standard hiring process for almost the last entire decade. What's really happening is that most of the people who were on the other side, being very selective in who they hire, are now really coming to terms with how bad the process is because they are the ones now trying to find jobs.
The problem always existed for someone else, now it exists for you.
[1] https://en.wikipedia.org/wiki/List_of_tornadoes_and_tornado_...
I grew up on the edges of the New Madrid fault area and, while earthquakes were never discussed, we did tornado drills about every two months while in school. After I entered the workforce, that got closer to once a year, but you were still expected to have a plan and supplies. It was basic emergency preparedness, like any sensible person. Granted, big F5 tornados are rare, but small ones were common enough to not even be noteworthy.
Having left that region as an adult, it was a small culture shock meeting people who never had this kind of training. After all, the places I've visited all experience tornados, though not as often as my old home town. Still, the usual attitude I encounter is "I've never seen a tornado - they don't happen here". It's true that tornados don't happen often, just like my birthplace hasn't seen a serious earthquake in my lifetime, but they do happen.
I guess that's why I'm curious about your experiences. I've never been to Japan and I've read enviable reports of your disaster preparedness, but I honestly have no idea how your schools and culture handle tornados.
1) This policy is known and communicated to current and future hires.
2) The company has found a way to pay each person the current market rate and makes efforts to adjust accordingly.
Otherwise why would anyone stay?
The founder was very public with other companies in the area about both his policy of firing 10x developers and hiring any warm body that could put a resume in his hand. He told stories at local business meetings of the various people he hired who couldn't find a computer and were fired on the same day. So, when you found out what the corporate culture was like after about a month on the job, you had two options.
1. Stay on for a year. This cemented to every hiring manager that you were a 1x developer (because you kept the job), but absolutely not a 10x developer. You might get a junior developer position somewhere else, but never more than that. 2. Immediately quit the job. You now had a one month stint at the firm on your resume. Every hiring manager in town knew that 5% of people with a short stint were good developers and the remaining 95% were people who just finished "COBOL for Dummies". You'd best just leave the gap in your resume if you didn't want your resume in the trash.
The problem is that employers make this process as toxic as it possibly can be, using every trick in the book of emotional manipulation, making you feel like you're blackmailing them and literally destroying their life. Adds a lot of resentment on both sides every time regardless of outcome and it just accumulates.
1. The employee was a vain troublemaker who had over-value what they were worth in the market. Firing them would not only remove an inefficiency from the system (as they were likely not to work as hard if they believed that they were underpaid), but it would also helpfully remind the other developers that they were all expendable.
2. The employee was a 10x developer who was vital to the company processes and could command a much higher salary somewhere else. Even if you gave them a raise today, they could be hit by a bus tomorrow. The best course of action was to simply rip off the band aid. Fire the employee, have security immediately escort them from the building, and begin triage to ensure that the critical systems that they wrote/managed could be handled by the next resume in HR's pile.
The line I will always remember is: Developer are like eggs. They are heavily undervalued, but also will crack under too much pressure. Thankfully, like eggs, you can buy them for cheap in packs of twelve, so it doesn't matter if you break a few.
For context: I spent 11 years at Intel managing pre-silicon and post-silicon processor validation. No processor that does only and exactly what the Programmers Reference Manual says, and takes the phrase "undefined behavior" seriously, will be successful. Google would do well to adjust their philosophy.
The standard document may say one thing, but what people do in the real world is the real standard. If your software has issues with the world's most popular IMAP server, you need to adjust your software to be compliant with the standard.
I'm personally more sympathetic to your actual conclusion, but it's odd how often a single argument can be used to support two conflicting beliefs.