the best projects are the ones you genuinely enjoy and will have use for\
\
back when i was learning Java, I modified the minecraft client to do basic hacks like X-ray to more sophisticated custom hacks like dropping a wall of blocks in front of people around me\
\
needless to say, i have been banned from several servers for doing this but it was a great exercise in navigating complex codebases through sheer experimentation (both the minecraft codebase and the reddit anti-cheat plugins) and I had a lot of fun.

Senior Software Engineer [5A] at Uber

Edbert Chan

Theres always issues at scale. Unique ones for sure. If all the technical challenges were solved, infrastructure, support, and all the dev productivity adjacents would have nothing to do.\
\
I suggest you think harder about your own workflow. What inefficiencies do you encounter in your workflow? Your builds? Your tooling? Why do they exist? What could be done better? What could be easier to understand? How can scale not be so damn complex or difficult?\
\
If you could save everyone in the company just 3% of time, that's already millions of dollars in developer hours you could save.

> Too much emphasis on Leetcode-style coding challenges

I've often felt that if you Leetcode properly and approached the challenge the same way you might as a proper engineer, you would consistently do well on these. Incidentally, I've faced a lot of problems in infra that actually seem similar to some Leetcode style problems.

> Since i've always been within product development and that's usually most heavily staffed, that allocation problem is usually solved at a higher level in the organization. But in general, I find developer support to be relatively understaffed.

I've often felt the same way about the industry for a few years now. It seems like because a lot of the platform-level stuff is solid and the standards are well defined, it is very easy to churn out products. I have a pet theory that companies could cut costs by simply paying product developers less since the technical skill needed is not as high as companies think. I'm curious how this will play out over the next few years now that "growth for growth's sake" is no longer the mantra.\
\
As for developer support, yes its very understaffed across the industry. But it's also relatively new from what I can tell (circa 2016, it was formally identified and defined). How many people do you think/speculate would have the confidence and skill to move from product to infra?

Not sure about "fu money" is attainable as a Staff Engineer though without holding a lot of the stock and it compounding at 30% year over year (which cannot happen forever). There is only 1 engineer I know who is Staff+ who is in VC/Angel investing but that is only because he had a buyout in a previous job.

IMHO FU money starts at $10M. Not even $3M is FU.

I've been in engineering for more than a decade and I am still working on the exact same technology that I have since the beginning of my career (Android). I arguably have a pretty bad WLB but I'm still alive for whatever reason. I disagree with Alex about this point because there is no shortage of engineers willing to work twice as hard as you to kick your ass.\
\
I'll be very specific with the reasoning.

At any rate, let's work backwards; what qualities would you need to have 10 years ago that would allow you to be relevant today?

- Picking the right technology/language and sticking with it. I got very lucky on this one but it was also expected. Smartphones were widely becoming adopted and users couldn't live without it. So Android was a natural interest for me.

You will find this knowledge will compound over time if you stick with it while everyone else is jumping in and out, desperate to catch up. That historical context will help you immensely.

- Focus on the fundamentals. I never tried to learn every little component that Android offered. Just roughly how the OS and SDK work and its quirks. Over time, the biggest gotchas came out and they would come out repeatedly. A good example of this is Samsung: they always modify the OS and rewrite their system + bundled apps, creating large headaches and random crashes we can't diagnose. But it is our responsibility to deal with it.

Technologies change but best practices rarely do.

- Efficiency. Efficiency. Efficiency. Fail fast and focus on the code velocity. Optimize your workflow and have a good understanding of where you can shorten feedback cycles in any project or workflow. One of the most under-rated tools is being able to commit things to branch, push it up to a WIP commit, and write a note about what you did to save for future prosperity. Your knowledge will compound as well and you can share your code and findings with others in a way that doesn't involve blocking meetings in your calendar.
- Be surrounded by people who you admire. It is easy to learn from people you like and want to learn from. Clone their methods and thinking and adopt them as your own. Nobody is smart enough to do everything from scratch. But you can copy the hard fought lessons and insights of your peers and avoid a lot of headache.
- Always keep reading and applying new ideas. One idea I stole was from George Soros where he treated financial markets as a lab to test his ideas about the world. Each trade was a sample data he used to validate or invalidate his hypothesis. This all culminated in his theory of reflexivity of markets (a VERY useful idea that is directly related to feedback loops) which he used to break the Bank of England in an epic battle that levered his entire fund on a single trade. I use my work process and codebase as a lab to test my ideas of how code works, how it ought to work, why certain things came to be, and so on. Codebases and practices change and so should you.

1) What has been the biggest weakness in quality control over hiring in both companies?\
2) What are the similarities, differences, and focuses in infrastructure's practices between FB and G? At scale, it seems like what they are trying to do is fairly similar, especially with the rewrite of Buck and the open sourcing of Bazel.\
3) How do you decide allocation of headcount and resources when it comes to product development vs developer support vs open source community support?

Oh wow, a topic I think I'm uniquely suited for considering I actually have worked product and infra on big and small projects at Apple and Uber. I am currently on an infra team. Note that my writeup with be uniquely suited for big tech and Android development.

