The title only so matters to the extent the company is a known entity.
The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.
HN user
The title only so matters to the extent the company is a known entity.
The "staff engineer" at some random series B startup 4 years into their career nearly always gets hired in at mid level somewhere like Meta.
get a lot of junk applications, but frankly, it is your job to sort through them.
But this isn't their job. Their job is to hire someone who passes the hiring bar. If they can do that without ever looking at a random resume everyone at the company is happy.
An unstated thesis of the article is that several years from now people who want to accomplish that job just won't look at resumes submitted online - whatever anyone's feelings about it.
I think the press release is actually clear that they felt this was necessary to retain talent:
Engineers in particular have expressed their desire to focus their time on engineering, without being hampered by slow process flows
I'm guessing ASML had a lot of regrettable attrition and heard this in the exit interviews.
By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.
Stepping back - my experience is that points are solving a problem good organizations don't have.
The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.
I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.
The process is quite easy to implement
Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.
Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.
If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.
is in points not days
I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.
I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.
But in my experience, your manager is expecting you to do all of your assigned role (e.g. write code), but then also do a bunch of stuff on top -- e.g. leading and taking ownership of new initiatives that is extra work.
Aside from AWS, who's famously bad at this, my experience is that this is usually because people want a faster career push.
Imagine Jim, 8 years into his career. Jim is pretty good and his work takes him 30-40 hours a week. If he worked another 5 years in the same role it'd probably drop to 20 and be chill.
Jim wants to get promoted. If he waited the 5 years he could do it working 40 hours a week. But he wants it now, and since he's not as good as he will be he needs to work 60. What does Jim do? He works the 60.
There's nothing wrong with this choice, I made it, I'm happy with my choice. I might make it again in the future, or not.
that got along well with leadership in a fast growing company
I may be reading too much into your post but I'll say that this sentiment is a common pattern I see in many competent senior folks who think they deserve promotions into roles above senior. Getting along with leadership is a huge asset for for this type of leadership role. It means that you stay aligned and push in the same direction together.
If you're not going to get along well with your leadership you need to be much much better than everyone around you - which is a significantly higher bar to clear. And getting along well is a skill. It's usually not the skill people want to learn but it's hugely valuable to be able to be chummy with a difficult exec.
This has always struck me as a pretty juicy deal going for the corporation.
It's a good deal if you deserve the promo. Giving someone the opportunity to take on projects at the next level and having them not deliver can be enormously expensive. The higher the level, the more expensive it is.
You run into other tools you have to cobble together as part of actual work, but you never have to memorize those particular tools
The statement I like to use as an analogy to this one is:
"I don't need to know how to add or multiply numbers, calculators can do it"
This is true in a certain sense, but if you are numerate you know that speed with numbers allows you to do all kinds of quick checks that less numerate peers cannot. It's my experience that colleagues who don't get good at leetcode style problems don't actually understand the skills they've left on the table.
I hate leetcode and that keeps me away from most of the job opportunities
Odds are that until you can get past this mindset, you will hit a similar wall in every career, it will just be less obvious to you that you're hitting it.
Success at most careers means a lot of tedious grinding out basic skills. If you're lucky you like the grinding, but that's rare.
And here's the important part - getting better at this stuff makes the job more fun, humans really like the feeling of mastery. My first 4 years in SWE were miserable because I had no CS background. But I ground really hard on textbooks and leetcode, every minute of which was uncomfortable, and now my career is awesome!
Maybe SWE isn't for you, but whatever you do, commit to the work.
Yeah. For all the excesses of the current AI craze there's a lot of real meat to it that will obviously survive the hype cycle.
User education, for example, can be done in ways that don't even feel like gen AI in ways that can drastically improve activation e.g. recommendation to use feature X based on activity Y, tailored to their use case.
If you won't even lean into things like this you're just leaving yourself behind.
Standards come from a mixture of culture and attention. The reason SF pizza is so much worse than NY pizza is that SF does not have culture of high quality pizza (I say this as an SF native). Conversely we have higher standards for Sourdough. Seoul has higher standards for Kimchi, you get the idea.
Everywhere is like this to some extent - no people can be an expert in all things.
Depends on what you're measuring.
Quite a few of AWS's more mature customers (including my company) were aware within 15 minutes of the incident that Dynamo was failing and hypothesized that it'd taken other services. Hopefully AWS engineers were at least fast.
75 minutes to make a decision about how to message that outage is not particularly slow though, and my guess is that this is where most of the latency actually came from.
Most of your complaints are about things that are not React. Those are optional. I can still standup a vanilla React stack in an afternoon just as easily as I did 5 years ago and immediately start writing the exact same code and have it "just work".
While I get what you're saying I don't think this is what most people think of as "solved".
The brass tacks are:
1. Estimates for the cost of obesity globally are somewhere around 2 trillion dollars.
2. Telling people to diet and exercise usually did not get them to lose weight
3. Giving people semaglutide does get them to lose weight
So many people in my life who were unhappy and struggling with their weight are now happy because semaglutide worked where advice about diet and exercise did not. I can't imagine most rare disease drugs will have that level of impact.
Most standard software engineering jobs don’t require that kind of research activity (although it does require some; product development is a creative process)
This seems to describe what good engineers above the senior level do. Certainly everyone with a PhD I work with who rose through the ranks said that being very senior was a lot like being a good researcher - albeit with much more pressure on execution.
It feels bad as a consumer, but the alternative is usually worse.
The "stop spitting in your soup if you pay us extra" is really efficient market segmentation. If you don't do that you need to find actual value props that separate the market in just the right way to generate the financials that allow the product to keep going as is. 9 times out of 10 the result is that failing PMs totally fuck up the product and everyone loses.
It's the SSO kerfuffle in a different package - terrible, but the right choice surprisingly often.
I imagine most people have the same value prop I do
1) I watch youtube more than any streaming service
2) I really really value not having ads in my life
So the price for ad-free youtube really seems phenomenal. None of the other features really matter to me - ad free dominates all value discussions.
I wish the article talked more about why people use Redis as a rate limiter and why alternatives might be superior. Anecdotally I see the following play out repeatedly:
1) You probably already have Redis running
2) Adding a "good enough" rate limiter is easy
3) Faster solutions are usually more work to maintain given modern skillsets
If you are a b2b SaaS company odds are your company will exceed 10 billion in market cap looong before Redis rate limiting is a meaningful bottleneck.
This is so much better than a decade ago! No underhanded "we're a family" - the company says "you will work 60 hours a week and take a big risk" and employees can say yes or no.
others you get an extra 1.5mm to sit at the computer for 2 hours a day and then take a nap
A few of the most world class reserachers can do this, all of my other friends and colleagues at OpenAI work 10-14 hours day - often 7 days a weeek.
OpenAI pays eyewatering sums but you're absolutely sacrificing years of your life for it.
I've read a lot of blog posts making this same argument for a year "Cloud makes 80% margins! You're fool for paying them!" and I think they show a lack of curiosity as to why so few companies paying 9 figure cloud contracts feels incentivized. That's a huge incentive for a director looking to make their mark right?
In fact we have an example of a company that spent years moving off cloud - Dropbox - and the company has been stagnating since - so this isn't some "easy win".
If you talk to smart business leaders you'll hear the main 3 points come up over and over: cloud offers three huge advantages that are worth incredible margins to many companies:
1. Your business can scale existing or new workloads very quickly
2. It frees up organizational focus for your customer's problem
3. It's easier to hire cloud skills for than bare metal skills
You'll note that improvement on all of these are a trade of money for more time and lower risk. Put in those terms I hope it's not confusing why we continue to pay cloud provides.
Managing down isn't actually that hard to get the hang of if you have strong technical skills and reasonable communications skills. But managing down is very similar to being a good teaching professor: absolutely worthless and largely done at your own peril.
To your earlier point - even this is contextual. Incredibly high performing teams tend to be really hard to retain. It's not that hard to make your bosses love you if you're posting wildly out of band results - so the struggle is making sure the people who are actually making that happen stay on and stay engaged.
(I'll note that some of the most successful managers I know built their career on creating playgrounds for a small number of high performing ICs)
I have - it works.
I can also assure you that despite the 100s of applicants hiring remains hard even with competitive market compensation. Filling a generalist senior eng headcount with $500k liquid total compensation can take months. Many engineers have wildly inflated ideas about their own abilities.
This has never stopped working for me - I interview every year or so as a matter of course.
My experience helping others is that in a tightening labor market they are experiencing "small fish in a big pond" syndrome mentioned above.
Compensation for the bottom 50-75% of talent has dropped significantly since 2021* - if you are in that band and chasing the same comp you're dealing with the "small fish in a big pond" situation. If these people drop their compensation expectations back to 2017 levels many of them will find jobs much more plentiful - though the very bottom of the pool is being driven out of the industry entirely.
* this estimate pulled from conversations with engineering leaders and recruiters at large SV tech companies
I had to answer within 3 days.
If you re-read the transcript, I hope you will come to the understanding that this is a lie. The company is trying to leverage your desperation for a job.
Last time I got a job offer the hiring process took ~4 months with seven steps
Just like increased compensation, gettting the timeline you want requires leverage. When interviewing I always communicate that I expect an offer from a peer competitor within the next few weeks - this expedies my interview process. I always end up with a minimum of 4 competing offers to use as a BATNA.
Something the article winks at here is that negotation has only a small expected payoff if you've navigated your career such that you're a "small fish in a big pond" so to speak.
Someone who can barely pass a FAANG interview likely can't negotiate much with Google but probably could negotiate at lower tier company like SAP.
*edit* I do this strategy 12-18 months whether or not I leave a company, it has never failed me
This is situational - as a strong engineer I have more leverage than ever to demand ever more eye watering compensation.
Weaker engineers and junior engineers are in more the situation you describe. This is tough and I feel for these folks but it is possible for many people to become stronger engineers if they choose to put in the work.
I'd encourage you to not take on a feeling of hopelessness here.
my impression is that they try very hard to have a consistent work culture across the company
they do - and they fail!
A truism is that your manager is the biggest determiner of your work environment. This is just as true for your manager as for you. To that end, your director/vp has a really outsized influence on the people you interact with the most (and thus define the experience of working at the company for you).
If you're like me and love talking to people you'll find a huge variation in the lived experience of people working these jobs.
E.g. Amazon, Meta etc. have terrible work cultures
This is like saying "Switzerland has a terrible work culture". These companies are literally the size of a small country - culture ends up being much more fine grained.
Anecdotally - most people I know at Meta love working there - fewer people love their jobs at Amazon, but many of them enjoy it. I've enjoyed all of my own big tech jobs despite much public griping about what it's like to work at these companies.
I'm not saying my network is represnative - but my experience strongly suggest the following:
- the way you experience work culture at a company is much more determined by your director/vp (e.g. the 50-200 person group you're most closely tied to) than the overall company culture.
- many reports of a toxic work culture are really just cultural mismatches. At scale, this means it's easy to read 100 stories of a bad match and treat it as toxicity.