
This is software (AWS) generated transcription and it is not perfect.
So I got my start in coding when I was about nine years old. My mom dragged me to this programming class. She was a talented linguist and mathematician. She was in graduate school and had two kids. After having my sister and me, decided she needed to find us something to do. So she got interested in programming based on some friends of her's having a business in it? And so I really got kind of bitten by the bug. At that point, I got this Atari 800 XL home computer, which was state of the art at its time. Another formative experience for me was when I picked up this magazine called AI expert. This was in the late 1980s when we called AI as AI before it went out of fashion and then came back into fashion. And it described how neural networks, after being sort of a backwater for a few decades, were just coming back into their own and how they could solve problems people didn't realize they could solve. So I took this back home and hacked up on my Atari 800 XL. Really a rudimentary three-layer neural network, and I use Microsoft basic rather than Atari basic because it had better floating-point operations. So from there, throughout undergrad and graduate school, I was really excited about using neural networks to solve a variety of problems and to learn more about the braid. And interestingly, despite all the enthusiasm of the late eighties and early nineties, our data sets weren't enough, Our cube wasn't intense enough, and we actually had some mistaken concepts back then about overfitting and about the wisdom of doing deep learning, as it's been come to now. So it's a combination of, hardware and data and mistaken theoretical assumptions that set us back by a couple of decades. Having said, I did them a fun work in speech recognition for my PhD at Caltech. But then when I wrapped that up, I knew that I wanted to go into industry and with that sort of started the next chapter of my career. Going into the industry, I started in the midst of the dot com bust. So there were all of these Web companies in the nineties. There's a lot of enthusiasm for them and a lot of investment in them, and it was all going bust. And I joined one of the first profitable Internet companies, which is called Goto.com. That was a bit of a gamble for me, and the right kind of gamble can really pay off. In this particular case, the company was doing search advertising, and at the time, Google had just started to gain prominence. Google look free and had no ads. Alta Vista and Yahoo and other portals have lots of ads, and Goto was out there basically doing search advertising before Google. I got into it basically by knowing a few people at the company, recognizing that this is a profitable company and would probably be expanding into a lot of interesting areas in the future. So, sure enough, I started out doing machine learning applied to fraud systems and some statistical analysis, and this and that. A few months later, the company I realized they wanted to do R and D and experiment with a few different product lines and improve their search relevance. So I got the chance to build a team a few months out of getting my PhD and really experimented with some exciting areas that were adjacent to the search ads business. If I looked literally at my thesis topic, I could have gone to a big company that was plugging away speech recognition. There was a lot of solid work going on. Microsoft was investing heavily. IBM was investing heavily. But I want to admit that there was a little more dynamic where a company like Google could invest in competitive business lines, and we could start products and ex products and more so than to be a part of a large corporate research machine.
Office hours are normal business hours and as a vice president, a lot of your time is spent dealing with team challenges. So basically hiring, giving people feedback, helping people in their career, making sure that projects are on track, meeting with executives internally and meeting with outside customers. I spent a whole lot of time in meetings. One thing that people should think about as they're getting a computer science education. The tech industry is unique and that you could get very far in your career as more of a pure technologist or as a leader of a team. And so I've chosen in my career to lead these large organizations. That's how I became a vice president. But you should also know that there are technical fellows who are peers to vice presidents in terms of compensation and in terms of their impact and so on. And they get to spend more of their time writing code, designing architectures, helping set the technical direction. So that's a really important consideration for students. Travel is reasonably important. We have internal meetings and sort of visiting the different markets in which eBay a presence. So that means meeting with our business teams in Europe and Asia to understand their customers and make sure that what we're developing is relevant to them. I also am personally a big believer in university collaboration and going back to campuses. And so I spent time traveling back to my alma mater, to ETH Zurich in Switzerland on and to various schools where we have particular ties. The last part of your question regarding working from home. We just expect everyone to use their best judgment. I personally don't find that I can work from home too many days because there are too many meetings and too many faces to face interactions. But from time to time, if I have to catch up on email and produce some documents or whatever, I will occasionally work remotely.
Hiring people who are smart and get things done. I look for fundamental knowledge and that means I will expect someone in a coding job to understand the foundations of computer science. And that doesn't mean having instant recall of the particular name of an algorithm or knowing an exact library method or something like that. What I try to do is to talk to the candidate about software, about computers and make sure that they really kind of understand what they're doing at more than one level. It's easy to fall into the trap of building a feature really quickly, sort of cranking it out without regard to having the right abstractions and implementing something in an efficient manner. There was this old philosophy that may or may not be outdated, but the old philosophy was that a computer science student should go through a C Class and the list class. The C Class because it'll stretch your brain and make you understand pointers and really understand the system performance. A list class so that you really understand abstractions on the power of functional programming and macros and operate at that level. It doesn't mean that when you get to a company that you're using those languages on. Of course, computer science has advanced a lot. You could learn Rust and Haskell if you like. But whatever language you're programming, you should be conversant in these different levels of computing. And that's what I look for. I interviewed candidates via this sort of open-ended questioning where I'll ask questions and figure out where the limits are of their knowledge. At CalTech, we have this saying in the PhD candidates exam that if the questions got easier that you would be failing candidacy. So the idea is you're always being asked a question that's hard to answer. It's a good thing if that question feels abroad and if you're a little uncomfortable answering it, but you want to be sort of stretched and solving something in real-time.