> hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency
I am not sure this is true. It is prohibitively expensive to read from all replicas. All you need to ensure is that any replica has the latest state. See how Azure Storage does it [0]. Another example is Spanner [1] that uses timestamps and not consensus for consistent reads.
> This decoupling and targeting a specific set of faults allows our system to provide high availability and strong consistency in face of various classes of failures we see in practice.
What that says is: for the failures we have seen so far, we guarantee consistency and availability. But how about the other kind of failures? The answer is clear: strong consistency only is guaranteed for _certain expected_ errors, not in the general case. Hence generally speaking, strong consistency is _not_ guaranteed. As simple as that. Saying it is guaranteed "in practice" is, pardon, stupid wording.
Absolutely, the vast majority (95%+) of logs are never read by a human. Therefore, processing it is enormously wasteful. A good architecture will write once and not touch anything until it is needed.
I spent years working on system handling 50+PB/day of logs. No database or ELK can handle that, and even if it did it would be prohibitively expensive.
Ignoring the fantasy b.s. in the second half of the article, the stuff at the top is exactly what I mean.
A mighty 400 GB/s: i.e. much less than the > 50 PB/day of logs the other person mentioned;
1600 hours of SD video per second: i.e. about 1-2 million concurrent HD streams, or much less than the amount actually served by YouTube.
IBM Summit "world's most powerful supercomputer": < 5000 nodes, i.e. much below the median cell size described in the 2015 Borg paper. Summit is a respectable computer but it would get lost in a corner of a FAANG datacenter.
The numbers are not fantasy at all - this will be a huge radio telescope - one square kilometer of pure collecting area and thousands of receiving antennas (For reference: Arecibo has around 0.073 km^2). We are talking data input to the correlator on the terabit/s scale.
And technology-demonstration with ASKAP are well under way.
ALMA is working quite well by now as well (> 600 Gb/s with just an 50 antenna array).
> Expect at minimum 2 Medium difficulty questions in a phone interview that need to be able to be solved in optimal space time complexity in under 45 mins
I see this being repeated on Leetcode and Blind, but it is not my experience at all.
In 2019, I got Senior level (L5/E5) offers from everywhere I applied, including Facebook and Google. I never solved more than a single medium problem in 45m-1h. I was asked a hard problem maybe twice, and not at FB & G.
I also interviewed 100+ candidates at Microsoft and Google. I have seen hundreds of interview questions and feedback reports and I simply can't corroborate that statement.
Oh nice, I've been waiting for someone like you to reply. Thanks for replying, I need a perspective from you as well.
Why do you think it happens this way? I have some other anecdatas that I gathered from the forums but I am not gonna spew it here because it could be offensive/racist or whatever.
But what I think the more reasonable answer is, because interviewers are humans, and a lot of it are based on luck. Maybe the interviewer has a bad day? Maybe the interviewer has a favorite question that is super tricky and he/she really want to test this to the candidates.
I also think that due to your seniority, it seems that the FAANG companies already know that you know your stuffs. Since L5/E5 definitely not an easy task. Therefore you don't get a really hard question, because they don't need to determine whether you are a risk or not. They already know that you will perform great in the company.
Btw if you are doing your interview like this, I commend you. Thank you for not making life hard on people. I myself has gone through hundreds of Leetcode but still failed, due to the harsh questions that I've seen these days. Yet due to Leetcode I postpone learning other things that can serve me better in my career. It is stupid, but it is what it is. I know a lot of people can relate with me.
Anyway, please continue to do a great work of interviewing people! Maybe one day I will get my chance.
I've never once adjusted my question based on where the candidate was coming from. The idea that people would ease up if they saw FAANG on a resume or a 10+ year career is just not a thing I've ever seen.
There are a few truths in modern tech interviewing:
1. There is a large amount of randomness. Between the question that an interviewer chooses to ask and whether the interviewer is having a really bad day, you might just get screwed.
2. A lot of people are genuinely working really hard to do a good job interviewing. I've seen careful and detailed interview feedback and talked with a huge number of people who really care about interviewing well.
3. Interviewing has less oversight than ordinary work, so some people are bad at it and don't get feedback. Some people get back luck and are assigned one of these interviewers.
4. Interviewees suck at evaluating their experience. This means that when somebody says "I did everything well except I missed some impossible optimal algorithm and they rejected me so that's bullshit" you should become skeptical.
5. Angry people get signal boosted. Online discourse around interviewing is dominated by people with bad experiences.
You answered some of my questions in some other HN posts. I remember you.
Thanks for the replies.
Btw I am curious of this one thing. Say a FAANG has X years of experience in a FAANG company and then quit. When he/she reapplies to the company, is there any sort of stuff that makes he/she preferred over other candidates? Why I'm asking this question is this. I imagine that a FAANG engineer who has more than X years of experience, say x = 10, he/she must have better things to do rather than just memorizing 1000 Leetcode problems. Therefore if being judged strictly by using Leetcode style questions, I imagine he/she would not do well.
If you leave and then re-apply, hiring managers will look at your past performance reviews when considering you as a candidate. If your past performance reviews were excellent, it'll be a lot easier to come back. If you left another FAANG company... it doesn't matter beyond maybe making it easier to get a phone screen.
I expect that everybody has better things to do than memorizing Leetcode problems. That's because I don't expect people to memorize problems at all. I strongly believe that candidates should be able to succeed at the question I ask despite never having seen it before in their lives.
What is considered a medium problem? Is this in terms of equivalence of problem levels found on leetcode and such? I have yet to do the grind. My current job is great and pays FAANG level- I hope to not have to engage in this crap.
Medium is defined as Leetcode's problem tagged in Medium category. It is quite blurry to be honest because some questions should be on Easy category and some Easy questions should be Medium and some Medium should be Hard and some Hard should be Medium.
That's good, keep that! Don't get involved in this crap. I have to do it out of necessity.
On leetcode they are literally marked "Medium". Mostly questions that involve some sort of BFS or DFS on graphs, figuring out the next available time slot in a meeting calendar, figuring out the best time to buy and sell a stock given the daily price, stuff like that.
> Standing is denser than walking, so the throughput is greater
Doesn't this depend on the walking/standing density ratio and walking speed/escalator speed ratio?
Let say the walking density is 1/2 of the standing density. If the walkers walk at the speed of the escalator (i.e. their speed relative to the ground is 2x the speed of the escalator), then the throughput is the same.
Holborn's escalators are over 23 metres tall, as tall as a six or seven storey building. Very few people will walk up the entire escalator, essentially limiting utilisation to 50%.
A DCT (Dual Clutch Transmission) like the Porsche PDK is not remotely comparable to a torque converter based transmission. Yet, both are categorized as "automatic".
And one of those cost approximately my annual salary and the other doesn't.
Telling people automatics are great when you are referencing a type that the majority of people will never have a chance of owning is a classic Hacker News manual-vs-automatic discussion trope.
Disclaimer: I work at Microsoft, not on Service Fabric but I have built complex stateful services on top of Service Fabric.
As zapita said, Service Fabric now handles containers but I think it is just because containers became trendy and FOMO kicked in.
Where Service Fabric is decades ahead of the container orchestration solutions is as a framework to build truly stateful services, meaning the state is entirely managed by your code through SF, not externalized in a remote disk, Redis, some DB, etc...
It offers high level primitives like reliable collections [0], as well as very low level primitives like a replicated log to implement custom replication between replicas [1]. I feel that publicly this is not advertised enough and it is unfortunate because it is a key differentiator for Service Fabric that the competitors won't have for a while, if ever because it is a completely opposite approach: containers are all about isolation, being self-contained and plateform independent while SF stateful services are deeply integrated with Service Fabric.
The first thing I was asked when I interviewed with Microsoft was what I wanted to do and what I wanted to avoid. I said, no frontend, something related to distributed systems and they put me up for interviews with an Azure team.
With Google, it was like "interview first, accept the offer before knowing where you are going to be placed, and we will put you in some team".
These are good anecdotes to share. A few years ago when I was a Microsoft college hire I got my impression from gathering anecdotes from others, but maybe it's better now!
Google absolutely has the problem you described and I forgot to mention it in my prior comment. With Google you have no clue what team you'll be on when you're evaluating the offer, but once you've accepted the offer you're given more choice with regards to placement.
I am not sure this is true. It is prohibitively expensive to read from all replicas. All you need to ensure is that any replica has the latest state. See how Azure Storage does it [0]. Another example is Spanner [1] that uses timestamps and not consensus for consistent reads.
[0] https://sigops.org/s/conferences/sosp/2011/current/2011-Casc... [1] https://cloud.google.com/spanner/docs/whitepapers/life-of-re...