What Alex said about leveling up at Product vs Infra is not entirely correct. I would argue its easier to get promoted in product than infra. Not to mention infra has a tendency not to let people into their teams until upper midlevel. Very few juniors are allowed to join so count your lucky stars if you get into one early in your career.

Consider that wide impact is something you need at the Staff level. If you upstream a change to a common product/infra library, you have a better chance of getting better promo rather than upstreaming changes to open source software. That's because the common product library/infra change is not in the traditional scope of most product teams as they're mostly focused on their own vertical. On the other hand, contribution to open source software and wide impact is baked into the nature of infra and so the only way you can escape that scope is by having an even wider impact: cross-company collaboration or some level of convergence between tech stacks (ie. Android should collaborate with Backend common libraries). Which is an insane amount of scope. You can roughly think of getting promoted from senior -&gt; staff in product to midlevel -&gt; senior; a +1 rank difficulty and scope.

As for the nature of the work, I would describe it as going from "well known and well defined" to "unknown and unknowable". This is because in mature codebases, 80% of the product's tooling, architecture, and practices are well known and well enforced. Therefore, the only thinking you need to do is the customers' expectations and flows in the system. The rest of the code is just a carbon copy of things you've probably done before.

In infra, the developers are your customers and you service them which means you will have to do things that few know the right answer for. For instance, debugging complex pieces of software you don't own but are using or investigating JVM level memory leaks (how many people do you know have debugged Java itself?). Personally, I never thought I'd be digging into the JDK 11 code itself and looking at how ClassLoaders actually work with compiler plugins when migrating from Java 8 to 11 as an Android engineer. But here I am.

This is also why I disagree with Alex's assessment that product people should enjoy interfacing with people more. Again, your developers are the customers on infra: you'll be talking to them and their managers to see their needs. If you're lucky, you'll also have metrics and dashboards built out for you like at Meta. That customer interaction aspect does not change.

This is also reflected in the feedback to your work. In product, you know if the goal is met if you have met the predefined requirements and if the user experience is solid. In infra, you may not know until it bites you or becomes successful. For instance, using Alex's example, if you want to decrease build times by 3%, you would need to study a system you are unfamiliar with and make several changes to several different spots. However, that system is not just unknown but also changing constantly so your understanding shifts from quarter to quarter. Therefore, you can never be completely certain that the fixes you roll out are ever going to get you to there. Certainly you can prove in isolation it works but in production where the variance of build times can go up and down by the week or day, depending on various outages and whatnot, its nearly impossible to tell (is it just noise or did you actually make an impact?).

I don't think most people should do infra unless:

1) You like being wrong all the time. This cannot be understated. You will always feel like you're wrong until otherwise proven. And even then, you can never be certain if its luck or skill.

2) You are self guided. Infra's problems are very rarely obvious. It is up to you to sniff those out, create your own projects and solutions, and lead them.

3) You are highly highly efficient and are extremely rational You need to have an understanding of when you're wandering too far in the wrong direction in an codebase you don't understand. This means being able to sense the unknown and unknowable and know what is a big time sink and what is the best payoff for effort.

4) You have a long attention span. You can focus on a single problem for weeks without making progress. I have a video, [Debugging Under Uncertainty](https://www.youtube.com/watch?v=OLJfWUyJPcA&t), that goes into the background reasoning and investigation behind why I filed [this fix ](https://github.com/bazelbuild/bazel/pull/15698)upstream and why I chose to write this. Its a relatively simple diff. Note the back and forth between me the maintainers.

5) You have an extremely high level of personal responsibility. Infra is always an unknown. You WILL break things and break them often and be wrong a LOT that may or may not break things for the entire company. But you must be able to own every error. You cannot claim wins and ignore the losses. Most infra leadership understand that mistakes will be made. But that is not an excuse to dodge your role in causing company-wide outages. See #1.

Don't get me wrong: the rewards and learning you will get are amazing. The smartest and most brilliant people tend to rise up to infra and developer productivity in general because it requires an amazing ocean of experience to make the right calls (or at least avoid a lot of failures). You will also get unique opportunities most engineers don't such as intercompany conference involvement.

If you want another sample of the type of work infra does, here is an[ issue I filed just today ](https://github.com/bazelbuild/bazel/issues/19934)against Bazel 7 that was only recently released a short time ago. This investigation alone took me several days and wandering into several dead ends. In the end, we have a fix that is just a few lines long but probably not suitable for upstreaming to Bazel itself but it gets us out of the woodworks. I highly encourage you read the conversation and my comments to get a sense of the sheer amount of proofs and dead ends I went into. And that's only investigating Bazel itself.

And if everything I just said seems overwhelming, keep in mind I'm only just a senior engineer. There are several staff engineers who do this type of work in their sleep, very efficiently, and without breaking a sweat while leading a very technically complex migration. They can investigate and file 3 times the issues and come up with better fixes for them in the same time it takes me to do 1. 

I'm just trying to keep up :D

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.

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.

Here's the YouTube video I made about this: [Debugging Under Uncertainty - Case Study: Bazel](https://www.youtube.com/watch?v=OLJfWUyJPcA)

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

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

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

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

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