Two small reasons to consider working at a company that has a high-quality engineering blog:
1. A sign of a transparent engineering culture (important!)
2. Some of your work & impact can become public (writing on the eng blog), possibly creating future opportunities for you.
High-quality eng blogs:
- Share in-depth details about eng challenges, approaches, learnings.
- Talk about (internal) tools used & specifics. Often with screenshots, code samples.
- *Always* display names of the engineers authoring the post
A company with a high-quality engineering blog typically:
- Supports engineers attending engineering conferences, talking about their learnings
- Has much larger internal awareness of who does what ("have you read their blog post?")
- Can attract industry-known talent more
On the other hand, my experience with companies who do not support engineers blogging (and don't have an eng blog):
- Often have nontechnical leadership
- Can forbid sharing of "internal" details: even if it's purely tech
- Can ban engineers speaking at conferences, podcasts etc
One of the reasons I was able to share so much of what I worked on at Uber, my lessons learned and others was... because much of it was all public, on the engineering blog.
Compare this when you work at e.g. Apple. No coincidence they don't have an eng blog. Different culture.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I've been tiptoeing on software engineering compensation in the Netherlands and Europe because... I was on the high end of it. Me and many others.
I'm starting to talk about how this system works, starting with why compensation is "tripolar". And why this is important (cont'd):
Silicon Valley is having a *huge* effect on the market going up. It might also help reverse people leaving from the EU to the US to make massive salary gains, now that the "top of the market" is going up. By a LOT.
Don't take how important it is to talk about salaries from me. Take it from a DM from a person who told me he wished he knew about these things *years* earlier.
In the best engineering organizations, engineers tend to get a lot of support from managers. And it works!
But I've yet to see a place that gave *proper* support for the frontline managers supporting their teams. It works for a while: until these managers burn out and leave.
"Proper support":
- Mentors in the org for line managers
- Team meetings with the "manager team" that's both a safe space to vent, and to take action
- Involving EMs in top-down decisions that will hit their teams
- Running retrospectives with the EMs, and acting on them
While I know a *lot* of frontline engineering managers who are amazing at taking care of their team, managers of managers and directors suddenly "forget" to do the same with their EMs.
Directors will often assume EMs don't need this. On the medium- and long-term: they would.
LinkedIn built their own crash reporting solution, and explain why they did it, and what benefits they saw.
2. At Uber, similar to LinkedIn, the mobile platform team built an internal crash reporting tool called Healthline that supported signals like ANR, non-fatal, OOM and memory leaks.
It was/is a really nice tool, with many internal integrations.
The engineering career framework for @prezi, with typical post-college experience years of experience, as shared by their former CTO. He's talking about what makes for a good software eng growth framework.
They settled on 6 levels to allow for enough space for growth.
They created an internal tool so people can browse definitions & examples, and for people to be able to rate themselves.
Engineers started to rate themselves, and use it as a starting point for career conversations with managers.
It worked out FAR better than they expected.
Promotions, merit increases are pretty standard (note to self: I'll share some details on this for non-EMs).
Promo committees are what you'd expect from a "modern" tech company their size.
Uber used to have more eng-heavy, as well as more manager-heavy committees:
Today’s episode of of practical software engineering tips & tricks: load testing 3rd party services/APIs in prod.
Aka how we made sure Uber’s payments providers would also be ready for the New Years Eve surge in the early years. A thread.
Up to around 2018, Uber saw a 5-10x traffic spike on NYE. Funny enough the spike would become the new “baseline” traffic for the next September.
But the first few years this spoke would nearly cripple the company. So we started preparing ahead of time and load testing the fall.
After we’d load test most internal services and ensure they’d cope, the next failure vector: 3rd party services.
We knew what would happen on NYE and were on standby. They had no clue and though assured over email they can take a 10x load... let’s say it wasn’t always the case.
For anyone looking for their first job in tech: it’s a beast to get - including the first in a new country.
The story of how I was a week or two away from leaving the UK, failing to get *any* response from recruiters, despite having years of work exp and a stellar CV. Thread.
I’m from Hungary and graduated top of the class at Budapesti Műszaki Egyetem with a degree in Technical Informatics. You probably never heard of it: neither have recruiters.
It’s the #1 CS college nationwide - perhaps phrasing it like this might have helped.
I worked fulltime for 2 years as a web (.NET) developer and placed #3 worldwide at Microsoft Imagine Cup 2008 - from 200K contestants.
A pretty good resume, if I might say so.
Odd enough, applying remotely for .NET positions in the UK for no responses. So I packed up and moved.