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.