You have misunderstood what the staff job entails. Consider that the staff vs senior role are 2 different jobs.

Senior: Problem known, solution unknown

Example: "Build x feature on Android + iOS. You also need to tell the backend what to send down"

Staff: Problem unknown, solution unknown

Example: "Reduce land times by 5%" This may include optimizing the build system itself, looking at machine capacity, caching mechanisms, increasing CI performance, etc. There are so many different areas that you may have no context on that you'll need to jump in and quickly become an expert in.

Or maybe you're in a product team

"Eliminate our dead unused code"

Its akin to being dropped on a deserted island and asked to lead a team to get off of it. That will mean

- Figuring out what vehicle we should have. Should build a canoe or a row boat? Or maybe there's an abandoned plane on the island. If we need to build a boat, do we have the resources for it? Then delegating building the boat or fixing the plane to someone.
- Figuring out how long we have to live. Is there any hope? Does the island have food and water? How should we allocate those? Should we instead take the longer way and invest into building a farm so that we have more time to think? Or maybe we have a finite amount of non-replenishable food and we need to build an escape as soon as possible.
- Rules for survival. Should we enforce a "only eat when you finish your job" rule? Or should we be more lax and let people eat whenever, trusting they will get the job done?
- Organization of tasks. How do you track the progress of everyone? What happens if someone is encountering issues and slows down the timeline? Can you readjust/reallocate or abandon tasks to compensate?
- Plus, being able to get your hands dirty if someone is slow or is struggling. Can you figure out the plane repair faster if need be?

Each one of these has its own engineering equivalents. I leave that as an exercise to the reader.

What I think you're misunderstanding is that you think its all about code. Its not. Shipping code is one of many angles by which to measure your productivity but its an ends to a mean. Why are you writing the code that you're writing? How does it fit into the bigger context? How will it get us closer to the overall strategic solution? Why should we allocate time and developer hours to this? Can we maintain it in the long run?

Your thinking should be strategic and try to handle the unknowns and potentially unknowables. Allocation of resources and identification of problem areas that are previously unknown is a big chunk of that. Ontop of that, because of how complex these systems and codebases are, unknowable/unpredictable changes will always come at you and you must be prepared to not let those derail your efforts.

If you cannot show the initiative to do that in a way that contributes to the strategic direction of the team, then you are not ready to be a staff engineer.

Senior Software Engineer [5A] at Uber

Edbert Chan

Most people here are talking about focusing on social "influence." I disagree. If you have a project that is well thought out, made simple, and well reasoned via an ERD that is 80-90% of the way there and several reviews from other people, there will be no shortage of people eager to jump on it for an easy win, especially if it has high impact.

Social influence just gives you an edge but is not a substitution for proper engineering.

What you've described is the "what" of software engineering, not the "how". That is, you are overindexing on information. Overreliance on this is very dangerous because you will never be able to fully comprehend all the intricacies of a constantly evolving codebase. What was true 6 months ago may not be true today.

I have never met even a Staff Engineer who could 100% tell me with absolute certainty what is happening across tech stacks that he has never worked on, only a rough general mental models for how they interact with each other.

It is only when you work with the code itself that you really understand what information is true and what is false. People may be mistaken. Documentation may be outdated. They are good starting points for information but you should weigh the accuracy of the information with the source.

There is what you think you know. Then there is what you can prove.

So I will tailor my answer on how to achieve this.

Consider that the job of a senior engineer is be able to solve "known" problems but the solution is "unknown". In most cases, this usually is a product or a feature that requires participation from both mobile, backend, and other tech stacks.

Work backwards: what kind of work should be expected?

1. The project should have a solution that is sufficiently de-risked and well reasoned. Why is it the best possible solution out of all other solutions? Why should things be implemented your way versus other ways?

2. Each part of the solution should be discrete, well laid out, and step by step such that anyone can do it. These usually correspond to Jira tasks.

   However, unless you've specifically interacted with that code, you're probably not going to be able to do this. What is most likely to happen is that you will have to consult with several experts in tech stacks that you are going to be making changes in and asking for their opinions. What components need to be modified, how the system at a high level interacts, what significant changes have been made in the past x months that you should be aware of, etc. You may need to also see a sample example of each of the interactions for clarity.

3. Hypothesize and iterate. Research is par for the course. You will have an idea of a solution. It will probably be wrong because you didn't know a few details that someone else will bring to your attention. Then you will need to improve your solution's design over and over again until it is the right one. This is what the ERD process is. It is a high level overview of how different systems, code, and contracts interact with one another. This is what you want to be able to visualize and understand. Yes its kind of a PITA but to be honest, clarity of design and thought and consensus about what is important and how to do things and checking for what you do not know is going to save you a lot of grief later on. Especially when avoiding crashes.

