Nodir.log

Episode 17: Finale.

About a month ago I've written a post about Outtalent, a startup that helps folks from around the world to join FAANG. Apparently my post generated considerable amount of candidate traffic, so @tilekgram, the founder and my friend, was very grateful. One of the services that Outtalent provides is TC negotiation guidance and it might increase compensation quite a bit. When Tilek heard that I will have negotiations soon, he shared their negotiation materials with me and created a telegram group with the Outtalent negotiation specialist Ana. She interpreted all TC-related emails from recruiters, drafted my emails and prepared me for phone calls: what to say and not to say, how to behave, when to show/not-show emotions, etc. I honestly was completely clueless in this regard.

Meanwhile, the Amazon recruiter was pushing for a decision and hinting that they might be about to bump TC more if it speeds up the process. When I shared my Google counteroffer, the recruiter pushed back a bit. In my head I was like "yeah, he is right", but Ana deciphered that the push back email did not actually contain any strong arguments against increasing TC, and came to the opposite conclusion — we must push forward (I couldn't see those clues myself). She drafted a response and prepared me for the final/critical phone call. It went much better than I expected: It seems the recruiter, the hiring manager and comp team were so tired of this taking so long that it took literally one day to approve the TC I shamelessly asked: it grew to 192% of my current TC. 🤯😂 Thanks Outtalent for extra cash! 🙏🏼🙏🏼🙏🏼

Today I signed the Amazon offer letter, submitted my resignation letter at Google and told my coworkers. I will be joining AWS ECS org as a Principal Engineer (L7) on October 18. I anticipate first few months at AWS to be tough because this job is a jump in the level. My new goal is not to get fired in the first 6mo 😅.

I am deeply grateful to everyone who helped me with mock interviews, prep materials, career discussions or just lending an ear. Thank you! 🙏🏼

This is the last episode. Thanks for reading 🙂.

Episode 16: Decision.

Suppose MSFT follows through with a good TC: what other dimensions should be considered in the decision? Are there any biases that I am falling a victim of?

Is my impression of .NET based on potentially outdated 10y-old good old memories? I called my old .NET friends and they told me that .NET got even better, and that C# is way ahead of Java as a language now (hopefully this will not cause a holy war in comments), but of course there may be selection bias here (these are .NET friends). I also learned that many switched from Visual Studio to JetBrains' Rider, but selection bias again — my friends speak Russian.

Am I just clinging to my past too much, trying to achieve college dreams, being afraid of stepping out of my comfort zone, and thus limit myself? Sure, stdlibs, runtimes and GC always fascinated me, but maybe its just my thinking got stuck in the previous decade, while the world and new generations have moved on to the Cloud. Am I falling a victim of Availability bias? For a true leap (episode 1), one must be ready to jump to something completely new, no?

To challenge the potential availability bias, on Thursday last week I spontaneously drove to the AWS building in Seattle. It is a gorgeous set of skyscrapers and huge beautiful receptions. I've been missing the city vibe since I left Tashkent — other than SF, Silicon Valley is pretty flat; and so is Redmond. I tried to picture what would day-to-day life be if I work here. The commute was fine, and also there as Amazon shuttles — I hate sitting in the traffic doing nothing, while I can work on a shuttle.

And then I spontaneously called my Amazon recruiter and took him to lunch to his favorite local restaurant. We talked about all kinds of stuff. He shown me various Amazon buildings and who sits where. Jokingly I asked him where the Infinidash team sits and we talked about Corey Quinn, and how one of the buildings is named after users that pay $0.05/y, but provide feedback worth millions.

When I asked how much time he has, turned out he is done for the day and will go pick up his kid. I was surprised because it was only 3pm — quite a contrast with what I read about Amazon's stressful culture where people work night and day, and one of my concerns for the first few years in Amazon. Apparently he picks up his kid everyday at 4pm. He then proceeded to give me other examples of how high-level engineers work, how EC2 co-creator didn't miss a single football game of his son, and about the art of not stretching yourself thin. I kept our conversation light, but in the end I told him that Google made a counteroffer, because I figured that MSFT. He responded that if it helps me to make the decision faster, he can take the counteroffer to the compensation team.

On Monday this week MSFT recruiter called me. Apparently my case was exceptional because I applied for one job, but then they were trying to make me an offer for a different job without making go through another interview loop. They had to jump through a series bureaucratic hoops to make it happen. In fact, she still didn't have approved TC, but because I've been pressuring them to hurry up, she was willing to share an approximate number that could get approved.

She said they cannot offer level 67, but only 66. Accordingly they offered the TC of ~1.28C where C is my current Google TC. Its better than my current pay, but the latter is no longer relevant given the offers; and MSFT TC is 30% less than AWS TC. I love .NET, but not to that extent. A few more email exchanges made it clear that MSFT isn't low-balling me, but they just don't currently have a job in DevDiv that would justify level 67.

Well, I really tried, but MSFT left me no choice. AWS it is! ☁️✅

There was just one thing left to do: use the Google counteroffer as a leverage to potentially bump the AWS TC even further. I mean, 1.83C is a ton of money, but still it is silly not to even try using a leverage when you have one. Till the next episode 😉

Episode 15: Surprise.

21 days after the MSFT interview I lost my patience and politely DMed the hiring manager. I figured that I didn't fail the interview, because otherwise I'd already get a NO by now (timing attack). I asked if the process is slow because he is hiring a team, so hiring decisions are interdependent. Or was it a job:level mismatch? I happy to help with .NET too.

His response was that I did "extremely well", to the point that they were worried about job:level mismatch. In the past weeks they gained a better understanding of Go toolset role and eventually decided there is not going to be enough scope for "my capabilities". Apparently his boss has been looking for another job for me in the .NET org since the interview and someone will reach out soon.

Wow, a plot twist! Flattering, but I wish they didn't keep me in the dark for 3 weeks! Their comms are so broken. Well, looks like I am overqualified for Go again, now in another company 🥲. I tried... Alright... Golang just ain't gonna happen.

On day 27, I met with a different hiring manager and we exchanged emails afterwards. The role is to own all of .NET performance, working with customers (Bing, M365, Azure) and various .NET teams to improve perf of their libs; be accountable for perf infra and still write code. I asked "if someone complains to Scott Guthrie about .NET perf, will I be responsible to handle this?", she said yes — that's a big responsibility. Re growth: I can have a strong mentor and I'd be working with the .NET performance architect. One downside: have to manage 5 engineers.

This gave me a new hope: .NET perf is on the critical path of Azure's success: higher perf => lower Azure costs => lower prices for customers => faster business growth. MSFT builds their own services on .NET, and they continue to invest in it. This role has enough importance and scope to justify paying good money. Optimizations are generally rewarding work. I also learned that .NET Core and ASP.NET Core are the most loved frameworks for 3 and 2 years in a row, respectively (2019, 2020, 2021).

I asked Jaana to connect me with David Fowler and he described the role from his perspective, as a customer. I synced with one of my interviewers who recently became a manager and he shed some light on his manager experience, how far he is from coding, etc. He also named 3 Partner architects in .NET: Jan Kotas (runtime), Maoni Stephens (GC) and Stephen Toub (libs) — I assume I'd get to work with them. BTW, I read Maoni's articles on GC maybe 10 years ago, glad she is still there. Interesting role... has everything: large scope, ties to business, coordination across many teams, infra work, writing code and diving deep to optimize perf. Sounds like a good role to figure out my strengths and go further in that direction.

The main missing info are level and TC — nobody said anything and I could only guess. Level 66 don't get paid what Amazon offered. Level 68 is way too high: the hiring manager is less than 68, so a 68 wouldn't report to her. The only level possibly satisfying these requirements is 67.

After that burst of activity, came another phase of excruciating silence. On day 28, my recruiter connected me with a different recruiter who specializes in Principal hires. I thought "Oh, she must be just like my Amazon recruiter who is not bogged down with hundreds of candidates! It will go much faster now!". Yeah, right... didn't receive anything from her to this day 😑

On day 34, I lost my patience again because of zero communications, figured MSFT is unlikely to offer more $$$ than Amazon, so to avoid wasting time on offers that I'd decline anyway, I emailed them what Amazon and Google offered. On day 35, I received "appreciate your patience, we are working hard, blah blah" without any sense of time frame/ETAs.

To be fair, I am partially to blame here: I applied to a low-level job and their hiring process broke down, but even with that everything seems extremely slow. I don't understand how can one succeed in business without ETAs/deadlines.

Episode 14: Growth.

Microsoft was completely silent for 2 weeks and this started driving me nuts. I pinged the recruiter saying that I passed the Amazon interview at PE level, that my previous compensation expectations are no longer relevant and that Amazon pushes for a decision; got a quick "Thanks, I will get back to you" and silent treatment again... 😤

At the same time, Amazonians have been engaging with me actively. The hiring manager described my first project and was ready to involve another PE to help me with onboarding. The recruiter told that the EC2 co-creator could be my mentor 🤩 and others would help me in areas where my skills aren't strong. Jaana described her work more, and that she collaborates with Senior PEs and Distinguished Engineers on weekly basis 😮. This is awesome because it means I'd get to learn from them — I never want to be the strongest on a team. I also learned that PEs+ are treated specially in Amazon: it is separate class of headcount.

Google offered more money for an easier job and the autonomy of working on whatever I want in my current org. Amazon is known to be very demanding, and it will be especially hard for me because it is a level up. There is a very real risk that I will fail/burnout in the first year, while there is no such risk at Google. But still, my strategy has always been to optimize for the long-term growth, so its hard to pass on the opportunity to learn from the EC2 co-creator and various Distinguished Engineers in the world-fastest-growing business — Google did not offer me that. Yes, first 2y at Amazon are going to be tough, but I work a lot anyway. If Amazon made a mistake hiring me, it means my learning will be even more rapid, so I decided that Amazon's high-risk high-reward deal is better than Google's safe counteroffer.

At this point I was pretty sure that I will join Amazon. At Microsoft, the job needs a Senior engineer and they did me a favor of considering me for a Principal. I'd be just one of engineers in a small team, while at Amazon I'd be supervising multiple teams. Given that the job at MSFT is much easier, it is hard to expect Microsoft to pay me anything comparable to Amazon. As much as I love Microsoft and Go, the pragmatic me cannot pass on a pile of money and unique learning opportunities.

Still, I am not a fan of jumping to conclusions, so I continued to wait patiently...... 😑.

You might have found this episode somewhat disappointing because there is not a lot of news, and that's exactly how I felt about MSFT recruiting process: I wait and wait for something to happen every day and NOTHING happens. Hours go by and I reach the end of the day without receiving anything, for days and days. This suspense is killing me 😤🤬. What would you do?

Episode 13: Money.

I've been waiting for interview responses any day, constantly checking email on my phone for the whole week since the interviews. On Friday the Amazon recruiter wrote "The team just debriefed and after a rigorous discussion recommended that we extend a principal engineering offer to you".

Holy shit!!1 Did I pull this off?! I was Senior Eng just a year ago, and now I get to be a Principal? That's two promotions in one year. Granted, I procrastinated my promo to Staff by ~1y, but two promos in two years is still a very rapid growth — am I gonna handle that? Was I simply over-prepared for the interview, and my interview performance was not really representative of my actual day-to-day capabilities? Looks like I fooled at least 4 interviewers out of 7. I couldn't believe his email until we spoke on the phone next Monday.

On the phone call the main question was compensation. One thing about negotiations is that you should collect as much info as possible, while giving away as little info as possible. In general you should be evasive and vague and TBH I hate these games... I tend to tell people what I think directly and honestly, sometimes too honestly (although I got better at this), and that's the exact opposite of what was needed here.

Given that this is the entirely new level for me, I didn't really know what compensation to ask for, so I asked the recruiter to make an offer based on my interview performance, e.g. median of the level. He told me what's the current median Total Compensation (TC = base + bonus + stocks) at PE level in Seattle, but also explained that apparently Amazon hires external PEs only if they are better than 50% of existing ones, and have a potential to go to the next level (WAT?), suggesting that I should be asking for more than median. I said I need 2 days to think about it, hoping that Microsoft that will respond too and my ask will be more informed.

After consulting with another PE at AWS and NOT hearing from MSFT, I continued the "fake it till you make it" tactics and boldly asked for 125% of the median, with a rationale based on "better than 50%". That was a lot, and after a bit of back and forth, the compensation team approved the TC of 1.83C, where C is my current Google yearly TC in Seattle. Yeah, that's fucking 83% more than what Google pays me! Crazy 🤑. It means we can finally buy a house easily and I can replace my old sluggish Nissan. Perhaps it also means that I was staying in the same place for far too long, and lost a lot of money by not earning them in a different place — I am rationalizing this now, but at the time I was like "is this for real?!". 🤪

I emailed the two startups that I am no longer interested in bit.io CTO role, and asked warp.dev founder if he can afford paying so much. Startups pay mostly in stocks that will grow one day, but I need a house sooner, so I had to decline warp too.

Apparently Google can do quite a few things to retain their employees — the only thing they cannot do is to increase my level just like that. My director coaxed Hiroshi Lockheimer to make me a counteroffer of one-time stock grant for the amount of 2.56C, vesting monthly over 4 years. That's purely on top of my current TC, so increasing it to 1.64C. Given that Google stock grows faster than Amazon and that my Google TC would grow a bit in November, Google was offering more money for an easier risk-free job. The only condition is that I stay at Google (don't have to be on the same team). Still, the choice between Google and Amazon is not as clear as it may seem and I will go over it in the next episode.

