How would the ordering of the interviews change your preparation?

Whether the interview is in-person or over VC, assume all of these skills will be tested. Whether you’re writing on a whiteboard or you’re typing in a dumb shared text editor or you’re using an IDE, you should be able to express your intentions with near-compilable code. If you skip a method implementation for time, still write the signature. If you’re abbreviating variables, still just note that. I don’t consider the medium very important when evaluating outcomes. I expect a little more shorthand/abbreviation on a whiteboard but not without clear explanation.

From there, algorithmic complexity is definitely something you need to be able to discuss fluently. I definitely review a lot of common algorithms, and also be sure i know examples of common complexities just to have it on hand (O(1), O(logn), O(n), O(nlogn), O(n^2), maybe a few more exotic things like O(nlognlogn), then some graph things for O(m*n), etc).

More important than memorization, IMO, is analysis. When you’ve written something, as you’re going you should know the complexity, and how it would change if you made certain tweaks. If you’re using library functions, you should know their complexities. Being able to discuss this, and time versus memory tradeoffs, is pretty critical.

For system design I actually am least psyched about the all-online version, because they often throw whatever their digital whiteboarding tool of choice is at you, and you have to adapt. I hate fighting the tool in real time. Like do the shapes have built in labels, or do I create my own text label for each? Do the shapes have “snap points” for connecting arrows or do I just get close enough? None of this is an issue on a whiteboard. I don’t have much advice here other that trying a variety of these tools and at least expressing a simple-ish system in each.

From an order perspective, while I’m still not sure the impact, I normally see an online coding screen first (rarely the screen is live coding with a person, but it happens), and once that’s cleared the loop is setup with some coding and design and behavioral rounds, but I don’t normally see an order, and don’t normally see you being disqualified in the middle of this. I’m sure if you made really offensive comments they might, but based on performance they normally look at it as a whole.

Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE

Lee McKeeman

In your work life, there’s so many different contexts that I don’t really know that there’s blanket advice.

I would measure how much contrition is necessary based on how impactful the mistake was. Did the meeting proceed and the outcome was reached without you, but you now require someone to debrief you? Can you get context from notes or a recording? If a group of people all dedicated time, and your absence meant the meeting had to be rescheduled, that is a huge trust buster and you owe them time, IMO.

From there, what is the content of the apology? Generally any apology must:
1) Take sole responsibility for your actions and the outcome.
2) Describe how you intend to make it right, validate that this is appropriate, and pivot if it isn’t.
3) Describe what you will do to prevent reoccurrence. Not “it won’t happen again”, but “change notifications for meetings and add them to mobile devices with notifications” or “write down comments and re-read them thoughtfully before sharing”. Whatever it is, it’s your responsibility and needs no assistance from others.
4) Not blame others, expressly or implicitly
5) Not contain “but”, “however”, or express that the reason for the apology is because you were told to, are required to, or is based only on their feelings. I.e. “I’m sorry you were mad”
6) Acknowledge that trust was damaged, and *you* are responsible for repairing it. Recognize this won’t be immediate, and you accept that extra verification or follow-up will be required in the future.

From there… you’re sort of at their mercy. Don’t grovel, but be sincere.

I will just say “borderline” and “missing data” are different states and reasons for an additional round. Maybe they told you it was borderline, but it’s hard to deduce otherwise.

Mostly I say this to say: it isn’t unreasonable to blame this last round. It also isn’t 100% the case. Being reflective is great, but you’re working from incomplete information/feedback. This may be a good design, but there were other things it didn’t “raise up” enough for an offer or to advance to next committee.

Was this a single “phone screen” round, and they did design? If not, wasn’t there like 4-5 interviews, and this was one?

I’m asking because design as prescreen isn’t normally what I see, and you have determined that issues with this particular interview are what sunk you. Maybe they do a “plug pull” amongst the regular rounds and tell you? Just not my experience.

Other have commented on the design, and I do agree how you discussed this was likely as much a factor as the written design. I had an interview Friday and some things that are “standard” in design interviews I will admit I had forgotten. Essentially I haven’t had a choice in data stores in a long, long time. I can certainly let distinguish between an in-memory, KV store, a cached + persistent KV store, a document database, a block store, an RDBMS, cold storage, data lake/analytics… but I really haven’t been like “hm, for caching should I use X or Y” in a long time because Google, Meta, and Amazon sort of… have that decided in most cases. Is CouchDB good? Or rather, what workload(s) is it good for? I had to say outright that I knew what it was roughly, but hadn’t evaluated it.

I hope my API design, my general system blocking, determine what needed to come from live sources, what could have a short TTL cache, what could have a long TTL cache, what was to be done on the server versus client, etc, and my honing in on unspoken requirements (upsells) was good enough.

To go back to IC from EM, this implies that you moved from IC to EM. This means that those going back must be a subset of those that moved in the first place, so it has to be more common to take the first step.

With that said, I think this is too situational to generalize. If the roles pay about the same, and both have upward mobility (career track for both), then switching back would be far more appealing (and possible). I know quite a few people who have managed people and don’t any more. I am on that list.

Regarding more senior level folks… I imagine most more junior folks aren’t in a position to be moving to a people management role, and I think the jobs overlap more and more the higher you move.

Is it bad to lie to manipulate them? I mean, I do think that interviewing and negotiation is a sort of information warfare, but outright lying… if they found out somehow later and fired you, would saving those two weeks be worth it?

I would say the same about pay. You don’t need to tell them what you get paid, but that’s different than lying and saying you get paid 40% more than you do.

Did you ask “what behaviors or artifacts would dispel concerns about maturity? What are some specific things I can do to grow in the dimension as quickly as possible?”. The quickly part is because “keep doing what you’re doing” is an easy thing to say when it comes to “experience” or “maturity”. If you didn’t ask, I don’t think holding on to bitterness that they didn’t lay out a plan makes sense. I might be a bit of a jerk and say that putting it on your manager to identify exactly what you should do without you engaging and digging in is a bit of a confirmation on the maturity concern.

August is now, basically. If your manager isn’t supportive, you have no document or collateral, you have no supportive feedback from next-level engineers, etc. you don’t have any case for promotion. February is aggressive if there are actual gaps to fill, not just documentation gaps. To show you’re working consistently at the next level for an extended period of time will be tough in 7 months, and you don’t even know what change you’d have to make yet. Not saying February is impossible, but it’s going to be an uphill battle.

You should make a very detailed and high fidelity plan to fill gaps and demonstrate sustained next-level behavior by this time next year, for August promotion. Then adjust it to a lower-confidence, more ambitious stretch goal of February. Be working like it’s February, but be sure August ‘25 is completely achievable.

If the requirements are very low, like developing features independently, and you have 3-4 opportunities to do that in the next few months, maybe February is doable. But it sounds like it is not just delivery/hard skills in question. If the maturity gap is about behavior and leadership, changing gears, owning larger things, helping others, taking better responsibility for problems, etc. is a lot to manage and have people trust its permanent in a few months.

To know any of this though, you need to have a real conversation. Thank your manager for feedback on maturity, and ask if you can zoom in on some examples where this presented itself, and what behaviors would show progress on this. Ask if that happens, would this be sufficient for them to support your promotion, and if not, what are the other gaps? For each, acknowledge and accept the gap (even if you have counterexamples, save them for a later write up), and ask again what artifacts will alleviate a concern or show a requirement is fulfilled.

Turn this into a list, and match up coming work to these. If your work doesn’t align, you have to see what pivots are possible without dropping much of your current slate. Know your list is aspirational and the last check mark doesn’t mean you get promoted. It is at least something actionable. Share a document with your manager where you’re gathering collateral, linking other docs, etc.

If a document or portfolio is needed, create a draft. Outline or skeleton. Start filling things in, or ask your manager to help. Build this up over time. Evolve it until you’re promotable. Meet with your manager regularly and seek feedback versus the plan.

You are seeking promotion, they are not giving you a promotion. Show maturity through responsibility, humility, and self-initiated action. 

My experience is that your point of contact has absolutely no ability to make a decision independently when negotiating. They have been trained in the art of candidate jiu jitsu, trying to use leverage against you to get a number. When they do tell you a number, they can’t change it themselves. You can make a counter, you can ask for at least TC of X, etc. You can say “nope, just higher” they will have a hard time. They know the first number is (possibly) below your minimum, or you’re bluffing. When you do give a counter offer or whatever, they just go to some unknowable entity and come back with a new offer. Doing this by phone gives you no advantage. They don’t have to make any decisions or have any pressure at all. At least by email you can craft a response, get feedback, etc.

SDE II -> SDM II -> SDM III at Amazon
v
L6/Staff SWE at Meta
v
L6/Staff SWE at Google

It wasn’t a strategy in my mind. I felt that I was unpromotable at Amazon as an SDE because of… I don’t know, the process and who I am. I wanted to be able to grow, so I did it. I do think having a strong grasp on the interpersonal process of getting things done as a manager does help you frame and make better progress as an IC.

Honestly, though, a lot of my interviews that got me to Staff were coding and design, leadership existed but I’m not sure having been an SDM/EM actually helped that much. Essentially my technical abilities and leadership abilities seemed to be at the L6 level at Amazon, but that was not getting me there because of me being peculiar in a way that didn’t always fit rubrics.

I am not sure that I am going to succeed as an IC at this point. I don’t know if I’d go back to management (but that requires trust, not succeeding as a pure IC doesn’t grant that), or maybe TPM if I could do it at a higher level and not have a truly devastating pay cut.

I’m interviewing on a lark right now. Started as a senior manager loop, and I am not sure if I wasn’t meeting muster as a manager, or if they really thought an engineering role made more sense, but they shifted it to senior staff IC.

I am not a round or square peg. I am not a geometrically-sound-shaped peg at all. So far fitting in any hole has meant the hole gets reformed by me or I have to shift uncomfortably to try to fit it.

There’s a few things that you probably want in place first.
• Scope that makes sense for a dedicated EM and Eng team (ideally scope has ballooned for an existing EM, so splitting is natural)
• Strong trust from the EM or Senior EM you will report to, anyone you’d be asking (please ask, don’t force) to report directly to you, and any stakeholders (PMs, etc) who will depend on your team’s output.
• Experience directing other engineer’s work as a project or team lead (ideally not writing code on the project), interacting across teams (with other TLs or EMs) to deliver something in partnership, and presenting results (ideally good and bad) to a director/VP (whatever your new skip level will be)
• A willingness to let go of coding and design decisions, and to tell engineers very bad news (poor ratings, project cancelation, etc.)

From there, if you get as much of this in place as possible, start by taking on some of your manager’s responsibilities. Shadow them in some meetings, then go in their place. Write a strategy document for a program or long-term plan for your team. If you can, own a project from requirements to delivery without coding or designing. Your ownership means you are responsible, you are making sure plans are sane, you are making sure work is allocated properly, etc. You give stakeholders good and bad news as soon as you know it, you course correct a plan and adjust dates proactively, and present alternative approaches to get plans back to green.

After you have a good feel for what the job will be like, if you still want to do it, see if you can have a trial period without permanent commitment. For a quarter or half, act as if in all ways, with your manager only entering notes (after reviewing with you) and ratings as necessary. If you and your manager agree it’s working, then make it official.

It is not a one way door. You don’t have to stay EM forever. You can learn a lot of useful things and move back to a senior or staff engineering role. There will be some reasonable suspicion that you can still work as an IC, so keep skills up. You may like to do that anyway once it isn’t part of your job.

For context I moved from mid-level engineer (L5) at Amazon to baby manager (most line managers are L6), was promoted to L6 as manager, then moved to Meta, then Google, as Staff SWE.

Start with test cases. Null input, zero length input, input with no matches of the search but is non-empty, input with trivial match, input with duplicates, whatever. Eliminate as many cases as you can with preconditions. Any edges that still require using the main algorithm should be the first thing you consider/test. Maybe it’s a do-while instead of while, maybe it’s doing a single-element look ahead or behind, but often if you can identify how to handle the edge doesn’t ruin handling happy cases, so it is more generalized.

If you know what you’re testing, it can make tracing easier.

From there, when I am in testing mode, I put comments after each line with the values of all variables before and after the line executes. When it’s a loop, there’s different approaches but regardless it is keeping the loop control and whatever outcome you’re looking for. I also look to comment, in advance, what is expected before/after each “stanza”, ie after this loop I expect all but X to be processed and held in the result buffer. The final step will be Y to process the remainder of the input. Or “the map will have keys that are the unique Ws, the values will be their occurrence count”. When you’re debugging you can validate those conditions are holding.

If you have methods ideally they are simple, and you can “know” what the outcome of a call will be. Walk it through a couple of times, but ideally you can then just say “when X is called, Y is returned”.

I guess also practice? Like do it on paper, do it in a shared editor, whatever. Put a bug in and be sure that the approach you are using surfaces it.

“HMs know these aren’t good predictors of performance”. It isn’t about predicting performance. That’s not really measurable. It is a bar that exists. The hope is to see how you think and adapt, as well as your existing knowledge and skill.

I know it doesn’t seem like it with current interviewing, but companies like Amazon spend a ton of time and money researching interviewing practices, measuring outcomes, doing analysis of different approaches, and ultimately this shapes how interview loops are structured. Imperfect, but huge effort goes in.

Anyway! I really only know Amazon’s process. In the debrief, what you did is discussed, but how you approached it, how you handled twists, how you handled feedback, and so on. At Amazon the HM and Bar Raiser make a hiring decisions. They discuss the data with the rest of the loop, dig in, and try to find if the gaps the candidate has are risks they are willing to assume, and if they have enough bar raising abilities to make it a good hire. If someone has average performance in everything, and a couple of yellow or red flags, there’s nothing to “pull them up”. If someone has a few stumbles but kills a couple of sessions then it is easier to accept what’s missing and still push them over the bar.

I am doing a program focusing on health, mostly weight loss but also building muscle and lifestyle change.

If I am making the choice, I am making the same things every day. It isn’t perfect but I can do it, and it is working for me. Autism probably has a lot to do with the comfort of routine.

Breakfast:
Baby Carrots (I don’t track calories from vegetables)
Skyr + Blueberries, sometimes with sugar free vanilla syrup (100 calories of skyr, 30-40 calories of blueberries, 7g carbs in skyr, 19g protein)
2x Starbucks Bacon Gruyère egg bites, made in air fryer (280 calories, 9g carbs, 17g protein)

