Wait, telegram channels have comments?!... я отстал от жизни. That's the main reason I didn't use it. Ok, maybe I'll try to post here more often
ок, вот у этого поста должны быть включены комментарии. Кто-нибудь, отпишите, пожалуйста.
Телеграм сейчас сильно глючит.
Телеграм сейчас сильно глючит.
What parts of AWS Compute do you use?
Anonymous Poll
38%
EC2
4%
Fargate
9%
ECS
6%
EKS
4%
Beanstalk
10%
Other
53%
I don't use AWS Compute
I have a pretty interesting (to me) hiring-related story developing right now, so perhaps I'll be simply recording it here as it happens. I'll start from the beginning though, so it will take multiple days to reach today's news.
The episodes will tell a cohesive story and will build on preceding episodes.
The episodes will tell a cohesive story and will build on preceding episodes.
👍4
Episode 1: Leap.
Throughout my life, my growth is a series of increments and leaps. My most recent leap was joining Google and since then it was only increments: I have been on the same team for 7+ years. I learned to work in a team setting and across teams, express myself in English clearly and convince others, scope and prioritize work, build distributed systems, focus on the user, etc. I grew from SWE III (L4) to Staff SWE (L6).
However staying in the same place has diminishing returns, and at some point the growth slowed down enough that another leap is more efficient. It became clear that it is time to change teams.
At the same time I and my wife finally decided to leave Bay Area and chose Seattle area as the destination. Here, the choice of teams at Google is not as great as in Bay Area. There is Google Cloud team in Seattle, but it felt different from the rest of Google (rumors, exec from Oracle) and it is #3 Cloud provider — I was cautious. There is also Fuchsia OS, which seems attractive, but my life is too short for C++ 😝.
There was one team at Google that I dreamed of joining for years: the Go language team. However, each time I inquired there was something off: too close to promo in my current team, then no headcount in the Go team, then internal tooling support as opposed to the open source part, then they hired only in NYC. I emailed their director again: remote work was OK now, but there were no jobs for my level (L6) — I waited for too long and got overqualified for my dream job 🤣.
Throughout my life, my growth is a series of increments and leaps. My most recent leap was joining Google and since then it was only increments: I have been on the same team for 7+ years. I learned to work in a team setting and across teams, express myself in English clearly and convince others, scope and prioritize work, build distributed systems, focus on the user, etc. I grew from SWE III (L4) to Staff SWE (L6).
However staying in the same place has diminishing returns, and at some point the growth slowed down enough that another leap is more efficient. It became clear that it is time to change teams.
At the same time I and my wife finally decided to leave Bay Area and chose Seattle area as the destination. Here, the choice of teams at Google is not as great as in Bay Area. There is Google Cloud team in Seattle, but it felt different from the rest of Google (rumors, exec from Oracle) and it is #3 Cloud provider — I was cautious. There is also Fuchsia OS, which seems attractive, but my life is too short for C++ 😝.
There was one team at Google that I dreamed of joining for years: the Go language team. However, each time I inquired there was something off: too close to promo in my current team, then no headcount in the Go team, then internal tooling support as opposed to the open source part, then they hired only in NYC. I emailed their director again: remote work was OK now, but there were no jobs for my level (L6) — I waited for too long and got overqualified for my dream job 🤣.
😁6👍1
Episode 2: Domain.
I must clarify that my interest is frameworks/libraries and developer tools, where the customer is a developer. My first piece of generic reusable code was a rainbow-colored button control in Delphi when I was ~14. At NetDec (Tashkent) I led the team to create UZTO framework, a la 1C:Enterprise in C#. Then at ComponentOne, the whole business is to sell software components, e.g. supercharged DataGrid for .NET. Those years my ultimate dream was to live in Redmond and work on .NET or Visual Studio. Then I joined Google where the job is to create the developer infrastructure used by Chrome engineers. I also fell in love with Go, hence the dream to join the Go team; but that didn't work out.
I learned that the higher you go in the career/level, the more important it is to work in the domain you care about. This is because at Staff+ level an engineer no longer can just write code or design systems, but must think about the business side - which is hard if you don't care about the domain of the business. For example, I don't want to go to Facebook or Netflix because I don't care about social networks or movies that much. Chrome isn't perfect either: people come here because they care about the Web - this ended up being the main limiting factor of growth in my team.
With such narrow speciality, there isn't a lot of choice really: if I don't know about a product, then it is probably not interesting. Also, the more developers use the tool/framework, the better; this basically narrows the choice down to the most popular languages, frameworks and tools. There are not a lot of teams like that, so where do I go?
I must clarify that my interest is frameworks/libraries and developer tools, where the customer is a developer. My first piece of generic reusable code was a rainbow-colored button control in Delphi when I was ~14. At NetDec (Tashkent) I led the team to create UZTO framework, a la 1C:Enterprise in C#. Then at ComponentOne, the whole business is to sell software components, e.g. supercharged DataGrid for .NET. Those years my ultimate dream was to live in Redmond and work on .NET or Visual Studio. Then I joined Google where the job is to create the developer infrastructure used by Chrome engineers. I also fell in love with Go, hence the dream to join the Go team; but that didn't work out.
I learned that the higher you go in the career/level, the more important it is to work in the domain you care about. This is because at Staff+ level an engineer no longer can just write code or design systems, but must think about the business side - which is hard if you don't care about the domain of the business. For example, I don't want to go to Facebook or Netflix because I don't care about social networks or movies that much. Chrome isn't perfect either: people come here because they care about the Web - this ended up being the main limiting factor of growth in my team.
With such narrow speciality, there isn't a lot of choice really: if I don't know about a product, then it is probably not interesting. Also, the more developers use the tool/framework, the better; this basically narrows the choice down to the most popular languages, frameworks and tools. There are not a lot of teams like that, so where do I go?
👍1
Episode 3: Google.
Besides the shortage of interesting-to-me teams, my other problem with Google is that a lot of cool people are no longer here: Larry Page and Sergey Brin left soon after I joined, Ken Thompson is on leave for years, Gilad Bracha and Guido van Rossum left. In the past 1-2 years Rob Pike retired, Brad Fitzpatrick and a couple other members of the Go team left to Tailscale, ironically the former SVP of ads left Google to create ad-less search engine, Neeva, and also took Chrome VP with him; two key directors in ChromeOS left; and a bunch of other stories like that. This is a worrying sign and feels like symptoms of a larger problem.
With all these reasons combined, it was natural to start looking outside the company. Fortunately the tech industry is growing in Seattle in general, and in particular there are Amazon and Microsoft headquarters here. AWS is the #1 Cloud provider and Microsoft produces the best dev tools in the world IMO (I've been a fan of Visual Studio since 2008) and also is the #2 Cloud provider.
Timing was good too. It felt like a start of a new chapter: new city, new job. Also Google doesn't pay for my move to Seattle area, because I don't change teams. This was back in May, so I figured that if I manage to land a job in Seattle before the move, then the new company might pay for my relocation.
Besides the shortage of interesting-to-me teams, my other problem with Google is that a lot of cool people are no longer here: Larry Page and Sergey Brin left soon after I joined, Ken Thompson is on leave for years, Gilad Bracha and Guido van Rossum left. In the past 1-2 years Rob Pike retired, Brad Fitzpatrick and a couple other members of the Go team left to Tailscale, ironically the former SVP of ads left Google to create ad-less search engine, Neeva, and also took Chrome VP with him; two key directors in ChromeOS left; and a bunch of other stories like that. This is a worrying sign and feels like symptoms of a larger problem.
With all these reasons combined, it was natural to start looking outside the company. Fortunately the tech industry is growing in Seattle in general, and in particular there are Amazon and Microsoft headquarters here. AWS is the #1 Cloud provider and Microsoft produces the best dev tools in the world IMO (I've been a fan of Visual Studio since 2008) and also is the #2 Cloud provider.
Timing was good too. It felt like a start of a new chapter: new city, new job. Also Google doesn't pay for my move to Seattle area, because I don't change teams. This was back in May, so I figured that if I manage to land a job in Seattle before the move, then the new company might pay for my relocation.
Episode 4: Preparation.
Based on my previous interview experience at Google, I believe that preparation is extremely important. This is especially true if the target job is more advanced than what you do now, i.e. if you leap.
Last time I spent 6 months preparing and documented it in my post. That interview was for mid-level (L4) though, but Staff+ (L6+) interviews are different enough that just following my previous preparation plan isn't gonna cut it. It is not that at Staff+ they ask for more advanced algorithms, ask to write more code or to design rocket ships; not at all. They ask for different skills, not stronger same skills.
There are three types of interviews: coding, system design and behavioral.
- At junior and middle levels, coding matters the most and there is no behavioral at all.
- At senior level, coding is slightly more important than system design. Behavior is sometimes assessed.
- At Staff+, the emphasis is on behavior. Also system design is more important than coding. So overall, behavior > system design > coding.
This is because Staff+ engineers spend a lot of their time in meetings, reviewing designs, rather than writing code 😭.
I have never had a behavioral interview before and I failed one of two system design interviews at Google. My old preparation plan is focused on coding (algorithms and data structures) which is the least important part of the interview at Staff+ level. Thus there was a lot of work to do!
Based on my previous interview experience at Google, I believe that preparation is extremely important. This is especially true if the target job is more advanced than what you do now, i.e. if you leap.
Last time I spent 6 months preparing and documented it in my post. That interview was for mid-level (L4) though, but Staff+ (L6+) interviews are different enough that just following my previous preparation plan isn't gonna cut it. It is not that at Staff+ they ask for more advanced algorithms, ask to write more code or to design rocket ships; not at all. They ask for different skills, not stronger same skills.
There are three types of interviews: coding, system design and behavioral.
- At junior and middle levels, coding matters the most and there is no behavioral at all.
- At senior level, coding is slightly more important than system design. Behavior is sometimes assessed.
- At Staff+, the emphasis is on behavior. Also system design is more important than coding. So overall, behavior > system design > coding.
This is because Staff+ engineers spend a lot of their time in meetings, reviewing designs, rather than writing code 😭.
I have never had a behavioral interview before and I failed one of two system design interviews at Google. My old preparation plan is focused on coding (algorithms and data structures) which is the least important part of the interview at Staff+ level. Thus there was a lot of work to do!