Mentorflare

Hello and welcome to another live episode of Cloudflare TV. I'm Matt and I'm here today with Usman, our head of engineering. Hi everyone. Hi Matt. Nice to see you. I'm Usman Muzaffar, Cloudflare's head of engineering. And today our subject is another episode of MentorFlare where we talk about our experiences and hopefully share some insight into what it means and how we do work here at Cloudflare and how that might be valuable to people who are looking to potentially work at Cloudflare or at a company like Cloudflare. Matt, I'm really glad to be able to chance to be able to talk to you about this. I'm excited to be here today. For offering to talk to me and I thought, you know, we should just start with you. Why don't you take a second and just tell us a working at Cloudflare? So I'm a returning intern on the workers distributed data team. Last year, I worked on workers developer experience with Wrangler. And my journey to Cloudflare started at the UT Jodhpur. I'm going to be a junior at the University of Texas studying computer science. Yeah. And I had known about Cloudflare before. I would always read the blog posts and I really enjoyed the engineering culture that I saw from the blog posts. Even with some of the scarier incidents like Heartbleed, I could see that there was a lot of effort put into showing real technical content on that blog. And I didn't see that from a lot of other companies. And so Cloudflare always kind of stuck out of my mind. So I made sure to go and talk to the, see the booth at the career fair. And that's where I met Joaquin and he told me about workers and I was super excited about it. And here I am. So let's, let's, let's unpack that last few sentences for a bit. Let's start, let's start from that blog. So a lot of people talk about the Cloudflare blog. Was that in fact, your very first introduction to Cloudflare? It was. So how do you remember, do you remember, I'm just trying to see how much of your actual, the actual interaction, like when did you first hear the word Cloudflare? Was it because you were browsing Hacker News and we were, we were trending up there or something like that? Yeah. I found about Hacker News a few years ago. Yeah. That's where, that's where I first saw the Cloudflare blog. Yeah. Yeah. So I think that's one thing that people outside of our industry may not realize just how many engineers really read Hacker News quite, quite regularly. I know I always have a tab open. And at one point when someone in my family asked me, what's this orange website you're always visiting? And you know, it's so, it's such a key part of, of how you share it. And for those who don't know, Hacker News is a news aggregation site, not unlike others, but all the content is just got a very strong bent for the kinds of things that engineers would be interested in. And so so it's one of the places where Cloudflare articles show up, show up a lot. So I think that's, that's really, really great that that was one of your first introductions. That's a pretty common story that we hear. So, so talk to me, what happened, what happened next? What, what was it that you heard at that booth that got your interest in potentially trying to work for us? So Joaquin explains, explains to me Cloudflare workers, which I hadn't heard about yet. And he was talking about, oh, so we won JavaScript at the edge and all of our colos. And the second he said, you can deploy code in three seconds and it runs all across the world on every request. And under a millisecond, I was, I was hooked. I, I, I wanted to be a part of it. Not a lot of people have that. Yeah. Yeah. The, the scale was super exciting. So I was, I was freaking out for the, for the interview on phone screen that he was, that he set up that day. And thankfully I did well and ended up here. Let's, let's talk about that. Cause I know a lot of people in our audience are probably thinking about that. So even if I have a conversation with a company that I'm interested in and, and I get a phone screen, like now what? Like, so, so as someone who went through this, and it's been a very long time since I've been phone screen. So my advice here is, is all tilted from the other side, from the kinds of people who are asking folks like yourself, but let's, let's hear from you. How did you prep for that phone screen? What did you, what did you do? I asked, I asked a few, a few friends for advice. And I think one of the best pieces of advice I got was to, to know when to admit that you don't know something, but to always know how and explain how you would find the answer. And that's, that's, that's something that I really tried to follow throughout my interview process. And I think even, even if you don't know something is you're still correct. If you come out with a, with a piece of knowledge of how to go find it. Yeah. And saying, I don't know is actually an accurate, is a correct statement. So picking up an answer is a false statement and there's nothing that annoys engineers more than someone who is pontificating without labeling it as pontification. Like if you're just, if you're opining on something, that's fine, but be sure to start with the words, I think, or maybe. That's great. So let's, let's back up for a second. So you're, you're, you're studying and you're a junior right now at UT, at university. Yeah. I'm an incoming junior at UT. So let's talk about why, why CS, how did you even wind up in this field? So all the way back in like sixth grade, I was playing this, this online game cannibal at school. Yeah. It's a little, it's a little side -scrolling game that you run in front of the, you have to jump and like the buildings are falling all around you. And it was like this little eight bit game and it was really fun. All the kids were playing it in school. And I saw it was a flash game, flash game. All right. Excellent. Okay. So I was already interested in computers by then. Like I had Linux on my home computer. I was, I, I, I was obsessed with like, um, like the compass, uh, little cube that you can turn around. I saw that on the YouTube video. That's how I first got in it really in computers, but I programming journey started with cannibal because cannibal is, was made, uh, with this open source game library called flixel and they advertise the library on the side of cannibal and you can download flixel and make games. So I was like, Oh, this is cool. I want to make games. Nice. So I downloaded all this stuff and started watching and reading tutorials and I didn't know anything that I was doing. And it took me like two months before I could even like get something to show up on the screen. And, um, eventually actually, uh, started hanging out a lot in the, uh, in the flixel IRC channel. Um, as a little kid, I was like 11 years old and, um, I actually did a Ludum Dare, uh, with some of the people on that channel. Um, and I'm sure someone's going to go and dig this up now. Um, and I made a game in 72 hours with some of the other people that were hanging around there. And, that's really where I got my first exposure to programming and working with other people. So I just want to pause for a second, because this is a very typical story. And yet sometimes this, a story like this is interpreted as, Oh, how am I going to compete with someone like Matt? Who's been programming since sixth grade. And, uh, and I, and I want, I want to tell them Matt story with a slightly different lens. Um, because what did you see? You saw someone who was interested in something like had, had that game noticed that it said, how was it built? You know, and that was all it took was that right click on built with, what was the name of the library? Flixel. Flixel. Never. I've never heard of it. All right. So built with flixel. Right. And so what you're seeing here is the primary trait that Cloudflare engineering looks for, which is curiosity, right? That is, that is the one thing that we are constantly that myself and the other engineering leaders who are interviewing new candidates of any level, regardless of whether you are, this is your first job out of college, or this is, you know, you've got 10 years on us and you're, you know, you've been doing this for decades is where is the curiosity? What is the desire to learn? And so this is exemplified really nicely in your story, Matt, because you're like, Hey, how did they build this game? Hey, check it out. It's right here. Oh my gosh. I could take a shot at this. And also buried in there was, it took me two months to get anything out. Right. And there's no incorrect number of months. It could have been, it took me six months to get something out. It took me 11 months to get something out. You know, that's all fair game. And then you went and sought feedback from other people. And I think one thing I want to say to our audience, one of the, some series of questions that we get a lot is, Hey, I studied something other than computers. The whole thing looks so intimidating. How do I get in? And the, the inspiring thing, you can, you can look at someone like Matt and be like, wow, you know, already at age 11, writing a game like, Oh my goodness, this, this is like, this is way out of my league. The other way to look at it is an 11 year old got in. So there's nothing to prevent you from getting in. And so that, that is, that is, I think a very inspiring story and not one that we should, we should look at as, as like, if you, if you didn't make the right call in sixth grade, you will never get into, into tech. Cause I don't think that's true at all. Great. Okay. Let's keep going with the story. I love it. So you're, you're, you're 11 years old. You're now entering middle school era. What's the next part of the, of the, your journey on computers and software and technology that's interesting. So I'd say where I started getting more interesting in the low level stuff is I had come across this capture the flag competition that was run by Carnegie Mellon university called I go CTF. That was excellent. They aimed it at high school and middle school students. They bid a huge effort to teach kids really advanced reverse engineering and security topics, like stuff that you would never ever expect kids to be doing. And people did really good. And I, I competed in seventh grade in the first PICO CTF. And for like two weeks, I didn't do any homework. My mom was driving me nuts saying that I'm horrible in my classes. All I was doing is PICO CTF. I'd go home and spend eight hours for two weeks on this. So what, where's this virtual flag that you're trying to capture? So, um, there is like five categories of, um, of problems. And usually it would be like you, you, you have to, uh, you have to like break into this privilege process and, and run some and run some code in it to get a flag that was that only that process could access. And a lot of the, uh, a lot of the problems generally fell into that category. And, um, there was also a few that were, uh, cryptography and that was my first exposure really to like higher level math. And, um, I really struggled with those, but it was, it was a challenge. Um, and I'm not the greatest, uh, math student, but I felt that, um, when you're motivated, you can, you can get through. So I did solve some of the crypto problems. Outstanding. Okay. So we're up to, so by this time, if somebody asks you, Hey Matt, what do you want to be when you grow up? What was the, was the answer just rolling off your tongue right away? Yeah. Programmer. I want to be okay. So we're, we're, we're in range. So, and, and, uh, you know, I'll tell a little bit of my story, but when I was at that age, I was also by now really like to me, the, one of the coolest things that in life was computers, but I was still giving a very different answer to what you want to be when you grow up. So we'll get to that in a second. But so, so by the time we're at high school, you are definitely interested in computers and you're, you've got your, your, uh, you got your hands dirty with some interesting projects at multiple layers in the stack. So it makes sense. UT Austin computer science. What did you, what, tell me something about some of your favorite classes and at university, which ones, what, what did you do? And what did you like about them? So my two favorite classes so far were operating systems and computer graphics. And both of those were because of the professors. They, those two classes had, um, the absolute most amazing professors I've ever had. Um, probably the best teachers in general I've had in my life. Um, they, they, they came in there and both, both of those guys could teach from the top of their head and no slides, nothing. And talk about the most complex, intricate topics and explain them from first principles. Excellent. Give me, give me a, a memorable lesson or a memorable idea. Operating systems is just jam packed with so many, so much, so much, such a rich amount of stuff. And it's all recent, right? I mean, the whole idea of an operating system is only, is only a few decades old. So does one stand out? Does any idea from operating systems stand out as like, I can't believe this is how it works? Um, I think, uh, like one of the most memorable moments in operating systems is the first introduction to like race conditions and concurrency problems. And, um, we're, we're in our, we're in our discussion session and the TA gives us this problem and, uh, and describes it and everyone gives all these answers and all the reasoning behind their answers and everyone in the class is wrong. Wrong class. One person got it right. That person Googled it the night before. Let's not give them any credit either. Yes. So, yeah, I think, um, so again, just keeping to the spirit of our topic, if I can pop a few levels off the stack here, part of what I just asked Matt, um, what are your favorite classes? That's a pretty standard question that any new graduate will get. Um, when they, uh, when they interview, uh, certainly as long as I've been interviewing new, uh, new graduates, I'll always ask what are, what are some of your favorite classes? And part of the reason I'm interested in that is I'm looking to see like, what is it that, what is it that is makes, that makes you and there's no wrong answer. Like, so Matt cited that he really enjoyed his professors. That's great. That's why a lot of us pick the careers and interests we are because someone was inspiring. Someone, someone taught us in a way that really resonated with us. And, but, uh, again, you know, the, the ability to say like, yeah, I remember learning this thing. And I remember thinking that's such an interesting idea. And it's so clever the way the giants, we all stand on top of, you know, all of us are standing on the shoulders of giants. Uh, so, you know, all the, all those, all those great scientists and engineers who invented the operating systems and race conditions and the dining philosophers problem and, uh, and threads and all that great stuff. Um, just reading their, their ideas and, and understanding them is so inspiring. And that's, that's what I'm looking for. Right? So why, why would I ask that? You're not going to relearn OS theory. You're not going to be anywhere near OS theory. Uh, that's already baked into the platform. Maybe someday we'll have somebody working on, on, uh, on a, on a novel operating system, but right now Cloudflare runs on Linux. Everyone knows that. Um, and so the, um, the, but the, the, the spirit of the question is what, what was it that got you excited as you were learning? How do you respond to new ideas? Because that's very much, that is what happens inside an engineering team. Uh, so great. So you said, Oh, S was one, one, tell us a little bit about computer graphics. You cited that one as the second one, right? So graphics, um, was also a very low level class and it was, this was the first time I had that I, I had, uh, taken a class at school. That was something I had never seen before. I had done a little bit of like 2d game programming, but I hadn't touched a single written a single line of code for 3d game programming. And that's, that's a completely different world with a lot of reliance and math. Um, there's a lot of, uh, you have to know linear algebra really well and have like an intuition for it. And developing that was a really, uh, difficult part of the class that I found exciting. And also like kind of like unpacking all of the, uh, all of the cruft you had to do to deal with these graphics APIs. That was really difficult. And since setting up your program to send data to the GPU, all the things that were hard about it. So, so why was it, why, why, why is it making your favorites list? If it was just a big pin in the neck, I'm drawn to complex systems. I really, I really like, um, untangling complex systems and, and I wouldn't even say only, only computers, but, uh, in general, I just, I think that's where all the interesting problems lie. And I think that's another, that's another sign that I would look for, uh, in an interview, which is what, what, what did you like? What did you enjoy the challenge of, even though let's stipulate, there was a lot of mess. There's a lot of cruft, a lot of complex APIs, and that problem shows up all over the place. Maybe it's in Kubernetes, maybe it's in, uh, dev tooling, maybe it's in how you talk to databases like this, this, uh, what the thing that turns most normal, regular people off software engineering is that from their perspective, they look at it and they're like, well, I have to deal with this machine that is so unforgiving. And if I make the slightest mistake, it yells at me. And I've got to explain everything in such an excruciating detail that I get why some people are excited about the creativity aspect, but I can't, I can't get past the tedium and the, the amount of details and the mess I have to deal with. And so that's another spark because I think the best engineers, the balance for them is way off. They will happily accept the amount of nonsense and the amount of tooling and the amount of crap you have to go through, uh, knowing that it's a pain in the neck and, you know, telling, writing the to-dos for themselves and saying, yeah, one day I'll automate this. And one day I'll make this smoother. And one day it'll be, it'll be easier, but it's okay. I'll deal with the pain right now because think of the cool thing that's going to come out of this, right? Think I, they can, they're motivated by the thought of that, of that, of that, uh, 3d game that's still in the conceptual phase. Um, so, and that sort of leads me to my next question. Um, Matt, just forget Cloudflare and forget the projects you did in high school and in college. Um, what, give me examples of things that you find interesting and fascinating. What, what are, what's technology in our industry that you think is cool or that you have your eye on or that you, you, you find inspiring? Um, that's a, that's a, that's a tough question to, to, to, to bring out. Cause there's so many, there's so many possible answers there. Um, here's another way of asking, what's a, what's a tool that you work with regularly that you don't hate? You, you like it. Um, then I love them. Then there we go. Let's talk about them. So that just, just so everyone knows what is Vim? Vim is this ancient text editor, uh, that was written by Graham Molinar, I think that was, uh, like 30, 35 something years old at this point with a very, uh, very intricate user interface that's in the subject of many memes over the years. Um, but it's, it's the, the interface is very terse. Once you learn Vim, it's a very efficient way for, for editing texts. But, um, there's a, there's a, there's a lot of debate on whether the Vim interface is the best compared to other ways. Great. And, uh, for those who don't know the, the classic, uh, and the, the, the other famous, uh, um, opponent of Vim is the Emacs world, which I happen to be. So Matt, you and I are going to have an Emacs versus BI, a cloud for TV session, and that will get 1 million views in one second because there's engineers love more than having an editor work. Um, so, uh, so we'll, we'll, we'll table that one for now. Uh, uh, one more question before we, and then, um, you, you can ask me some questions. Um, what'd you work on last year? So last year I worked on Wrangler, which is the, the CLI for workers. Um, and I built the, the live reload feature for Wrangler. So you could, um, to make it easier to work on workers, you can have a single tab open and make changes. And it would update that same tab. And I was really driven as a, out of a desire to have, um, this faster iteration time. I was getting really frustrated, uh, with, with working on workers before. And I made this, I made this demo and I pitched it to the team and it happens. Yeah. Um, great. So that's, uh, you, you've, you've had a chance to work with some of our, some of our most interesting, uh, technology. And so, uh, it's, uh, it's, it's really great that you've had a chance to be part of the team and work with it. Um, I'll, uh, uh, let me, let me, uh, let me compliment Matt, Matt, Matt's story with a little bit about myself. Uh, so Matt, I'll, I'll go ahead and pretend you just asked me. So tell me about you, tell me about you. Um, uh, so I will, I started, um, in a very different field. I was studying biology and was going to, and studying to be a doctor. So that's lesson one. I want to impart to the audience that if you studied something other than computer science, you shouldn't in any way be dismayed or think that software engineering is somehow off limits. Uh, there is a, uh, it's such a young field and there's so little figured out that, uh, anybody who's smart and curious and empathetic, or who's trying to be smart and curious, empathetic, you know, aspiring to those things, I think we'll find that there's plenty of opportunity to, uh, to add it. I, my story in some ways is a lot like Matt's because I was messing around with computers when I was, uh, when I was a child. So I, I got my first computer right around the time that Matt was I think, I think it was like 11 years old or so as an old Apple too, and, um, really loved it, tried to learn everything about it. It was, it was difficult in those days because there was no Internet and there was limited material. So part of the challenge was just trying to get information about how the computer worked, which now you absolutely take for granted. You can just, you know, in a few keystrokes, Google anything and, and learn anything you need to know about how something works. Um, but if you had asked me all through high school and all through college, for that matter, what would you like to be? I would have said, I want to go into medicine. I was studying, uh, biology and molecular biology, and I really liked medicine. I mean, I really liked, uh, biology. I thought that was really cool. So for all the, all the stories that Matt said, like the operating systems opened up my eyes and computer graphics were great. I could have given you a corresponding story about how I thought recombinant DNA was really interesting. And, um, and all of that was, was going great, but somewhere along the way, uh, as I entered, um, my, my medical studies, uh, the Internet really started to take off and it was impossible to ignore. And I found myself spending more and more time, uh, on this new technology, uh, downloading this program called NCSA mosaic and trying to tell everybody about this thing called a web browser and, uh, and, uh, and way beyond email. Email was more or less established, but that was it. And the idea of where does email fit into the Internet with some was, I remember trying to understand as a medical student, what is the difference between email and the Internet? Like even a basic question like that was kind of, uh, was, was kind of hard for me to answer in 1992. But when I did understand what's going on and suddenly had a model, I was like, this is really cool. And so I made the difficult decision to leave medicine and transition into computers. And, but basically I just got a job at the university where I was studying, uh, working for a professor of psychology of all things who needed tools built. And this was a very unusual part of the story because I had no form. Not only did I have any formal training in computer science, so I had taken a few classes. I took an operating systems class and I took a database class. Uh, so I had some idea, uh, but I didn't have a degree or, and certainly not a full engineering curriculum, nor did I have any proper understanding of how a software company works because I was basically a purpose bespoke tool builder for this one university professor, uh, building interesting, interesting statistical tools and tools to help run experiments in that lab and tools that, uh, did other, other various things. And, and this, uh, professor was a great lover of computers and technology at probably six different operating systems and, uh, six different computers, including a next workstation and a true 64, uh, uh, deck station and multiple spark machines. So I got good at all kinds of wacky things. And the other enormous asset I had was time. I was never under any pressure because it was an academic environment. And because, uh, they were all long running projects and there was no customer other than the boss who was sitting right next to me. Um, I, I had the time to learn things. And I think that is, uh, that has served me very well, but doing all this, the Internet is blowing up and everyone's saying, you respond, you have to move to California. That's where all the action is. You have to get a job in the Bay area. Uh, and I was very intimidated by that because I didn't have a CS degree and I didn't have any formal work experience. And, uh, all I had was, uh, uh, uh, projects of various forms that I worked on that I was happy to talk about. And, uh, so one thing I did do was go to a conference and try to meet as many people as I could. And I think that was where I happened to meet, uh, the people who, uh, who eventually gave me a job in California. But I think that the, the larger lesson I'd like to think here is you don't have to have studied computer science to get a job in software. I'm a, I'm a perfect example of that. Um, but you do need to really care and really be curious and have almost an insatiable curiosity for how things work. And, uh, a little bit of, uh, develop a little bit of a, uh, a willingness to ask the question that, you know, may seem like a quote unquote, stupid question. Like I just don't understand how this works and, and, uh, and ask them. And now it's, it's way easier with forums and, uh, with so many different places to learn from people. I think people forget that, but the, uh, the, uh, the advice that worked very well for me is always ask questions. And I got pretty good at asking questions and just constantly try to learn where, where my thinking had a gap and, and, you know, you understand something, if you can explain it to somebody else, if you can't explain to somebody else, you probably don't understand it. So that was another thing that I spent a great deal of time trying to, uh, trying to, trying to, and, you know, Matt's, uh, feedback at the beginning was don't ever pretend like, you know, something when you don't, uh, I think is also really important, uh, especially as you start to work with teams. So I came out to cloud, to, uh, the Bay area, and I joined a company called script X, which at the time had spun out at sun microsystems and was working on the tool command language. So if you're still running a Mac or a Linux box and you type TCLSH, or if you ever use Mac ports, uh, or a whole bunch of other tools, uh, that are still built on the TCL, the tickle programming language, I had the privilege and honor of working with a lot of the core team behind that. And so got to get to really understand how, how proper engineering works. And, um, when that company wrapped up another one, another one, uh, another startup from those same individuals, uh, was funded and, uh, they invited me to be one of their early engineers. And that's really where I grew up. So it was a dev tools company called electric cloud that I started off as an, as a junior engineer and eventually had a whole bunch of different roles. I spent some time in product management. I spent some time in customer support. I spent some time in sales engineering, and, um, that is unusual, uh, to have sort of done the Robin of different roles in a software company. Um, but it's one of the things that I really, really like about my, uh, my time at electric cloud is that he exposed me to so many different parts of the business. One of the questions we've had is, is it important for, is it important for software engineers to have a background in business and to understand the business? And Matt, you and I started to go back and forth on this a little bit. Uh, do you, do you have, do you have an It is important for software engineers to have a sense of the business of the product that they're building. I think personally, um, I find it, I find it important for myself. Um, I think it's guided some of my decisions, but I think the product that I work on is very unique in the sense that engineers have, um, a lot of say in the direction because we're building something for engineers. And, um, I think knowing the product is a very important part of that. Yeah, absolutely. I think, I think that's a, that's, that's a, that's a key thing. Um, I'm going to switch to, I'm going to try something. I'm going to switch to just, uh, um, I think, I think if, uh, Matt, if you can go ahead and address the, the, the sound that's in the background, I'll keep talking a little bit more about my experience while you, while we address that. It's a live show folks. Part of what part of what we're doing here is making sure that, uh, it's as good. Well, that was fast. That's all it took. Excellent. Yep. That's all it was. I was just explaining that it was a live show and we're still working out the kinks. So that was, that only took two seconds. Well done. Okay. So the, the other question I think, um, uh, that, uh, is, is, so what, what happened next? How did you wind up and, and get to, um, get to Cloudflare? Um, so the next part of the story was that having been in a whole bunch of these different roles, having been in, uh, in sales and in product management and in, um, engineering, I suddenly got the urge to start my own startup. And, uh, so I, I got, you know, right, right around that time. It's not been eight or nine years. I got great ideas. I got, I'm going to build something on my own. And at the time the mobile revolution was taking off, the people were realistically looking each other in the eye and saying, you know what? I think PCs are dead. And so, uh, the iPad had just come out. So around this time, uh, myself and another, another friend of mine from electric cloud, we started, uh, we quit our jobs and we, we started a company and it took us a good year before we really sort of had enough of an idea there that we were, we could credibly start to raise funding. We entered ourselves into a couple of startup competitions. We did really well. The product was really beautiful. It was an app for salespeople and, uh, and we got funding and I was able to hire a couple of, uh, some of the best engineers I'd worked with. And that store, that company was called Celigy. And, um, it was, it was great. We were able to build some great products and, uh, and land some, some customers. Ultimately we were acquired by a company called Viva, uh, which is another great success story in the Valley. And so I'm very proud to say that the team in mass went to Viva and we continued to stay together as a team and worked on things inside Viva. Uh, but from there, um, the, uh, John Graham coming, who was our CTO again, called me and said, I really think something great is happening at Cloudflare. Why don't you come help run engineering with me? And so, uh, uh, Cloudflare, I just had a change in leadership. And so there was a position open. So I actually joined Cloudflare in the end of 2016 as engineering chief of staff. Uh, and if that sounds like a made up job, it kind of was a little bit, it was mostly to help John get the team organized. And a few months later that turned into officially the Cloudflare, uh, head of engineering job. And so now at Cloudflare, uh, most of the teams that are building the main products, not all of them. There's a lot of, a lot of different places where products get built. I report into my organization as well as the teams that are responsible for operations and network. So a big chunk of what makes Cloudflare, Cloudflare is part of my organization. I'm really proud to be part of that team. How would you say your role has changed over the years since you joined? It has changed. Yeah. So it started off, like I said, just, uh, at the time I joined Cloudflare was maybe 50, 60 engineers in the main section with five or six engineering managers. Um, we are quite a bit bigger than that now, uh, numbering hundreds of engineers and dozens of engineering managers. And so part of my job has been about scaling the management and scaling the process. Um, and then over time I've also become more and more involved in operations as our customers have become more demanding. We want to make sure that we continue to develop an even more resilient and more reliable and more secure service. And so that becomes another part of it. And so really my job has evolved because the mission of the company, while that has stayed the same, the bar, which we're trying to hold us to keeps going. So there's more products, there's more scale, there's more people. And that means that the nature of my job changes, even though the mission stays exactly the same. How has Cloudflare evolved? Um, how has Cloudflare engineering hired people to keep up with all this growth? Yeah. So hiring people is a big part of, is a big part of the game, right? So like there's, there's only one of the most fair things in life is time. There's only 24 hours in the day and that's true for all of us. So the only way to make more time is to hire more people who can, who effectively can, can increase your bandwidth. So I think, uh, I think we've done a good job at hiring at Cloudflare, you know, we've opened up offices in more places and we have, um, we have paid attention to how we hire and what kinds of and the kinds of the programs, like the ones that you're a part of the internship and then coming back as a full-time employee, uh, later is another thing that, uh, some interns, uh, uh, have done. And so I think a lot of it is paying attention to, um, where we want to hire, what, who we want to be on this team, making it more efficient and then paying attention to other things that we really care about, like diversity and location and cost of cost of living so that everyone isn't necessarily working in the barrier where it can be very expensive. And so I think it's a, it's a cross -functional effort to pay attention to where we are growing things and being very intentional about what it is that we want you engineers to be working on and always put our focus on the, uh, on, on the place where we try to move the fastest. So, um, I think, I think we're good to move to Q and A before this episode, we had like 1500 students, uh, submit questions for us. And we've been, we've been discussing in the ones we wanted to talk about and I think we have some great ones. So, um, I'll start off with, what do you think are the most underrated technical skills right now, which will be needed for the future? Yeah, I knew this question was going to come. Uh, so, cause, uh, I think, and I'm going to answer in a frustrating way because I know what people are hoping for is, you know, point me to the O'Reilly book that I can get and point me to the, to the programming language that I should learn. Um, but I actually don't think that's how it works. I don't think the, the, the underrated technical skill is the meta ability to learn new skills. Uh, that's actually what's most important. There's an old joke of, uh, you know, when, uh, that, uh, sometimes you'll see, you'll see recruiter posts, uh, Hacker News loves to make fun of this. Uh, you know, Swift programmer needed 20 years of experience and the language itself is only seven years old or whatever. Uh, so like the, the idea that this is a baked tech industry is simply false. We're still learning what it means and how you develop software, especially software at scale, like cloud for scale. And so the, the technical skill that you need more than anything else is the ability to acquire new technical skills and having the emotional attitude that says, no matter how much I loved something or how proficient I became in something, I'm interested in learning a new way of doing it. Even if I am the world's fastest Python programmer, uh, maybe I'll, I'm going to spend an afternoon learning how Rust works. Uh, even if I really, really love, uh, Postgres, I'm going to spend some time learning, uh, you know, CockroachDB or something, some, some, something new. And so I think that, that ability to dive deep, you know, just sort of headfirst into new technology and have a little bit of a framework for yourself for how you explore things. I think too often you read about something on Hacker News, you open up a couple of tabs, you look at it and go, huh, that's interesting. And that's that. But really what I've noticed some of the best engineers do is they book an afternoon for themselves. They've, they've set aside a Saturday morning and they sort of clear their desks and they make a big cup of coffee or whatever it is that gets you in the right headspace to just, okay, I'm going to download some new crazy technology, some new package, some new language, and I'm going to play with this and I'm going to get better at understanding how, um, how, how this works. And that is, uh, that is the skill that I think is, is one of the most important to learn how to do is what would you say though, Matt, what do you think is one of the most important skills? I would, I would agree with that is, is learning how to, how to learn new systems, how to, how to be a polyglot, how to learn new languages, how to learn new frameworks. And I think the best way to hone that is, is to do by doing is you just have to keep exposing yourself to new things. And I think some of the most productive things to expose yourself to are things that you don't agree with things that you're unfamiliar with. Like something you look at and you go, what is this? I don't like it. I don't want to learn it. Like if you're very picky about syntax, you only like white space languages, go learn something weird. If you only do scripting, I would just go learn rust, go learn C. If you like verbose syntax, go learn K the weird language for this time series column database that, uh, definitions for a function are shorter than the name for it. There's so many things you can learn out there that will open your horizons and give you new, give you new ways of thinking about complex things. Yes. And actually, as you're describing that another thought occurred to me, which is another important point, never be scared to take the wrapper off the thing, right? Like don't accept that it's like, like, go ahead, download the sources, grab through it. Somewhere in there is the system call that opens the file for the new language. Somewhere in there is the system call that makes the network. Like I think another thing that you will, you, we notice about, uh, some of the best engineers is a fearlessness to go lower in the stack because after all the stack was just made by other engineers. There's nothing sacred about any of this. It's just all other engineers who had set one point, sat down in front of a keyboard with headphones on and banged out some code. And they didn't have any special ability. Uh, there's that old quote about, uh, hockey team that was trying to look folks. They, they put their pants on one leg at a time. That's absolutely true in engineering too, right? Like it's, it's, it was just engineers. There's just people like us who sat down and wanted to solve a problem. And, uh, and so you sh we should never feel like something about that's off limits. You know, one of the things that took me, like I was halfway through my career before I sort of internalized, there's nothing sacred about the kernel. You can get into the kernels also just source code, just another program. Like go ahead, download the kernel sources, pull it up in a debugger and step through it. Like learn how some of this stuff works at a lower level. Um, and, uh, and never be afraid to ask why you may find frequently that there is no good reason why there is no good reason why, why some convention is there, or the reason why is so antiquated, it doesn't make sense anymore. And that's, you know, that's one of the great insights that actually that's a great lesson for product management is they don't let themselves get bound by the past and can think through like, you know, that's not really important anymore. We can, we can let go of that requirement. Um, and, uh, and, and, and, you know, great new products get a lot from there. And Cloudflare gets hundreds of intern applicants. What can one do to stand out? How would you recommend making use of networking virtually? Hundreds of applicants is right. You know, we doubled our intern class. I was just texting, uh, our, uh, intern coordinators and, and other, other leaders who are responsible for the intern program. We have 80, eight, zero interns, uh, or, or something in that order. A lot of interns that we are, that we are, uh, hiring, um, for, for this year. So, so while we've doubled the class, uh, size, there's still immense competition. Uh, so it's a really fair question. How do you, um, how do you stand out? So let's start with the basics. There's no doubt that academics matter. Uh, if you, if you're, if you put yourself in the shoes of myself or any other engineering leader, who's going through a stack of resumes, you've only got, uh, an hour or say to go through 50, 60 resumes, what are you going to do? You're going to, you're going to try, try, try to fill. So grades matter. So for, if you're, if you're wondering, is it worth putting the extra effort into that CS problem set for the OS class or for your graphics class? It is, it matters. That's one of the first things that we, we, uh, that, that is used as a, uh, as a thing. But again, it's just, it's just an initial, initial filter. I think that the next thing we look at, uh, other ways to stand out are what kinds of projects have you done and what is there some kind of a story to what you have taken? Are you, is, uh, um, are you interested in projects from high school? Are you interested in projects that you've done after all? Is there some kind of a narrative to what kind of things you've been interested? If I take your example, Matt, you said, look, I started off wanting to, uh, I wanted to just learn with games. And then from there, I got into a more low level thing about cryptography. I started programming where I took a little, some on graphics classes, this idea of extending this to the edge and being part of a company that is making it easier to write code in a new way, this kind of narrative. And if you were to package that into a cover letter and I know cover letters are sometimes they go out of fashion, but frequently we will read cover letters. And we, and if there's, if it's clear, a candidate put some thought into trying to explain why their interests and their past activities line up with the positions that are open at Cloudflare. Um, that, that, uh, that's interesting that catches our eye. Um, open source projects, uh, can be, are, are, are great. Especially if you used to use this word, this frame, I don't know if people still have it. Resume quality. Like if you're going to point us to an open source project, make sure it's your best, best work, you know? Uh, cause we're only going to have a few seconds. Unfortunately people will click through it, but if it's clearly documented and clearly, uh, the code quality is, is really stellar. And maybe it includes tests and a well thought out idea of where you want it to go next with it. Um, and it's not just a fork of something that someone else did and it's not, it doesn't, it, it, it showcases initiative and it showcases passion as opposed to accidentally. Sometimes we see this showcasing laziness. Like what you don't want to do is accidentally send the sense that I took the classes that my university assigned to me. I forked the repos that my buddies told me were interested in and I would like a job. That is what is impossible for us to distinguish from. That doesn't mean you're a bad engineer, a bad candidate, but if the question is how do you stand out? That is an excellent way to not stand out. Um, whereas if you, if you highlight things that you care about and projects you've worked on, um, that catches on. But definitely the thing that catches our eye the most is a non-trivial project. And this is a tall order. Uh, but what I mean by non-trivial is something you have built and worked on something that actually has eyeballs, has users. It doesn't mean they're paying. I'm not saying you started your own business. I know that's, that's impossibly difficult. That can be really hard. And honestly, that was going great. Maybe you don't even need a job. But the, uh, but the idea that you have a, uh, you have a project that has users, anything, right? You, you built a library that has stars on GitHub. You built a small service that a bunch of people are using. Uh, you know, it's, it doesn't matter what it is, but the idea that you have run something in production, even if production is tiny, that really catches her eye because there's an enormous difference between running something that just is on your laptop and running something that the real world actually uses and bangs on. And that, that is something that I think, and I don't think it takes much to give it a shot. Like you could put up a website with anyone of any silly idea, tweet about it, point your friends at it, get a few people to try it and then watch what happens. Watch how, how many different errors show up in your logs. Now, how many different places you are, how many times your latency is lousy because of some other corner case you hadn't thought through. And as you pay that down, you will learn so much about what it takes to run a service in production. And if you can highlight that in your application, you'll catch our eye for sure. Um, so those are just a couple of the things I think, you know, um, clear resume, uh, you know, it's better to have not list everything, not list every class, not like I, we're not impressed by long resume, especially if you're only two years into your, you know, this is your thing. I don't expect a resume that's more than a page, but I want that page to have a very high signal to noise ratio, right? So I should be able to look at it and say, this is what this person has studied. This is what they're interested in. Here's projects they've worked on. This is what I'd like to, and, and extracurricular stuff is fine. Like, you know, uh, if you're an athlete or an artist or a musician, uh, those all, those all catch your eye because those all usually are indicative of somebody who has passion, who has curiosity, who is interested. Uh, and those, those are, those are all, those are all, all fair game, especially when you're early in your career. All right. Here's a, here's another one that's quite specific. What advice do you have for a rising junior student who's interested in AI and interning at Cloudflare? Yeah. So we picked this question because that's a particularly, okay. So let's just answer the question. What advice do I have? Everything I just said, apply to Cloudflare, indicate your interest, maybe add a cover letter, AI at Cloudflare, uh, where we, where we use it the most as you, if you read our blog is on how we, uh, our, our security products that are looking for, for bots or malicious activity. They use machine learning and artificial intelligence to identify is something good or bad. So the more you can learn about that, the more you can play with that. In fact, this is a good plug. If you were part of the interim class that applied for Cloudflare, one of the things we're working on, and you'll, you'll get more details about this, uh, soon is a, uh, is a way to make it, uh, a small free, um, free credits so that you can explore the Cloudflare service. I think a little bit of actor of workers and access and our storage products. So engineers, uh, who are, who are students can, can explore that. So that's really exciting. So I think play with our products, uh, try to explore them a little bit is, uh, is an excellent idea, but I think buried in that question is a meta, is a meta answer, which is I'm interested in AI. Okay. That's great. Again, like I said, I'm looking for a passion, but it is also very important not to accidentally pigeonhole yourself because we're, uh, if you look at the world from my point of view, I have, uh, you know, dozens of engineering teams working on lots of different products. And what I'm, what we're trying to do is make sure that the Cloudflare business builds the products that are most valuable for our customers, whether they're paying customers or freeing customers. And as we do that, the challenges change over time. So yes, right now it might be, I need a, I need a whole crew of individuals who are going to be awesome at AI, but maybe next time it's something else. Maybe we need to migrate to a new platform or I need to rebuild a proxy, or I need to rethink how databases are organized. And so one of the ways to make you to grow fast. And I certainly this served me very well is I actually have very few opinions on what I want to work on other than I want to work on something that's important to the business. And so that's another piece of advice that I think, uh, we don't tell young people enough, which is the advice to work on something where you will learn the most is fantastic, but always ask your prospective employer, what is it that you're facing? What are your problems and what can I do to help and be willing to pick, to join any team, uh, to give it a hand, because you'll find that the problems change so quickly, uh, that the people who are adaptable and flexible, uh, in some ways have some of the greatest opportunity for growth. Can you explain the differences between the different types of engineers, like front-ends, back -end systems? Yeah, I think this is important. This comes up a lot and not all teams use it, use the terms interchangeably. So front-end for Cloudflare usually means user interface. So, uh, the, if you go to Cloudflare's website and you go to dash.Cloudflare.com, that's the, that's the control panel. And so when we say a front-end engineer, and by the way, these terms front and back come from simply, if I'm the, if I'm, if I'm the human being, and I'm sitting in front of the color, how close are you to the, to the human being? So this is more towards the front versus the back, uh, meaning that it's, it's further away from the user. And so front-end engineer at Cloudflare is, uh, usually someone who has user, user interface, uh, events. So people who are interested in JavaScript frameworks or user interface technologies and are interested in making that back-end systems, uh, it's just the converse folks who try to stay away from the front-end, but are much more interested in how the databases or the data or the flow or the APIs that are backing those systems work. And that's again, just a, just a delineation to help, uh, understand what kind of roles are open. There's nothing set in stone. I've got plenty of backend engineers who write front-end code. And I definitely have a lot of front-end engineers who are like, actually, I'm just going to fix the backend part of this. So we move back and forth. Uh, the roles that are more, we use the term systems engineer at Cloudflare. It's just, it's historical, but really it's exactly what software engineer means at other, at other companies. It is somebody who is mostly writing code, uh, and paying attention. The other role at Cloudflare is system reliability engineer. They also write software, but they have a much more operational focus. So they are frequently at a root command prompt and they're frequently making sure that systems are doing what they're supposed to do. Uh, as I think our, our head of SRE is the implicit else in every piece of code. So if you, whatever you, whatever you didn't think of, if you think of all the, all the conditions that your software is supposed to be able to handle, if it, if it, if it suddenly is faced with something that the engineer who built it didn't encounter that last else clause, the implicit person who's going to make sure that this thing stays up and figures out what do we need to do to make sure that it continues to deliver great service to our customers, that's system reliability engineering. But those are the roles. There's, uh, there's a lot of overlap between them and I, I wouldn't, uh, I don't think it's worth getting too hung up on the roles because they're, they're, they're, uh, engineers move quite freely between. What do you think is the best way to transition from a technical role to more of a product or managerial role? Yeah, I did this. Um, so it's the, um, there's a book that I love that's about, this is called Inspired by Marty Kagan. And he talks about how, I think I can't remember what company it was, but he spent, you know, two years working on a piece of hardware and it didn't sell well. And at one point he said, but then why were we working on this? Like, how did, how did we, whose idea was it for us to build this? This wasn't a cloud, this is decades ago. And, uh, and that's when you, you start to realize there's a whole other discipline called product management and product management sort of grew up in, in front of me in my career. When I first came out to the tech industry, there were very few people who had the job product manager and everybody who had that job, other people would look at them and go, what does that mean? Are you in marketing? Are you in engineering? Are you, what exactly does product manager do? And now it is very well understood. Product management is a full-fledged, full-fledged peer of engineering and marketing reports to the CEO and product managing job is to figure out what are we building? Why are we building that? Um, when you're a very small startup, those are the same people. Uh, when I was part of my startup, I was product manager and systems engineer and janitor. Uh, one of my other jobs was to clean the bathroom because there was only three of us. And I, I wanted my colleagues to write code, not worry about the bathroom. And so, uh, but as you grow, you stratify. And so the team that is responsible for figuring out what to build product management. So that's, that's my, my, I gave you that explanation because the question is how do I transition into product management? And the answer is to continually have a very high bandwidth open relationship with your product manager. Someone has already told you what to build. If you've come to Cloudflare because we have a very talented and mature product management function. And for engineers who want to go in product, I would ask that they ask a lot of questions and check all their opinions because you don't have all the, all the information that the product manager has. They're the ones who are talking to analysts. They're the ones who are talking to customers. They're the ones who are talking to the founders. They're the ones who are collating all the information from the world to try to figure out what it is we should build. And it can be very easy as an engineer who's asked to build something going, this is dumb. I don't understand why we're building it this way. I got a better idea. We should build it this way. Instead, I should be the product manager. That is not the right attitude. The right attitude is instead to ask, wait, why, why are you asking us to build it this way? What other choices did you, did you, uh, and that the more empathy you build for what the product manager has to do. There's other rules about product managers. Product managers aren't allowed to be cynical. I frequently talk to product managers as like, you must always have the operator because the product manager is driven through a sense of true unbridled optimism. We're asking you guys to build this because we believe it's going to be a success. Engineering can have a bad day. Engineering can have, like you said at the beginning, like sometimes we have outages. Sometimes we have bugs. Sometimes we have problems that we can wildly misscope something that we thought would take us a week, takes us six months. Um, and so there's, there are problems like that that can be top, but product management is almost a mindset as much as it is as a skill. And so if you want to get into that, it's great. I did it too. I spent two years in product management and I think the most important hallmark is to be curious and understand where your PMs are coming from. Here's what I've been excited for. What is the most basic universal skill that you think every engineer must know? It's curiosity. It's a willingness to learn. Um, it's the, uh, it's the, and that's, that's something that I think is absolutely basic. Now, as someone who runs software teams with hundreds of engineers, the next one I'm going to say, and the one that I'm sure a bunch of people already surprised didn't say it's communication because that's really what happens when you show up at a engineering shop and you realize we're not, this is not even exaggeration. We are literally all collaborating on the same giant asset, which is the Cloudflare code base. So we are, you might write code, Matt, that I am going to, in the very next day, rename your variable or rechange the format. And so if we are not, if we are not a hundred percent aligned, we will step on each other's toes and drive each other bonkers. And that's where friction comes from. And that's when shipping with quality and shipping with speed runs into trouble. But you asked, what is the fundamental thing? And so if you're just starting your career, if you are still in university, I do not expect that you have worked with big teams other than maybe just three or four people in a class project. And there, the rules were pretty well understood because you knew what you were trying to build. It was less of a discovery phase. So communication is something that develops over time, but curiosity has got to come from the beginning. This idea that I want to be able, at any time I should be able to ask, why does something happen? In an era of you, I don't get how you do this. So I Google Stack Overflow. Stack Overflow seems to have an answer with 700 upvotes and a big green check mark next to it. I'm going to cut and paste that code into my code and call it a day and get back to whatever it is I was trying to do without really ever understanding what did I just paste into my system? And so that I think is the difference between, and you can say that, isn't that, well, come on, that's beginner stuff. That's the difference between an amateur and a professional. Yes. But fully understanding, actually going one level deeper, why does that code work the way it is? Why was that the right answer? Why didn't I think of, find that answer myself? Why did I have to go to Stack Overflow? What was the gap in my model or understanding, or why couldn't I just get this from the docs? That curiosity and using it as a tool, I think is the most important skill. But let me ask you, Matt, what do you think is the most important skill? You've now done a tour of duty at Cloudflare. I would agree it's communication and not just with other people, but with yourself and other people in the future. Is writing something, writing documentation, making conversations, recording decisions that for other people to look at a year, a month or whatever from now. And I think, as you said, the only way to learn communication is really by doing. And before Cloudflare, my biggest exposure to working in a big team is I did FIRST Robotics in high school. And I had this transition from the very unstructured, chaotic environment of FIRST, where I was a big personality and I was making a lot of decisions to working as part of a greater team, where I couldn't have my hands in as many things. And my mentor and my manager last summer, both named Ashley, were amazing and taught me so, so much. And one of them said something to me that software is a team sport. And I would say that is the best piece of advice I can tell anybody is in order to be a truly good engineer and work as part of a team and build something that's greater than just yourself is you have to be a team player. You have to have empathy for your teammates. You have to have empathy for your user, for the other parts of the organization and for yourself and for yourself in the future. You have to care. Yeah, absolutely. I think the team sport analogy is dead right. If anything, it's like 11 people playing soccer where all of them have a foot on the ball at the same time. That's what the coordination problem is, is how do you get everyone to work together? Good. What, let me ask you another question, Matt. So what's the most fun part of your job? The most fun part of my job is, this is probably gonna be a controversial answer, but I actually kind of enjoy debugging. Well, I love debugging. That's not controversial at all. Who's disagreeing with us? We're right. That's the correct answer. Debugging is the correct answer. I feel like I always come out the other side of a tough debugging problem having learned something. So I tend to really enjoy it. And then I'd say it'd be like a tie between that and shipping, like seeing your product out there, people using it, people liking it, is a great feeling. And I really enjoyed that last summer when I launched Live Reload. That's awesome. That's great. I would say that when I was writing code and closer to a smaller team, I would have given those exact two answers, debugging and shipping are some of the best. My position now is several layers of abstraction removed. The most fun for me is talking to engineers who tell me what they've just built and the problems they've solved, including the hard stuff. So some of my favorite conversations are talking to a group of engineers who feel enough comfort with me, even though I'm not someone they see every day, but feel that Cloudflare is the kind of place where I can tell a smart, you know what, this took forever and it really shouldn't have taken forever. This should have gone faster. And here's what I think we should be working on to make this better. That to me is great. I'm very drawn to a sense of motion and progress. And it doesn't matter to me what the y -axis is. It doesn't matter to me how far deep in the hole we are and how bad something is, if it's going to be better tomorrow. So that's one of the things that I find most enjoyable at Cloudflare, is working with people who are so committed and so dedicated and so passionate about making things better. Whether that's awesome new features like the one you built with Wrangler, where a whole new interface shows up for a whole new technology platform, or whether it's fixing something that, you know, 10 years ago, the folks who, the giants who were all standing on top of the shoulders of the original people who built Cloudflare, who were just working at breakneck speed to make this thing just stay up, you know, had to take shortcuts. And now we have the bandwidth and the foresight, the vision that hindsight gives us to do it right. That's so gratifying and so much fun. Good. Any other last questions we should ask each other as we wrap up our session? I think we only have 10 seconds, so I think it might be time to sign off. 10 seconds left. Matt, this was fun. Thank you so much. Yeah, I enjoyed this. Great. And thanks everyone for watching. I appreciate it. We'll see you again on Mentorflare soon. Bye all.