I don’t super carefully measure the skyr, so it could go up 33 calories if I take 1/3 a tub instead of 1/4, but that means 6 or so more grams of protein.
410-450 calories, 16-18g carbs, 36-42g protein (plus vegetable calories)

Lunch and dinner are the same. I do eat other things sometimes, but this is staple:
Immi ramen (spicy “beef” or Tom yum “shrimp”, it’s all plant-based, hence the quotes) (300-310 calories, 5g net carbs, 21-22g protein)
2-3oz of Realgood Chicken strips in air fryer (65-100 calories, 1.5-2g net carbs, 12-18g protein)
2 vegetables chosen from: Baby carrots, coleslaw “super” mix (shredded vegetables) with lemon juice to cut bitterness, celery
365-410 calories, 6.5-7g net carbs, 33-40g protein (plus vegetable calories)

I don’t always eat this for all 4 meals but try to do something similar (low or no carbs, chicken or fish, occasional beef or bison, extra vegetables). 
Per day if I do these 3:
1150-1280 calories, 19-32g net carbs, 102-122g protein

I haven’t actually looked at the calories before, but figured it would be interesting to see. I can’t attest that this is like… the healthiest, but leaning more on chicken and fish, eating 5+ servings of vegetables per day to get full, and cutting snacking has made a huge difference. I can get full eating this way and don’t feel hungry between meals. Prep takes about 15 minutes of air fryer time, with the rest all fitting in that time. I clean the kitchen, do dishes, etc while that’s happening.

Because I feel guilty saying it, I tend to avoid it, but I am also taking Zepbound. I established the eating habits first, but for the first time in my life I learned what feeling full, but not way over full, felt like. I am on the fence about how long I will keep using it due to side effects, but if it can support what I’m doing already (and stop eating when I’m full, which happens now), I am willing to try. I’ve yoyo’d for years and was up to a fairly unhealthy weight, so this is a health-based action plan.

How will the answer change anything? Will this affect your confidence? Will your nerves be on edge? Will you prepare in some different way?

They are very unlikely to give you significant feedback. They may disclose if there is missing data, maybe not. They may be borderline on leveling, not general hiring. Someone may have botched their data collection.

I would say approach it as you have approached the rest of the interviews. Ask if you want, but be aware that you may get information that negatively affects your performance.

Scenarios:
1) You bail on the loop, don’t know the outcome. Maybe there’s no cooldown, but certainly you won’t “jump the line” later.
  1a) You love your new job, at worst you wonder if you would have cleared Meta but it’s just a what-if
 1b) You don’t like your new job, you want to move on, you restart the Meta interview from scratch if you want to try again.

2) You follow through on the Meta interview, you get an offer, and you decline.
  2a) You love your new job. You might have a touch of confidence now and in the future having cleared the Meta loop.
  2b) You hate your new job, you want out, you can maybe skip some if not all of the process at Meta if you go back. Even if not you have more confidence interviewing there and elsewhere since you cleared the loop already.

3) You follow through on the Meta loop, you don’t get an offer.
  3a) You love your new job, you’re glad the Meta outcome doesn’t affect your options much since you’re already somewhere you’re happy.
  3b) You hate your new job, and you’ll have to wait for the cool-down period if you want to pursue Meta again.

All the a) options are better than all the b) options. 2a better than 1a better than 3a. 2b better than 1b better than 3b. Since you don’t know if a or b will be what happens, and you can’t be sure if you’ll clear the interview, it’s really a matter of how much you’d regret not knowing the outcome. The cost of completing a no/low stakes loop seems super low, and no pressure. Best case for you to perform well. If you have extreme rejection-sensitive dysphoria, maybe don’t risk the rejection. Otherwise, why not?

Are you used to writing Apex? Have you tried writing anything you’ve done in Apex in Java?

I am not an expert. I mentored some interns who were writing some localization fixes in Apex, and had to help debug a few things. There are for sure differences. I know off the top of my head multithreading (or lack thereof in Apex) is pretty significant. Especially in a lot of backend code, efficiently splitting work across threads to improve per request (or other work unit) latency is pretty critical.

You can’t just decide you’re going to learn multithreading in Java and do it. I will say Concurrent Programming in Java by Doug Lea is a good book, but I don’t know if it is good for beginners in concurrency. Maybe it is, I just haven’t approached it from that angle.

Otherwise I just don’t know what modern Java features are available in Apex. Streams, Optionals, lightweight threads (again, really concurrency-specific), and other features are in common use now, and I don’t know which you’d be exposed to in Apex.

I would say that while a lot of backend work is still Java, Kotlin is making significant moves to supplant it in most settings where Java has been used (as it’s “first class” execution environment is the JVM). I don’t know that investing in learning Kotlin now will be a faster route to achieving your goals, but might be “different-er” from Apex and avoid you spending too long thinking only in terms of what you are used to.

I think it is practical to make the move, but you may have to really break yourself of what you know. Most Java code isn’t directly accessing data, UI interactions will be very different from what you’re used to (and I guess isn’t very relevant to backend work), and so on. That’s not a language issue, it is I guess the “platform”, where Salesforce is very insular.

My plan would be to start writing Java. Potentially setting up a server on your machine, and solving simple problems. Writing arithmetic programs, doing simple crud with a data store, etc. Focus on APIs where there is a request (JSON is still popular, could do protobuf), you do some work, and return the result to your client. From there maybe some GitHub projects could be some code to read and see how modern Java constructs are used to build high-concurrency services.

I know switching jobs isn’t easy, but… maybe while you’re navigating all of this you’re looking, too? It seems super volatile and undependable.

Be the engineer you want to be, even if it’s not the norm. If you think documentation is valuable, write it. If people don’t like that, you don’t have to publish it and can just do so when you leave. If you want to push your status updates instead of getting pinged, give an over-aggressive schedule like 3x per day, and meet that schedule.

Otherwise it sounds like you’re saying you don’t have faith in the business model, the development model, and those in charge. If that’s the case, what is motivating you?

Not questioning the general sentiment, but am curious in regards to your specific situation… do you think making the leap sooner (if it was Taro or similar) you may have carried less credibility into career coaching? Just picking a couple of cut points:
L5 at Meta, no manager role (I think you were hired at L5, promoted to L6, then nudged into TLM)

After Pinterest, before Meta (round 2)

Pre-Pinterest


If they are asking for references a company will normally share: The dates you were employed. MAYBE the job role. If the name of the role changes they MIGHT indicate level, but still unlikely. Apple buckets everyone into “associate” when they leave so this isn’t an issue, as an example.

No agencies that track data for background checks like convictions and credit would have any indication of your job level.

It seems like you’re asking because you were dishonest? I know it’s all a game, but the move is avoid, not lie. Avoiding is strategy, lying can be fraud.

I don’t know startups at all, but am trying to understand motivation here. Is it recognition and respect you really want, or is it actually authority? Like you want to be able to tell people what to do or pick your own work without justification because you hold authority, and not have to sell and influence without that authority?

And you’re saying you value this authority more than choosing exactly what job role you’d prefer?

Further, a (T)PM connecting directly with junior devs to ensure clarity, help coach them on the business and product, etc. is pointless?

I have never seen a TPM (with the P being program or product) write any code. I have seen them contribute to design discussions, especially when there’s cross team requirements. 

You note that craving power is natural for management. That seems very backwards to me. Management isn’t empowering at all. Maybe if you’re a founder, but generally if you’re effective it’s through partnership and servant leadership, not wielding power.

If you do feel empowered by managing people, and want to code, some companies have a Team Lead Manager (TLM) role that maintains individual deliverables and codes while managing a smaller team. You can then choose to stick with the hybrid role, or move toward exclusive management (org leader) or back toward a senior/staff engineer IC role explicitly.

I can’t answer all of these, but my gut is that while there’s likely to be a seismic culture shift moving from MS to Meta, there’s a strong chance you can adapt and L5 is a big step up over L62 and a decent step up from L63 (for comp, at least).

I couldn’t adapt fast enough. I joined unallocated and it took me like 4 months to find a team match and then couldn’t be what they wanted.

1. I don’t know reality labs. In general you will need to move fast. During onboarding try hard to advocate for tasks at the current level you are working through (they want you to ramp through L3 and L4 before doing L5 things). I struggled with there being nothing really scoped and straightforward, so it was perceived I was struggling with simple tasks when there were no simple tasks.

2. There’s a ton of scope in infra. Impact can be multiplicative. 2k devs saving 1m per day is 33 dev hours daily. That’s almost an extra week of productivity every day.

3. This isn’t something you can know in advance. Your manager may be ethnocentrist or racist, there’s no way to know. Chances are that if bias led to this it isn’t outright racism, but could still impact you. I wouldn’t start out worried about this. You could be treated inequitably anywhere, don’t assume you will be in this circumstance.

4. You mean they came to Meta from Amazon, and at Amazon they were L6, but you think they might be L5 at Meta? It’s possible, but with the misaligned leveling, unless they had just gotten an L6 promo, they probably came in at L6/Staff at Meta. Even so, I think this is a little… I don’t know, I guess I understand a potential negative take when your right to work could be at risk, but “I’m glad there’s more senior people to learn from” feels better than “I have to crush my peers to survive”. I don’t actually know how competitive and stack-ranky it is, but I wouldn’t go in looking for a weaker team so you’ll be able to outcompete them. 

In terms of what you’re really asking, which is like career advice, I always get scared about butterfly effect things that would mean I didn’t end up exactly here.

In terms of goofy answers: buy/mine as much bitcoin as possible 5 years from now. Sell it in March or November 2021 or wait until February of 2024. It may raise beyond those points in the future, but those are local maxima as far as I know them.

Same with butterfly effect, but getting therapy, leaving a relationship, etc would be good, but I wouldn’t have this life so…

Sorry, this isn’t helpful!

If one were to ask “what would you tell new grads today?” it would be much different. Focus on debugging and fixing production issues, they are harder than writing the code in the first place. Learn an interactive debugger. Do work other people don’t want to. Write human-language documents much more than you think you should. People are more complicated than computers, learn speaking, conflict mitigation, and negotiation. Learn the workflow of the most productive person you have access to. Staying late doesn’t make better code or getting you promoted. Max out retirement savings as early as you possibly can. You didn’t learn to code in college, start learning now on the job or during prep. 

Do you want to manage people? Do you want to manage low performers through improvement or being fired? Telling people when they aren’t getting promoted? (Of course you also get to tell them they are) Do you crave more meetings?

Mentoring more junior engineers should already be part of a senior SWE job. Being a direct manager actually makes direct mentorship more difficult because one big part of mentorship is effectively managing the mentees challenges with their manager and how to work effectively with them. When you are the manager that isn’t really possible.

What support are you going to be given? Like is their training? Or will you roll up to an amazing senior manager or director that can grow you as both an engineer and manager?

How many reports? More than 2 is going to be a significant demand on your time. Your ability to deliver on individual contributions will be impacted, your ability to learn purely technical skills may be affected by the time demands of managing and learning to do it well.

The more positive side is that working with Eng managers, and within team constraints, changes when you’ve done the job. You understand limitations, you know why odd decisions may be made. You empathize and may be able to aid managers more effectively. You can lead a team as an engineer when there’s a manager transition, leave of absence, etc. It can be very beneficial to have these skills and as you move up as an engineer, leadership will be critical, and having the perspective of direct management can be useful.

More than anything, though, focus on if you want to do this, and be clear on a trial period where you can back out. Don’t trade a job you’re good at and enjoy for one you’re bad at and hate.

“Behavior set of Boz”:
You mean burning billions of dollars on dead end projects, rejecting inclusivity, being utterly self-assured while being protected from those at the very top? If you can swing it, I guess you can try to find out.

That’s 1/2 joke, 1/2 sincere anger at his behavior.

Promotions aren’t an evaluation of how far to promote you, the question is only N+1. If, without any experience, you tried to emulate Staff behavior it would be… sad. Being able to influence at that level with no practice, talk about systems and their behaviors with first-hand experience that you’re missing, etc isn’t tenable.

What’s true is I was stepping into places a Principal (L7) belonged as an L5. It ended up with me being told I was way overindexed on leadership and didn’t have tech artifacts to support an L6 promo. It isn’t helpful to get too far over your skis.

In the near-impossible scenario that you are successfully performing your whole job at a level that’s N+3 or whatever, know it won’t get you promoted to that level for years. I’d guess no fewer than 5, but I know there are wunderkinder. Going elsewhere and aiming for N+3 will be rough. N+2 is a huge reach. N+1 is very possible, maybe promo to N+2 in a year if you’re killing it, but still another couple of years to N+3. It could still save a couple of years to bail.

Is this real, or a joke?

If you’re leaving, the sooner the better. Don’t let them invest time in training and on-boarding if you’re not staying.

Agree with Alex, this is about your friend. If you’re willing to completely destroy their trust and friendship for this other job, that is your prerogative, but know that if you don’t speak to them about it and be on good terms if you do this, that’s a big sacrifice. Jobs come and go, friends are a lot more valuable.

From there it is also about the people at the company you’re leaving. It is a small world. The recruiter, manager, etc won’t feel good about working with you in the future. If you can move very fast, maybe they can hire other candidates and it’s not a huge inconvenience.

With all that said: you must take care of yourself. You should consider all of this, and still make the decision that is best for you. If you’ve gotten a prestigious offer you likely can again, but if you won’t learn where you are that could lead to stagnating. I would also run a pros/cons by someone you trust or here.

What will “reaching the stars” do for you? Will it ever stop, or will it always be the next promotion or big company to chase? My concern is that you are asserting big goals, but it may actually be that the current situation is “never enough”. Where this comes from, if true, is likely work for you and a therapist or confidant, but it’s not that unusual.

We get the impression that standing still is falling behind in our industry. We can continue to grow without striving for another “step up”. We can get more efficient so we put less time into draining activities, we can learn to better delegate so more is achieved without our direct involvement. This may not get you promoted, but it may reduce your stress, which I think is a bigger win.

The real “secret” in my mind is getting more done in less time. Maybe it’s automation, delegation, process refinement, practice, or any other means to efficiency. Doing that means that you can focus on other things because you can get your required work done in less time. It can feel like “if I am more efficient, I can just get more of those same things done”, but I’d encourage, instead, to use that time for learning, for self-initiated side projects, for mentorship or other “soft influence/skill” work. If your “must do” tasks are done, this changes the pressure dynamic. If you can use more time for less stressful, more rewarding activities that are still valuable to your team, this helps relieve pressure.

