Yiyuan Li Interview

Honestly I don't really plan it. The field moves every single day, and when something new shows up my first instinct is to go build with it. Not read ten threads about it. Build something, even if it's bad.

The example I always come back to is from before Claude Code existed. People were just starting to talk about letting an AI actually operate a computer, and the second I saw the idea I wanted my own version. So I started writing harnesses for it (with python as my prototyping language). The model was GPT-3.5-turbo back then, the first one that could code at all. I learned a stupid amount from that one project like prompt engineering, LLM tool calling. Its basically the agent harnesses engineering nowadays. Almost nobody was doing it, and that one project taught me more about LLM use than any course could have, because there were no courses.

That's pretty much how I do everything. See something, rebuild it myself, then push on it until I get why it works and whether I can bolt it onto something I already have.

The other thing I actually believe in is sharpening the tool, and there is an art behind it. There's the work, and there's the thing that does the work. Building the side project versus building the components to make the side project. Shipping the feature versus refactoring so the next ten ship themselves. People who only ever do the task stay slow forever and never notice.

And the excuse budget is zero. We are in computer science. Everything is online, most of it is free, and you can have the frontier the same day it ships. So when someone says they don't know what to learn next, what they usually mean is they don't actually want to build anything. That's not a knowledge problem. It's laziness, and I'd rather just call it that.

I Google it. Whatever you're stuck on, someone has almost certainly hit the exact same wall and written it down somewhere. And yeah, AI can hand you the answer instantly now too. But here's where I'm going to be annoying about it. Reaching for AI the second you're stuck is the worst habit you can build. That's how you brain-rot yourself. The whole point of being stuck is the thinking that happens while you're stuck. If you outsource that every time, you never actually get smarter, you just get faster at copying.

So my rule is I have to take a real swing first. Google it, then go read how other people solved the adjacent version of the problem and adapt it to mine. That adaptation step is the actual skill. Anyone can paste an answer, but knowing why someone else's solution does or doesn't fit yours is the part that compounds.

I really think AI should comes in at the end, once I've genuinely wrestled with something and I'm still stuck, then it's a fantastic tool and I'll use it without guilt. So the order matters, always think first.

When I started, I didn't reach for the friendly stuff. I went down to C first, to memory and the CPU and how the machine actually does what it does, and only later climbed back up toward the higher-level tools. That's backwards from how almost everyone learns now, and it's backwards on purpose. The reason is something I keep running into, in school and in industry both. People start at the top and they never look down. They learn the framework but not the machine underneath it, and then they spend a whole career standing on abstractions they couldn't explain if you paid them to. It works fine, right up until the day it doesn't.

Web development is the cleanest example. We've stacked frameworks on frameworks on a language that was written in ten days, until nobody can see through any of it. Someone ships a site over a weekend, it turns out painfully slow, and they genuinely don't know why. They go read the best practices, except they're already following the best practices, and it's still slow. The real problem is three layers down, in the framework or the runtime or some box they've never opened. And when you're sitting on a black box inside a black box inside a black box, there's nothing to do but file an issue and hope someone smarter shows up.

A lot of modern software running at something like a twentieth of what the hardware can actually do, and most of that loss is just abstraction we piled on without thinking. That's not a rounding error, that's most of your computer sitting idle because we decided we'd rather not understand it. And it keeps getting worse. Jonathan Blow, a famous game programmer has a whole talk about how civilizations quietly lose the ability to build the things they depend on, not in some dramatic collapse, but because each generation only learns the layer above and forgets the one below. Software feels like it's heading exactly there. It's sliding toward slop, and now AI helps us produce that slop faster than ever. Cheap software, in quotes, more people pouring in, most of what comes out is garbage. I dont want to be mean, but it's just where we are.

Which is the whole reason the fundamentals are the best bet you can make. If you actually understand the low level, the memory, the performance, the security, how the machine really works, you become the person who can fix the thing nobody else in the room can touch. That's what makes you irreplaceable. Not as a career trick, just the plain fact that when the hard problem finally shows up, you're one of the few people who can solve it.

So part of this is honestly just how my brain is wired, I like everything low. And it pays me back constantly.