Given that normally I make 2.56C in 2.56 years and that it took me 3mo to prepare for the interview that earned me 2.56C, these 3mo were quite literally 10x more money-productive than average; fastest money I ever made. Many of us should be doing this more often 😀.

With two offers on my hands and increasing sense of self-worth, I continued to wait for Microsoft...

Episode 12: Amazon interview

Amazon interview was 2x more deliberate than Microsoft: 6.5h with 7 interviewers + a writing exercise offline.

Principal Engineers write a lot of docs that are read by many people, so a part of interview is to assess your writing skills. The writing exercise is a 2 page narrative that should avoid bullet points/sections. It is assessed for clarity of thought/expression (i.e., did you explain your point well?) and organization/structure (i.e., does it flow? does it make sense?).

The essay must be on one of two given topics. I had good stories on both; one of them is a bit nuanced — it would be cumbersome to explain it verbally (I could mess it up if I tried). Thus I chose the more nuanced story for the writing exercise — this enabled using this good story without a risk of screwing it up, and this was an opportunity to demonstrate my ability to explain something nuanced in a narrative that flows.

I was asked if I want to do 6.5h of interviews in one day or span to two. Obviously I chose two, for my sanity, and to be able to reflect on interviews of the first day, learn my lessons and apply them on the second day.