Beyond that, there are boundaries. If you always say yes, or work late, or take more on to show you’re a team player or whatever, you may be able to handle it for a while but could also burn out quickly. You are starting a new job, it is a great time to set boundaries for yourself first, then establish them at work. Actually scheduling things at 5:30p (hobby things, not extra work or training things) can serve as both a hard stop for work, and a release valve to reduce stress and refuel. If I didn’t have kids, I would have struggled with this, but it was my “why” for having a hard stop time.

I’m glad you are listening to the warning signs. Decaying health at 26 from overwork is a bad time. Exercise is a great start, and invest in your health. Whether that’s with nutritionists, or personal trainers, or specialized healthcare (genetic testing to optimize diet or supplements), or sleep specialists… staying healthy should be a huge priority. Without your health you can’t even eke by at work, much less excel. I’ve been underwater with depression and other things for a few years and it sunk my time at Meta and it’s 50/50 if I can course correct now at Google. I started with a new psych in January, and if I had done that 3 years prior things may have gone much differently.

You may have anxiety or some form of compulsive behavior that’s worth looking into. If you don’t even know it’s very hard to “recover”. If you are having panic attacks, see a psychiatrist. This isn’t something to push through. 2.5 weeks off is fine, but when you get back you will still be the same person you were. You may be carrying a little less stress, but you will recreate it without intervention.

I guess this comes down to:
If we operate like an F1 car, but maintain ourselves like a 70s beater, the wheels will come off and we will be useless. Investing in maintenance of many kinds, and taking care of ourselves like we are high-performance is critical. Get massages, do yoga, talk to doctors, go to therapy, have a mentor you confide in, eat vegetables, socialize with friends, build ships in bottles, whatever it takes to keep yourself running smoothly. Then don’t try to do a cannonball run in a sprint vehicle.

Hm. Being an advocate or cross-org champion for technical solutions doesn’t seem like a mid-level engineer-ish role to me. I’d say senior technical program manager, or part of the work of a senior or staff engineer. I’m not saying you can’t do it, but that work is a lot of soft influence, salespersonship, advocacy, and so on. You’ll be finding the common reasons not to, and finding convincing counterarguments.

There may be coding work, like building proxies or adapters to allow gradual adoption of the new APIs. There could be coding to demonstrate integrations. Or automate them if possible. Or adding test harnesses or other infra to let teams gain confidence in the transition. It could also be building dashboards, or building experimentation such that you can divert some traffic to the new API in parallel with the current API, comparing results, etc before moving live traffic to the new APIs.

If you haven’t driven a program like this before, it is sort of… tricky for a new-hire, mid-level engineer to run something like this. You need to garner trust, and if the first thing out of your mouth is a sale pitch requiring engineering time being taken from current priorities, that isn’t going to do it.

I am not sure how much of this will be in the interviews. Now might be a DSA, coding, problem solving, design type time, tackling the migration program is a “once you have the job” problem, unless you were told you’d have specific questions about this in your interviews.

Balancing the promotion portfolio for this many people isn’t very sustainable. If your team has the scope of work for 5 senior engineers, but there is organizational pressure to have mid-level people doing senior level work instead of rewarding that with promotion, the organization is badly broken. If there simply isn’t that much senior-level scope, then the strong mid-level engineers seeking promotion need to be told they need to move on to another team that has scope and few engineers able to take it on.

I might have longer term succession plans, seeing if any engineers prefer moving to a management role, and devolving the team into 2-3 smaller groups. 2-3 role changes to a “training wheels” manager, with intention to promote to “full” manager equivalent to a senior engineer, then 3-4 senior promotions, with one per team (with the current manager continuing to own deliverables and direct engineers). This structure turns this over-large team into a small org (I would imagine backfilling engineers into the spaces vacated by engineer to manager role changes over time). This would allow better focus (I hope a team that size has multiple features in-flight, etc.), and clearer ownership.

On a team of 5, I’d expect one senior promotion in a year, assuming there are none already on that team. Extending that to 15 (assuming 3 significant areas of ownership), I would say 3 could be possible if the manager had a lot of support in getting feedback, writing docs, etc. 7 seems absurd. If you’re asking how they pick the 3… well, that’s tough. Mostly it’s based on self-motivation, and gap analysis. Telling someone a target for promotion that really isn’t reasonable with their gaps is a setup for major unrest.

The standard dodge is “based on my experience and scope of work, I am targeting senior roles. I’m sure that this level at <company x> is high, and if there is a calibration concern I’m happy to chat with a hiring manager or a screen to ensure that this is appropriate, to ensure we can all respect each other’s time.”.

I can’t blame them for wanting to calibrate a loop appropriately. It’s a lot more “expensive” and difficult to coordinate an interview loop with all senior+ people. There’s also enough bias and other factors used to underlevel folk that resisting providing them reason to calibrate you lower makes sense.

So then what? Do you say you *were* a senior engineer, and hope they don’t ask where? Do you just avoid it and say senior is your target? At some point if you most recently had a senior role you likely wouldn’t resist the question so much, so you’re probably telling them anyway.

Focusing on impact (team lead, tech lead, owner of complex system) that aligns with senior could help. 

July seems doable, it’s June. Maybe it’s the last day of July, but hopefully you can tough it out. If you do get a new opportunity ideally you can set your start date to the day after vested shares are in your account, so you see the light at the end of the tunnel.

The rest of this is a lot more complex. It seems like you came in with what may have been reasonable suggestions, but hadn’t established trust, and maybe weren’t delicate in your suggestions. This set you up as negative and critical rather than positive and helpful. Maybe your approach was really delicate and folk still got defensive. Either way, it’s a chance to learn, and you can consider how to balance proactively making helpful changes and bring viewed as a know-it-all or negative/confrontational.

It seems like your manager does want to rebuild, but you are putting the responsibility for the strain on your relationship on her. You are going to need to be ready to accept responsibility for your part if it’s going to improve.

Regardless, if you think you’re done, I’d still try to make amends with your manager if only to get experience doing that.

The “Goldilocks” company that has great work life balance, deep learning opportunities, no politics, and good pay is simply difficult to find. You may need to rank these, and develop strategies for learning about your highest priority items. 

“If I (am) wrong I admit it and rectify it”. This sounds like reasonable “action” part of STAR. Documenting something, or just learning and applying the new knowledge are good, reflective actions. 

You don’t need a huge mistake to answer this. The point is about being reflective, and learning from mistakes.

I had a phone screen with a candidate once who said they’d never made a mistake and never missed a deadline in a 20+ year career. That’s ridiculous.

Google isn’t what it used to be. Any long-lived tech companies are the same. I started at Amazon in 2012 and it wasn’t what it had been, but it was still taking big risks, Bezos was still running it, there seemed to be a lot to figure out. When I left in… 2021? Things were way different. Not bad, but maturity can bring caution. I don’t know what the risk tolerance is, but in many areas it was tightening.

When I joined Facebook in 2021, I had heard such amazing things, and maybe in some parts of the company it was still there, but it seemed very different than how things were described back in the day. There almost seemed to be tension between those that still championed “Move Fast and Break Things”, and a pushback as that motto had been deprecated.

When I joined Google in 2022… I think things had changed, but there was still a sparkle. The real change was the layoff in Jan 2023. The attitudes and morale shifted dramatically. Growing up and spending responsibly (especially with record profits) seemed antithetical. It is definitely different.

And I don’t know if there’s anywhere I’d rather work. I am sure there’s somewhere in Google where I’d fit better than my current team. I’m sure there’s a company that has a Lee-shaped hole where I’d fit perfectly. I don’t know where those are, and it’s still Google. Yes, important people have been laid off. Yes, there’s crises of confidence at times. Google. I work on Gmail. When I’m doing data analysis for user impact the denominator is billions.

I think that people are worn out. I don’t know if it’s specific to Google. I think how bad it is varies a ton, though, and it’s hard to generalize. If you’re on the fence, talked to people in different teams around the company. If it’s dour across the board you have your answer.

+1 On FMLA as Rahul mentioned, which is none of your boss’ business, and beyond their control.

I am a big supporter of visibility for mental health. By the same token if you don’t already have psychological safety established with your manager, I am not sure if disclosure about this makes sense. I am not sure what you could gain telling them. If you need leave, your manager isn’t involved; if you want a change to your workload without official accommodation like a part time schedule, they likely can’t or won’t do that; if you want support or a sounding board or someone to listen they likely aren’t the right person. I get that addressing your lack of capacity matters, but there are people who shouldn’t be trusted with this information and you don’t know enough about this person to be able to tell if they qualify.

If your work quality isn’t suffering yet, it will. Resetting with FMLA or other leave or something else as soon as you can could be a defining factor in whether you can recover and thrive at this job. If your performance is suffering and you are already overwhelmed, trying to solve both at once is very hard.

Good luck. Get help. Talk to a trusted friend or mentor at work and get advice. If you think it’s safe and has benefit, you can tell your manager, but it doesn’t sound like that’s the situation.

They may want to ask for the specific level being offered. Is it L63? L64? I would guess L63. In terms of comparing to ranges, they should be sure they are considering their work location, as this can affect compensation.

Another aspect is you mentioned taking a pay cut. Did you mean getting an offer below market rate, but it is still greater compensation then they have now, or do they actually make more now than this offer? If the latter, that is leverage since they have a choice to get paid more by staying put.

Getting a higher offer even if they don’t plan to take it (I.e. an Amazon offer, even for SDE-II, could be higher, SDE-III much higher) is the “obvious” negotiation tactic.

If your friend does need to start this job immediately for visa reasons they are in a lurch. Time to interview elsewhere would be limited, and getting a start date would be critical.

“Most challenging” doesn’t always mean the most successful or impactful but it would be nice if you had an example that happened to check both boxes.

From there, I would try to orient these on both of those axes (maybe a few more):
1) which had technical challenges you’d never faced before, and that you successfully overcame? Rating is how complex or how far afield of your current knowledge it was.
2) Which had leadership/comms/interpersonal challenges you’d never faced, rate same as #1.
3) How much did your actions in overcoming the challenges above improve the outcome? If someone with less experience or lesser abilities were in your place, how much worse would it have been?
4) Which did you learn from, and allowed you to be more effective in the future? This is normally in the form of “what would you differently if you were doing this again now?”. Something that changes how you delegate work, lay out an execution plan, etc. can show higher level learning and leadership.
5) How impactful was your work? When you’re doing implementation in a larger project this can be hard to quantify. The incremental value you add versus someone a level below you, etc can be a useful metric but may still be hard to quantify. In your first example it sounds like you added automation when the ask was investigation. I am not asserting this is the best example, but it shows how your involvement solved a bigger problem.

It will not be straight forward to “score” for these dimensions, and when you get a result it may still be ambiguous, but hopefully this exercise can still help you index. 

Oh, the leaving is “any stock after this may be worth substantially less, so my total compensation will go down, so I should get a job elsewhere with what I perceive to be more stable stock price”. I guess that’s an approach?

Taking the offer seems like an opportunity cost thing, mainly. You’re going to have some of your comp tied up in private shares with risk to the value when they do convert to public shares. All of that is outside of your control, but would you feel much safer having public shares of a potentially less volatile company?

Alex mentions below that being a Pre-IPO person may lead to faster growth, which then may lead to higher total comp, which may mean larger stock grants. If the stock did crash, your future grants would have a planning price lower, so you get more shares, so then upside if the stock recovers is higher. Of course all of this is speculative and it is going to boil down to if you think locking up some percent of your comp in volatile, non-public shares is a good bet.

Are you being offered private RSUs that would convert to public RSUs (and vested private shares convert to public)? Or options? What is the valuation they are using when determining a dollar amount value of the offered shares?

You can’t guess how the market will react. Normally non-public you treat the stock as a bet, not your primary compensation.

Would you accept the offer if the stock was worth 50% of the number they presented? 

It is really a risk tolerance question. I don’t get how it would be helpful to quit near the IPO?

+1 to Charlie and Alex’s thoughts.

I want to add something, though. If the culture is blameless, this person doesn’t have to accept blame. If they are blaming others, that is the root of the problem to address. Don’t worry about them being reflective and publicly accepting blame. They may have self-confidence issues, imposter syndrome, are insecure in their seniority, or any other number of issues. Maybe they’ve been scarred by a culture of blame, have been fired or seen people fired when something is “pinned” on them. Whatever the reasons, that’s not for you to know.

You *can* talk to your manager about this person, and I don’t know that you have to in order to work on this. You can spearhead blameless culture, team norms, and other principles that aren’t targeted at this person, they are meant to improve culture and morale team-wide. When they are understood and adopted, it isn’t you pushing back on this team member, it is the team culture and they are being reminded that everyone is on the same side, fighting against faulty systems and processes, and for the end user.

When people bring up a mistake, you don’t have to accept or assign blame. You say “I’m excited to drive the postmortem on that, I bet we can identify some solid action items to make sure that never happens again, or can’t affect that many users.” If someone is pointing a finger, I think that you *can* gently redirect. “Yeah, it’s really unfortunate that we didn’t have better documents in place. It was really admirable that Ajay took that on, and has already implemented some of the AIs to protect the rest of us and our users”. Again, you don’t HAVE to be the only champion, and always be redirecting, but if the team norm is “we blame processes, we praise people” it can be easy to just say “blame the process” or whatever as shorthand, and ideally the rest of the team will, too.

Don’t set this up as a conflict between you and this other engineer, or something they need to fix. The team needs to fix it, the problem is with culture, not one person. If they don’t know any different, blame-assigning isn’t particularly unusual. At my first job we’d form a blame train, picking up people as we went, trying to track down who broke the build or whatever. It was sort of light-hearted, but wasn’t as productive as looking for the problem not the perpetrator.

 No. The parts you can negotiate are none. Managers, before it is finalized, may have a tiny amount of discretion but that has largely been stripped away. You get bottom of band L5, and if you are still in a starting grant that has increased in value, you may get very little new RSUs, but you will get a base bump.

You do not have any leverage. There is no reason for them to negotiate. If you want to go out and get mid-level offers elsewhere now that you’ve earned the promotion, then take that offer and see if they will dive and save for you, that is actual leverage. If you want to leave, then boomerang with new comp (be warned that giving up unvested stock is risky, your new offer may have a smaller grant if the price has really grown) you can get higher in band.

This simply isn’t when you negotiate. You get the promise of dramatically higher comp if you get good ratings later, but this isn’t the big payout. Promo + high rating can get you to 2x previous comp, promo alone doesn’t.