4. When in doubt, delegate. For areas you are responsible for, your knowledge should be deep. For areas you choose to delegate, you should have the right rough broad strokes and let someone else fill these in. It is not necessarily important that you know how to work with a custom in-house architecture on the mobile side if you're a backend engineer. All you need is for the mobile engineer to craft a feature that does xyz behavior when abc payloads are sent from the backend.

5. If all else fails, sometimes put the team on your back. I've been in projects where people who are responsible for their portion do not deliver or, at least, need you to figure out something for them. Do what is necessary to find the piece of information or general strategy. I find that finding example diffs that are similar to what is expected is a very good way of communicating this. Chances are, in a mature codebase, standards have been set and features don't differ too much from one another. You can probably dive into the git history and pull up a change similar to the one you are thinking.

Your relationships with people are not nearly as important as your ability to execute and deliver. Or rather, your relationships with people are meant to allow you to execute and deliver on projects. Influence is leverage but if you cannot even deliver or execute, there is no sense in applying leverage or influence. Why should people do what you say when you do not have a clear plan or vision for how the product will be made?

At the end of the day, your solution should be mostly right. There will always be small hiccups not accounted for but they should not move the solution roadmap too much unless you're dealing with something very bleeding edge or you're looking to perform a task where both the problem and solution are unknown (and therefore, nobody has any context on).

You have overindexed on the "what" not "how" of software engineering. You are essentially creating a glorified flash card memorization system.

Not only that, you have created a website where the person has to fill in the topics, time, and check off boxes themselves. This isn't a interview preparation app. This is a productivity app that keeps track of what to study. Its really more similar to Jira.

There are 2 parts of being a software engineer: the software (coding, language, concepts, info) and the engineer (think, design, test, create, improve). I would argue you are an engineer first before you are a software engineer.

Consider what features you can add to help people execute faster and better on the information that they already have. How can they efficiently use this information to solve any problem they may receive? Where may they misexecute on problems? Why? How will knowing "NextJS" help them in their Google interview? Is it the most important thing for them to know?

There are plenty of platforms that sell "information" (I argue that bad information is worse than no information). But there are few, if any, platforms that train you on how to think, take effective action on the information you know, and how to work through problems effectively and efficiently in unknown and unknowable spaces.

You aren't paid for what you know. You are paid on how you act on it. Ideas are cheap. Execution is everything.

For a better treatise/explanation of where I am coming from, here is my doc

