In my career I did a few rescue operations when I as external expert was asked to come in and understand why project was failing. Random code review is amazing tool to understand quality of engineering talent and process maturity.

My process was to schedule 2h block and then start with pulling random diff. I checked if engineer can explain diff purpose from both technical and business perspective. Then dive in and assess understanding of code base by asking about random functions/lines. Follow up if I do not understand something. Why was it done this way? Did you consider other options? What are pro cons? How long did it take you to write this? Who reviews it? Any approvals were needed? What was process to ship it?

You will be surprised how often sr/principal engineers are clueless and dev process is full clusterfuck when people copy/paste without understanding what they are doing.

You very quickly understand what’s going on. You do not need to talk to every engineer - random representative sample is good enough. You do not need to have domain understanding too - though it’s obviously very helpful.

Those who think this is a code review for the sake of looking for bugs or architecture issues are missing the point.

It's an intimidation factor on Musk's part. Are you willing to play along and show your work? Or are you going to huff and puff and complain about it? Maybe you're hiding something, or maybe you're not going to be a cooperative resource going forward. Now you're on the cut list.

Maybe the code will get glanced at for a moment. Most of us can tell well written code from spaghetti without running it through a compiler. But still, that's not the prime objective here.

We don't know who they people he brought over are. It's doubtful that they are people who've never done anything but write code for Tesla. Were I in Elon's shoes, I could easily imagine digging up some employees with prior relevant experience and asking them to just browse through the codebase and give a rough appraisal of how tight it is. You can tell a lot by looking at basic things like coding standards, state of source control, development environment, testing strategies, what kind of code reviews are happening, how modular the code base is, what the service architecture looks like, etc. I've worked in a number of industries and good code and tight systems look different from bad code and sloppy systems. He's probably not looking for anything specific, but rather to get some understanding of the state of engineering there.

They don't really need to find out anything meaningful. They are basically just putting Twitter employees on notice that they may be going deep into the details when assessing where the company is at and what changes they might want to make.

It may not be the best way, but I could certainly see it having some value.

Twitter has a ton of home grown tooling that a company it size wouldn't have if it was started today.

Is the team of people maintaining their custom stream processing engine really going to say "You could probably just replace this whole team by using Flink"? Repeat for their custom NoSql DB, their batch processing engine, their RPC framework etc.

I never said it was the best way, but it may be the most viable option. And you dont have Tesla engineers personally go through the code, you have them sit down with twitter engineers and have them walk through how it works. Its probably a general understanding exercise.