Sorry to disappoint. I promoted like 4-5 people to L5 and one to L6, and if they’d gotten a high rating at the previous level, the promo bump was often underwhelming and I had no leverage to make it any better for them. At least the base cap was changed, L5 to L6 if you were already near cap could feel very bad. L6 to L7, even worse. You have earned a new bottom for your comp target. If you got really lazy at L4 they could knock your target back down to bottom of band, now your floor is above your old ceiling, but that can be little consolation.

I think other companies do this very differently. Amazon is… Amazon.

Non-technical is not accurate to describe what complex, cross-team coordination. That requires a blend of deep technical skills and a very special kind of communication skill, too (which we call a soft skill, but technical communication is still tech in my eyes.

I would try to have each contributing team provide individual updates, so you can collate that with status against dates for work streams and the overall project. If you can front load anything that is an interdependency, it means that a single-team delay doesn’t cascade. Determining the API contracts and mocking/faking both sides at the outset, having data entities predefined, etc. can avoid blocking between teams.

Communication to clients should likely be different than internal xfn project status. Clients should have a stub endpoint to call from the outset that fakes results, and adds request validation little by little (did you send what’s required can be done right away, making sure a specific item id can be validated once you onboard that dependency, etc.), can let clients start writing the treatment arm of their code so they can easily test what they’ve done so far. They should be able to either use your fake responses, or at least self-generate a usable model since the model will be determined in advance.

I would challenge you to be very aggressive in finding possible pitfalls, failures, long tail items, and so on and do them first. Don’t start a privacy or security review when you’re code complete, start it tomorrow. For launch, look ahead and see if you’re in a Q4 freeze or other holiday chill period that will stop you from launching, and provide alternatives (pre-launch before, fast follow after, or do deep testing during the freeze to prepare for launch, or launch in non-prod, etc). Design your experimentation/ramp-up considering the whole system, so you aren’t trying to coordinate ramps on different systems with different controls. Maybe that’s having the client callers send their treatment with their request (as a “mode” or “behavior”, not just “T1”), then wire it through to your dependency, or have your experiments “or’d” so you can enable a path based on a client call, or a dedicated check in a given service (maybe to allow you to send traffic in parallel and do a comparison offline, etc). Know how you are sure it’s working and how you’ll validate and prove that. Define your metrics up front and create your dashboards early. Be able to show success/failure even with very early mock traffic. Have a rollback story already written, don’t think you’ll just modify a binary or modify an experiment in one spot. Do you need to rollback a schema change, or can you leave it? Do you need to have a rollback journal to undo data writes? Do you need to have a coordinated rollback across systems, or have an “and” kill switch with any experiment check, so once you throw it you’re back to 0. Do you need holdback to have longer term comparisons to the old call path? Do you go from exclusive old, old + new with comparisons but old result used, old + new with new result used, exclusive new? Creating a correct system seems like a win condition, but without a well-orchestrated, confidence-instilling launch it doesn’t matter.

I don’t know, that was a lot of writing. Hopefully some parts are useful.

I think Ryan has given strong ideas already. I will add what my knee jerk reaction: ageism. Maybe this is strictly about years of experience, and get that you want to “get credit” for the impressive work you did. Things like “when did you graduate high school/college?” Or “when did you leave <hometown>?” Or “we have a great 401k match, have you started investing in yours, yet?” all scream to me “red flag” and trying to see if you are too young or too old or too child-having age, whatever they want to discriminate toward or against.

Don’t mean to instill paranoia, just sharing things I learned not to do, even out of curiosity, and something I look out for.

Everything you’ve said sounds like “they are junior and still cling closely to others to guide their work”. Some junior folk very quickly move toward independence, which is generally definitional of mid-level readiness (not that alone, but it is necessary).

So this person has bad habits, and only works well when given very clear tasks, with minimal (or no) ambiguity, and nothing unexpected. At least outwardly it seems that they don’t even try to unblock themselves, but maybe you just don’t know what they are trying. This sounds like a typical junior engineer to me, maybe you have been exceedingly lucky with others you’ve worked with.

So what are you, a senior member of this team, supposed to do? I would say you need to help them see what a more effective junior does differently (try to idealize, don’t compare directly to another team member), and what someone that is close to promotion to midlevel does differently. While it should be clear that you can’t provide a complete list that, when completed, will give a certain rating or promotion, you should be demonstrating growth areas to them and having that in your own mind. Once you know the gaps, how to fix them will vary.

If you don’t know how to coach or teach one of these things, find out from a mentor or other more experienced engineer. If you try something and it doesn’t work, try something else. If certain things are bad habits, you may just need to tell them, I.e. expect turnaround of a day or more on CLs, any follow-up after 1.5 working days should be in this form. Be sure this is codified for the whole team, not just them.

Beyond all of the strategies, have empathy. They are trying pretty hard, it seems. They follow up perniciously, they request help getting unblocked immediately, and they deliver on clearly defined work. The behaviors you don’t like (and others may not) seem eminently teachable, not deep, irredeemable shortcomings. Assume they are doing their best and willing to learn until you are given proof to the contrary.

I don’t understand this whole story. In terms of facts, the first part doesn’t seem to have anything to do with you. You stated your manager was gone, and more interesting work was given to your team, and another engineer is leading that. Did you feel that you deserved to lead that work? How did it end up led by someone else? When you say you didn’t speak up, do you mean you didn’t ask to lead or own a specific part? None of that seems related to your manager at all.

The next part is more concrete. If it is true that your manager is only critical of you publicly, and never anyone else on the team, that definitely seems problematic. Do you have any additional perspective on this? You may not trust other engineers on the team to discuss it, so it may be hard to find someone else that has witnessed this. Is your manager critical of you or your skills, or of a specific piece of work? Is there truth to the criticism, but the manner it is addressed is bothersome? Have you asked that critical feedback be delivered immediately by email or DM, or in a 1:1, rather than providing this feedback publicly? Maybe it wouldn’t matter, but it’s worth asking.

From there… “deal with him” maybe isn’t the right approach. Either you can discuss this and see if it’s incidental and can be corrected, then if it is “hooray”, if not then next steps. If you can’t discuss it, then you need to move on if it’s that bothersome.

In terms of growth, I think you need to assess if it is truly only you not being given stretch opportunities, or if there are only a few available. You also need to assess what you’ve asked your manager for, what gaps are between your current rating and the next according to him, what gaps are to promotion, and so on. If you don’t know any of that, and you don’t identify what projects or work you need, then you haven’t positioned yourself for growth. If your manager refuses to discuss it with you, or help you find the work you need, then it may well be irreparable and time to move on.

For all you know, your manager thinks you are happy with the work you’re doing if you’re not asking for something different. The criticism may seem incidental to him, and very hurtful to you. He won’t say “I don’t like you” outright if you ask, but you can see if he is open and behavior changes or not and figure it out.

AWS is very different from the rest of the company. There will be core infrastructure things, but a lot of teams are building products that are sold to customers. Revenue is strong. It just is a different beast than the rest of the company.

Retail will also continue driving revenue, but it is a very entrenched business that moves more slowly. Often a pretty big team might own a widget on a detail page, and are responsible for massive traffic and can move metrics a lot with small changes, so it’s high pressure, but can get solid recognition if you move those metrics the right way. Retail is not sexy, it is the warhorse that, along with AWS now, funds everything else.

I worked in Video, and while it was fun, I don’t totally understand why the company is pouring so much money into content. Maybe it’s the hope of ad revenue, even from prime members?

There are some very expensive risks being taken, like Kuiper. It will be a huge success or get shuttered.

I think that your manager is more important than any of this, so finding a handful of things that sound interesting, and gauging by the manager through informational chats or during the interview process (or after if you have an offer) is going to matter a lot more.

The first one gauges if you really have grounds to refer them based on first-hand information or not. If you barely know someone, or only vaguely, you probably aren’t a great source for them being a fit. At best it’s then what I would consider a “sourcing” referral, you pointed them at a potential candidate.

If you actually know their work, the second is your opportunity to highlight why you are willing to (in a small way) vouch for them at tiny risk to your credibility. People bomb interviews all the time, but if you regularly refer people that are duds and can’t clear a phone screen this will discredit you. It may not show up in a review, but I prefer recruiting friends to like me. So this question is basically like… this person led this effort and overcame this adversity. Maybe not full STAR, but a mini version.

Can you draw a block diagram of your system, API endpoints, subsystems, etc. with API calls to your dependencies? Do you know what your call volume budget is? Can you enunciate which are hard dependencies for which of your operations, which are nice to have, which you can survive on cache for on a limited basis? Do you know know which systems can be used async via queues and which must be sync? Do you know where your data is stored and if any other systems access it directly? Do you know what impact slow or failing requests against your APIs has on your callers? Do you know what circumstances may lead to your dependencies load shedding, and how your systems respond? Do your systems shed load, and if so how is this signaled to callers and how do they respond? Do you know steps to onboard a new caller to your system? To add a new dependency you call? Do you understand the lifecycle of each of the requests that come to your system, and where you’ll scatter-gather, versus making certain calls in serial? Do you have a dashboard to see your own traffic, broken down by caller, and the traffic you are generating to your dependencies, including error rate and latency?

It is a lot of stuff. Depending on the system maybe it is too much to stuff into your head, but your runbooks and architecture diagrams should enunciate this, and you should be able to refer to it quickly. If you are creating a new design, and you’re going to be adding a dependency or adding calls to an existing dependency from a new context, you need to be able to identify this, ensure they are aware and you begin onboarding or adjusting your budget with enough time, knowing how you test, etc.

1. What reason do you have to think she would lie? What is in it for her to lie? Avoiding you feeling sad? She has to reject people outright all the time, she can handle it. Why is it relevant if they picked a better candidate from inside or outside the company? Again, why lie? To save your feelings? Would you feel worse if it was a better external candidate?

Beyond all of this: how will your behavior change in any of these situations? If you failed outright, you passed but an internal candidate was picked, you passed but an external candidate was picked? I can’t imagine what you’d do differently now in these circumstances, so it seems like maybe this is only to calibrate your feelings, I’m not sure. You did a good job. You can feel proud about that. You didn’t get an offer. You can feel sad about that.

2. It’s fine to ask. They won’t give you answers. This opens them up to being sued. If they tell you if you did X better you’d’ve been given an offer, but you are able to find through legal discovery that another candidate did not do X and did get an offer, you can assert some sort of bias. I know it is a pain, but you are not getting that feedback. You can recount the interview and your notes to someone in a hiring position there or elsewhere and get feedback, or run a mock interview with similar questions and get feedback.

Things going very wrong, things going very well, and huge surprises seem to be the general categories. Again, don’t focus on one story for each, but certainly anything standout along these lines include in your prep. Consider strictly interpersonal scenarios, not only technical ones. A technical disagreement with a peer is sort of both, but being able to talk through how you resolved a disagreement, or regained trust after it was lost.

Things like what you do when you can’t solve something yourself, or have made a mistake, are also important.

The themes you mention are pretty good, but generally I’d start with what your best stories are, not trying to shoehorn one thing into each theme. You won’t be asked “tell me a time you resolved a conflict”.

You need to have the best stories, that demonstrate you at your best, prepared. Do not game it. Do not over prepare trying to have a situation for every LP. We could edit the list, like Frugality practically never gets asked, but it doesn’t matter. If you try to figure out a “good story” for every LP, you’re going to try to guess which LP or LPs they are after with each question, then you’ll rattle off your prepared story. And they likely won’t get the data they need.

For major initiatives, be able to talk about important decisions you made, results, what you could have done better, and what you learned that you’ve applied elsewhere. Don’t try to spin it as customer obsession or disagree and commit. Tell the story, and expect follow-ups.

If you’re asked about difficult customer and you’ve never worked directly with a customer, you have to use a proxy. “Our PMs are the voice of our customers, and brought us a problem that seemed impossible to solve, and wouldn’t budge” or “our project manager was very inflexible with status reporting and it took a toll on myself and the team, and I worked with them to change it like this…” or “my lead had brought me a design, and asked I implement it as is, but I saw some problems and was having trouble convincing them to change.”. It doesn’t have to literally be a customer. You can say “internal customer” or “partner” to be clear.

Don’t memorize a story unless you really can’t explain things in near real time. Essentially, if you can get by with some cards or notes that detail high points of each story, do that.

4 weeks is a significant investment, so I have to assume the new framework isn’t just “new”, but better in measurable ways? Or enables some cleaner or clearer paradigm in your code?

Can you create a shadow API for the new framework that matches the existing functionality exactly, then defines the missing functions the way you would implement them if it were to be enhanced, then behind that delegate to the old library? You can then write your new code against the proper specification for the new library, but you spend a day writing the shadow API object/interface. You can do migrations as you touch other files (potentially even method-for-method if you use an instance of the old library directly, or via the shadow API initiated with that same instance), so you get more and more compliant to the new library.

You can then, without blocking, do piecewise improvements to the new framework, but not have to do a big-bang conversion when it’s ready, or block building the new thing. Once the new framework is ready, you can first make it “switchable” via the Shadow API, then just change your imports (or whatever for your language) to swap strictly to the new framework once you’re confident in it.

This provides an upgrade path for other systems as they can also use the shim/shadow to do method-wise transition, then the ultimate swap.

Maybe this is totally impossible, and you’d have to derive dozens of result object shadows and so on, no idea what it does. I am only saying that blocking direct work on a new feature or system on a 4 week “nice to have” dependency upgrade is simply a hard sell, and in no way a small undertaking. If the old library is deprecated and you’re adding it to a new project, that is certainly different, but finding a way to keep working while migrating gradually in parallel is still a sell.

Unless using the old dependency is so inefficient to develop with, adding more than the 4 weeks you’d need to switch to the new one, this is a really hard sell as you present it.

Does a product manager think they are good ideas? If so, partner with them, get them to champion it, and get it on your team’s roadmap. If they don’t think it’s a good idea, and your manager doesn’t think it’s a good idea, either you need better support for it (showing market fit, user demand, etc) and be able to demonstrate it is a better way to spend time than your current roadmap. If it isn’t, it isn’t the right thing to work on.

If it is actually small, if you can keep everything else on track and prototype it, so be it. Showing people something, and showing progress in a short amount of time, can make it easier to allocate a trickle of time. Otherwise, and rightfully so, the assumption is that it will be much bigger than you think and will be a whirlpool for time.

The question up top makes sense, but the rest of that seems like it’s copied from a wiki or generated by an LLM.

Read documents.
Write toy code.
Read real code.
Add/extend real code.
Read code reviews of experienced engineers writing Hack, and see what they are doing, and what feedback they get.
Submit a few reviews yourself for minor/softball/bootcamp bugs. See what people say and why you did it wrong.

If you iterate the steps you think are helping (revisit docs after you’ve tried some things and are more likely to understand them, read more code with fresh eyes, etc).

When reading code, ideally find things that are being newly-written in Hack, not piecewise conversions from PHP. When people are writing new, clean code in Hack, what does that look like? You want to emulate that, not the just-barely-converted legacy PHP.

I have to imagine… I can’t remember the name, I think “code lab” is Google’s name… but there are classes that have a “lab” element to do sandbox coding in. Definitely do that, there must be a Hack one, I would bet maybe multiple.

I’m guessing you’re not going to find a ton of howtos online, as Hack, while open source, seems to have limited use outside of Meta (they say Slack and Box, but that’s not critical mass). As such you’re going to be relying on internal resources, but it is invested in heavily, so there are a lot of those. I’d bet there’s “learn Hack” workplace groups and things to get support, etc.

Leading is anything you do that sets others in the right direction or makes them better. Anyone can lead. You don’t need a title or direct reports.

Managing people is taking responsibility for their delivery, keeping them from being blocked or distracted, providing them specific support if they are struggling, giving them clear direction on their performance and promotional potential, assessing their performance, and delivering difficult news (poor perf, no promotion, project is getting killed) with grace. Ideally a manager is a leader, certainly if they are good at their job, but that is not always the case.

What you seem not to be hearing is that you need to stop blaming your reports and start assuming blame yourself. If they do things that higher level people ask (why wouldn’t they? Doesn’t that person have more authority?) and you don’t like that, you need to let them know that any requests of their time can’t be discretionary, no matter who is asking. If the person wants to tell you your report must do a new task, they can. Otherwise the default is always no, because it will require dropping an existing priority. You should be making it clear to others that your reports can’t be available for ad hoc tasks, and telling your reports that YOU are the “bad” one. They never need to say no. They say “I’d love to help, but my manager said I can’t break focus on my current tasks. If you want to see if this can preempt existing work, please talk to them”. Or just “My manager asked me not to accept outside work, and it needs to be pulled in through him” or whatever.

Despite all of this… you being L2, and having two L1 reports, and that after L4 engineer (senior-staff level) the only next step being a full time people manager, is sort of a demonstration of where value is placed. If the company thinks the only distinguishing behavior between levels is direct people management, that’s just a problem. If the best engineers have to leave, stagnate, or move to management, that forces brain drain.

If there are no options but for you to manage people, i think you need an internal mentor that has a lot more experience managing to help you. You also need to dramatically change your attitude. “They are not listening” is not a good assessment. They are listening. Then someone else is giving them a more compelling pitch and they accept that. You are not communicating in a way they can hear and understand. That is shared responsibility, but falls more on you as the manager. You need to get through to them. Figure out how to ensure they take away what you intend. Ask for a written summary, something. If they are getting it wrong you can correct it quickly and adapt your communication.

Also, “lead” and “manage” are different. You are not ready to manage. Leadership would be admitting what you’re good at (and bad at) and focusing on how you can best contribute. That is as an IC. Learning to lead as an IC is a different skill, and you may be better at that. Certainly there’s less at stake.

Your credibility is at much greater risk trying to manage them when you aren’t ready and aren’t supported than it would be to come out and be honest that while you are ready to technically grow to an L5-level IC responsibilities, you aren’t ready or interested in managing people.

You need to dramatically shift your perspective. They cannot self-direct work, you are too hands-off, and have no clear goals or check in structures. I am sure your reports have no idea you think they are under-performing. 1:1s should be weekly at least, more frequent if they are just ramping up.

If you refuse to do what is right for them and yourself, and let your manager know you cannot manage others now, then you need to take a lot more ownership, this is your move, you tell them:
The expectation is you complete these tasks by this time. If there are things blocking your progress bring this to me immediately and we will work through it and adjust the expectations of completion. If you are not doing this, and are instead working on other things, this would constitute underperformance and we will have to document this. I have not done a good job managing expectations so far, or checking in and supporting you. Anything until now is my fault, and I am committed to providing better support and expectations from now on. What happened before won’t be held against you, but we need to work together so we can make up for the set backs I caused you.

You don’t have the luxury of doing deep research and learning what you want to learn until you fix the issues with your mismanagement of your reports. If you can’t manage them well, and take on your tasks, and take time to learn, you have to prioritize them before yourself, and it is further evidence that this is not the time in your career to be a “team lead manager” or whatever this hybrid role is.

You should not be managing people. Period. At this level I can’t imagine why you would be asked to, it’s inappropriate.

It’s not your fault, but you don’t know how to manage people. You should apologize to your reports, and ask your manager if you can transfer them to a more experienced manager. You aren’t learning, your reports are suffering (seriously, you’re going to PIP someone who’ve you terribly mismanaged?).

I guess I don’t have all the information, this could be really unfair, but you aren’t providing sufficient direction and then getting angry about it. If your reports are easily swayed by other engineers you’re not providing the motivation, rationale, or encouragement to keep them on track.

You want to be an IC. Do that. Chalk it up to experience. You learned something (that managing with the level of support you were given is not good for you). Move on, take responsibility for letting this go on far too long, and get back to IC work.

Was there any demonstration of the limitations before you initiated these work streams? I.e. did you load test, showed a breaking point at N TPS, but you know the system will need to support 20*N TPS at launch?

Do you have demonstration of engineering efforts before and after these changes to show that there is higher productivity?

Did you ask your EM if these changes were the right prioritization, versus getting to an MVP sooner, showing real world impact, then prioritizing fixes before launch?

Did an L6+ engineer agree with your assessments and the prioritization of these changes? Do you have their approval and support in writing?

If your team’s mode is feature delivery, and not on-going support and incremental change, then it may be true that your EM values direct contribution to delivery over better engineering. You are asserting that these changes are critical to launch, but if you haven’t demonstrated that, it looks like strictly BE, which may look like it’s at cost to delivery timelines.

When trying to ship something big, I am most concerned with knowing what the first step is we can take, how many independent/parallel work streams there are, and what decisions can be made early to keep those streams running as independently as possible.

Certainly knowing what you’re supposed to build is critical, but something like exact UI design shouldn’t block you building the data aggregator. The exact format of a service reply from a dependency shouldn’t stop you from creating your business logic or persistence layer. What the expiration policy is for retention of your data shouldn’t block design approval.

If you really need a single design to rule them all for the whole system, you should still devolve most of the details to design docs scoped at a module or service at largest. The big picture can compose these, and show overall data flow, have blocks for caches and storage, etc, but semantics of calls or locking or something should be in a lower level design. Having sub-owners for each of these designs, and giving those individuals ownership of implementation (with you possibly owning one, but contributing where need is most) helps further make things run in parallel.

For me this isn’t like… what methodology or what rituals you perform, it is about having the fewest number of blocking dependencies as possible. If a decision can be made later, make it later. If a decision isn’t terminal/one-way, make it with less data and do so early, knowing you can change course later when the new information arrives.

Last thing I can think of is to start any review you need (design, privacy, security, data, whatever) at the start of the project, and provide the assets as needed. Get these done as soon as you can. Waiting until code complete makes this a huge serial effort when you have the least wiggle room. If any of these trigger required changes, the sooner you know the cheaper it is to fix. Again, if you can decompose these to module or service level, instead of needing a single reviewer that groks a giant system, that’s great.

So really, what I think the “good parts” of Agile or Scrum or whatever are isn’t like… having a standup or whatever, it is not trying to write requirements in stone with every possible contingency covered, then starting coding, then doing iterative testing, then doing documentation, then doing internal reviews. Doing least-informed decision making, working on all stages in parallel, and changing course as soon as something is known, tends to go way better.

There are, as I think of it, levels or stages of mentorship and multiplying impact. 
1) You can’t really help anyone, you’re just learning yourself. How you can have impact is writing down every question you have while learning and their answers, noting everything that didn’t work (and what you had to do instead) while following the on-boarding documents, anything that wasn’t easy to understand, and so on, then make sure your notes are correct and codify them by publishing a “read-along” of the onboarding tools, updating the onboarding documentation, etc. Contributing to future onboarding success as a new team member is great.
2) You are comfortable helping new team members with their onboarding. You can walk them through tricky parts, answer their questions, etc.
3) You’re comfortable mentoring/coaching 1-2 people 1:1, helping them improve, move toward promotion, making better choices, etc. You are comfortable with 1-2 people pairing with you on a project and directing their work.
4) You coach or mentor many people, have an understanding of needs across your team and make improvements, you are able to teach others how to effectively mentor or lead a small project, and you can lead larger projects with 4+ other engineers, making all of them better as they work with you.
5) You are coaching many people to coach effectively. You are teaching people to lead large projects. You are able to delegate large project ownership to others with the right level of involvement to make them succeed at delivery and making the other participants better. You have cross team focus for engineer experience and making improvements.
6) You can teach people to teach people how to coach. You can coordinate multiple large projects led by others and make sure they are all working well together. You focus on an org, and improving things for everyone.
7) You can codify coaching, teaching coaching, teaching teachers, etc in a standard program. You may run this program initially, but should hand off ownership. People can take these classes and become better leaders, regardless of knowing you or being in your org. You help others codify their own areas of expertise to teach at scale. You improve experience for engineers across orgs, or a whole company depending on size.