Rust is home for me, so I'm biased on this, but the pain everyone complains about is the entire reason it's worth it. When people say they're "fighting the borrow checker," what's really happening is the compiler is forcing them to answer questions they were always supposed to answer and had just been quietly ignoring. Who owns this piece of memory. How long does it live, who's allowed to change it, and when. In Python or JavaScript you never need to care about it. The language lets you stay ignorant and feel productive, right up until something mutates underneath you and you're staring at a bug at 3am that shows up one time in a thousand.

I like Rust cuz it just refuses to let you get there. It drags all of that to compile time. The borrow checker it's telling you there's a real flaw in how you structured the thing, before it ever runs. it's pointing at a bug you would have shipped.

And the part that surprised me is it doesn't stay in Rust. Once ownership lives in your head, you can't switch it off. I write Python now and I'm still thinking about who owns this object and who's allowed to mutate it, even though nothing's checking. You start coding as if the borrow checker is watching when it isn't, and your code in every language gets better for it. An easier language would have let me write the same sloppy thing for years and never once told me it was sloppy.

So maybe you should get used to pain, life isnt easy but the struggle is just the compiler teaching you to think correctly before runtime teaches you the hard way, just like life.

This is the same idea as before, the balance between shaping the feature and building the habits that let you shape features faster. A tool is just that second thing made permanent. Emacs is the purest version of it I've found.

The whole pitch of Emacs is that the tool bends to you instead of you bending to the tool. It's absurdly extensible. Anything you can imagine, you can make it do. You pull all your nice little TUIs and tools into one environment, keep a single config, and run that exact same setup on every device you own. One unified experience, shaped entirely around how you work. Most tools make you adapt to them, but this is the one that adapts to you.

That's really my whole point about taste. You deserve a tool that fits you, and you shouldn't spend years contorting yourself to fit a tool just because everyone else uses it. The default advice is "use VS Code or you're not a real software engineer," and that's exactly the kind of hype I'd ignore. Not because VS Code is bad, but because letting the crowd pick your tools means you never find out what actually fits your hand.

So the taste isn't "use Emacs." and honestly I wouldn't recommend Emacs to most people. The taste is that you should try everything, keep sharpening the tools you keep, and when nothing fits, build your own.

Python is what I use when I just want to get something done. If I have an idea tonight and I want it working tonight, I write it in Python. The ecosystem is huge, it stays out of the way, and I get to think about the actual problem instead of the machine. Data/AI stuff, quick scripts, checking whether an idea is even worth building. That's where Python is good.

I know that sounds odd from someone who loves C and writes Rust most of the time. But it's not really a conflict. I use Rust when I care about correctness and speed and control. I use Python when I just need the thing done fast. They're for different situations and I'm glad I have both.

The thing I actually believe is that a language is just a tool. It's not who you are. Once people start saying "I'm a Python developer" or "I'm a Rust developer," they kind of trap themselves, and they end up using that one language for everything even when it doesn't fit.

I don't really get the language wars either. People arguing their language is better than yours. Most of the time that's just picking a team to cheer for instead of solving anything. I'd rather know a few languages well so I'm never stuck. Python's in my toolbox because it's the best tool for a certain kind of job. That's the whole reason.

Is a paper that Ken Thompson wrote in 1968, on searching with regular expressions. It sounds quite dry, it's just matching a regex. But the idea inside it is one of the most beautiful things I've run into.

The naive way to match a regex, and the way a lot of engines still do it, is to try one possible path through the pattern, and when it fails, back up and try another. That backtracking works, but on certain inputs it blows up and the time goes exponential. You can hang a whole server with one short string.

Thompson's idea is to stop guessing one path at a time. You turn the regex into a little state machine, and instead of trying one state, you track every state the machine could possibly be in at once, and walk through the text a single time. One pass, no backtracking, linear no matter how nasty the pattern is. And the part that still gets me is he did this in 1968, and he didn't just describe it, he had it compile the regex straight into machine code on the fly. That's basically a JIT compiler, decades before anyone used that word.

For me AI is a really good tool for exploring ideas. When something pops into my head, I can ask it to draft the idea out quickly and see whether it actually holds up. It also makes learning faster. When I jump into a new codebase or a new project, I use it to break the complicated parts into smaller pieces so I can study each one on its own.

