Let me kind of work backward. I've been here for five years with Microsoft, started a division of data scientists that were outward-facing, on one hand, to work with enterprise customers and get them up to speed on what we call the digital transformation. At the same time, we're working closely with our product group and as you may know if you're working with software in the field, the cloud product we have. It's called Azure. It has quite a wide range of machine learning tools and features that come along with it. That was interesting. We did quite a few projects with customers as a group of PhDs that I ran, maybe about half a dozen of varying degrees of success. That group has now been reorganized and the data scientists who were in that team have been spread widely through Microsoft. Let me go back a little bit before Microsoft. Before Microsoft, I had worked with Toyota in a user experience role where we were looking at user data in the cabin. What it was like for the driver and what we could do to change their experience. Then, before that, I worked quite a few years with Intel research. Going back to some of the early work that they did on analyzing data from fabrication plants. In the midst of those major roles, I have worked with several startups, which is typical of what happens in the Bay Area in Tech. My original degree was out of Stanford School of Engineering. At the time, we had a department called Engineering-Economic Systems. It's now part of management, science, and engineering. I think that perhaps gives a good sense of the academic area I came out of. At the time when I did my degree, we were starting work on the research program in Bayesian that was coming up and spinning up in the AI field, and I was part of that community and today continue to consider myself part of that community. It has somewhat been eclipsed by a lot of the recent advances in machine learning, but I think there's still some good lessons from that area of study that should not be forgotten. So that's kind of in a nutshell what my career path has been. I want to underline a few things. I can't say I've come up through a data science curriculum, right? When I came out of school and as we developed the analytics that I have progressively engaged with, Data Science was coming to life. Data science saw its first origins in I think in about 2006 when Patil at LinkedIn coined the term. I think the other side of it is that I think the preparation that we had in different analysis methods in the management science and engineering program and maybe it's worth going into some of that in detail about excellent preparation for what we're doing today. So I guess that's kind of a nutshell there. I think maybe worth delving into a few of the experiences along the way.

I think it might be worth speaking broadly about Microsoft and picking up some of those items that I mentioned in the previous answer. As an applied research scientist, I think of it as a role that encompasses data science but as a broader reach and some broader aspects than what more people maybe think of today's conventional data science. And I think being on the cusp between the research community at the product teams is a very interesting place to be. And I think that is really what an applied scientist and a data scientist, as one of those kinds of applied scientists, find themselves in. Now, Microsoft has a very extensive research division of about 1000 people. It's perhaps if you put it alongside many university computer science programs, it's probably one of the top 10 in the country in terms of its productivity and the kind of work that's done there. The challenges of how do we make that relevant and bring it into use and see its effects on the day to day product is an important role that I see for an applied research scientist here at Microsoft and that again, there's a lot to say about that. It's quite an extensive discussion we have internally, and it's also an evolving discussion. I think for myself coming out of a research background originally going back to the work when I was part of the research at Intel research, gives me some good insights and some good road feel for what it takes to do that kind of work. So to go down to responsibilities and decisions. Well, I've done two things here. So in the previous position here at Microsoft, we realized that positions are pretty fluid. They turn over regularly. This kind of tech has quite a bit of evolution in the organization. This organization tends to move quickly and reform as necessary. The original works as a researcher, as a data science manager, I had a team of five PhDs. Our job was to go into a situation internally or with an external client, and we'd be the first person on the scene in terms of analysis. We'd sit down with them at a whiteboard and say, "What's your problem? What are the issues? What's relevant to stuff we could do with our toolset." And we thought that widely, we didn't just think of your conventional machine learning tools. We thought of it as using all the possible analytic toolset that we could apply probably to a problem either from our proprietary products set and actually even from open source. We'll be the people who would design the original approach to the problem. I think that's a really interesting area. Now I'm doing something similar, but I'm entirely in a product group. So I had the same ability to initiate work on a problem to define a problem, figure out how it can be approached if it's worth approaching. And, convert what maybe started off as w somewhat poorly defined set of issues has something that we can frame as a problem with a solution and figure out within the resources and data that we have, whether it is a feasible problem to solve. My hours are quite flexible. In fact, I have nobody who pays much attention or gives much regard as long as I am speaking to the right people at the right times in the meetings that I've agreed to come to either by telecommuting or by being here in person or by traveling to one of our offices, Redmond being very commonly the destination. Since that's what we call our mother ship, where most of the work goes on. I have pretty much responsibility to work where I can and when I can. And there's a responsibility about what's the joke about 90% of life is actually just being there is actually being present, and it turns out that if you think of what that freedom might entail, I'm often here close to eight in the morning and I'll work. I'll try to get home for dinners may be the way to say it, and often part of my weekends is involved with reading papers or reviewing papers or tidying up some e-mail or software that I've been working on. I say I'm fascinated by the work. I'm motivated strongly by it, and, it inter-leaves with my life. Both in the office. I have a good work-life balance in the office. I like the people I'm working with. We go out, we have fun. And also out of the office, where often bring a lot of it with me and flavors and colors. Some of my outside activities, such as the local meetups I go to in the field, and, actually, things like this.

I think Microsoft has one of the best R offerings is in the cloud. I work closely with a group of folks who came from a startup called Revolution Analytics that brought in our product here into Microsoft. A lot of my work right now is in Python. I think the main interesting point here is working in a product group, the tools we used in data science are actually somewhat distinct from the tool train that a software engineer uses. And one should not confuse the fact that a data scientist such as myself or the folks I've worked with and over for maybe quite proficient in the software, in getting things done, in terms of solving the problems in software being self-sufficient to build and run and generate experiments. But that's a different task than running a product, working with the repositories of the actual code that is in the product and the toolsets that are there. And, I'm very cognizant of what a software engineer does, but I would never want to present myself fork or claim to be that particular set of talents that a software engineer brings. I think there's a vice versa there also. So, yes, much of the work I do is writing software. It tends to be often taking a certain mathematical approach is and customizing them to the problem at hand may be different than in some other areas of data science, which are much more an application of existing software tools. But I think it is clear. And I think, it's really necessary for me to work side by side with the actual engineers who are using the toolchains and that test procedure and the deployment procedures that are part of the actual product development rollout.