[Welcome to the Coding Interview, You Suck](https://docs.google.com/document/u/1/d/1eKirumpmwDWTtKCJKn2HuoQ2NavEfR41whmTyaQcio4/mobilebasic)

Old question but I'm going to give you a structured checklist because a lot of the answers are too vague and too disorderly. They are not necessarily systematic or actionable. The problem you are talking about is more colloquially "decisions under uncertain with imperfect information". You are asked to perform a task given a codebase that you cannot completely possibly completely understand. This is fairly common actually, especially when you get to the senior level.

I will be drawing on my own experiences navigating the Bazel codebase since its an open source repo. I have a real example of debugging the Bazel codebase, making a change, and upstreaming the change to Google. You can probably steal 70% of the workflow that I'm doing and massage it to what you need to do.\
[Debugging Under Uncertainty](https://www.youtube.com/watch?v=OLJfWUyJPcA)

1. Documentation.

A lot of documentation will be high level descriptions of what the code should functionally do. However, most documentation will be out of date, is poorly written, or will not make sense until you actually work with the code. There is often a lot of context on how each portion of the codebase works that is implicitly assumed by the authors. Other times, the codebase will evolve and the documentation will NOT be updated.

However, that's not to say the documentation is useless. It should give you a rough idea of what levers you can pull and how information flows through the system. Documentation should be treated as the "spirit" of the codebase unless it is meticulously kept to date.

Bad information is often times worse than no information.

And yes, the git history is a form of documentation. Hopefully the committers have left meaningful comments and explanations.

1. Create a mental model of roughly how the codebase works around your target area.

Start with an end-to-end story of how data flows through the system and codebase. What package/classes handles what? What are the expected inputs/outputs? How should it roughly function? This is pretty easy if you can search for strings that and plug a debug point in the codebase.

Through testing and navigation and stepping through each code flow, especially with a debugger, you begin to understand the discrepancies between documentation and what the code does. You may even need to re-read the documentation and start asking around for why a document says x but you see y. Every discrepancy or misunderstanding is a learning moment.

1. Experiment, experiment.

Now that you have a rough mental model of how the code works, prove that you are right. Plug in some inputs and see if your outputs are what you expect. What will break the code? Why? What are the shortcomings? How would you troubleshoot x errors?

If you don't have an idea of how to debug issues in the area of the codebase as efficiently as possible beyond "just debug", you don't have a good understanding of what you're working with. Experiments are designed to get you there.

There is what you know. Then there is what you can prove.

1. Prototype

Now that you have an understanding of the area you need to modify, prove that your idea works. Do a hacky, least effort, high fail fast prototype of your idea. This will prove 2 things. First, that your mental model is indeed correct. Second, how easy it is to make the change you need. When writing code for unknown and complex codebases, your changes should be as simple as possible. And I mean VERY simple (maybe even 3-4 line changes per diff in some cases when its time to productionize it).

In complex adaptive systems like codebase, there is a very real risk of cascading failures.

1. Productionize

You have tested your idea, you understand how the area of your code works. Now it's time to design + write the code properly. Think about all your use cases and, given your knowledge of how the code works, try to come up with some code structure. Think of how it will scale, the future of the codebase given its past evolution, what you need to defend your code from, etc.

Hope this was useful. I know this was long and pedantic. But I cannot stress how important it is to make simple, prove, and bulletproof changes to a complex codebase. It will take you a lot longer than you think to go through this but you can always justify it by saying that you are being cautious and guarded. But do be pragmatic and loop in your coworkers throughout the process.\
\
Failures from unknown and unknowables, including and especially those cased by emergent properties of complex adaptive systems, cannot be overstated. Black swans are far far more common than you think and just because you have test cases does not mean you've necessarily thought through all the points of failure. You don't know what you don't know.

# “Spend each day trying to be a little wiser than you were when you woke up. Day by day, and at the end of the day-if you live long enough-like most people, you will get out of life what you deserve.”

―**Charles T. Munger**

Why? Why would you ever reject this opportunity? That sounds insane to me. You are effectively throwing away a golden ticket just because you weren't paid yet for the value of the golden ticket.

1. If you really were hired as an underleveled, then this project should take you less time than expected. That sounds like an easy "exceeds expectations" to me.

2. You can use this project to assemble a promo packet and get a promotion. Heck maybe 2 even. It's in your manager's interest to get you promoted so they look good too. He just needs the ammo from you.

I won't advise on how to do what you asked because its not an attitude I want other people to have. I'm not saying to work for free. I'm saying to take every chance you have to prove you deserve what you want. If it doesn't work out, at least you have projects beyond your level (L+2 according to you) and you can always go to a new job with it and get the title there.

I suggest not doing that though. Beyond L5, its very difficult to get a new promo by switching teams/companies. There's a lot of background knowledge that is built over time simply via exposure which is incredibly important for being "that guy" who everyone turns to during a fire. Take every chance you have to be important and learn something.\
\
“To get what you want, you have to deserve what you want. The world is not yet a crazy enough place to reward a whole bunch of\
undeserving people.”

―**Charles T. Munger**

Just like any topic: use them. Then realize all these are just ways of writing things.

The way to improve isn't by writing code but realizing how they work, why they work, and why they're used, and how things can be done better.

You should not be focusing on language and features. You should be focusing on understanding what you're writing, why, and most importantly, how to be as efficient as possible at figuring out what you need to write.

That's the difference between coding and engineering.

Why do you care? You have no control over day to day price fluctuations. 99% of the time the transactions are just quants who are following value at risk models or rebalancing based on modern portfolio theory formulas.

Every price action is a vote, a random action based on some reasoning you don't know about. If people vote for some insane proposition based on some insane reason, you wouldn't follow them. For instance, if someone buys a share of Google just because he thinks dogs are superior animals to cats, you would call him nuts. Yet that's effectively what every price action is: a price is just a vote on what the asset is worth and a buyer and seller have exchanged money for the asset.

Why do you care about something you don't control and don't influence and can't understand? Price is just an opportunity to buy or sell the stock because other people are buying and selling.

I made a LOT of money simply by holding my stock (and concentrating my wealth in 2 positions), not caring what the stock price did, and sitting on my ass just trying to be better at my job. It works out way better too: you'll make way more money and life is way more fun. What's more important to you? Stock rising 5% or getting promoted 1 year faster? You'll make more money in the latter. Plus, you have complete control over.

In full disclosure, a good chunk of my net worth is still in Apple or Apple-exposed positions.

My personal take is that I don't think engineers should ever have been compensated in RSUs to begin with. Stocks represent ownership in a business and most employees don't think about the business or the quality of the business. They see it as a trading instrument just because someone else will buy it at a higher price and they have no idea how to actually trade.

It is absolute madness to me that people who has no financial training and can't read a 10k care so much.

If you seriously are suffering from FOMO, I suggest doing 3 things:

1. Ask yourself what is the money really for? Does it matter if the stock price rises 100% tomorrow and falls 50% the day after? After 2 days, you're back to where you started anyway. If you are retiring in 10 years, then you only need to check the stock price near that time unless the company you work for suffers some fundamental catastrophe. Lucky you, you work there so you can actually change that!
2. Focus on your job. Become a better engineer. Focus on your code. Getting promoted faster will increase your wealth way more than some silly price action.
3. If all else fails, study finance on the side. Understand how the world of finance ACTUALLY works. Learn how to read an annual report and meet some actual money managers. Then try it out. I am 90% certain you'll be wiped out or underperform in the long run because most people don't have the temperament for it.

As a rebuttal to the "just sell and diversify in index funds", I think that's great advice for average people. But I found Munger's approach far more intuitive and I naturally was doing it anyway because I understood value investing.

***“I think it’s much easier to find five than it is to find 100,*” the 97-year-old investor argued. “I think the people who argue for all this diversification, by the way, I call it “diworsification”. And I’m way more comfortable owning two or three stocks which I think I know something about and where I think I have an advantage.”**

As someone who has networked not just at random tech events but also at Bazelcon (hosted by Google), Droidcon, Gradle Productivity Conference, and even some investment conferences like Berkshire Hathaway Annual Shareholder's meeting and Beard Group's Distressed Investment Conference, the biggest barrier I've seen for new engineers (and new people in general) is bringing something to the table. 

What do you know that someone else does not? What may interest someone? What work have you done that makes you see the world and other work in a different light? What results can you share with people?

Networking is just business: it is a give and take relationship. Its about trying to meet people who will give you value or may give you value in the future. This means that you must be able to sell your skill, brand, and knowledge in exchange for someone else's. Time is limited and not everyone you meet will be able to make your time worthwhile. So it is important to show you are worth someone else's time.

I disagree with simply asking questions. People don't always want to answer questions, particularly if the questions are naive. The questions you ask also reveal who you are just as much as they probe because they operate from a set of assumptions.

Since this is your first conference, I recommend bringing a prop: a project, metrics, or perhaps some code you can share with other people. Not only does that allow you to show you have something of value but it also allows you to demonstrate it. A picture is worth a thousand words.

As an example, I was networking with people from Spotify regarding their Bazel migration and we had a different view of how to do their migration. I talked about how we were doing ours (dynamically) and showed them some of the metrics we were tracking to do so and why we disagreed with their approach. We had a great 3 hour conversation afterwards that spawned into both engineering and non-engineering practices.

Simply put, be prepared with knowledge that can be contrarian and genuinely insightful to others and be prepared to back up those. You will find people who are similar and/or have expertise in that field. You can then compound that knowledge over multiple conversations and conferences.

You are not looking closely enough at your performance or your approach to problems. You are only matching result to effort. That is, you believe that your thinking is right only when you get the right answer and vice versa.

That's incorrect. What matters is the thought process and questions you ask yourself to get to the right answer. Think about how you scope, plan, design, test, and improve solutions to DS&A + system design problems. Is it systematic? Do you have a set of questions you can ask to parse the problem down to a unique and stable design? Can you scale the system? Do you avoid obvious pitfalls and repeated debugging of code?

The name of the game is efficiency and risk in the procedure you take. Not result.

Your quote: "instead have to actually work through the problem-solving and having that dialogue with the interviewer" indicates that this is lacking.

The way to beat out luck is to become skilled. Over a large enough sample size, skill beats luck and results that derive from luck revert to the mean. Which means that over time, the underserving may get 1 offer but never will never get them again.

If you disagree, here are some things you should ask yourself:

1. Is your approach to problems consistent? Can you prove that across 30 random problems, you can get the answer or close to it on at least 70% of them?

2. Are you keeping track of every time you fail to answer a question? Are you considering the questions you need to ask yourself to avoid failing in the future?

3. Are you able to explain your thought process clearly and simply to a 5 year old on how you derive the answer? Are you able to defend your approach and answer?

PS. You will not get an answer from the company because they do not want to say anything that might get them sued. It does not do them any good either to help you. Worse, they may give you misleading information to make you feel better. Bad information is worse than no information.