I had 7 interviewers: my hiring manager, my recruiter, 3 Principal Engineers and 2 Senior Principal Engineers 😲. I did not stalk Amazon interviewers as much as Microsoft. All but one interview were one hour long. I won't list each interview, but here a couple that stuck out:

1) Sr. Principal on dev tools for internal teams. Full hour for design of a system I built. Two things caught me by surprise:
- I expected to do a system design of a hypothetical system, not a real one. I had to quickly decide which of the two systems to describe. Later I regretted my choice.
- The diagram app that Amazon suggested to use (awwapp) stopped working, or at least I could not get it work. I had to quickly switch to excalidraw.com instead and did not regret (nice hot keys).

2) The recruiter assessed me on interpersonal LPs for 30 min, primarily earn trust, hiring and develop the best, and insisting on highest standards.

3) Principal Engineer who shipped AWS Wavelength. 30 min LPs and 30 min coding. The coding problem was interesting - there was a bit of graphs, but mostly it was about concurrency — a crawler in a single process. I used Go, so concurrency was pretty easy. I used packages errgroup and semaphore and almost used sync.Map. Coding was fun, as always.

4) Sr. Principal Engineer, co-creator of EC2. He was Principal Engineer when I only started coding in school, and he has an extremely serious face expression on his LinkedIn profile -- I was pretty nervous... but in reality this was the most fun interview because it was the most technical.