I’m sure it can scale to industry-wide impact, too.

You need to learn to put practices in place that work without you there. You want to be the “top” of a coaching tree, where people you taught are prolific, people they taught are strong leaders, and so on.

If you hand someone something and they don’t follow through, it’s their loss. You can give them another shot but you partner more closely, or hand it to someone else and let them know you’re happy to help them again when they can commit. 

If you aren’t able to communicate details and that’s why they didn’t succeed, then you know you don’t actually have that ability down, and you either shadow really closely to fill in gaps next time, or you do it yourself more and document more completely, assuming you need to show someone starting from zero how to do it.

What are you trying to achieve? Getting attention on LinkedIn? Getting your resume through an initial pass at a future employer?

Amazon wouldn’t tell them you were an employee. Amazon doesn’t (as far as I know) directly contract, so you didn’t have a contract with them. You worked for an outside firm, and that firm had a contract with Amazon. Amazon didn’t pay you. In terms of experience, it is great if you were embedded with an Amazon team and were able to learn from there. If you delivered significant work on your own, that can speak for itself when discussing it or on your resume. I would still be cautious about indicating you worked there.

I obviously am coming at this from an angle where I have past and current employment at “FAANG”, which is a privilege and makes it harder to like… say who or who not should claim this.

Saying what’s true, that you were assigned to an Amazon contract and delivered X, seems absolutely fair and correct. Otherwise it feels like a risk of misleading. I guess it’s a trade off between the benefit of those you successfully mislead, or are fine with this representation, versus the detriment of those that find the claim disingenuous. The harm of the latter seems significantly greater than the benefit of the former, but perhaps only on an individual basis, and in aggregate you think it’s a net win.

Safety is really hard to discern before you’re really working on a team. I find that many big companies have a lot of positives being neurodivergent, like affinity groups and insurance coverage for things like occupational therapy and other autism-friendly supports (mostly allowing these to be billed in-network for out-of-network providers because the services are less common).

What safety might mean to you also matters. Does it mean you are comfortable disclosing to your managers and peers without fear of rebuke? Does it mean flexibility in working style? Does it mean inclusion and accommodation even if you don’t disclose? Does it mean access to other ND peers?

I didn’t have a diagnosis while I was at Amazon, but just sort of knew I was different. When it came to WLB (Jeff wanted to say work life harmony…) I just had to set the boundary myself. I had a family, which many younger engineers didn’t. I maybe hid behind this, but still tried to champion for same work, no heroics, etc. for everyone.

Meta had a reasonable internal community… but I can’t remember a ton about it. One thing I remember was speaking at/mentoring in an event that was geared toward college-attending autistic folk, intended to help move forward with resumes and interview scenarios.

I do love the Google autism ERG. I do like some of my teammates a lot, and I may still feel closer to some of the folks active in the Autism community. When I’m freaked out or struggling I’m likely to ask them first. I have presented some slides and thoughts about autistic inclusion, being an ally, etc in a few orgs. It is well received and I have had some good follow-ups.

I can’t say which of these places has been best as an autistic person. I feel like Amazon was most rigid, which meant rules (leadership principles acted in this way), and I do well with rules. Secret rules or norms are tough, and while they did exist I did learn to navigate them. I knew how the rating system worked and how to use it to my advantage. I knew how to get people promoted. I had sort of cracked the code. Meta was awful because I just didn’t fit. Team match was hard, setting expectations was hard (I wrote up a launch plan, had it approved, and was then given another one 6 weeks later and was told I was behind). I don’t think it’s all bad there, but my experience was. Google seems to fall in the middle. I have survived longer here than Meta, but don’t feel like I have the mastery I did at Amazon.

Honestly I strive for autonomy because I know if I can work my own way I can do amazing things, and am stifled if things have to be “just so”. I keep thinking the next promotion will grant me that autonomy. That hasn’t worked so far.

I don’t have experience in entrepreneurship, so can’t say how you achieve balance there. Zach Wilson, popular data personality and ADHDer, said he’s working 80 hours per week, but is also wildly successful and seems happy, so… that’s cool? I am terrified to try my own thing which makes me sad, but it is what it is for now.

Not sure how helpful this is, but really I’d be looking for health of an ERG, and might even ask if you could speak to someone in one of these groups. An HM might not know anyone specifically but I am betting they could talk to an organizer and get a volunteer.

So a priority queue that trims everything of lesser priority on insert (lesser would be based on directionality)? But you normally use it for indexes into something else?

This is probably really important for certain things. It is not a type of problem I’ve needed to solve, but that certainly doesn’t mean it isn’t valuable.

I consider myself… I don’t know, pretty good at understanding things… I don’t know if this subject is over my head, or if your writeup is assuming things about the reader, but even having eventually worked out how the structures work, I still don’t really understand how it solves these problems.

It’s admirable to have written this up, and I’m confident there is an audience for this, and I don’t think I’m part of it.

