The big two, x86_64 and arm64, have 64-byte cache lines, so that's a reasonable assumption in practice. But I was surprised to discover that Apple's M-series laptops have 128-byte cache lines, and that's something a lot of people have and run, albeit not as a server.
Yup, this is how stuff ends up getting lost and delayed, even if the crews on either side are competent and efficient. Most people can't fill up an 18-wheeler, so some bin packing has to take place for the long haul.
I've done a couple of cross-country moves with a full house and had fairly good luck -- North American Van Lines if anyone is interested -- and by far the best experience was when my stuff was last into the truck making the long distance trip. It was delivered a few days later by the same truck and driver. Nothing was lost or broken. There was no chance to screw things up with intermediate transfers to depots.
"Work 5 shifts per week to monitor the NERSC HPC Facility, which includes 2 - 3 OWL (midnight - 8am) shifts. Some days may be onsite, some may be offsite. The schedule will be determined by staffing needs."
40 hours per week, full salary, full disclosure about the night shifts, but none of this 24x7 wake up in the middle of the night on top of your regular job bullshit that the tech industry insists on.
there's nothing wrong with shift work, and there's nothing wrong with the graveyard shift (for people who want that job), but there is a LOT wrong with alternating day and night shifts in the same week every week, and nobody should agree to do that. (perhaps if you are in your early twenties you feel like you can handle it, but I'm not sure that's a good idea either)
I tried graveyards and swing shifts in my twenties. I only did it for a year, but it wrecked my sleep schedule for years afterward; I struggled with insomnia because of it. Not sure there is any age where this works.
Some people can handle it better than others. I'll never do it again though.
some of the people I know who've made it work, and I'm not recommending this either, are "hardworking ambitious immigrant" types who do it to hold down two full time jobs. tends to be in industries where the overnight shift is a quiet shift rather than something like running the same factory at full tilt overnight.
My natural rhythm makes me a nocturnal being, while the society works 9 to 5. Once I realized this, it became obvious why I feel like fuck all the time. Can't wait to retire.
Shift work sucks more than on call for me. I like having a flexible schedule that I can work whenever I want, and I'll happily take the remote risk that I'll get paged during my one week per quarter on call rotation in order to guarantee that no one expects me to be on during set hours the rest of the year.
I think the problem isn't on call itself, it's that a lot of companies suck at on call. If your rotation is every 3 weeks and you get woken up in the night at least once per rotation, then yeah, that's awful. But the problem you have in that case is that stuff is always on fire and you don't have enough people on the rotation, not with on-call as a concept.
I'd take a night-shift job over being on call ontop of a 9-5.
I think the real answer here is to have team members on multiple continents. Have some team members NA/EU/Asia then it's always reasonable hours for someone to deal with the production problem. High priority issues can be worked on around the clock without anyone working overtime.
That's still shift work. It's still the company assuming that I'll be available during N specific hours of the workday in order to fix issues.
Look at it this way:
If I work a job where I'm expected to be on 9-5, 46 weeks per year, 40 hours each week, that amounts to 1840 hours of scheduling my life around my employer.
If I work a job where I can schedule my work however I like and also have on call 1 week out of every quarter, the worst case scenario there is 672 hours of scheduling my life around my employer (and in practice the demands of on call in my current rotation are far less than that). The rest of my life I can schedule as I please, so long as I do my job.
I would rather take the option that minimizes the number of hours where my employer gets to tell me where to be.
I know plenty of friends (mostly medical) who've had "on call" shifts on top of their 9 to 5, but in those cases it was pretty exceptional for them to actually receive a call, and the "interruptions" would be a small number of hours.
"This was the first leadership interview loop in the past 12 months (20+ companies) in which anyone had asked me to write code."
Interesting data point for the question: at what point in your career will you stop being asked to write code on a whiteboard to prove you aren't lying on your resume.
I’ve never been through an interview cycle where candidates didn’t lie about this, so I assume pretty high. It always boggled my mind that people would claim programming skills but not be able to write hello world.
If its not the pressure cooker, this is trick question and i am going to blast you for missing the return and void in parenthesis types question then we can partially blame the candidate.
Many of us have faltered like this once or twice unless its an outright lie kind of situation.
I’m not a fan of trick questions. It’s usually something as simple as “you have 10 minutes write out a program in any language you like that takes in a string and prints out the reverse.”
The idea is just a litmus test and I don’t think it’s useful for filtering anything other than liars. I never had someone completely freeze up.
You got 21 recruiter messages _with salary_?? Amazing.
I have had almost no luck getting that information from recruiters without hopping on a call. None have ever provided that information upfront.
I only managed to get that info from an Amazon recruiter after pushing the issue pretty hard. At first he bragged that Amazon had upped their bands, without mentioning any numbers. When I asked how much, he pointed to a reddit thread and levels.fyi, still not mentioning any numbers. I finally straight-up asked him to stop being coy and just name the range, after all it's law in California and I'm going to keep asking until I get an answer. It took him a couple of days to respond, then I never heard from him again.
And this is the only recruiter that has ever actually given me an answer. Ever.
How can it simultaneously be the hottest job market in anyone's memory, and yet the process still looks like this? These don't look like companies struggling to hire; these look like companies being exceedingly picky and not suffering one bit for it.
It's where they're applying, I think: "Apple, Babylon, Cloudflare, Deliveroo, Monzo, Spotify, TrueLayer." Don't know anything about Babylon or TrueLayer but most of these are largish, established companies. I've found early-stage startups less picky recently - I got a job at a startup in November that only required 4 video interviews each between 30 minutes to an hour. No whiteboarding, mostly just discussing previous projects. Finally the last (4th) interview was with the CTO where he started by saying: "It's really hard to find people good people to hire right now" and basically said he wanted to hire me and asked if I had any questions.
Have Startup salaries gone up recently to match the market? I had thought it's pretty understood that you are taking a significant paycut relative to established players to basically play the lottery with startup equity?
Startup salaries have gone up a lot in the last few years from the boom in funding. Experienced engineers with several years of experience are clearing $200K+ in base, and getting a solid equity cut too: https://topstartups.io/startup-salary-equity-database/
Appreciate the link. Don't know if you're affiliated with the site but the ability to sort the data would be incredibly useful and the name of the Startup would be of interest as well like levels.fyi
Maybe the other way to look at it is, the "established players" can only employ so many people. Many of them are paying some pretty insane salaries now (I consider over $200K pretty insane) - but as I said, they can only employ so many people. In my case the salary is plenty good without even having to take equity into account. And the work is likely much more interesting than I'd get to do in an established company. Also, if the startup makes it I could be in a pretty good position being able to call a lot of my own shots as to what I'm going to work on and how I'm going to work on it - autonomy.
All that to say, it seems a lot more like a lottery trying to get a job with the established players (after jumping through all their interview hoops), and while the money might be better, the type of work, what you work on, the level of autonomy you're given (or not) is also very important.
I am applying to ~10 companies, mostly start-ups, and they all have the same process. They are mostly not pure algorithms but have varying degrees of difficulty and all use multiple rounds of on the spot coding. Perhaps ironically I found the one purely algorithmic question (standard graph traversal) to be the least stressful.
Because regardless of the hotness of the market 90% of candidates are still completely unqualified for the position they are applying to. Companies would rather keep the role unfilled than hire someone who can't code "hello, world!" (and no, that's not an exaggeration).
That may be a challenge, but if a candidate has years of experience in the software industry then their resume might vouch for some skills. If a developer has delivered features to common tools that many appreciate then how is it possible that they cannot accomplish basic coding tasks? The main problem here is that teams that are hiring often don't even bother to read resumes and so they end up with a process that is expensive, broken, and actually insulting to the most qualified candidates.
That's the point of the interview, to validate the resume by having in-depth conversation about the projects in it.
Note this doesn't mean trying to test for the skills that they must've applied to do those jobs. That's hopeless to achieve in an interview for all the reasons endlessly documented in these threads. Instead, assume that if they did the jobs listed in the resume, obviously they must have the skills to have done them. So now the interview is about validating they did those jobs, not the technical detail itself.
Based on more than two decades of hiring, this works very well.
Yeah, the expectation that _everyone_ excels in leadership and influence leads to some absurd situations, like everyone on a team being "tech lead" for some part of the project. Or the all-"senior" team. Presumably they're all leading each other? Same game goes for cross-functional impact.
The whole point of the separate individual ladder was to give an alternate career path to management. What a lie that's turned out to be.
Thank you for calling out on-call responsibilities in your job listing. Too many job listings today fail to mention that _very significant_ responsibility.
I enjoy working with distributed storage systems, but I don't think I will ever carry a pager for one again. I wish the industry could figure out how to separate designing and building such systems, from giving up your nights and weekends to operate them.
Separating design and build from operate is antithetical to Amazon. It isn’t a “figure out” for a lot of companies including Amazon — it’s very intentional and seemingly unlikely to change. They’ve observed that they create a stronger culture of ownership (which then drives getting things fixed faster and more empathy for the customers) through having the builders also be the operators.
Still needs supportive management: there are teams at Amazon who have time to fix everything which paged them at anti-social hours, and there are teams which don’t prioritize beyond minding the SLA of their COE Action Items, and more silently accrue operational debt and page people more often. Tricky balance to be sure.
Even the ‘SRE’ or ‘PE’ approaches you see at Google and Meta don’t obviate the need for development teams to have on-call rotations. At least in “BigTech” where teams operate services instead of shipping shrink-wrapped software it’s becoming rare to NOT see some on-call responsibility with engineering roles (including management). I suppose it isn’t just on-call, and the other big change in BigTech of the last decade was the somewhat widespread elimination of QA teams and SDET roles, and the merger of those responsibilities into the feature/service teams, and to SDE.
There's different schools of thought around this and I certainly understand your perspective. At AWS, carrying a pager at limited times (in our team, 2-3 weeks per quarter as mentioned in the link) is considered an important part of our culture of operating at-scale services. In our team, we try to minimize oncall burden as much as possible by investing in automation, and only alarm if the system really doesn't know what to do. We have a separate planning bucket for burden reduction every quarter.
Other interesting thing to mention is that as an SDE you're not the only one that has oncall duties. In our team at least, PMTs are also oncall for about the same time. This creates a good dynamic as everyone is incentivized to minimize the oncall burden.
Sort of. Many teams in FAANG put their devs on rotations that aren't full on-call like SRE (and some managers put their devs into full SRE rotations without mentioning there is a bonus). I always check with my future managers that they don't plan to do this.