He asked me to implement a simple flood fill algo on a bitmap (matrix of 0s and 1s). I typed it up quickly -- I guess this problem was to ensure that I can still code.

Then he gave me a class in Java to review. The code was (intentionally) shitty: hard coded connection string, login and secrets; violations of the SRP, poor Java API, not closing resources (connections, record reader), sequential RPCs, SQL injection, fetching data from DB and then not using it, doing aggregation locally. I asked what kind of primary/secondary indices exist, how data is organized physically, whether the db engine supports UDFs (one of the aggregation functions was a decay func), etc.

5) Two more PEs spent 30min on LPs, and 30 min for a design of a hypothetical system. I emailed one of them with more design ideas after the interview #yolo.
————————

Overall, 6.5 hours:
- 2h=1+0.5+0.5h of SDIs
- 0.5+0.7h of coding
- the rest is LPs

Amazon interview loop certainly felt tougher than Microsoft, but still I felt good about it, especially when an interviewer reveals their satisfaction from the conversation.

This was 1w after MSFT interview. Microsoft/Amazon promised a response within 2w/1w, so I expected both results at about the same time.

Episode 11: Microsoft interview.

Late July. We just moved into our new apartment on Friday, and next Friday, which was also my birthday, would be my Microsoft interview. Our new place is 10 min walk from the very Microsoft building that I'd be working in, so I took evening strolls there, standing before that building and visualizing that pretty soon I can finally accomplish my 15 year old dream of living in Redmond and working on dev tools at Microsoft, not too far from people like Anders Hejlsberg who created the languages I grew up on. The sense that I'm sooo close and imagining that it already happened, inspired me and helped with nerves ☺️.

