I'm Edbert, Ex-Apple current Uber Infra Android Engineer. AMA!

A question and a recommendation:

Question: You seem to be much more interested in investing compared to most software engineers. Do you feel you can get better consistently better returns, or do you do it because you enjoy it?

If you feel you can achieve better returns, can you share what you're looking for? Since I don't have any inside information, competing against incredibly smart traders who commit their lives to investing feels like a losing proposition. (BTW, would love to have you join for finance office hours on Nov 13.)

Recommendation: I recently listened to this (very long) podcast about Berkshire Hathaway which I'm sure you'd love: https://www.acquired.fm/episodes/berkshire-hathaway-part-i

Sorry for the open-ended questions that begs for an essay response.

1. What do you think are the most complex classes of problems? Is complex the same as difficult, in your opinion?
2. If intelligence (commoditized in the form of AI) were as abundant as electricity tomorrow, what would be your strategy to obtain massive leverage?
3. There's a high correlation between intelligence and success in big-tech jobs. Even though some people are incredibly humble about it (Alex), you can easily tell they're way above average when they speak or explain their thought processes. Do you think this concentration of intelligence is a net positive or something to be concerned about?
4. When will "gaming" (some form of it, comparing that to couriers) become a normal job that regular people can live off of?

@Rahul:

You seem to be much more interested in investing compared to most software engineers. Do you feel you can get better consistently better returns, or do you do it because you enjoy it

Enjoyment and winning go hand in hand. I doubt someone would enjoy doing something they are consistently bad at.

I see investing as just a game/sport where I get to learn about the world and if I'm right and everyone else is wrong, I can profit. It is points on a screen that are wagered to get more points. But in that, you are also trying to size bets, get information, and make decisions under uncertainty. The process by which you improve is the same as Dota actually: watching replays and backtesting and forecasting repeatedly over multiple scenarios.

In the best case (which I think I'm currently in), I am able to leverage my knowledge to make lifechanging returns. At worst case, I'm basically paying tuition to the market to learn about how the world works and how to become a better thinker.

I don't think I'll be able to consistently get better returns over the long run unless I do it full time. In fact, I'm very lucky to have achieved the returns that I have over 7-8 years. But here are my insights.

1. It is nearly impossible to get 20% YoY with long term "buy and hold" investments alone unless you are very good, very hard working, and very lucky and you have some degree of active management. As time goes on, your returns converge onto the business's return on equity which means all business converge to the average of 8-10% year over year. The discount you buy at determines your return.

There are a few ways to actually achieve this though. First is through arbitrage (mergers, spinoffs, etc.) and value+catalyst that supply alpha to your port. Second is to let one business or investment achieve insane returns, make a massive bet on it, and don't lose money on all the others. This is essentially the Buffett approach. $KO returns basically 50% year over year w/ dividends between 1989-2000. Li Lu did this with his investment in BYD. Chuck Akre with his AMT investment. The list goes on and on but essentially, every major investor has that one swing that surprises them that catapults them into legendary status.

There are some I know who have done this in the microcap space. But they are all former finance professionals who have 10 years of experience in the industry. You can think of a hedge fund with less than $1bn AUM as essentially a startup and the analogy holds: most startups that succeed are the ones with an experienced founder at the helm. Very very few succeed without that prior industry experience.

In short, to consistently beat the market, you pretty much need to have a degree of active management. The "buy long term" is a method that really only works if you can buy something at a discount that will grow to an insane valuation and can swing at it with the full weight of your capital. I have done this with Apple.

2) Frequently trading is a sucker's game for 99% of people. First, you're competing against brilliant quants on Wall Street who are math olympiads, working 100 hours a week. Second, your orders are just going to get front run by machines so you pay a higher vig/fee to get in and out of your trade. Over time, you are almost guaranteed to hit the gambler's ruin and hit 0.

That's a part of the sport: play against people worse than you. The question is who is on the other side of the trade and what do they know that you don't.

1. Engineering and investing occupy the same side of my brain. Investing is spending money now to get more money later. What is engineering but choosing to spend time now to save time later? The process is very much the same (research, ERD, etc.) so it comes fairly naturally to me.

2. If you're going to actively invest, you have to know accounting. I recommend studying for the CFA exam. Passing it is another matter.

