I think the original test still hits most of the important points. But yes, there's room to adjust some of them for modern tooling; the web ecosystem; and the current agile mindset.
1) Replace "source control" with "distributed source control". Or something about source control where branching and merging is cheap.
2 and 3) Replace "build" with "deploy" for web apps
4) No change
5) I've always been iffy on this one. What sort of bugs? All bugs? What software is ever bug-free? No new code until you've handled every single edge case and typo? Not very agile. I think this is another that differs between web apps and "shrink-wrapped" (even if digitally shrink-wrapped) apps; and with digital distribution significantly shortening the build/distribute/feedback cycle, it's less crucial than it used to be even for the shrink-wrapped apps.
6) I might replace this with something more agile involving sprints/milestones/target dates; or about adjusting scope to meet schedule
7) The term "spec" tends to get feathers ruffled, especially in agile circles. I've seen software built very successfully from nothing but a UI design and a short bulleted list of legal compliance requirements. I think there's room for something here about knowing what you're building and the whole team (from design/product to engineering to QA) being on the same page about what that is.
8) This. 10000x this. This is the item that 95% of software companies these days fail hard.
9) I've seen people complain that this doesn't take into account the prevalence of open-source tooling, but I think the point here is that you should be willing to invest a LOT of money in making your developers' lives easier and software quality better. Don't skimp on workstation hardware, or AWS instances, or licenses for whatever tools will improve velocity/software quality/quality of life. Perhaps it could be reworded somewhat.
10) These days I would split this one into whether developers write automated tests that are run in CI and whether you have someone other than the developers do click-through testing, both of which are important (unless you're writing nothing but SDKs)
11) I would say during either an interview or a take-home exercise, but yeah. Write code as part of the interview process.
12) Kind of meh on this one. For most web apps you can do A/B testing, partial rollouts, and feature flags to get much higher quality and nearly as quick feedback than you would with "hallway" usability testing. For shrink-wrapped apps, I think it depends on how representative people in your hallway are of your target user. Yes, you need usability testing, but the "hallway" part is debatable.