Given the importance of demeanor in this interview, I also followed the advise of my therapist to use a standing desk to ensure a good posture, open chest, higher chin, and other funny stuff like that to maximize my perceived confidence. I didn't want to take any chances 🤷🏻‍♂️.

At this point you might have noticed that I tend to over-prepare. When the Microsoft recruiter told me the interviewer names, I went on a stalking expedition trying to figure out what they might ask. For example, for one interviewer the only info I found is his papers on .NET GC and memory mgmt, so I went ahead and learned Go GC and memory mgmt. Another one is leading .NET assembly loading, so I brushed up my knowledge on process startup. I also prepared good questions for each interviewer -- in hindsight this was the only useful part of this stalking.

The morning of my birthday I spent with four interviewers.

1) ASP.NET group manager. 35min behavioral and 20min for a tough algo problem about mex and interval tree (I didn't write code). The follow up was making it a distributed system.

I asked him what processes does Microsoft have to get things done across teams.

This interview was the toughest one and I wasn't sure about my performance. I couldn't help but wondered if the interviewer wasn't in a great mood: he didn't know he would be interviewing someone until one hour before the interview, and this was 9am (my hiring manager got stuck in an airport).

2) Rust team manager. 30 min behavioral (including my biggest invention) and 30min on a trivial coding problem (reverse first K nodes of singly linked list in O(1) space). He let me code in my favorite editor (VSCode) and just share my screen.

I drew a parallel between Rust and Go teams (both langs are external to Microsoft), and asked him about the size of the Rust team, where they contribute more and where the work is coming from. Soon after the interview I realized that I forgot to say something, figured out his address and emailed him #yolo

3) VP of platforms and languages. Full hour of behavioral questions. Knowing that his opinion is going to matter a lot, I strongly expressed my true enthusiasm about Developer Division from the start. Surprisingly he knew Goma, Chrome's compilation service, which was in one of my stories.

I asked him what's his vision on the Go team for the next 3-5y, and how long would they report to .NET folks.

This interview was the most fun. I messaged him on LinkedIn with a follow up clarification too #yolo. BTW I never spoke to a VP at Google.

4) .NET Native AOT manager. 30 min behavioral and 30 min system design, but completely local -- with IPC over named pipes.

I asked him what's the plan for reflection in Native AOT, what's the ETA, and about various trade offs that they had to make.

———————————

Overall, 2.5h behavioral, 1h algo, and 0.5h system design. I didn't expect a lot of SDIs because this org doesn't ship distributed systems.

Through the interview loop I was energized, smiling and enthusiastic -- I think standing all this time helped. I felt pretty good about this interview, felt like I passed it. This was a great relief, so I stopped worrying about Amazon interview -- whatever happens, I will be able to work on Go.

We went to a fine French restaurant to celebrate my birthday. My Amazon interview was in 6 days.

Episode 10: Mental downhill.

