Having a mentor will help you grow a lot – usually your mentor is your local TL but there seems to be some kind of hidden expectation that you can only have one mentor. I’ll get straight to the point, you can (and should if you desire) have multiple.
Becoming a mentor isn’t becoming some kind of lord – it’s not even an official role. Some people might be mentors without knowing it (e.g. I think good and nice senior engineers will naturally be mentors for others).
Most of the time, your mentor is your local TL since they are close to your work so they can go deep about technical details with you and are aware about your work environment (e.g. product priorities, organization process etc.). I think it’s however useful to have more distant mentors:
- From other companies – these can give you more perspective on what other process/technical solution may work. Note that something working at doesn’t necessarily work for your company but they are good to know
- From other technical domains – engineers tend to have expertise in specific topics, and for example the best way to learn about network challenges is to have a mentor who specialized in network
- From other functions – as an engineer, you can learn a lot from product managers, project managers, product counsel etc. These folks see the world in a different way and it’s very interesting to understand how they operate
I personally had the chance to have a lot of mentors during my careers – interestingly enough I didn’t have any formal relations with most of them. Some were just peers that I would chat with at lunch, some were just coworkers in other orgs that I interacted a lot with and some were just friends.
If your mentor gets offended that you are learning from others, you just have a toxic mentor.
LinkedIn post
ORMs (Object Relational Mapping) get either a lot of love or a lot of hate – people usually love them because it’s a higher level API than directly hitting the database – so they don’t need to know the exact names of the tables involved, which keys are used for joins etc. Others hate them because they potentially hide SQL issues (e.g. join operation done without index).
I personally think that ORM provides a useful and interesting layer of abstraction if used right. Beside hiding some complexity from engineers, I think ORMs create an interesting and useful layer of abstraction, and more importantly an important choke point – you can do company wide changes in your database without having to deal with thousands of call sites/SQL queries. You don’t necessarily need one straight away, but you may consider it (or a similar layer of abstraction) when your org reaches a certain size.
Having a higher level API means you can roll out a caching infrastructure without requiring every product/service team to know about the change – all the complexity of freshness/eviction can be hidden from engineers who focus on other engineering issues.
It’s however important that the ORMs are properly used – and that engineers don’t shoot themselves in the foot. For example, ORMs should also enforce that you can’t join two tables without using an index.
I personally think that it’s unreasonable for every engineer to be an expert in database – e.g. I don’t think it’s reasonable for every engineer to know about how MySQL cache operates. I think part of the push back against ORMs is also just misplaced pride – interestingly enough, I’ve never heard people complaining about privacy policies being hidden from engineers day to day work but hiding SQL complexity is a problem.
Thoughts? How do you feel about ORMs?
LinkedIn post
While I was at Google, everyone’s level was public by default. One could opt out of showing their level but the vast majority of engineers had their level public. I recently learned that now levels are hidden by default – it’s unclear why though it looks like it was tied with a migration of the tool displaying levels.
My personal take is that levels should be public:
- It’s useful to calibrate expectations – e.g. you wouldn’t throw a new grad on a company wide outage by themselves, you would make sure they have enough support for them to be successful. You basically end up working in a more efficient manner.
- It’s better for people’s growth as performance expectations are better calibrated – e.g. one bad situation that can happen if you try to go for promo but one of your peers thought you were one level lower – and they never had a chance to provide feedback on what you were lacking.
Eventually people will figure out your level, hiding it just makes the initial interactions more difficult.
On the other hand, it’s important to acknowledge that someone’s level is a very broad performance signal – you can be underperforming at a given level or be close to the next one. So we shouldn’t anchor too much on someone’s level but just use it as a broad signal.
LinkedIn post
In a large tech company, the fastest way to increase your comp is to get promoted. You may get a slightly bigger comp increase if you ask for it, but it likely won’t be significant.
In big tech companies, compensations are automatically computed based on a magic formula mostly relying on location, level and rating. Once the initial numbers are out, managers have a bit of leeway to adjust comp as they see fit but the usual adjustments are peanuts (at Google, it was about a few thousands dollars per year across a whole team).
If you are really good and a flight risk, you may get a large one-off compensation increase (e.g. you may get paid your L+1 level even if you’re not officially at that level). But this is very rare and usually restricted to fairly senior engineers.
Switching job will give you a short term increase, but won’t last on the long run – the simplest proof is that nobody reached a Meta E8 comp by switching companies every 2 years 🙂
LinkedIn post