3. Always try to stack the odds in your favor. Instead of trying to bet on the growth of a particular company, just filter your list to avoid the losers. Then find the companies that you have an edge over other investors in. However, that edge can be difficult to tell unless you're competent. The difference between an amateur and a pro is that a pro can tell the difference between a 60/40 vs a 40/60 chance of success, even though there is no way to actually mathematically calculate the odds.

I have a short list of 100 companies that I watch but it took me 2-3 years of screening and studying full time to assemble which essentially meant I had 2 jobs. I don't have the mental stamina to do that anymore so I've stopped looking actively for investments. I just journey to the Berkshire meeting every year now and the side events and conferences as an intellectual hobby now.

I've done well on a few including DIT, TWNK, and shorting housing through derivatives.

Incidentally I was sent a job application for a fund once but I did not have the appropriate YoE.

Represented the US in France and Poland for fencing in 2009 for the Cadet World Cup.

😲

How did you do? Do you feel like the skills you got from fencing were transferrable to your SWE career?

What do you think are the most complex classes of problems? Is complex the same as difficult, in your opinion?

The most difficult problems are people problems which is why I spend very little time thinking about it and more time avoiding them. Or at least mitigating them as a factor. My social skills aren't the greatest and I just prefer to let my engineering skills prove my points.

As for the most complex class of problems, I would say those are situations that are some combination of unique, unknown, unknowable.

As an engineer, you have a chance to stack the odds for various problems in one way or another. But you should still recognize what situations you can and cannot affect and the likelihood of success if you do x.

At a basic level, a lot of risk toy problems have known probabilities (ie. fair coin has 50/50) and its trivial to calculate payoffs. But at some point, the probabilities become unknown (U) despite knowing all the information (ie. probability of a car breaking down in the next year, you can inspect the entire car). Then you have unknown and unknowables (UU) (ie. probability of another terrorist attack) where the state of the world you are observing is imperfect. Then you have unknown, unknowable, and unique situations (UUU) (ie. probability of the US economy failing 2008).

The rough translation to engineering is:

U: Debug a consistently reproducible bug

UU: Debug a Java memory leak in a complex codebase

UUU: Migrate codebase from Java to Cobol

This paper by Zeckhauser does a better job at illustrating this.

If intelligence (commoditized in the form of AI) were as abundant as electricity tomorrow, what would be your strategy to obtain massive leverage?

I would look for what an AI does not know. AI's short coming is that it can only draw lines through data. I'd be looking for things that are not in the data. For instance, AI cannot tell you the existence of black swans if all it knows are white swans. In fact, it is in the nature of statistics to eliminate the exceptions because of noise. But that is bad if the exceptions are the ones that are going to cause you the most harm.

There's a high correlation between intelligence and success in big-tech jobs. Even though some people are incredibly humble about it (Alex), you can easily tell they're way above average when they speak or explain their thought processes. Do you think this concentration of intelligence is a net positive or something to be concerned about?

I am pretty sure I have a sub 100 IQ. I have routinely gotten B's instead of A's on school exams because I misremember there are 50 cards in a deck instead of 52. I would also say its a net negative: an organization cannot be completely made of very smart people. It must have some people who are willing to do the work despite their intellect screaming at them to not do it. Also, thinking you're smarter than you actually are leads to some very dangerous behavior, including overreaching and fraud.

See the meltdown of LTCM and Enron.

When will "gaming" (some form of it, comparing that to couriers) become a normal job that regular people can live off of?

It won't. Barrier to entry is too low and skill ceiling is too high. If you think you can have a normal job where only the top .01% of the player base is capable of making money, thats impossible. The only way to get there is to spend 18 hours a day, 7 days a week working your butt off to stay ahead. If you slack, someone else who's more degenerate and willing to throw their life away is going to kick your butt.

How did you do? Do you feel like the skills you got from fencing were transferrable to your SWE career?

In the US, if you make top 16 in the rolling point standings by the end of the month/quarter, you get to represent the US in the following world cup. I don't remember doing too well. I think I got top 64 in both events. In Paris, I had to fence my own club mate from the US in the direct elimination matches. I stopped fencing I think a year or 2 afterwards to focus on school.

The biggest thing I think I got from fencing is persistence and personal responsibility. Since fencing is just a 1-1 sport, you are solely responsible for the wins and losses. That has been a very big mantra for me ever since. Outsmarting the opponent isn't as much of a thing as people think: because of how fast fencing is, it's mostly all automatic with a first to 15 done in less than 3 minutes nowadays. You pick what action you are going to do at the beginning of the point and automatically do it and calibrate based on how the action went. Of course, the opponent is adjusting to you too.