When the Amazon recruiter contacted me, I immediately recognized him from his Quora post about Principal Engineer interviews. He responded to my emails very quickly and late evening, we talked on the phone multiple times and his communication was very clear — I knew exactly what to expect. They even shipped me a mini whiteboard for system design interviews 🤨. Overall my recruitment experience with Amazon was absolutely amazing ✨. Apparently Amazon has a dedicated team of recruiters for Principal+ hires. They don't have a lot of candidates, and they can afford spending extra time with each of them.

This was a stark contrast from Microsoft recruitment experience. It took days for the recruiter to respond. I had to ask [how many SDIs will I have] multiple times, and got the answer just one day before the interview, when all my prep time was over 🤦🏻. A few times the recruiter responded "I will get back to you later", but disappeared for days. We didn't speak on the phone.

Upon the conversation with the hiring manager at Microsoft, it turned out that the team is 3-5 people which is 10x smaller than the team I currently lead (what did I expect?..). My excitement about Go @ Microsoft steadily turned into 😐. At some point I actually emailed the hiring manager that this is probably a level mismatch. He responded that he was disappointed, but understands and that based on our conversation he'd support my candidacy if something more interesting comes up at Microsoft.

All of this was happening in somewhat stressful circumstances: the date of our move from California to Washington state was getting closer, I didn't sell my car yet and our stuff wasn't packed yet (2 floor house). I was going through breakup with Google, the office and the co-workers that I spent 7 years with; and I couldn't even tell them yet, so I couldn't say my goodbyes properly before moving. A kid in my child's kindergarten classroom got COVID and my child had to quarantine at home. I had major Imposter Syndrome with Amazon (prev episode). Finally I was annoyed by awful Microsoft recruiting experience.

Recognizing my emotional state, I decided to look at this more rationally: I don't change teams often, so it is important to think long term. Even if the Go team doesn't work out, I'd still be in the right place, surrounded by products I love and people I admire, finally fulfilling my college dream. The awful recruitment experience is not a predictor of work experience — it just means Microsoft doesn't invest enough in recruitment processes — so I decided to tolerate it. I emailed the hiring manager asking to be reconsidered, and he confirmed that his leadership can consider me for Principal.

It was July, when many take vacations. I figured that's the best time to have interviews, but that was shortsighted: the key interviewers took vacations too 🤦🏻‍♂️😁. It was especially hard in Amazon case because there are 7 (!) interviewers. Microsoft managed to schedule an interview after my vacation, but I got so nervous 😨 that I fell into sleep deprivation cycle, exhausted myself 😫😴 and had to cancel last minute...

All interviews had to be re-scheduled after our move, i.e. much later. I got more time to prepare, but also the uncertainty was prolonged. The move involved driving 1300+ kilometres on two cars with 2 kids and a cat for 12h. On the first day in Redmond we were welcomed by an anomalous heatwave 🥵 and we didn't have AC or even fans. I got dehydrated and had to cool myself down in a bathtub. Also we didn't have kindergarten yet.

All of this is to say that I was in no condition for interviews that were scheduled for next and next-next week. I might have been extensively and methodologically prepared, but I was a nervous wreck 😵‍💫🤯.

Episode 9: Imposter Syndrome

Jaana Dogan is a Principal Engineer at AWS (L7) working on Observability. Before that she was Staff Engineer at Google (L6), working on Go and Spanner. Originally she is from Turkey.

I asked her what she thinks about me applying for Amazon Senior SDE and she suggested to ask my recruiter to be considered for Principal Engineer (PE) instead. PE, aka L7, is pretty high level; after all I was promoted to L6 only a year ago, but Jaana was convincing and I followed her suggestion. At least it will be interview practice, right? I'm interested in Microsoft anyway.

My recruiter basically said no. Jaana convinced me that interviewing for Senior would be a complete waste of my time, and that having strong offers is critical to have leverage in compensation negotiations. She emailed two other senior recruiters and vouched for me. They were hesitant too: normally early Google L6s are not considered for Amazon L7, but Jaana was persistent and somehow convinced them.

I also learned that the role is quite business oriented, whereas I am much more of a nerd 🤓 than a businessperson 💵. I wrote down my recent projects, but Jaana brushed them off as low-impact compared to the kind of things that L7s do 😳.