You’ve already gotten a lot of great input. I will share my experience going from a mid-level engineer to “level 0” people manger, to “level 1” people manager, then back to IC at staff level.

These aren’t very similar roles. At Amazon, there is not a Staff level. L6 is senior engineer, L7 is principal. L6 was when many engineers didn’t see a path to L7 as an engineer, or wanted a change of pace, and moved to people manager (SDM there). Amazon doesn’t have a hybrid IC/manager role, but Meta and Google (and likely others) do. They call this Team Lead Manager (TLM), and generally give someone fewer reports than a dedicated EM. This is often a “test the waters” role. I guess some people might stay there for a long time but every TLM I’ve known has moved to a dedicated “org leader”, meaning engineering manager, or have moved back to full-time IC work.

I will describe my conception of the difference:
As an engineering manager, you try to remove administrative, and occasionally technical, blockers from your team so they can do their best work. You support their growth, but this isn’t always technical coaching. Often this is OK, because growing above mid-level is often more focused on soft skills, which a manager better have a good handle on. An EM spends a ton of time in meetings that have no one else on their team in them. Managing up to high levels in the org, justifying team focus, need for HC, selling a roadmap, etc. Managing laterally to bargain with other teams for who does what work, when it will be done, etc. Sometimes EMs will review a design, but rarely as a sole reviewer. A manager does a lot of work, but it doesn’t look like engineering work. They point people in the right direction, then try to get themselves and everyone else out of the way. I say they “lead from the back”, because they are not doing the same work as the people they support.

As a staff+ IC, assuming no people management, the way you support the engineers you’re responsible for is very different. There’s more direct input to code and design, there’s more work on actual technical process and tooling because they should know what parts of the process are painful, often participating in the dev process themselves. They design larger systems, or support others who do so, even if they won’t be involved directly in implementation. When they are managing up, it is often working to get people in the right place to get something done, or providing perspective on the technical state of systems and where investment is needed. If they are running a project as a lead, they may be talking about dates and progress, but that’s often not the main focus. For managing across teams, it is normally being a facilitator. Instead of debating who does what, they help teams understand the best technical approach and let that guide the decisions. They often hear more real feedback from other engineers that a manager may not, and ideally can champion fixes for these things.

In terms of “why”: for me, I was burned out on my leadership making awful decisions, and protecting my team from them. I was over getting HR directors involved in poor practices in rating employees, etc. I was spending all of my time trying to salve self-inflicted wounds, not helping my team achieve bigger things. I wanted to be reviewing designs and code as a primary part of my job, not an ancillary, unappreciated part.

I say all this, and will probably manage people again at some point. The time is not now.

I guess if you are providing the employer a value of full time pay in part time, I don’t think there is anything like… morally objectionable to this.

If you commit to do work, and do it in whatever time you allocate, cool. If you are leading them to believe you’re working full time… I don’t know. Grey area, leaning toward “I don’t like it”.

I don’t know anything about contract work, or being a partial CTO or whatever, so… *shrug* maybe others have a better take on this.

Are you hoping to get a 1099 job where you’re paid for full-time work and work part time? Or are you expecting to work “normal” hours for one of these companies and just need to know what hybrid schedule looks like?

I was full remote at Google until a few weeks ago, and am now hybrid, going to a local office 2x per week. The 2x per week was established from my org when RTO happened, so that’s why this is the standard. I am adjusting, it’s going OK.

I consider attending meetings work, but I have a pretty significant amount of time to be heads down. Much more than when I was at Amazon (even as an engineer, but as a manager it was close to no time out of meetings). Right now I probably have 4-6 hours of meetings per week. I don’t count a huge org all hands type things where I have it on one monitor passively and still work on other things, but that’s maybe an hour meeting one a month.

Alex covered a ton, I can’t hit a lot else, but will mention this:
In my experience and in a ton of examples in Larson’s Staff Engineer book… a “Staff project” is about 50/50 in promotions. Looking for such a project, and setting your sights on it, could end up not having as much impact and visibility than other cross-org or company programs you could set up, or work you could do. Focusing on a “big bang” project isn’t necessarily Staff behavior, doing the really challenging work that others won’t or can’t, seeing around corners, and making everyone better are. I know you didn’t say this would be all you would do, I’m just saying that if you’re doing everything else, and getting deep knowledge of product and team, a project opportunity may come up. If you are focused hard on finding a project you may not be doing everything else.

I’m sorry if my replies made incorrect assumptions or mischaracterizations. Any discussion of these type of issues on Blind is certainly triggering, and the use of “won” describing a decision being made to use one design over another was also problematic for me. It is likely unfair to ascribe blame, my intention was based on a feeling that you were treating the situation as a competition with this other team. This reply of yours may be affirming that, and that’s fine.

If your org punishes managers for trying to make improvements that is worrying, and as you stated is maybe out of your scope. This was why I suggested involving a lead that may be in a better position to affect change.

Yes, a lot is lost in async text conversation. Happy to chat on the Slack. Obviously I can’t initiate such a contact.

If Alex or Rahul think any of this discussion is out of bounds I’m happy for them to request edit or deletion or do that themselves. I was stating my opinion of the appropriateness, but wasn’t claiming to be the last word.

Regarding “fixing everything” I guess I am overzealous on that and do try, but recognize that isn’t always practical.

Good luck, enjoy.

I may have misattributed tone in your message above. The list seemed to be enumerating how they are wrong, and how your team is right. More worrying is the us versus them attitude.

Maybe you are not comfortable soliciting help from your director, and working toward a solution that helps everyone. If so, talk to your lead, or the Team A lead and ask them to do so. This infighting between your teams is bad for everyone. I am really suggesting being on the side of fixing the problem, not perpetuating it.

I think this is exactly the kind of conversation that belongs on Blind. It started with a process question related to code changes and turned into a discussion of the real problem, which is this on-going internal conflict.

This is dysfunctional, but you are an active participant. No one is “winning” when engineers can’t discuss and choose the best approach and the only resolution is through escalation. You seem to be delighting in your team winning, the other lead having to reshare a document because you escalated without discussing it and coming to a resolution, etc.

You are on the same side. Fixing the dysfunction is the problem, you’re all worse off as long as it goes on, and it’s bad for the org and your users. You are part of the responsible parties in fixing this.

You are delighting in a Blind “vote”, one of the worst, most toxic places on the internet when it comes to our industry. That there are active discussions about this in an anonymous context, with people chiming in to slam other teams. Yuck.

There is no benefit to team A to slow you down for the sake of it. They are assuredly getting pressure to finish their own tasks, and they have cited away team support as an impediment. The easy move is to try to reduce that via process instead of developing technical approaches to shared ownership.

“Evil thoughts”. This is work. I doubt seriously anyone is trying to actively sabotage other teams. Even if they were, that’s not evil.

In the same paragraph you state you have empathy but then state they have strong opinions on trivial things and that they are incapable of thinking of other solutions.

How are you working actively with them to fix this? When are you deleting Blind? When are you meeting with your shared senior manager or director to ask for help improving the culture so everyone can work together more productively?

I would say one can’t have their cake and eat it, too. If there is a clear business reason for outside teams to contribute to your code, that needs to be manually supported or a model of co-ownership via plugins or whatever is really critical. Saying no to both, or making it difficult, isn’t really feasible.

I think that this “we have to touch so many places, so a plugin won’t work” is totally understandable as the system wasn’t designed for extensibility like this. Wiring a plugin instance to all of these different places assuredly feels impossible. This is a bit chicken-and-egg. One can say that extensibility is needed first, and wait, or wire a proto-plugin setup first then push toward the goal that way.

In the latter case, for each distinct behavior you modify, I would make a functional interface or whatever that describes what happens there, I.e. userUpdateInterceptor or onSubscriptionDeletionResponder. You may have a dozen of these, but if you scope this properly, it will be very clear what each piece is for and what it’s doing. The plugin itself can have Optional elements for each of these, and only provide what is needed for each feature. Then you provide a multi binding, where you register your plugin, and whenever these behaviors are needed, a List of nameOfBehavior is passed in. I am thinking in Java but this can be adapted. pluginList.stream().map(PluginType::getCoolBehavior).flatMap(Collection::stream).collect(toImmutableList());

That could also be abstracted to a generic method that takes the PluginType function for extracting the needed behavior, so that boilerplate is hidden and you just see calls to getBehaviorForPlugins(plugins, PluginType::myBehavior). Then in the code that runs this, you determine an execution style, isolation levels, etc. Do you need to count errors per plugin, etc, make sure a plugin can’t crash you, determine if plugin behaviors run on the critical path or on another thread, etc.

For the first go ‘round to try it out you don’t need to do all of that, but would set up any places you modify to have a list of the behavior interfaces passed in, even if you’re just going to pass the reference in explicitly.

When it comes to new plugins needed new behaviors, the plugin interface itself should be updated, with every behavior-yielding method having a default that returns an empty optional. That way, all existing plugins will just have an empty version of that behavior and none of them break.

It doesn’t mean no reviews ever, but essentially you write you whole plugin for a new feature in your own code hive, get it reviewed and approved by your team, then the add to the registry (with an experiment that controls if it is added or not) is what the other team reviews, along with new behavior injection/addition. There must be rigorous testing, but it changes the place where the teams intersect.

This wasn’t your question, but I just hate when engineers are essentially set up to conflict because investment is being made in these cross-org away team model tasks and not in removing that need.

I have also found luck, when things can be async, to just publish a signal to a queue in the host system, then subscribe in a completely separate service your team owns, and do whatever work you need. This relieves even more testing burden from the host team, because no matter how much work you do or how often it fails, that’s irrelevant. They ship signals, the rest is your problem.

You could ask them what problem they were solving with this, in case it would help your team with supporting away team contributions.

Almost assuredly they accepted an away team contributing, maybe a lot of times, and the level of engagement required for this was much higher than was expected or promised. They got none of their own work done supporting these projects that they rejected doing themselves due to priority. They need to protect their time, and deliver their own projects.

If their code needs to accept contributions, working toward a plugin model, or an async mechanism to publish changes, or some other way for others to own their own code, and have it integrated in a standard way. Everyone is sad when the away team model is used.

• Don’t create slides 

• Don’t try to be funny 

• No slides, no memorization 

• 2-3x the length running through it, recording, listening back, doing that again. 

• Other tips: Most of the above is joking, but not all of it

It sounds like you’re not a “natural” public speaker. Public speaking is directing and maintaining attention. If you don’t have any of that yet, start small. Don’t try to give a company or org-wide presentation. I did and regretted it, but it did sort of “break me in” and make me more comfortable later. I would recommend owning team meetings for a while, running some social events, being the emcee at some smaller meetings (introducing other speakers, providing time checks, ensuring there’s a way for people to follow up with presenters).

If you can, start a book club, and you get it organized then direct who will present what, then open each meeting, turn it over to the presenter, and set the table for the next session at the end.

Work your way up. Do an engineer-only knowledge share or show and tell on something you’ve worked on. Be responsible for inclusivity of remote folk in meetings, getting questions addressed, ensuring microphones are used, and so on.

Eventually you want to be able to run something with no knowledge of the subject matter, introducing and transitioning people, or to be able to give an ad hoc elevator pitch of the work you’re doing, or what your team does to someone who is unfamiliar.

In terms of slides, my real advice: • Don’t. Show a demo video, or draw, whatever. 

• if you must, very few slides and NEVER READ the slides. The slides show graphs or demonstrate details that are harder for you to talk through. They have links or ways to reach out after (and you share the slides). They pace with per-topic intro slides. You don’t want to be reading slides, and you don’t want the audience to be reading a wall of text while you’re speaking. 

• I really don’t know about jokes. I consider this a nice-to-have once you have everything else down. Throwing memes in slides or gifs or whatever… you can maybe do one, but be interesting before you’re amusing. 

• You don’t memorize slides because you aren’t reading slides. I find memorization or a script kills any human element. I like to have a bullet list of important things, and go through the presentation filling in the gaps and record it, and see if you need to change order, add bullets to ensure you hit important points, etc. I like to use the presenter notes in slides to aid with pacing, but this is my bullets for the section, not a script to memorize or read.

Dont be fussing with slides or bullets at the last minute. Give yourself a deadline and just finish it. You can still practice, edit if you absolutely must, but doing the work on the slides until the last minute means no practicing with your actual materials.

If you are giving a huge presentation at some point when you work up to it, give the same presentation to your own team or org. Yes, they will have to hear it twice, but you get practice and can hone, get real feedback, etc.

Them getting you sick with something you’ll recover from is sort of a personal thing you are mad about, and acting from there is not going to go well.

The bigger picture is that, when sick, people can work from home. There is no reason to come in sick. If you have to (but you don’t), wear a mask (did they? Did you?).

I will further state, though, that while them coming in sick was irresponsible, you were likely already infected from earlier in the week but were asymptomatic. Yes, they may have been infected first as their symptoms started first, but if your symptoms started Friday you were likely infected on Wednesday or earlier. Not saying this excuses them, but might reframe that while you disagree with their choice, you were likely infected before they made that choice.

I don’t think you’re in a state of mind to have a blameless postmortem on this and derive any useful action items, because you are completely in a blaming mode. If you can move past that, I think action items should align with your employers guidance. If it encourages staying home when sick, that should be honored. If they come in, I think wearing a mask AND staying away from people would be a respectful approach. Go to a separate room or stay at your desk for meetings, even if everyone else is in the office and has a room.

In general I don’t think you will alter other people’s behavior here, though. I think “I am very concerned about getting sick and infecting my partner” without stressing if there’s any heightened risks, etc and saying you’ll work from home while folks are sick in the office is the best thing you can do personally. If you don’t have the autonomy for this and will get in trouble for not being in person, you may be out of luck. You could subtly start leaving a box of disposable masks in the team area, making sure there’s hand sanitizer and use it frequently (there is pretty intense peer pressure for things like that), using hand sanitizer when entering or leaving any conference room, etc. If you just make these all-the-time habits, it doesn’t single any person out, leading to conflict.

Mid-level can have a pretty broad range. The entry-level roles will “age out” if you haven’t advanced to mid-level after some number of years. Mid-level may not be a “career level” everywhere (senior pretty much always is), but it still applies to a wide variety of experience levels.

At Amazon there were plenty of people at or hired into SDE-II with 10+, and rarely 20+ yoe. I was hired to Amazon at this level after about 8 years of experience at smaller companies. I wasn’t promoted to L6 (as a manager) until I was over 15 yoe total.