I would say Dota helped me more as a SWE. In Dota, you're dealing with multiple teammates and more probabilistic and unique situations. My ability to ignore the opinions of people helped a lot in not tilting during matches. The way I improved at Dota was the same as I did in engineering.

As a solid example, I remember in 2016 I spent probably 60 hours/week watching a pubstar play Spectre. I would watch his replay, pause after 10 seconds, predict his next move, and verify the prediction, and write it down. If I got the prediction wrong, I'd write down what he exactly did and what things he was looking at (creep wave, enemy heros, etc.) and try to reverse engineer his thought process. I spent easily half of that time on nothing but replays.

It was pretty insane and in that month alone I think I got 65% winrate and gained 700 MMR or something (Divine 2 is like 5.3k). But I was getting some forearm cramps and had to stop. But that experience alone taught me the power of watching replays intensively.

That process is exactly how I read code, ERDs, and so on. I don't just read the code. I read the process of the code. The background, the decisions, how it got to where it is. That will usually give me a start. Each time the code changes is a chance for the code to have been written perfectly the first time: what was considered and what wasnt? What were the circumstances that lead the code to be written this way to begin with? Could this have been prevented? What other factors were introduced? Usually these are in the description of the diff.

Edbert, what's the best way to collect feedback from interviews? A lot of times, interviews are opaque and the team does not really share feedback.

I usually try to read the body language during the interview + ask at the end of a technical interview (e.g. if it is LC style and more objective with a defined rubric) if I missed anything or if they have any specific feedback for me.

I feel like I can make changes faster if I get more constructive feedback.

what's the best way to collect feedback from interviews? A lot of times, interviews are opaque and the team does not really share feedback.

You can't. Simply put, companies have no incentive to share info with you because if they say something wrong, they could be sued frivolously. To share feedback with people is no upside to the company and a lot of downside/risk. Why would a company want to help you?

If I were you, I would pick over your mistakes. Every one. Redo the problems and solutions afterwards. Record yourself and watch your own replay or ask someone better than you for help. It sounds like you are on the left side of the Dunning Kruger effect: you are paying attention to everything except for what really matters. You are watching body language and treating is as a conversation instead of a proper test of your engineering prowess.

Think of this as a game that evaluates your engineering skill rather than as a interview as a person. And consider the company and everyone else to be your competition. Find people better than you who can consistently get results for help and pay if you have to. Don't skimp out: you will save your self a lot of time and headache if you spend the few bucks to have someone tear you apart.

Pretty cool you are moving the build infra from Buck to Bazel (or Blaze, as Google calls it internally). What's the main consideration behind the change?

Pretty cool you are moving the build infra from Buck to Bazel (or Blaze, as Google calls it internally). What's the main consideration behind the change?

There are a few but I'll hi light the main reasons

1. Lack of support from FB. When we made the decision, FB was already using an internal fork of Buck and had announced the rewrite to Buck 2. This meant that we would have to be the maintainers of Buck 1.

2. Lack of community support. Lots of Buck adopters like Snapchat had already started to migrate towards Bazel and thus the rest of the community soon followed. Lyft and Spotify are also companies that come to mind. Alignment and modernization with the community is paramount in the Android world where everything is open sourced with G as the benevolent somewhat dictator.

3. New features/more stability. Remote build execution did not exist in Buck 1 and it would be great to speed up build times. Bazel also offers a few other features like Build without Bytes and whatnot. But one major issue is that Buck often would do things incorrectly in the name of speed and optimization.

As a concrete example, imagine a module that declares resource R.int.a. And you have another module R.int.a. Buck compiles the resources as a separate step and does not check by default if there are duplicate declarations of the same resource. This is because Buck will compile the Java modules on a build and then generate the APK with install rather than generate the APK with build. Furthermore, Buck will just scan the list of directories for all the resources and combine it as a single step in install in order to save time on incremental builds. Therefore, if someone were to run buck build app, the compile time would succeed because every resource has a match. But you could potentially fail at runtime because the attribute would match the wrong value from the other module.

I am way more interested in how the heck did Facebook didn't have this issue or at least didn't upstream it to the repo.