I started to regret that I agreed to this. I am strong technically, but I never operated at PE's scope. It is not even enough to pass the interview — the other part is to actually survive the high expectations at work. I've seen over-leveled folks at Google and didn't want to be one of them at Amazon.

Later, somehow my recruiter decided to skip the phone screen 😶. I was surprised, flattered and terrified to miss their expectations and waste time of 7 extremely senior interviewers.

Overall I had a major imposter syndrome, but at the same time I didn't want to flake. On the inside I felt like I definitely don't belong - it was a "fake it till you make it" type of situation.

L7, WAT?

Episode 8: Options.

I always wanted to work for Microsoft because they make the best dev tools/libs. I've also heard that Amazon pays well. My plan essentially was to get both offers, use the Amazon offer to negotiate a good pay at Microsoft and go there.

It was late May when I (re)created my LinkedIn profile. Among a dozen messages from recruiters, a couple were interesting.

First of all, an AWS recruiter reached out about a Senior SDE position, aka SDE III. According to levels.fyi, Amazon levels are pretty wide, and Amazon Senior spans both Google Senior and half of the Google Staff. I am in the beginning of Staff (consistently meeting expectations; promoted a year ago), so interviewing for Amazon's Senior wasn't completely unreasonable. Also, confusingly for recruiters, both Amazon Senior and Google Staff are called L6. I figured that at least it would be an interview practice for Microsoft, so why not.

There were also two startups that matched my domain (episode 2):
- bit.io is a sort of GitHub for Data, and they are looking for a CTO. Both "GitHub for Data" and "CTO" sound cool, so I responded.
- warp.dev is a super-charged terminal, founded by former Google Principal Engineer (L8) who led Google Sheets. He emailed me himself 😮, said they have a small team of very senior/strong engineers and the work is mostly coding 👍🏼.

Both startups sound interesting in their own way, especially that I'd get to write code, but I still prefer Microsoft/Amazon mostly because I want to work on more fundamental, low-level stuff. I told both startups that I'll respond after results of Microsoft/Amazon interviews.

Finally I noticed a job posting by Microsoft about their new Go team 🤩. Now this was very interesting! Remember, I tried to join the Go team at Google for years and now my favorite Microsoft forms their own Go team. And the hiring manager is the C# team lead! That's all the things I love in one place!

The job posting was for a Senior Engineer though, which is actually lower than my currently level. But still, this felt like a unique opportunity: I've applied and asked to be considered for a Principal Engineer, which is next level after Senior at Microsoft🤞🏼.

I also promised my wife that I won't take a pay cut because it would jeopardize our plans to buy a house in a year.

So my options were the Go team in the Microsoft Developer Devision or Senior SDE at AWS. The plan B are the two startups.

Episode 7: Behavioral.

Behavioral interviews are by far the most important type of interviews for Staff+ level. They assess your soft skills, such as communication, getting things done, customer focus, etc. Microsoft calls them Core Competencies. Amazon calls them Leadership Principles (LPs) and there are 17 (!) of them.

I must say that Amazon takes LPs very seriously, like a religion. LPs are used to make decisions, resolve conflicts, evaluate employee performance, etc. They are the main (only?) common thing across all Amazon teams. Overall there is much more behavioral interview preparation material for Amazon than Microsoft.

In a behavioral interview you are asked to tell real stories from your past, multiple per interview round. For example, you might be asked about a time when you disagreed with your manager/team, what were your actions and what was the outcome. In Amazon interviews, each behavioral question corresponds to one LP and it is important to deduce which LP you are being asked about. Your story must clearly demonstrate that you have the LP/skill and should follow the STAR format (Situation, Task, Action, Result).

It is not easy to quickly recall the most compelling story matching the question and tell it in the STAR format, on the fly. I prepared a few stories in advance by going through my 1-year-old promo packet and by finding behavioral questions on the web. For each story, I made four sections (S, T, A, R), and in each section wrote down key points that I must not forget to mention. I didn't try writing narratives because there is no time to read them during the interview.

Still there will be situations where none of your impressive stories matches the question. Practicing mock interviews can improve your ability to quickly recall and compellingly tell an unprepared story. Your interview partner should be senior enough to assess and give feedback on the structure and clarity of your storytelling. Ideally they are from the target company and conducted behavioral interviews themselves.