The approach may vary when it comes to how you prepare to level your skills up, become a better designer, and generally be on a more direct route to senior level behaviors. If there are truly no opportunities to gain those skills where you are, you sort of know it is not a place to keep growing. Otherwise you need to find how to position yourself with your manager, peers, more senior engineers, a mentor, and potentially a sponsor to start getting the opportunities, stretching and growing your skills, and having visibility with the people you need support from.

If your current company isn’t it, there are sort of… safe bets for growth opportunities. Giant tech companies are an avenue, but also may not promote you when you’re ready. You’ll grow, but may feel stuck in a rigid system. I don’t have startup experience personally, and I’m sure it’s not uniform, but certainly building from zero is a very different when it comes to explosive growth opportunities, and less gating to taking on stretch projects and having immediate impact.

There are plenty of individual behaviors required, but I’m guessing that’s covered in a master class or other answers. You need the opportunity to exercise those behaviors.

It will save more than 1-2 years. Having gotten a senior offer, and coming in at mid-level and hoping for a fast promotion once you get comfortable is unrealistic. You’ve demonstrated your abilities in the interview, but that’s not how promotion goes. You have to be acting in your new level for some time (6-12+ months), you have to have collateral, support from senior+ engineers, a competent manager to help with your doc/portfolio, and so on. I can only speak to Amazon as it is where I managed people, but MANY first attempts at senior promotion fail, and while some managers are aggressive and try again in six months, filling some significant gap often comes up, so it’s another year.

You are going to feel out of your depth whichever level you come in at. You will likely have access to senior+ onboarding buddies, mentors, etc if you come in at senior. You will likely have mid level folk helping if you are at mid level. This can have a major impact on your ramp up.

At many of these companies, the first promo from entry level to mid level is expected in 12-18 months, and after that there is a literal clock in some cases. If we imagine it took you 12 months, then 2.5 years more may be aggressive for a senior promo, but definitely not unheard of. Yes, you got that experience elsewhere, but if you took on complex projects and were very self-driven, it is very possible you are at that level and just selling yourself short. I didn’t get to that level in my career for 15 years, and it was as a manager rather than engineer. Time doesn’t matter as much, and while you may have done interview prep, understand that every other candidate has, too, and they didn’t get upleveled.

Further, upleveling is rare. These places downlevel all the time, reject tons of people on-level, make plenty of offers on-level, but to change course midstream, adapt the loop or have every person capture next level data, and be able to make a hiring decision is simply a tremendous anomaly. You didn’t trick them.

You can take the offer and remain humble. You will have a lot to learn. Sure, you don’t want to accept it and get fired right away, but you should have faith in the interviewers, hiring committee, or whatever other process happens that you are capable.

Do you know Java? If not, start there. Have you worked in any other iterative, C-style language? And/or modernish OOP language? If yes to those, it shouldn’t be hard.

I actually don’t know the right way to start learning Java. I imagine looking at existing code and solving problems you’ve already solved in the language. I guess you explicitly mention Java, but… are y’all not using Kotlin? I don’t know that it’s easier to learn than Java, and if there’s an existing codebase with Java I guess even if you focus on Kotlin it won’t be all you need.

OK, so Java… language-wise, not complex. More involved in my opinion, is the Android framework and specifically managing lifecycles of various elements. Fragments, Activities, Views, like… understanding when to do what, and also what must run on the UI thread, and how you bounce things off that thread to do something heavyweight, that then uses a callback or other redirection to update the UI back on the UI thread. I would say that asking someone that’s familiar to show you examples in the codebase would help, and just reading the Android documentation.

From there, I’d try to work on existing code, fixing some bugs and things. Maybe small feature changes, but not tremendous changes to UI Views. Make sure you can make your way around the app, see how network calls happen, how that makes its way to the UI. If your team uses MVVM or something, learn about where the models are, Views, and ViewModels. Maybe learn 3 things about a more exotic UI element like a RecyclerView.

Only when you can do the rest of this should you get involved in actual UI changes via XML. I got confused at first because while they definitely are XML I guess I always felt like I couldn’t make sense of XML and the docs for Android make it not very hard. Again, find out from your team how much is done in the xml and how much is done in code.

Is the expectation that you pitch in for a few weeks, or take a major role in Android dev? This could be over investment if it’s short term.

I think Rahul used to teach Android dev? And likely has YouTube videos?

Read “Effective Java”, as mentioned. Ok, now do it again and write code samples or find ones in your code to fix to adhere. Alright, now codify the rules in your linter and make it part of the coding standard for your team (with whatever exceptions are a must). Read it again.

Read “Java Concurrency in Practice”. Explain to the most junior engineer you know why the idiomatic solution for double-checked locking works (with volatile, with local cached version, etc). Then explain that this is why you use memozing suppliers instead of hand-writing this. Write different concurrent code with native @synchronized critical
sections. Do it with methods instead of a brief section. Use ReentrantLocks instead. Now do it without locks using Atomics, Suppliers, etc. Ok, now with chained futures. Alright, do readers/writers. Ok, now modify criteria with deadline for readers to avoid starvation if many writers are queued.

Learn how to create type safe arrays of a type determines via reflection. Now never do that in production code.

Compile a class file. Use javap to disassemble the class file. Make changes, do it again, see what changes. Dex it for android, then use dexdump to evaluate the dexed version. Repeat all of these steps. Tell me why you can’t have more than 65536 methods in one dex file, and which instruction is the limiting factor.

Write a function in C. Have it add or multiply two numbers. Simple. Call it through JNI.

Read the source code for Java and Guava collections.

Oh, now that you’ve done all that: why do you care what’s under the hood? Are you needing to write your own JVM or a new GC, or needing to tune behaviors for a given workload? Do you just want to write idiomatic Java and know how to debug it? As mentioned above, this is X-Y. What do you want to achieve, and why do you think knowing java under the hood will help? 


> Should I expect acknowledgment or appreciation from my manager for these extra efforts?

No. You are working more. They didn’t ask you to, and even if they did it was up to you. If you said you’re going to put in extra hours for a month to solve some huge problem and you do solve it, you will get credit for solving the problem, not the extra hours.

> Is it beneficial to communicate my extended hours to my manager…?

Probably no. I think you need to figure out if the team is all over-worked, or if everyone else is working sanely and you are not, and figure out why if the latter. Alex mentioned focus and efficiency. If your tasks are mis-scoped communicate that. You’re not getting a bonus for working extra hours.

> How do managers typically view overtime?

If you’re exempt, it’s not "overtime". But in terms of working many extra hours… I would prefer you didn’t. If you boost productivity in the short term, you’ll set incorrect expectations on what you and your team can deliver, and you’ll get stuck in a cycle. Your work quality will decline, your productivity will drop, and your team will be even more overextended. Work at a sustainable pace, and set expectations accordingly. If your workload can’t be done sustainably, that needs fixing. Again, if it’s just you maybe you need new approaches. If it’s your whole team you need your manager to know and fix it.

The technical leadership track is not about becoming more technically proficient in some stack, or knowing 3 more patterns, or nuances of your favorite languages compiler. Designing something important, and being able to manage dependencies, other engineers (and make their work better because you’re there) contributions, launch with clear metrics, and maintenance without a huge human cost matter much more than you, individually, designing extremely complex systems.

I will note that collaborative editors seem scary, and there are weird edges for sure… but most documents are written by one person. When there are multiple editors it is a few to a few dozen. I honestly don’t know what 500 people actively editing one document looks like, but that’s rarely v1. Ten in-flight edit operations with sane resolution mechanics is probably enough to get started. The scale for docs is a lot more about breadth (billions of documents) than concurrent editing of a single document. One of these is much, much harder than the other. And once you solve one for a smaller number of in-flight operations, scaling that may not be as crazy. Note I don’t work on docs, but imagine dispatching the 200 in-flight edits to different hosts in bundles based on nearness in the edit point, then recombining the results after these are all resolved, push that state back to clients, etc. I’m sure this isn’t how it’s done, but you don’t have to know either. You need to have common sense design skills for the domain you’re working in.

You listed 3 things you’re doing:
Org-spanning projects
Org-spanning impact (through projects or other behavior?)
Multiple mentees

Ok. That sounds like seniorish behavior. Are you scaling mentorship so that other senior or mid level engineers are learning from you how to effectively mentor, and setting up a cross-team matching program to get more people mentored and mentoring? You need to scale yourself. 3-4 mentees is a lot, but priming 3 new mentors every 6 months, then moving on to teaching the original batch to teach others in a year or so means multiplicative impact. What you do by your own hand isn’t enough, you need to multiply impact through systems, programs, and elevating others to do what you can do.

With org-wide projects… that’s cool. Did you design it from the bottom-up? How much responsibility did you have for delivery, how many engineers’ efforts were you directing during implementation, how many course corrections did you make to stay on track, how many stakeholders did you keep informed on a push basis, etc? The project matters, but your behavior matters more. How a junior, mid-level, senior, staff(+) handle similar work is different. Considerations are not the same. How it never has to be done again, or made less painful happens at higher levels.

Years of experience is a poor metric, but some companies will gate on this if there’s no clear guidelines and more senior people to assess candidates for promotion. Have you asked for differences between you current behaviors and what a promotable candidate would look like? Have you asked where your manager thinks you are, and how far you have to go?

I will note 5 years is… a good start. I know folk have grown to staff quickly. These wunderkinds are not the standard. I worked in smaller companies for almost ten years, then worked another 8 or 9 years in FAANG before getting to Staff. While YOE is not a good proxy, I think you should be realistic about your progress. What opportunities are being gated by this promotion? What will be different if you get there in 1 year versus 3 years?

Your friend/manager sharing performance comments about other engineers is totally out of line. It’s already dicey that you had a personal relationship, they interviewed you, and they are your direct manager. I can imagine the senior most engineer/lead being given some direction on who needs help, etc., but just tossing out “yes, S1 is underperforming” is really problematic.

M+S1, Y+S2 :: M+S2, Y+S1 :: M+Y, S1+S2. These are the possible permutations, that’s it. 3. The manager not trusting you, so not giving you a meaty project seems unlikely. They aren’t giving S1, who they have determined to be an underperformer, an important project. 1/3 of the time, you’ll be with S1, the rest you’ll be with others and likely get better work. Have you told your manager you think you were given the less interesting project and want to stretch on more ambitious projects?

S2 has the red flag of saying “You look like you can’t code”. That’s super problematic. I would recommend checking in with them to make sure you’re progressing in their opinion, and actively seek constructive feedback. If they are demeaning, that has to be addressed. If this was a jerk thing and they move past it, it’s not good but survivable.

I don’t intend to criticize, but if you’re referring to folk in a non-gendered way, just use they or their name/“label” (Senior 1) if “they” would be ambiguous. S1 got one “his”. Generally I appreciate degendering, but I can’t “skip” the paired pronouns and it’s a speed bump.

Focus on your manager’s feedback and direction. There’s nothing you can do about your manager’s feeling about S1. If S2 is a jerk again, it’s worth mentioning to your manager. Focus on what you can control, which is the work you do.

This is not a make-or-break conversation. You don’t need to impress them, be a person. Ideally you sow seeds of an ongoing relationship. Even if it’s not formal mentorship, being able to ping them with quick questions, whatever… that’s real value.

The “easy” things to ask would be things like “What do you wish you knew when you first started here?” and “Who do I need to know to be effective?” and “What is the worst code we have, and how can I learn it?”. But really… you don’t know enough yet to ask any really probing questions. Most important is “Can we meet again in 6 weeks when I’m terribly confused?”.

If your EM cannot give this person critical feedback on this negative pattern of behavior, they need to escalate. This is not acceptable.

You COULD ask the E6 where in the issues delegated to you that you can find the required information, as it feels as if you should be able to find this yourself based on their response to questions. If there is none, you can then ask “is there another method you’d like me to use for knowledge transfer on tasks? Right now I feel that I’m bothering you when I ask in X or Y forum, and I’d like to smooth this out”. Something like that. But I feel like this person has… something else going on. I think they have technical depth that their level requires, but does not have the soft skills required. They need support in developing this. Your skip or a more senior IC in the org may be able to help, but this person needs to accept they need the help. Feedback from a high enough level may get them there, but it may not.

You can also leverage your EM and ask them to triage these issues coming from the E6, with a standard format that includes the details that tend to be missing. If the E6 won’t follow the process, then it has to get escalated.

It is my opinion that someone at this level helping a more junior employee through a sensitive HR situation is sort of part of the job. Yes, it was nice they did this for you, who is in another org, but their impact should be very broad.

This feels more like you should write and send a hand-written note thanking them personally. From there, sharing with their manager or HR in their space seems too convoluted. At most you could say “I had a very difficult and sensitive situation I cannot discuss explicitly, and person X went above and beyond to aid me in navigating this. Without help on this matter &lt;fill in, would you not work there?&gt;.” That seems to cover like… a great thing was done, but it cannot be discussed.

It sounds very, very difficult and am sorry you and your team are in that situation. The old team didn’t hold up because what is being asked is impossible. Step one is to protect the team’s ability to function long term, and that means working reasonable shifts and resting. If this means, for a short while, you have one person from each discipline on-call so they can be putting out fires, and others are resting, then there’s “recovery days” following on-call, do it.

Automate, and simplify the hell out of things. Do things run out or disk space? If more disks can be thrown at it, so that. If not, rotate anything that uses space off aggressively and automatically, and have alarms that escalate as the disk gets lower and lower. Have fix-it scripts to aid in cleanup if a human has to do it, but make that the exception. If the systems you support are unstable over time, look into rotating servers out of the active pool and restarting services however often it takes until you can figure out what is leaking memory, file handles, or whatever else causes time-impacted instability.

Ideally I’d try to have 3 designated work types:

- On-call
- Automation/operational tools
- Core systems stability

It may not mean that every week people swap, but you need to guard people’s time to be able to focus on fixing the sources of the fires, not just putting them out.

On-call should be generating hash marks every time a particular issue occurs so you can have that guide prioritization of tools to automate or simplify repair, and fix root causes.

You should invest in growing your ability to handle greater complexity and more ambiguity. You should invest in growing soft skills, decomposing work streams, mentorship, and other soft skills.

In 5 years whatever tech you invest in will have changed dramatically. How you manage complexity, ambiguity and interpersonal communication won’t.

