I'm more into remote positions, built a very decent setup at home. However, I like the idea about traveling for offsites or office work, it is great for touching grass time to time, make good connections and know your team faces.
I'm on this that technical interviews aren't broken (at least the ones I did during the past 2 years or so), what is broken are the job specs. They may have turned _picky_, but okish.
Worst thing is that the data loss impact in money is not limited to the blackmail rates. What I'm saying is that even if everyone pays and 4kBTC (4.3M USD today) is collected by the perpetrator, there are other impacts in terms of legal issues and insurance. I don't know how to calculate this, but it could be an interesting number tho.
You don't need to calculate it, don't even try to estimate it. Just make up a number. A huge number. Larger than the whole world's GDP if you can. That's how the RIAA did it.
I do think that you need to learn how to use in the best way the technologies you have chosen or that are present in your current setup. No matter if it is a MySQL, Postgres or any other DB, it requires as a part of a job, learn how to use at it's best. The points on the article are good, however it's true that Postgres had problems with scalability not so long ago. That's changing, however I think that other data stores have addressed the problem of availability and scalability earlier and gained maturity during the last years.
Also, there is something that caused some noise to me:
This point is correct; PostgreSQL indexes currently use a
direct pointer between the index entry and the heap tuple
version. InnoDB secondary indexes are “indirect indexes”
in that they do not refer to the heap tuple version
directly, they contain the value of the Primary Key (PK)
of the tuple.
That's true, but the article doesn't make explicit that the PK on InnoDB is a clustered index and, that there are other optimizations like adaptive hashing to make read queries faster.
Agreed 100%, and the author also failed to mention several other advantages of having a clustered PK and indirect secondary indexes. A few off the top of my head: reads in PK order are faster due to lack of indirection; clustered index takes up less space due to lack of storing pointers to tuples; secondary indexes will be covering (no need for PK lookup at all) if the query only uses columns in the PK and secondary index.
It is interesting/ironic to see the article complain "those limitations were actually true in the distant past of 5-10 years ago, so that leaves us with the impression of comparing MySQL as it is now with PostgreSQL as it was a decade ago." In the MySQL world, we very very frequently see the opposite -- Postgres fans bashing MySQL for things that haven't been true in 10-15 years, as well as things that simply have never been true. It certainly is frustrating, just like what the author is experiencing!
Having a favorite/preferred database is fine, but I don't understand all the extreme views -- why do so few of these articles take the view that Postgres is a better fit for some workloads, and MySQL/InnoDB is a better fit some other workloads?
Or even just an acknowledgement that the authors of these articles rarely, if ever, have a comparable amount of expertise in both databases -- which would be necessary to make a fair comparison. Yes, Uber's original article clearly shares this same problem, but at least they seem to acknowledge it more clearly than the author of this response article. Take the section on replication comparison, for example: the author is describing logical replication support in Postgres even though it's currently a third-party addon. Cool, but MySQL has all sorts of third-party replication systems too. Alibaba has implemented physical replication in MySQL. And meanwhile even in MySQL core, there are two different types of logical replication -- there's no restriction to only use statement-based logical replication as this article implies.
BTW, good luck on the interviews!