Which sentence was toxic or bigoted? "Hate to say it but Amazon was hiring the folks getting laid off from major banks a few years ago." or "[Amazon] abandoned hiring only the best a long time ago."?
On top of that, many banks have a hiring bar for their software folks that's far, far lower than one would expect a company whose primary job is ensuring the correctness and integrity of its records to have.
(Also: "profoundly" toxic and bigoted? *Seriously*?)
I don’t think that answers the question. Denying transactions is certainly an issue. If it is true that the majority of mining power is in China, only a minority is outside of it. What mechanism does Bitcoin have for a minority of nodes to deny the transactions of a majority of nodes?
The "verification" nodes don't do anything to prevent censorship by miners.
The threshold isn't quite 50%+. If one of the 49% nodes mines a block with a would-be censored transaction, the censoring notes have to make an economic decision to try to mine a replacement block and then a second block on top of that to rewrite the chain. At 100% this is easy, but at just 51% it's a costly gamble that will frequently fail at a huge dollar cost.
A block costs $200k at current prices. At just over 50% of the network, you are gambling at least two blocks to force a rewrite.
>The "verification" nodes don't do anything to prevent censorship by miners.
Absolutely agreed; however, eventually some non-hostile miner will randomly generate an acceptable `nonce` [entire point of hashing/energy-usage] which DOES include the censored-by-some transaction.
An additional function of the node-verification network (which uses essentially no energy, relative to mining) it to maintain the entirety of `mempool`, which is where unaccepted transaction-attempts live until mined into a block [which is then "accepted/denied" by same node-pool].
tl;dr: as far a probabilities go, unless you own exactly 100% of mining pool, it is impossible to censor a tx from the node's mempool; all you can do with <100% is DELAY transactions.
I'd like to think that but, hiring for a couple open roles posted only internally at a FAANG, I definitely received emails from external individuals inquiring about the role - and found out there's a whole cottage industry around referrals for a fee.
I've worked in both sorts of companies. The constant questioning may work well at smaller scale but kills productivity at larger scales. Putting aside that it inevitably becomes a political exercise as much as a technical one (because the different technical solutions almost always reflect competing priorities), it also requires perfect sharing of information across the organization, which does not scale.
Especially in any sales driven organization, I've seen it cause issues with infra teams questioning the need for certain features. Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.
> Meanwhile, the answer is that the features are necessary because someone is willing to pay $$$ for them.
Just because someone is willing to pay for them doesn't mean they're worth doing. It could be that adding a feature makes other features harder to add or support. So sure, it might get you a win today, but it will cost you in the long run. And someone needs to be making sure the question being answered isn't "do we want a win today", it's "do we want the win today at the cost of a larger loss tomorrow" (when that's the case). And the sales team and higher managers don't see that. So it's the developer's job to make sure the questions are asked.
Sure, sometimes the answer is that yes, the feature is needed today, and it's worth the pain later caused by it. But if someone doesn't ask about the pain, it can't be considered into the decision.
I think the problem isn't constantly questioning! The major problem is many times, the ideas was top down, without a basic research or thought about possible RoI, wants to be discussed more because the team that will implement wants to know better and avoid mistakes, such behaviors always causes friction!
If a company doesn't have consistent metrics for performance reviews uniformly across teams, get out of that company yesterday. That's just a hotbed of nepotism.
Just proves the point, this person just cargo culted what makes google so famous in recent years. If you only metric is to launch new projects, you’re only gonna launch new projects. Who’s gonna get promoted for maintenance.
>Conceptual examples (not looking to argue about the specific bar)
Again, not trying to debate what the specific bar should be, just giving examples of the kind of metrics you can use. What's your preferred alternative? Lines of code? Whenever your boss feels like it? Stuff like that is why no one believes a "senior staff superstar" from the hot startup of the week is any good and requires them to do whiteboarding.
With sufficient granularity there is no difference. I can't give exact quotes without violating NDAs but variations on these have been the performance review standard at every major company I've worked at or known people who work at.
The metrics which determine if someone gets promoted. Those decisions are being made by some group, presumably with guidelines. If the process for getting promoted is "this group does whatever they feel like" that company is a disaster and you need to get out.
Thus, there are rules, and they are written down. If they're not visible to normal employees, they guess the rules based on who they see get promoted (cargo cult) while the committee uses the true metrics.
It's not like becoming a manager is a secret cult where you're dropped in and you suddenly have carte blanche to do anything. At established companies there are rules and procedures, and while you will likely have access to more information than individual contributors, you won't just be promoting whoever you feel like without having to go through others.
Most also look like hobby projects more than professional, so I would imagine having a lot of free time is a prerequisite. I don't know anything about the guy but all of the things you listed are reimplementing something that already existed, which is faster given at least the requirements are very clear.
Downvote though you may, you misunderstand containers - they are not simulating a whole operating system (that would be a VM), they are using features built into Linux to isolate tasks running on the same OS kernel to be isolated from each other.