And as with any migration, there comes a few issues. For instance, it turns out Bazel has severe limitations when it comes to memory efficiency. A few issues I've filed seem to be because Bazel assumes that all memory available on a machine can belong to it. This means that builds are more likely to fail on CI, especially if memory estimations are wrong. Because Uber has a 10M line codebase, the amount of memory consumed can be enormous. For instance, Dexing, by default is assumed to consume 2GB of memory when in reality it can consume as much as it wants. What if it consumes 10GB on some modules and 2GB on others? Bazel sort of assumes that it can always fall back to swap memory in case the memory pressure blows up. So variance + being wrong with estimations can be a great way to choke Bazel and cause really wierd crashes, which inspired this fix.

There are a few other ones including but not limited to being out of sync with the Android Gradle Plugin and libraries but that may be less of a concern since my understanding is that G's focus is on the 99% of Android devs that don't have to deal with scale and hence non-Bazel related stuff, especially since Gradle is modernizing to try and compete with Buck and Bazel.

If you have any leeway, especially with Terry Xie, we'd love for all the debugging/resource measurement tools y'all have developed inside G for Bazel to be open sourced. That would help a long way.

Anyway its a very interesting project to work on and I'm very happy we have a tech lead who is absolutely phenomenal. Shoot me an email at edbert@uber.com if you'd like to discuss more.

Edbert, I've got a few more questions for you!

• What has been the one thing you wish you had changed as you started to grow in your career?
• What are you reading on investing currently? Are you open to sharing resources/tips/books/advice that you recieved that really helped you?

And thank you for your previous answer. I already do what you say - try to re-solve the question again and pick apart what other aspects I could have covered in the interview. I was just looking for ways to see if I can improvise. What you said definitely makes sense.

What has been the one thing you wish you had changed as you started to grow in your career?

The one thing I wish I had changed as I started to grow in my career is talking to others more frequently. This is a very big problem I've had (and still continue to have at times) and I think because of my nature. I rarely ask questions unless I can somewhat anticipate the other person's response and have a natural debate/back and forth. Testing someone else's ideas helps me understand their idea but if I don't know what to expect from them or at least show my own work, then I don't feel comfortable having a good discussion and I end up just copying their own opinion.

This has burned me a few times in my career and I'm still struggling to find the balance. Combined with my terrible short term memory, its a very annoying weakness to have. The good news is that by being as thorough as possible, that knowledge compounds over time and because its usually written in notes, memos, and git commits that I distribute, I can always reference them and send them to other people (with proof of work too). But it makes me terribly inefficient in the short run.

From what I can tell, the people who are more successful than I am are the people who can leverage other people's information, know how to filter it, and apply it meaningfully. This could be because of the immense amount of context and experience in a subject matter or general wisdom in one's career.

What are you reading on investing currently? Are you open to sharing resources/tips/books/advice that you recieved that really helped you?

These days, I'm more interested in reading human history and biographies. Economic Thought and Ideology in Seventeeth-Century England is currently on my desk. There are lots of parallels between England/France and US/China relations today, including internal strife in England like the reorganization of social/economic order from familial structure to state-guided enterprise. I find that the principles there are more applicable to many areas in life. For instance, From Third World to First by Lee Kwan Yew can be read multiple different ways. First, as his biography. Second, as an exercise in pragmatic decision making. Third, as a post-mortem of nation building (yes, post-mortems can be applied to successes as well). Finally, it is also an observation of human nature: where a nation's culture and background shapes the work habits, politics, and attitudes of its leaders.

I would say simply cloning the mental models of the people you respect and admire is the best thing you can do. That's how I've conducted my own engineering career: I just studied and copied the code and thinking of people I really admired . That means studying their work, their words, and trying to emulate their conviction by looking at every decision they make and why they made it. To that end, I've looked at the 10k's of every major investment decision Buffett made (shoutout to Adam Mead for doing this leg work. His book The Complete Financial History of Berkshire Hathaway is very good as a reference/summary book) and the holdings of Charlie Munger's portfolio while he ran Blue Chip Stamps to try and create a mental model of what they look for (and what to avoid). Source material is always better than someone else's interpretation.

That said, that's why Poor Charlie's Almanack is my absolute favorite. Its a collection of his 12 or 13 talks and every so often, I re-read it and pick up something new in the talks that I missed before