Fortunately I have a friend, former Amazonian, who was kind enough to spend his time on mock interviews with me. I also asked for help in @FAANGInterview and another Senior SDE at Amazon agreed to do mocks on LPs. Lastly I had a neighbor who is a Principal Engineer at AWS, and he did one mock interview too.

Overall, behavioral interviews are the toughest, because if you don't have real high-impact stories, then you have little to say. At the same time this is the most important part of a Staff+ interview loop. I did 15-20 questions in mocks. I also practiced by talking to myself, like you rehearse a presentation.

Resources:
- Former Amazonian unpacks each LP. Very helpful! See his other articles too.

Episode 6: System design.

System Design Interviews (SDI) have two key assessment points: disambiguation and design. I'll focus on the former, because it is critical at Staff+ and because there is a plenty of material on the latter.

Engineers often deal with ambiguity, where the presented info is confusing, unclear and/or partial (плохое ТЗ), or where there is no perfect solution to a problem and a compromise is unavoidable. Interviewers use SDIs to assess your disambiguation skills. Especially at Staff+, they intentionally omit important requirements and expect you to ask clarifying questions to uncover them. If you don't, then your solution might end up solving a different problem, turn overcomplicated or simply not work because of incorrect assumptions. Jumping into solution without any questions is a major red flag 🚩.

Here are some questions you might want to ask:
- who is the customer and what is the customer problem we are solving?
- what's in scope and what's not? What already exists and what needs to be added?
- what are expected scale, latency, availability, consistency?
- what is the budget? How much time for development do we have? How many engineers?

How you think and what trade offs you consider are also assessed. For some questions, I found it effective not only to ask the question itself, but also elaborate on my thought process that led to the question. For example, instead of just asking "do we prioritize latency or time-to-market?", consider "I can think of at least two designs. One is to do X: it is simple and can be delivered quickly, but the long tail latency would be 2s. Alternatively we could do Y: the latency would be low even in high percentiles, but it is more complicated and will take more time to deliver. For this interview, do we prioritize long-tail latency or time-to-market?". Here you:
- presented multiple solutions to the problem
- demonstrated that you consider pros and cons of each solution, and are capable of making an informed choice
- disambiguated by asking the question, and retrieved more info from the interviewer.

Lack of real experience is easier to detect in an SDI. With experience, you might think "last time I did something like this, I had to deal with X. What about X?", leading to a good clarifying question.

Mock interviews are essential for SDIs. In my first mock SDI I failed to ask about scale, assumed data won't fit one machine and it led to an overcomplicated design. Practice and attentive listening to feedback improved my performance significantly.

You need a partner to practice SDIs, so preparation is logistically harder than coding. Soon after I started helping others with their coding interviews, kind people pointed me to @FAANGInterview and @sysdesign_interview. In these telegram groups people pair up and interview each other. Overall I did 4-6 mock SDIs.

Resources:
- SDI structure video. Check out other videos on that channel too.
- SDI structure in text form (not mine).
- I liked SDI videos at interviewcamp.io. They are behind a paywall though.
- I do mock SDIs in addition to coding (sign up).
- Resources pinned in @sysdesign_interview

Episode 5: Coding.

Coding interview is the least important for Staff+, but on the other hand it is the easiest, and I can do it on LeetCode completely on my own, so I started with coding prep to get it out of the way.

I focused on problems of medium difficulty on LeetCode. Easy problems are too easy to ask in a job interview. Hard problems often require too much code for a single interview.

I solved 5-10 problems in each category (tag). This ensures good coverage -- it would be unfortunate if you spent all your time on trees, but then you were asked about dynamic programming. Then I solved random problems -- btw this way you don't know the category and must figure out the technique yourself. Finally sometimes I solved problems in my favorite categories just for practice and fun. Overall this approach worked well for me, so I recommend trying it.

One thing that LeetCode does NOT help practice is concurrent programming. I use Go where concurrency is easy and I have recent experience so I didn't have to prepare, but I definitely recommend practicing concurrent programming for your coding interview.

I also help others to prepare by doing mock interviews in my Friday and Saturday evenings. Sign up here:
https://calendly.com/nodirt/interview

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!

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.

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?

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 🤣.