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

ок, вот у этого поста должны быть включены комментарии. Кто-нибудь, отпишите, пожалуйста.
Телеграм сейчас сильно глючит.

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.

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

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 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 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 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 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 didn't read it myself, but everyone is recommending the book Designing Data-Intensive Applications
- Resources pinned in @sysdesign_interview

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