>400k and fully remote is still not easy. Most of the obvious high payers in big tech (e.g. Meta) have required days in the office, and I can think of very few high-paying companies that don’t have N days RTO at all levels (literally only Netflix off the top of my head).
It is also not the case that such people get in without interviews. Senior+ (though largely staff+) is generally when you can make 400k and there are definitely still grueling interview loops at those levels.
Sorry, I didn’t remember the start of the thread by the time I got here. But in later comments you said “in addition, if you are 400k+ you'd probably enjoy the privilege of skipping the interview and even having a position opened for you” and “or you are in the > 400k camp where you don't have to worry about job availability”, both of which I disagree with and provided counter examples for. So, one being in the 400k+ camp does not make it any easier to find an equally well-paying job, hence toleration for being treated like a child.
That’s the trade off being made for convenience. It’s still somewhat multifactor though (I’ve seen people call it 1.5FA); authentication codes have the benefit of being resilient to replay. So, you’re not pwned even if someone steals your password somehow.
Even if someone steals your phone, you should have a passcode. If they know or guess your passcode, well… someone could steal your house/car keys too, and we still carry them around anyway :)
If we are assuming that the password manager is on the same device used to login, a replay attack is bordering on rediculous.
In this scenario, you are assuming that the client is not compromised (since otherwise they would just steal it before you use it) the server is not compromised (otherwise what is the point), you do not have an active mitm (otherwise they could use the token directly instead of replaying).
All that really leaves is you have someone capable of passively eavesdropping a TLS connection (usually much harder to do than active mitm). I suppose someone literally looking over your shoulder or recording you with a hidden camera - but even then they just have to out-race you hitting submit.
Sorry, I meant replay really broadly because I could not come up with a better term in the moment. For example, a password can be leaked in many ways (guessed, by a breach if the website has poor password storage, etc) and be “replayed”, as in the attacker just enters the password themselves. A code does not have that problem because it is temporal.
Ah ok. Its confusing because one of the requirements for time based one time password 2fa is that if you use the same 2fa token twice,it is still supposed to reject the second one even if it is in the same time window.
On the server side usually a "key" is stored, which for TOTP based 2fa would allow the attacker to create future 2fa tokens if they got ahold of the key. So what really saves you is the website choses the key not the user, meaning every website has a different one. Not the temporal nature.
Anyways, usual term for what you are referring to with reusing passwords is "credential stuffing".
My university had lecturers that were precisely this (masters in CS, focused on teaching intro undergrad courses).
However, I think there is still a lot of benefit from having researchers teach upper level courses. Firsthand experience in research brings an additional dimension that can be appreciated by students who are beyond the introductory level.
There are also tenured professors who are good at both research and teaching!
4 engineers for an entire phone company sounds scary. I’m sure your engineering is robust enough such that outages are minimal, but that still sounds like a lot of on call (rotation of 4 = once a month?). Even if you only get paged once every few months, you still need to worry about getting paged until your shift is over! Even if you don’t worry in the psychological sense, you still have to schedule around it.
I actually screwed that up, we only have 3 total software engineers. Including myself.
We do have other employees who maintain the hardware, on-call DBAs to manage issues, etc. I'm only speaking to the software engineers.
And we have lots of hardware and lots of open-source solutions that handle the actual calls.
I'm full-stack but lead on the front-end, a complex Angular application to manage everything from huge call centers to small restaurants.
We have C# for APIs, cloud Oracle for the database, and a whole slew of other software and services to manage the actual calls.
Each of us is specialized in specific parts. Our up-time is tremendous given the amount of code we've written. It's extremely stable.
I've been at this 20+ years, as have the other 2. We know enough between us to get this done.
I've never been called after normal work hours. We release the updated front-end every week and haven't had any issues. And a lot of changes/improvements go into that ... that's a lot of my job.
Sorry, but I'm skeptical that you actually run "an entire phone company" in the way that most people understand the term. You mention that you use lots of open-source solutions, and I'm guessing you outsource the build and operation of the network to a real phone company, probably similar to an MVNO. Am I wrong?
Meta is very different from that, they build the products that users interact with, but also build things at the bottom of the tech stack. At their scale, this makes business sense to do so, and comparing your headcount with theirs makes no sense.
I don't really understand why software engineers keep dunking on each other like this. I get that people want to broadcast how smart they are, but in reality we're just giving the general public a warped sense of how much work is actually involved in building large-scale software systems.
I’m also skeptical any time someone mentions 5 nines uptime at a small scale. For one, it takes a lot of engineering to be able to actually monitor and detect that with precision (that is, how do you know you are 99.999 and not 99.995?) and with so few people there may be holes in what’s monitored (there are so many places you can drop requests/whatever and lose availability). There’s also tail risks like datacenter incidents (if your servers are on three racks in two data centers) or dependencies like power outages that you may be getting lucky on avoiding due to small scale, rather than amortizing over a huge fleet - that is to say, if there is a 1% risk per year that one of your racks goes down and takes you 3 9s when that happens, you are really at slightly under 4 9s, but with only a few racks it doesn’t happen most years.
That last one is I suspect what makes it so small scale operators can achieve “5 9s” with a fraction of the engineering of larger operators. You can get a lot of 9s most years because you dodge infrequent risks.
> I’m also skeptical any time someone mentions 5 nines uptime at a small scale. For one, it takes a lot of engineering to be able to actually monitor and detect that with precision (that is, how do you know you are 99.999 and not 99.995?)
We have that in place. We run phone systems that businesses depend on, and we have SLAs that guarantee this uptime in order to secure customers. We have network engineers dedicated to everything from guaranteeing it on the cloud side to checking Wireshark traces for any hint of abnormalities, every day. When I say 3 people, I mean those of us writing the front-end, back-end, database procs, and code that the open-source libraries require, including forking and custom patches. We have other team members ensuring our HA pairs, load balancing, redundancy, fail-overs, and all the other associated technology is working as expected.
I won't get into the details, but we have not violated our SLAs, ever.
And you'd be surprised at what open-source software we are using to drive parts of this system. Kudos to them, they are helping us maintain this with some rock-solid software.
I think you cannot really salvage this argument. The way you describe it makes it sound to me that your company's success is ore likely due to luck and not just competence. It's also not clear if you really think this is a model that can scale to the size of Meta or if you just wanted to slide in a humblebrag.
> It's also not clear if you really think this is a model that can scale to the size of Meta or if you just wanted to slide in a humblebrag.
It can't. It depends on "software services" hosted and coded by "other software companies" so his infra's SLA is basically outsourced to either Amazon, Microsoft or Oracle.
> It depends on "software services" hosted and coded by "other software companies" so his infra's SLA is basically outsourced to either Amazon, Microsoft or Oracle.
It also depends on an incredible amount of in-house custom code.
If I deploy a change that breaks our Angular front-end, or a C# API change that has a typo that routes calls to the wrong places, or a configuration file for our open-source software that handles the phone systems, how exactly do we tell our thousands of customers they can't run their call centers? Or our restaurant customers can't take orders because their phone systems are dead?
Let's not be ridiculous. I'm not humble-bragging. I'm telling you what I do at my job.
> I don't really understand why software engineers keep dunking on each other like this.
I'm not dunking on anyone, I'm explaining my day-to-day job with a very small number of senior engineers.
We run a highly complex system. There's no way we could handle millions of calls with five-nines otherwise.
I won't get further into the details because I don't want to reveal too much PII.
I fully understand how much "behind the scenes" work goes on at a place like Facebook. I'm not sitting here imagining rooms of graphic designers thinking what the CSS button radius should be (although I'm sure with 85,000 employees, those happen also).
But note that Musk walked into Twitter, fired en-masse, and it still seems the same to me.
Yes, there are senior engineers who keep the core functionality working.
That is still far less than 85,000 employees.
In our case, it's 3 of us handling all software development. And we write a lot of mission critical code.
> Even if you only get paged once every few months, you still need to worry about getting paged until your shift is over!
I'm not sure what you mean. A page every few months will be considered world-class achievement in a FAANG-like company. Take Amazon for instance, the oncall is brutal and getting several pagers per day is normal. Other companies may be better, but not one pager per few months better.
When you're on-call, you need to be prepared for a page. That means you can't get drunk with your friends, or get on a plane, etc. Being on-call means being ready to answer a page, whether it comes or not.
> A page every few months will be considered world-class achievement in a FAANG-like company.
Except maybe it's a different beast entirely. At amazon, they're constantly pushing new features at most teams. A stable phone company may just be handling pages for when hardware fails. Presumably there's bugs in fast-moving new code more frequently than hardware failure of a tiny org.
Also, fwiw I've been at amazon and had on-call rotations where we didn't get paged monthly. Your manager/team isn't allowing you to allocate resources to fixing your alarms or bugs if you're getting paged that often and not a crazy critical service.
Years of study are definitely not required to get up and running! I attended a 3 day workshop for TLA+ and spent ~2 weeks modeling a new project that my team was working on. I found lots of potential edge cases that would result in data inconsistencies without even having to write tests or think about how to articulate the issue in the first place, as the model checker is able to output the exact program flow that results in the error.
You still need to make sure your implementation matches the spec, but that’s an easier task than squashing concurrency bugs, let alone figuring out how to repro in the first place! The hope is that by writing the spec you avoid a good chunk of errors from the start instead of encountering them one by one.
You can’t deduct charitable donations unless you don’t take the standard deduction. Instead, you must itemize your deductions. In practice this means you take the standard deduction because most people don’t total more than the standard deduction when they itemize (you have to be decently rich to afford to donate that much!).
Last year you could deduct up to $300 in donations on top of the standard deduction, but I didn’t see it this year.
> In practice this means you take the standard deduction because most people don’t total more than the standard deduction when they itemize (you have to be decently rich to afford to donate that much!).
Charitable donations aren’t the only itemizable deductions.
Ok, I’m sorry for not enumerating all possible itemized deductions when we’re talking about charity specifically.
However, charity is probably the most well-known deduction that you can control (in contrast to stuff like state taxes, which are more or less predetermined). And even among the deductions you control, those deductions require some spending. Can a non-rich person really spend enough to itemize beyond the standardized deduction? If you know how, please let me know because I’ve never gotten close to the standard by itemizing! Even when I’ve had large purchases to compute sales tax for I’m still far away.
Otherwise, it’s pretty clear that, generally speaking, charitable donations aren’t helpful for reducing one’s taxes. I’m sure people donate because they want to, but the tax benefits are not part of the calculus.
This seems a bit extreme. If you can afford to move, does interest rate really factor in? If rates get worse you’ve still locked a better rate, if rates get better you refinance. Besides, there’s plenty of reasons to move besides for a job (and not everyone can work remotely or get a remote job with comparable compensation).
Yeah, you’re going to pay some more interest if you get a new mortgage, but don’t you just adjust your monthly finances and eat it? As long as you can hit your long-term financial goals, the “once in a generation” rate doesn’t seem so important.
Yeah I think the HN crowd is vastly overestimating how much people care about rates. Most people are not perfect financial optimizers - they’ll just pay whatever they can maximally afford per month for a house that most closely matches what they need for their present life. Few people are coldly rate rational.
You only have to look at what people pay for car loans to confirm this.
They care about what they can afford each month. They indirectly care about the rate. The sign on the starter home neighborhood near me was $719/mo when I moved here in 2020. It crept up to 850, 970, 1100, and then they changed the sign to not have that information. Same houses.
Hopefully only sane mortgage products continue to be used so it doesn’t end up like automobile loans. Aren’t most car loans 72 months now? That’s what is required to get the monthly note affordable for most buyers.
It’s not about optimizing it’s about cash flow. If you get a 500k mortgage today at the current rate of ~7% your monthly payment is about 3500/mo. That same mortgage financed 2 years ago around ~2% is a monthly payment of 1800. For the SAME house you are paying basically double the amount per month.
This isn’t optimizing a few bucks per month it’s about not being able to afford the same house.
Every homeowner knows this and if they’ve ever had the incling to move int rh last year theyve done the math and realize it simply doesn’t make sense. People won’t move right now unless life forces them to.
And I think this type of opinion goes too far in the other direction and essentially accuses the common person of being a complete ignoramus.
> they’ll just pay whatever they can maximally afford per month for a house that most closely matches what they need for their present life
Right, and if you ditch a 3% mortgage in favor of a 6% mortgage your monthly spend goes way less far. You're looking at a loan payment that increases by about 40%.
Right, and further not being perfectly financially rational is quite fine! Finances aren’t the only factor in any decision, nor do they need to be the primary factor.
It makes sense why someone who is good at LC via pattern recognition might not be as good at competitive programming. However, it’s not clear why the reverse would be true. Surely someone good at solving unencountered algorithmic problems would be good at LC?
You're right, it's true - if you're good at competitive coding you'll be good at LC. But that's incidental. You don't even need to be a Div 1 competitor on (say) Codeforces to be great at LC - the bar is incredibly low. Just being average is more than good enough at interviews. Serious competitive programmers aim to solve problems much harder than Leetcode. Just look at some older ICPC and Codejam problems.
There are some people who basically just do competitive programming to be good for interviews, but they don't get very far - not even to div 1. They reach whatever bar is necessary to clear an interview and quit immediately. The people who seriously compete to go for ICPC World Finals or to get far in CodeJam, they aren't really concerned with interviews.
That's right. I'm an okay-ish competitive programmer (around 2400 on Codeforces). I haven't played competitive programming for years (though being semi-active in the community, for problem setting etc) and last I tried I can still randomly draw a LeetCode hard, consistently solve in 10-15 minutes max.
The problem is LeetCode is SO BORING for anyone ever tried competitive programming so people usually won't do it at all.
Are those “with a track record of making a difference” also ok with interview tests, white boards, and/or take homes? I don’t know if viewing excessive tests with disdain is a characteristic solely exhibited by ex top tech; I feel like that’s a universal sentiment among top talent regardless of their background. Not wanting to be burdened with unnecessary burden is a good thing!!
I also don’t think people generally have a problem with interviews. You have to be assessed somehow, obviously, and people at top companies still get interviewed when jumping to other top companies. I’ve really only seen serious complaints (that is, beyond mild grumbling) when interviewing is a huge time sink for a specific company, especially when that company’s compensation is lower and/or the communication process is poor (e.g. ghosting).
Why in the world would anyone interview with you if your company offers less than top tech for equal or harder interviews? (Spinning your rhetoric back at you for added effect. I don’t know what your hiring is like.)
Why in the world would anyone interview with you if your company offers less than top tech for equal or harder interviews?
People who need job will apply. Its not like some one is forced to apply when otherwise they could get million dollar a year job to develop deep machine learning AI at Google.
This isn’t necessarily a useful anecdote though. If your previous payment processors weren’t using a bank that failed during that time, then you getting paid on time isn’t a sign of redundancy; they were just fortunate!
It might be fair to say that Rippling failed by choosing the wrong bank, but that’s a very different argument than saying that Rippling didn’t have a good backup plan. If all you’re going by is that you’ve always gotten paid (vs say knowing who your payment processor banked with and what their Plan B in case of bank failure was), for all you know your previous payment processor had no backup plan either!
Yeah I think ADP has one account at the East Piscataway Chemical Savings and Loan. If that bank failed the same thing would have happened to ADP. Rippling definitely didn’t expose themselves to excessive risk for no reason other than their inexperience.
It is also not the case that such people get in without interviews. Senior+ (though largely staff+) is generally when you can make 400k and there are definitely still grueling interview loops at those levels.