I began with a career in academia. I was a mathematician, did a PhD in Maths. I started at Cambridge University. And then I did some postdocs, Cambridge and Southampton then back in Cambridge again. So I started out doing Stochastic network modeling, then branched out into Rotation Systems. I also did some kind of game series and sort of stuff, but after I've done three postdocs, I didn't quite make it to the next level of academic career and become, like so in the UK you would become a lecturer, but in the U. S. you will be sort of like Assistant Professor. I realized I was getting to that age where I should be moving on and I think I hadn't ever been because I moved my focus around a little bit I never ever really got fully established in an area on, but also it's quite hard. It's hard to make that transition from being a Post Doc to becoming a faculty staff member. So as I kind of saw this looming up at that time period of my career. So starting my last postdoc, I realized it might be my last postdoc. As that was coming up, I spent some time by diversifying my skills and understanding. I taught myself more about coding, programming. I looked into what it would take to become like a software engineer. Due to the technical work, I had previously worked for six months as an engineer. It's a company called Cambridge Consultants. There was some sort of theoretical work. We mainly programmed that Matt lab and sort of prototyping things. I kind of tried to learn a bit more about programming in general, become an expert. After I finished my work, I was looking for a position. I was excited about working machine learning on and there was a spinout company from the Cambridge University engineering departments that was a member during the postdoc. They were looking for people and I interviewed and I joined a start-up quite early on. It turns out that I actually suited startup life. In programming and then in later management quite well on, because it is a very small startup environment. If you take the initiative and you simply listen to what needs to be done and do it, then you become in charge of that thing. That allows you to expand your responsibilities and get experienced in things that you might not get to do in another company because they're much less restricted. It's very much a single swim kind of environment. It's a good way if you come from academia like I did maths. I had the mental ability to do a lot of things, but not sort of the technical knowledge on the job experience. So the start-up went well. We got acquired by Apple and now I'm managing people inside Siri. It was a huge change in my career trajectory and truely the big break was doing the startup. Before the startup, it would have been quite hard to get a similar position. A PhD is gonna be useful if it's extremely relevant. If I had a machine learning PhD might've been easy to get a machine learning job. But even here within this company, when we're interviewing people, a massive PhD is not taking quite the same way if he hasn't got industry experiences. But what I found was that a lot of the things you need to know to be a good software engineer, they're not that hard to pick up if you've got a very good technical mind and if you pick up things quickly. It does help to actually do some of the research beforehand. If you want to make that transition into industry, do some of the groundwork. These days, the environment, the job market is good for loads of internships and lots of companies. That's something that's really valuable to do. You can do internships with a professional body, you can get experience. It looks great on the CV and you'll probably get contacts. People will probably wanna hire you. I hire people, speaking with my experience, If I work with someone during an internship and I know they're good, then I'll hire that person.

My job has transitioned from one where I was I was coding and doing machine learning research and product development. So my team is responsible for machine learning components, a couple of other side projects within Siri. We do some research to try and develop the techniques, and then we privatize and deploy them. So my role of transition from a machine learning scientist and engineer, developing and coding, create production code to the one where I saw managing on doing that. So I was managing the projects and also I do line management as well and then over time into transition, where my teams got bigger, bigger, I'm actually doing more with the management responsibilities and now I don't really do any programming. But I do technical leadership still. So I'm involved in discussions where we'll talk about problems and possible solutions, possible algorithms, ways to approach things, ways to investigate things and my experience with the research in the past means they're going to have a reason to get intuitions about what things are gonna work or things are not gonna work, I guess. A guide for junior people, especially machine learning. You know what kind of things to try, generally tend to find that people get really excited about possible solutions on devices should always be. Have a look at the data and try and understand what's actually going on first. Maybe the problem's very easy. Or maybe the problem's very hard, but you must understand the area. So in my day to day, I spent a lot of time communicating with other people, having discussions about what work should be done in the future. Currently, we're in a planning phase. So a lot of interactions with other teams to try and come up with a road map for how to make Siri better. And how our component should evolve, how it should interact with other components. That's a big part of my responsibilities. Certainly networking with the By the rest of the time, I spend on assigning work for people and detailing planning solutions, having discussions, line management. You have to organize people. And as a line manager, one thing I take very seriously is like personal developments for my team. We have to find out where do they want to go. What can you do to help get them to carry in that direction? So it's a little case of kind of finding out what kind of things we want to work on, what experience I want to get and make sure you line things up currently. Make sure they're doing things that are interesting to keep them motivated. Motivation is more complicated than just what you're working on. So I live in San Francisco, but I work in the UK fairly frequently. So I do travel kind of a few times a year at least. So when I'm in the UK It's pretty much a 9 to 5 job. When I'm in the U. S. there's quite a long commute from San Francisco to Cupertino. I tend to work on the bus, so it's a bit more. I spend a bit longer working, but I don't tend to do it. It's not too crazy. Actually, it's quite reasonable. Things were a little bit crazy during the startup. Not too bad but I think we were quite lucky. The general policy that my managers had kept was we allow one day a week for working from home. Well, they're flexible when people want to do a couple of extra days because maybe they need to look after their child or something.

I use a lot of different languages. So we've got programs in Python, JavaScript, c++, Java, Kotlin, Spark, Big Data, stuff like that. In terms of frameworks or machine learning frameworks, I think I've mostly used TensorFlow. My team quite like Pytorch. I think that TensorFlow kinda hits the good spots of flexibility, usability, and extensibility and also there's a lot of support for it in the community. Models and algorithms? So I mean I don't think there's any I can think of that's unusual that we've been using which is outside of the usual computer science type. We need to study computer science. You learn classic algorithms. With models, generally, I feel like the right way to operate a machine learning problems. The first thing to do is sort of investigate. See what's going on there. Then you need to start out with a very simple, structured model. See, what if the simplest thing works. So the easiest way? Well, actually, the idea is to start the heuristic and the kind of cut your heuristic up the features and feed into the linear model that's like pretty simple. And then a nice thing to do after that is to kind of try out a mix of different approaches. You won't find that kind of a good bit of future engineering. I found that in a linear model with pulling all the future combinations can be expressive enough to kind of do just as well as the recently used a small neural network. And you really don't need like a big, deep learning network until you get on the next stage of really big data. It depends on the problem that you're looking at so obviously in some areas, Deep Learning's the industry standard. It gets huge benefits. Generally, with a new problem, a good way to start off with the simple thing first and build up your complication.