1. If it’s 5 per week, I feel like you can answer. “I’m not in the market right now, but good luck on your search!” Is easy. If you want to be specific “I’m not interested in consulting roles right now, but I appreciate the consideration!”. That’s 30 seconds. If you do 5 at the end of the week, that’s 2.5 minutes. Recruiters are valuable connections to have.
2. Where you’ve worked may affect recruiters, but once you get an interview (via a recruiter connection because you don’t burn bridges), as long as you’ve done complex work, and have the right skills, the interviewers or selection committee won’t care about this Tier stuff.

If there are two people that can do this work, you and an E6, and the work that needs to be done is “lower level”… it has to be done. You can try to decompose it so you can both knock it out in a week or two, you can have a “get it done” rotation by project or month or something… but the bottom line is they have seniority. You should be shadowing them on the work they are doing, contributing where you can, etc. but sort of have to accept they are better suited to take on that work now. There’s times that simply require delivery, and times you can stretch and grow. With two iOS engineers, though, unless y’all move to a shared code setup that allows other devs to contribute, you cross train, etc there probably isn’t ever going to be a time you’re not building workaday features.

It sounds like hiring an E3 or E4 isn’t an option, not sure about cross training, but basically this isn’t a team to grow on with the current composition. Maybe you can build something that allows no-code/low code feature addition to accelerate that stuff, but that seems lofty.

Your manager should be handling this. If there’s a normal on-boarding that’s companywide before you join your team, maybe they are waiting for that. Ask them! Your manager is the entry point for all of this stuff.

In terms of what YOU do, write up your intro. What do you want to share about yourself? Any specific tech things you care a lot about? What made you want to join PayPal? What about this team? Any hobbies you’d want to share? I go for humor but that’s not strictly necessary.

Beyond that, you should definitely be in rooms and meeting invites soon, but if it distracts you from onboarding it’s fine to wait until your “team join” date.

beyond that part of your onboarding to the team should be to meet everyone 1:1. I just do it for face time, getting some notifications and expertise out of folks, etc.

Just saw this. If you’re still struggling maybe you can get a corvid for a study buddy: <https://www.beautyofplanet.com/scientists-find-crows-are-capable-of-recursion-a-cognitive-ability-thought-to-be-unique-to-humans-and-other-primates/>

I worked at Amazon as an L5 engineer, then L5 software development manager, then promoted to L6 software development manager. As such, I only worked in a mid-level engineer role there. What is going to impair my ability to answer exactly as you want to is I didn’t really do what my role entailed? I was glue, and sometimes that was coding, but a lot was being a de facto TPM, solving one big thing that impacted a lot of teams, and other weird things.

I will tell you what I saw as more common for the role. At first in video the L5 SDEs were the senior people, even if it’s a mid-level role. There was one L6 that was drifting away, and 3-4 L5s, with… I dunno, 20-25 L4 engineers we supported. That ratio meant a lot more support via code review, design review, triaging issues, validating test strategy with QA, arguing with counterparts on the devices side about requirements, and so on. I would expect a TPM or senior engineer to do a lot of those things.

In my second org, things were a little more normal. L5s were the coding workhorses. They did design some subsystems, led projects with a couple of other engineers on them, did some cross-team work, but still had to do a lot of the coding. The L4s were slower, needed more handholding, and so on, though many grew very quickly. I don’t recall a hard breakdown, but would say that meetings were 8-10% of their time, reviewing code 10-15%, reviewing designs 3-5%, planning 10%, designing 1-3%, oncall/operational support 10%, other weird overhead 5-10%, then coding in what’s leftover (37-53%). As they grew toward senior, the coding shifted down, mentorship, reviewing, ombudsperson work with other teams would go up.

Maybe this helps?

First: I’m sorry you’re being treated this way, it’s really outrageous. Consider carefully what you’d like to happen now. If the manager stopped and apologized, would that be enough to reestablish trust, or is it permanently damaged by their behavior to date? If trust cannot be repaired, you cannot work for this person going forward. If you’re wanting to take action to protect others that’s admirable, but you need to take care of your own mental health first.

So now action steps. Document these things, with quotes or very near quotes/paraphrasing. Having a paper trail no matter what happens next is critical. Check in with people that have witnessed this that you trust will keep the conversation private. Do they see what you see? Have they experienced something similar? You are impacted by this behavior, but others being able to back you up goes a long way if you formally complain. Have someone else you trust see the paper trail as you’re building it so, if things come to a head, it can be shown that you did not make all of this up on the spot.

If you cannot find a new team, or some freeze or whatever keeps that from happening, looking outside is a good idea. Just do that anyway, so you have options.

In terms of layoffs, your manager having a chip on their shoulder isn’t great, but raising a red flag and then being retaliated against for it would likely be a much more serious issue than the behaviors themselves. This is a main reason you keep your file with someone copied on it with clear dates, etc.

Beyond that I’m not super sure what to tell you. Having 1:1 shadowed secretly or whatever to have this witnessed is unlikely to happen, you recording without permission is a bad idea and maybe illegal, etc.

So the short version is “get out”, the long version is document and cover your ass as thoroughly as possible.

I don’t know the very best resources for this, but would mostly say that having an ideal problem is often the best way to start proving this out to yourself.

You mentioned a lot of use cases, so probably picking one of those would help. I frankly fall back to recursion last when an iterative solution, often with a queue, cannot be used. Recursion has the messy issue of (in most languages without proper tail recursion and things) burning stack space, and when operating at scale that often isn’t workable. Trampolining is a technique that is rarely employed (in my experience), so stack exhaustion is a big risk.

Anyway! Let’s say you’re doing a binary tree exploration. You are passed a node that’s the root of the tree. Your exploration will either go right or left. Once you’ve picked which one, you are going to begin a search on the right or left node. This is the same work you did on the root node. The same method can be used. So now you do a search starting with left, then pick which of its children to explore and call the method with the appropriate one, and so on.

The “normal” setup for recursive functions is to have one or more base cases (null node, node with no children, node that matches search criteria) which do NOT call the method again, instead returning a terminal value and one or more recursive cases that DO call the method again with different parameters, often returning its result.

Things can get tricky when you need to construct a result based on the full recursive path, if you need to create a set of results (ie multiple matches), and plenty of other situations without a single return value determined in the base case at the deepest level of recursion. I would say that is “next step” once you gave the basics down.

You generally DO NOT want to store any external state. Your state is the current status of the stack, or possibly (like a visited set to break cycles) some state passed through as a parameter through the call chain.

I would start with something like a Binary Tree Map, where keys are the sort criteria of the map, and each node contains a value. Your node has a left node, right node, key field, and value field. The method you build is “getValueForKey” and accepts a base node and a key. It returns the value in the node with the given key, or null/empty/throw if there is no node with a matching key. Write the base cases first:

- Null node input, return null
- Null key, return null
- Key matches node key, return node value

Then the recursive case:

- Call the method itself again, returning its result, and passing the right or left node and the same key

Once you’ve built this you can write additional methods like an insert of a key/value, that returns the old value if it’s being replaced or null if it’s a new key. You can write a remove that unlinks a node (but is a little trickier, because if you’re removing a node in the middle of the tree you have to merge its children. The easiest is take the right node, then descend the right side of the left node until you get to the bottom and place the old right node there. This definitely unbalances).

Eventually you’re going to be able to enumerate base cases and recursive cases when considering these problems. Sometimes you’ll need to have an entry point method, then a recursive helper because you need to have helper parameters like the visited set that you shouldn’t require a caller to provide.

This is rambly. You’ll probably get a clearer answer asking ChatGPT.

This is tricky territory. Someone is going to feel excluded. You say senior engineers, but if a L62 is leading a team, do they get to come or not?

From there, direction can be challenging. Is this social? Is it scrum of scrums to share what major progress is being made and any overall blockers to see if anyone can help? Is it to talk about cross org initiatives and how to coordinate (separate from kick offs and XFN meetings)? Is it to drive things like engineering productivity, engineer satisfaction surveys, cross-org hack days? Maybe process things like mentor matching across teams or full-org design reviews or senior-eng casual coffee chats?

If you actually feel like one or many of these things would be useful and truly the engineers at L63+ are the right folk to drive this (versus TPMs, involving eng managers, etc), then maybe this is a good plan. Ideally, though, anything you discuss and decide should be actionable by members of this group, otherwise it is just an exclusive club that generates work for other people and that feels bad.

I think discussing challenges that may be hard to talk about with managers in the room (prioritization issues, difficulty with randomization, etc) could be helpful.

From there, like anything that is expensive (this meeting is expensive once, very expensive if reoccurring more than 2x per year), you should drive consensus that it is valuable to the org and to the individual attendees with a doc. Write up goals and non-goals, what would be addressed in a one-off, or that needs to be addressed on a reoccurring basis (but i would honestly defer the decision to have it repeat), why this forum would be the best way to address those things, what some alternatives are if this isn’t adopted, etc. Have one or two peers review first, refine from their feedback, and if they buy-in ask the group to review it with a one week or so lead time. If they buy in (like any doc), then proceed with scheduling a single occurrence. Have a clear agenda, drive clear action items, and afterwards you can write up a postmortem and get input with a survey (maybe two questions, did it have value, would reoccurring instances have value) and decide how to proceed.

This could be revelatory and very impactful for the org. It could also be a huge waste of time. Try to work out if there is at least strong potential for the prior before you prove the latter.

Rahul already hit on most of the high points I’d suggest myself. One thing I’d state slightly differently, which is: If you take on the “personal projects” or “initiatives” and devote X% of your time (whatever you and your manager decide) and shrink enough glue work to do that, what gets dropped and who is going to pick up that slack?

Ideally you’re working your way out of a job in as many ways as possible. Don’t do anything for an extended period of time that no one else can do, be partnering and passing things over. Run one book club, then pass MCing/organizing to someone more junior for whom this team impact actually moves the needle. Run a knowledge transfer then have it recorded and good documentation, and let someone else take on being the point of contact for this. Whatever you are good at that others aren’t, it is your job to teach and transfer.

From there, recognize that you are growing and evolving, and as Rahul recommended, make sure that growth is in a direction you actually like. You shouldn’t be coding more, but coding critical things very efficiently. You shouldn’t be designing all of your teams modules, you should have best practices and a review process that puts guardrails on everyone else doing that. Eventually you should be working to spread this to other orgs if it’s effective, or find how to adapt your process into a common framework. It’s a scaling game now, and you don’t scale by coding 10x as much.

You said you shared a file with your accomplishments, so I thought this sort of… covered what your boss could share with others to try to “sell” this. The email seemed like a sort of… documentation thing. If the file is a punch list and you think narrative form would be more convincing you could definitely write that up.

Is it important to you that you do not improve managing up and working well with others? Has every one of these interactions been flawless so it is impossible that this is legitimate feedback? Do you have a lot of reliable witnesses to all of them that have confirmed this to you?

It is unfortunate that a concrete example wasn’t provided. Regardless, it is still a gift to have this feedback because this seems like a clear blind spot you have. Others are observing a soft spot, letting you know, and you aren’t wanting to hear it. Do you believe this is being done dishonestly as a personal attack or to sabotage you?

Late feedback is better than no feedback. Even if there were other opportunities maybe recent events and corroborating details from others made this bubble to the top in terms of priority addressing it.

Would you have preferred not to be told? are you wanting advice to help “change” your manager’s perception of this in you without changing your behavior?

The general answer is to ask if they block this critical work, or if they are nice-to-have and can be tackled separately in a dedicated CR instead of adding complexity to what you’re already doing since they are out-of-scope. Rarely does someone want to be on the hook for blocking something for superfluous reasons and have their name attached, so they will back off. You should create a ticket or ask them to in order to track the follow-up, but you don’t have to own it and they can help prioritize it if it’s really important.

In terms of saying “some other team owns this library” I think it’s fine for you to open an issue against that team, link their comments, and CC the commenter. This shouldn’t take long, and doesn’t mean you own it. Pointing them to the actual person requesting helps, since it is really their ask.

Leading by example is a good policy but I wouldn’t try to get out of things by showing that the requestor isn’t following the rules they espouse. This can only cause trouble. What you can do is ask if this should be a part of the team’s coding standards, and create an issue and put it into meeting notes for a team meeting to discuss if that is a standard you want to establish. If so, then this person is then more beholden to the standard. If not, you shouldn’t be required to be the only one doing more than required.

Can you address your ideas to one or both of these engineers separately and garner support before bringing it up in a meeting with both of them where they may be vying for… I don’t know what, attention, respect, power? You attempting to be a third voice and get your ideas heard and accepted in an already contentious environment doesn’t seem like a recipe for success.

if your boss specifically wants you interceding in the conflicts between these E6s, I don’t think your boss is doing the right thing. They should be figuring out mitigations on their own. You can always note in the meeting that you are thinking through an alternative idea and will send it out after when you’ve fleshed it out. That way you can show initiative and that you’re working through things in the meeting without the discussion happening in real time with this jockeying between leads.

It feels a little silly to me, but I’ve never been great at these sorts of things. My biggest “raises” have been getting top of band new stock grants, dramatic stock growth, and changing companies. I guess early in my career I had large raises by percent, but I was making very little to start with.

Maybe this “write a letter” thing is effective and I’m just out of the loop, but I am not sure the goal. Like you get the rationale back in writing? Or… they… can’t deny you asked them?

Are you delivering 20% more value than you were when you got your last raise (not like this really determines anything, just don’t know what is driving this ask for you)? How big of a raise was it?

What is true is that you are very unlikely to get this raise even if you send the request as a singing telegram or written on a delightful red velvet cake. If you’re paid below market, getting a market offer and either taking it or leveraging it is probably the quickest way to increase your comp. Even trying to get a counter seems less likely at a company where your tech skills and what they cost are a liability not an asset when they look at the books.

Someone is expending their energy, and taking a risk of negative pushback and hurt feelings, to provide you with information that will allow you to get better, with no benefit to them.

Not telling you is very easy. The easiest thing in the world. There is no (or very little) risk in keeping quiet. Giving someone critical feedback takes courage, preparation, and finesse.

When you are getting the feedback, it is not the time to respond. You can yell, cry, swear, whatever later. In the moment you can ask some clarifying questions like “what specific situation did this come up?”, or “Do you have any ideas of how I could have done that differently?”. Otherwise, so not be trying to synthesize or process the data in the moment. You need to be a passive observer. Take the notes and really process and make a plan later. Nothing you say in response (except “Thank you”) isn’t really going to be helpful for anyone.

it is also fair to seek a second opinion, as you may exhibit some behavior in certain situations, which changes how you approach it. 