It's a lot harder to make such drastic changes to something that's already serving production traffic at scale. It's okay to reinvent solved problems sometimes because the alternative is be a multi-year project with unclear returns.
Also, the 7 day retention is a feature - it helps us recover data quickly in case of bugs in our storage code.
The thing that makes the redbook special in my opinion is that the editors have been able to apply their research to solve actual problems for paying customers! You don't get to see enough of that in academia.
Most companies in the valley have a terminal level (a level at which you're not expected to progress to the next one) that's close to level 3 in the chart here. In my experience, a lot of people don't progress beyond that. For the ones that do, the number of years of experience plays a smaller role than the quality of the experience itself.
Salary negotiation is pretty one sided today with companies holding all the cards. Better visibility into numbers will definitely help level the playing field.
Collecting offer letters is an interesting way to build trust in data. What's the incentive for someone to upload their offer letter though?
If you're interested in buying one of these, Unicomp (https://www.pckeyboard.com) purchased the rights to continue making Model M style keyboards once Lexmark removed them from their line of products.
Also, the Model F (https://en.wikipedia.org/wiki/Model_F_keyboard) is considered by many as being superior to the Model M. IBM made far fewer Model Fs compared to the Ms, so if you find one of these in the wild, it'll be really expensive. https://www.modelfkeyboards.com is trying to re-create the original Model F.
Most people who joined in 2015 were getting RSUs and not options. Also, the strike price on options is dependent on the 409A valuation and not the valuation at which they raised money.
1. The US issues approximately 1M greencards every year - employment based petitions are around 10% of that number
2. The bill does a gradual rollout of eliminating the cap - so most people who have already applied for a green card and are in the US should not be affected
3. Employment based green cards are allocated based on skills - there's a specific allocation of 50K green cards just for diversity every year. That's around 35% of the employment based allocation.
Kafka can probably guarantee exactly ones semantics on publishing (conditions apply). It definitely cannot guarantee exactly once semantics on the consumer and processing side. Imagine a scenario where you receive a message from Kafka and process it, but the processor crashes or has a network partition right after. There's no way for the message to be acknowledged and you either have to design your system to be idempotent or handle exactly-once semantics further down the stack.
Databases have been handling exactly-once semantics for decades now. What Kafka is doing is not new and actually gives you a false sense of security when it comes to these kinds of things.
We don't run a TSDB. A TSDB doesn't work for the kinds of queries we run - specifically, TSDBs don't work if you want to
* analyze every datapoint you receive
* when the dimensional cardinality is high
* you want to analyze behaviors over time (e.g. the output depends on the orders of events followed - like creating a funnel report)
There's no off-the-shelf solution that does this at the scale at which we operate - hence the need to write our own custom solution.
Disclaimer: Not the author, but I was on the team that migrated our infrastructure to GCP.
As a startup with limited resources, it's important for us to invest all our engineering strength into the things that create direct value for our business. We'd rather pay Google to manage machines and run services like Kubernetes, Spanner, Pub/Sub and others and free up the engineers to work on our core analytics platform.
Being on-call/carrying the pager for a complex and unstable distributed system is a great way to understand how to build a good one. Building a distributed system isn't hard per-se. It's almost always the non-determinism and the associated difficulty in debugging errors that's a problem.
We try to avoid microservices wherever possible. If we're adding something new, it typically starts off as part of the service being deployed - either as a container within the pod (we use kubernetes) or as a library that the code can use. If something grows big enough in a way that it can't scale with the service it's running with, we split it into a separate service. The opposite is also true - if a service that we run no longer warrants a separate deployment, we make it a container or a library. We use GRPC for most communication and interfaces for anything that travels package boundaries. Both of these help with making the split/aggregation a lot easier to manage.
Averages are a little misleading because pretty much everyone touches python only about half the engineering team uses it as their primary programming language. I don't have the median number of commits or lines per commit handy - but that would be a better approximation of developer productivity.
As you can see, over the last 3 years, we've rewritten large parts of our infrastructure in golang. While we still use python for a lot of things, we felt that the type safety and concurrency primitives in go were a much better fit for writing some of our core services.
His use of b.N is correct. The code you have is simply multiplying N by 100 with the inner for loop - so your times are 100x of what each "concat" operation (+,WriteString) takes.
You are also allocating a new string/buffer/builder for every run - which is not useful if you want to just benchmark concat.
I really hope they use some of this money to better screen dashers and improve customer support.
We used to order lunch on Doordash once a week till things got so bad that we decided never to use Doordash again. Orders would regularly have missing or incorrect items. Some dashers would leave the food in the lobby, text me, and leave. Delivery was hardly ever on time and there was no way to get in touch with a human on customer care except through some unlisted numbers. We've switched to Caviar(https://www.trycaviar.com) since and have no complaints.
That's like saying if everyone maxes out their health insurance, insurance companies will go out of business. In any given year, not everyone is going to use the ~$8000 allocated to them. Also, healthcare in India is cheap. $8000 goes a long way.
Also, the 7 day retention is a feature - it helps us recover data quickly in case of bugs in our storage code.