But I don't use it to come up with the ideas for me. Most of the time I treat it like an interview partner. I ask it questions, it asks me questions back, and we go through the pros and cons together. There's a skill I use called Grill Me that does exactly this. It keeps throwing follow-up questions at me, especially on architecture problems, so I have to defend my thinking, and I usually end up at a better answer than I started with.

So the line is pretty clear for me. On the thinking and architecture side, like my 42 projects, I'll use AI to talk through a small piece or to get my head around a concept I haven't learned yet. But I don't let it do the actual coding. The coding is the part where I still struggle, and that struggle is the whole point. If I hand that over, I don't learn anything.

Honestly I don't have a rule for it. I'm the opposite, I'm the kind of person who wants to lean on AI as much as I can. I keep asking it things, I keep trying to pull more out of it. When I ask AI to do something and I get back a result I don't actually follow, it makes me uneasy. I don't like that feeling at all. So I can't just take the answer and move on. I have to go back and understand it, or it sits there bothering me.

The hard part is that AI hallucinates. So I'm always in this tension. I want to use it a lot, but I also can't trust it blindly, because some of what it tells me is just wrong. Being sure the information is actually correct matters to me more than getting something fast.

The way I deal with it is pretty simple. I'll push back and ask "are you sure," and get it to double-check with a web search or another source. And a lot of the time I try to figure the thing out on my own first, then go to AI, because if you only rely on it you can waste a lot of time chasing an answer that was wrong from the start.

To be honest, I think I'd get worse. I don't think a 13-year-old should have this many tools, especially AI-powered ones, which are very powerful.

Like I said before, AI can easily give you the wrong answer because it hallucinates, and it can produce things that never happened. It definitely will.

When I was 13, I don't think I had any critical thinking. In some ways it makes me better, I can learn a lot faster, but as a kid I wouldn't know how to use it correctly. I might just become lazy because of it.

And here's the thing about AI, a lot of the time it sounds better than a professional. So a kid has no way to tell when it's wrong, because it's more confident and more polished than they are. That's why I think a kid with AI only really works if there's an adult around who understands the tool and can guide them. On their own, the kid just gets led somewhere they can't check. The tool can help, but you still need someone to guide you.

The thing that does the most damage is also the thing teachers think is kindness. They take every kid and push them down the same path, and they reward doing what you're told far more than being curious about anything. In their head they're protecting you, making sure you can survive in the real world. What they're actually doing is slowly draining the curiosity out of you.

I'm honestly the perfect example. Middle school in China. My teachers didn't like my real hobbies at all. The whole system there is built so you can't specialize. You're supposed to be good at everything, math, physics, writing, all of it at once. And me being into computers? That did not go over well. They'd basically tell me, "you play on the computer, so you're not a good student, you're not focused on your pen and paper." Looking back it's kind of funny how backwards that is. The one thing I actually loved was the one thing they wanted me to stop doing.

And here's the part I'd really want the teachers in this room to hear. A system like that is built to produce obedient, evenly average students. But average is exactly what the world is about to stop needing. AI already does average work better than an average person. The people who are going to matter are the ones who went unreasonably deep on something they actually cared about, and those are precisely the kids you label as problems, the ones who won't stay on the path, who won't put the computer down. When you smooth a curious kid into a compliant one, you think you're saving them. You're really just sanding off the one thing that would have made them irreplaceable. The kid staring out the window obsessed with one weird thing is usually the most valuable person in the room, and the system is built to treat them as the failure.

Easy, just guide them. That's the one thing. If you know the subject, do your best to help them go deeper. And if you don't, find someone who does and point the kid toward them.

That's honestly the thing I always wished I had. Someone who could tell me what to learn next, or even just sit down and figure it out with me. You don't have to be the expert. You just have to either be the guide, or be honest that you're not the right person and hand them to someone better, it's worth more than the whole syllabus.

Okay, seriously, just do whatever you like. And be good at it. Find the thing you want to do, the thing you actually like, and if you really like it, just be good at it. That's it. There's nothing else. Try your best, put in everything you've got, and be good at it. Choose one thing and master it, that's all. Do your best, and study as hard as you can on the subjects you love.