Asking someone to relocate across the country, and not offering severance if they refuse, is basically firing people without severance.

This may be fine legally as severance is only something that companies offer voluntarily, subject to a severance policy that they write themselves, so I'm sure they have a loophole in it for that. But I've never heard of any other US big tech employer doing that: this just reinforces the impression that Amazon is the worst employer among its big tech peers for tech workers.

Whatsapp chats are end-to-end encrypted, which your texts are not. Also texts do not work internationally reliably or for free.

The alternative to Whatsapp is Signal (or other end-to-end encrypted, crossplatform chat app), not SMS/RCS.

Outside the US it has also become the standard communication tool. Send a kid to school? there is a whatsapp group for the class parents, and another one for your carpool. In the US enough people use iphones for Apple's messaging app to have critical mass, but that's not the case almost anywhere else in the world.

Einstein's "spooky action at a distance" ("spukhafte Fernwirkung") is *not* entanglement. It is the collapse of the wave function. This is a widely held mis-conception, but Einstein's first use of the term was in a thought experiment that did not involve two entangled particles but only a single particle hitting a detector. He objected to the idea that when the particle hits the detector in a specific spot, the wave function everywhere else instantly collapses to zero, unbounded by the speed of light limit.

Personally I've almost never asked algorithm questions to candidates in interviews. I feel like the typical algorithms in these questions are hard enough that if you don't know it/remember it you'll struggle to come up with it in a few minutes during an interview, while also being easy enough that if you do remember it, it won't be too hard to come up with an implementation. E.g. dijkstra's algortihm is really simple once you know it, but dijkstra was a pretty clever fellow to come up with it in the first place... So it ends up being largely a knowledge-focused question, which isn't the best.

When I'm interviewing a junior, I'm actively looking for pockets of knowledge and understanding in a sea of ignorance (the field is too vast for anyone, but especially for someone newer to it), so knowing they don't know a specific thing doesn't tell me much: they don't know most things, and that's ok. I might ask an algorithm question to a recent CS grad who tells me that algorithms and data structures was one of their favorite classes. When I'm interviewing a senior candidate, asking an algorithm question would likely measure how much interview practice they did to remind themselves of all that stuff, more than how good an engineer they are.

I guess there are some super-simple algorithm questions that can be used to filter out the people who can't code at all (e.g., fizzbuzz, or insert into linked list or such), but any kind of programming task will probably do for that purpose.

I appreciate the idea behind letting people use whatever tools they use in the real world in the interview: it's a bit like open book exams. If you can quickly look up something, it's as good as knowing it yourself in practice.

However, as somebody who has interviewed a moderate number of people (including one last week), I don't know how I would incorporate AI use in a live interview. There's so much randomness when you use AI to assist you in solving a complex problem: sometimes it works right away, sometimes it requires a lot of trial and error prompting, sometimes it does not work at all and I give up and do it entirely by hand. I do believe with some practice it can increase my overall productivity a little bit, but on any given task it may or may not help.

When I interview someone and I ask them a question, I can compare that to how well I would have done on that question (which is a bad metric if I'm the one who came up with the question) and with how well past candidates or colleagues have done on it. But if they're using AI, which changes from day to day, what am I comparing against? what counts as good enough? Maybe one candidate's chosen model/tool happens to be less good at this particular problem then another candidate's, so they waste time chasing hallucinations. Does that mean I shouldn't hire them? It's really hard to evaluate.

They're not taking a "US job". Tech jobs are largely without borders, and go where the workers are. They're taking a job in the US. Otherwise, they would in many cases take that same job in a different country, paid with money sent out from the US by their US employer to some office abroad. Examples: a) Microsoft opening an office in Vancouver to hire the same people they could not hire in Seattle when the h1b visa caps were first hit b) the startup I was part of in the 2010s hiring multiple people in our London office who had lost the h1b lottery to be hired here in the US

US can choose to get payroll and income taxes and spending from the people who take those qualifed jobs here in the US, or have those jobs go abroad.

These are two different things.

Coding with AI assistance is what a software developer does who is using AI to a greater or lesser extent to help in their work. The end result is expected to be code that the developer understands (whether they wrote it themselves or not) and that meet the project's standards for code quality and such.

Vibe coding is someone using AI to build a relatively simple application that they would not have either the capability or the time to build on their own, generally to meet a specific use-case or "scratch an itch" that would otherwise go unscratched. In this case, the developer may or may not have any relevant software development skills, and does not need to understand or even read the generated code. If something doesn't work as expected, they give the AI further instructions to hopefully solve it. The end result does not meet any particular coding standards, and is likely not good quality maintainable code, but in many cases it gets the job done.

As a tool to enable non-developers to self-serve a solution for some relatively simple use-cases, i see vibe coding as somewhat analogous to excel or other applications that allow non-developers to build stuff that solves their problem, without writing code themselves. The excel formulas and automations that lurk in the giant spreadsheets that are passed around non-tech workplaces might make a software engineer scream in horror, but most of the time they get the job done.

They're not running a bus service. They're not shuttling people back and forth on the same route: they're operating in large, complex cities where all sorts of things happen. In the end it's a numbers game, there will be many boring rides, and once in a while a few novel things will happen.

There weren't just problems with the "scientific inference" from the trial. The Stanford Prison Experiment was simply academic fraud. From the wikipedia page:

More likely, end this program and US competitiveness on the international scene will decline, while companies hire the same people (who would have come here on an H1B) in other countries. That's what happened the first time we started to hit the H1B cap, during the dot-com boom: Microsoft for instance opened an office across the border in Vancouver and hired people there instead of in Seattle.

Our president is already working hard to make the US unattractive to top foreign talent who might attend or work at US universities. Do the same for private industry and the US will become a technological and economic backwater pretty quickly.

The US isn't magically entitled to be world leader in science, technology and business: it achieves that by attracting the top talent from around the world.

There doesn't seem to be as big a competitive moat for AI model developers as was initially thought (that was I guess the lesson of the "deepseek moment"). If some leading labs raise prices excessively, customers may be able to switch to a different lab or just run a slightly smaller model locally for "free".

Even if AI can do that... who is going to review those binary blobs?

The way to fix that is to make H1B be portable with the worker from one employer to another, and allow workers some time to legally stay in the country after they lose their job to look for another job. That way once an H1B worker is in the country they are just as marketable as everybody else, and can demand market wages.

Will require some new/tweaked visa fraud checks to avoid companies specializing in getting people H1B who then leave immediately to work elsewhere, but is very doable.

If you're worried about being kidnapped for your huge amount of crypto holdings, just sell it all and put it in normal investments that are not as easily and irreversibly stolen by somebody applying a 5 dollar wrench to your knee until you give them access.

Personally, I think that any employee who wants to write code in a non-safe language such as C that will run as part of a company's products or systems should get approval on sheepskin parchment written in the CTO's blood with a phoenix feather pen and sealed with the recently departed pope's wax seal.

Obviously I am partially jesting: there are some cases where the low level languages are the only available or viable option (embedded code, device drivers, some cases with extreme optimization needs) but otherwise it is just not acceptable to deploy code written in a language where memory safety issues are possible: it is just too risky. If you think you're too smart to make such errors in your C code, well, let me just say that doesn't sound very smart.