Why I Joined Ponder: Hazem Elmeleegy

Aug 12, 2022 7 min read

Articles
Why I Joined Ponder: Hazem Elmeleegy image

At Ponder, we celebrate the diverse background and perspectives that each of our team members brings, so we started a “Why I Joined Ponder” series to share and learn from their experiences. Our first interview was with our Founding Architect, Hazem Elmeleegy. This interview took place on Monday, August 8th, 2022, with Peter Olson (Chief of Staff) as the interviewer. What follows are highlights from the interview. You can listen to the full interview here, or read the full transcript here.

Why Hazem Joined Ponder, in a Nutshell:

Hazem grew up in Alexandria, Egypt, in an engineering family. His father had a hunch that computers were going to be the next big thing, so purchased a PC for Hazem and his brother when they were little, which was unusual at the time. Hazem’s older brother went on to study computer science at Alexandria University, and Hazem followed suit.

After finishing undergrad, Hazem earned his PhD in computer science from Purdue University in Lafayette, Indiana, as part of a database lab, and then went to AT&T Labs for two years, Turn for six years, and Google for four years, before coming to Ponder as our Founding Architect in 2022.

So why did Hazem join Ponder? In his words (lightly edited for brevity + clarity):

I’ve always been thinking about being early in something. But knowing that making such a move comes with a huge amount of risk, you have to be very careful in choosing. You want to make sure that the problem being addressed is a real one, that it’s serving a really large number of people, and it’s not a repetition of something that’s already out there. And then you need to feel comfortable and confident and happy with the team that’s working on it, and you want to think that this is the right team to take this solution to the problem to completion, or at least to the next level. And both those things I found very clearly in Ponder.

Most of my work before that was in C++ / Java, in systems serving those kind of developers. So initially, when I heard about Ponder, I thought that this was a foreign space to me, but digging a little bit deeper, it felt like — no, no, no, no, this is super relevant. And not just that: It turned out that there is this huge community of data scientists that is growing at a much, much faster pace than the other programmers in other languages. And they are not as well served as, for example, people who are using databases. So that gives you an opportunity. And you know that saying that software is eating the world? I think it’s very true, but for this to come to its full potential, people who are completely outside of the computer science world, who are specialists and experts in completely other areas, need to get closer to the computer science software world. And for that to happen easily, they need an easy programming language to start working with. And Pandas and Python seem to be doing a great job in that already, enlisting more and more people every day. So the only remaining thing is making sure that those tools that have already done a great job in attracting more people are up to the level of other systems like databases that have been around, maybe for longer — They are both at the same level in terms of reliability, scalability, usability, all of that. And Ponder seems to take this as its mission, which is a world-changing mission.

And the team is world-class, clearly. For any outsider, I think they can recognize that. But to me I was a little bit more than just an outsider. It also happened that I have this direct relationship and direct interactions with the founders long before they started Ponder. So I had this advantage of knowing how good of a team that is. So that was another big, big, big attraction to me. There was this sense of: If not now, then when? Companies are more like humans, like little kids. At the very beginning, a year can make a huge difference. If you have a one-year-old — from one year old to two years old, it’s a completely different person. So if you didn’t experience that period, it’s gone forever. Whereas as they grow older, for example, from 39 to 40, you can easily afford to not see someone for three years in a row, and then see them again. You’ll still find the same person, and you can catch up. But for little kids, and for very little companies, it’s important to be there while they are growing, at least it’s something to be missed. So yeah, this is how I convinced myself to make the jump.

And here’s Hazem’s answer to the question: “How would you describe Ponder’s culture?”

If I’d summarize it in two words, I’d say “infectious energy.” I feel everyone is, besides being really good at what they’re doing — there’s this strong feeling that each one is trying to come up with one way or even 10 ways to push the company forward and to push their teammates forward. You can easily see this on Slack, in meetings, in group meetings, one-on-one meetings. Each one is just trying to find: How can I help the company? How can I help my coworker? And I think this type of culture, if we manage to keep it and grow it, continuing to hire people with the same caliber, like what we have today, these are the ingredients for success, in my mind. So yeah, it’s just adding to my enthusiasm about the company.

———————————————

For those who want to listen to or read the full interview, see below for our Spotify podcast, as well as a lightly edited transcript:

Structure of the Full Interview:

Part 1: Growing up learning computer science in Alexandria, Egypt, and studying at the University of Alexandria

Peter: Hazem, we’re so excited to have you here for our first “Why I Joined Ponder” interview. We’re going to talk about a bunch of things today, and we’re going to culminate in this question of: “Why did you join Ponder?” But the first thing we want to tackle is a little bit about your childhood and your interest in computer science. So my first questions are: Where did you grow up? What were you like as a child? Did you show an interest in computer science from a young age?

Hazem: Let me try to give a quick flavor for what things were like back in the day. I grew up in Alexandria, Egypt, in a small family — I had only one older brother. And both my parents were engineers. My mom was a chemical engineer, my father was a civil engineer, and most of my extended family were in engineering. And the nice thing is that — I guess my father had this foresight from a very early time that maybe computer science is going to be a big thing going into the future, so he wanted to get us exposure to computer science from early on. So he got us a personal computer, a PC, which was sort of rare at the time. If I am to date myself — This was when I was in elementary school, which was probably the late eighties. My brother was in middle school back then, but since we got introduced to that and we had it at home we had to spend a lot of time with it, we started to learn things like Microsoft DOS and things like GW Basic, like basic programming skills and gaming, of course. And then the Internet came along, and a whole bunch of more computer-related activities started to surface in our schedules. This was a very good way to set the stage for knowing that we have this inclination for engineering and computer science. And when I say “we,” by the way — that’s because my brother chose the same path, and I was behind him in some sense.

Peter: It sounds like your dad had this vision of your becoming computer scientists. But it also sounds like you were okay with this vision. Did you ever not want this — Like your Dad wanted it, but you didn’t?

Hazem: I’ll tell you — The decision point was at the time when I was finishing high school and choosing which college to join, and which major to be part of, and so on. And as I said, most of my family were engineers. At the same time they were hoping so much that one of us would be a doctor, and my brother had already chosen engineering and then got into computer engineering. So I was the only remaining hope, so I gave it a very serious consideration, the different branches of the medical space. But then I ended up feeling that I am more into things which will give you an intellectually challenging kind of problem that you need to solve — Much more than those areas where you need to have a high capacity of memorization. Like being able to put in as much information as possible, and making it available as quickly as possible when you need it. I felt that my strength would be more in the problem-solving type, and knowing more about what computer science is really about, the algorithms and data structures. It felt like this is a much more natural fit for me. So then at the very last minute, I made the decision: Okay, let’s go engineering. And then from there I continued to computer engineering.

Peter: So when you talk about making this decision, you’re talking about at the end of high school, making the choice, and then you stuck with it?

Hazem: Yeah, because this is how it used to work back then. You finish your high school, and then there is a match program — A nationwide match program where you put your preferences. So if I had put like, whatever the preference, most likely I would have been able to get it. So I had to decide: Do I want to put this as my top preference, or that other thing? And then, and this was the decision that made me where I am right now.

Peter: It sounds like by the time you finished high school, you already knew a fair amount about computers. I can’t remember if you specifically mentioned knowing data structures but you knew enough of the beauty of computer theory — Did that mostly just happen at home, or did you have course work at school about computers at all?

Hazem: The introduction to programming, if you will, that happened at home. And then, since my brother was three years ahead of me in in school, by the time I was making that decision he was already in his first or second year in computer science. So I could see the type of things he was learning in the CS major. So this is where I got some initial understanding of what it’s all about at that time.

Peter: So let’s talk about your time as an undergrad studying computer science.

Hazem: So I think we were lucky, in a sense. I mentioned I was in Alexandria Egypt, and the biggest two universities in Egypt are Cairo University and Alexandria University. With Cairo being in the capital, it’s much bigger. But it just happened that the first department focusing on computer science / computer engineering happened to be in Alexandria. And again, some very early professors had that vision, perhaps since the late sixties, where it started as a sub-branch or a sub-speciality of electrical engineering. And then soon after, in the early seventies it had its own department. And it’s a very focused group, also. Very few people. Most of the time it was like 20 to 30 students. By my time it was just about 60 students, so not that big of a department, and usually the top of the class in the engineering admittance, altogether, would end up being in computer science. So in that sense it was very competitive. And the professors would push us to the limits, trying to get as much out of us as possible. And also there was this nice research culture, if you will. Not necessarily during undergrad, but for all the ones who graduate — They’ll become TAs and usually then get a masters from the same university, and the majority of them would pursue a postgrad, like a PhD, abroad, usually in the US, in some of the really good US schools. So even while in undergrad, it gives you a vision, or a path to follow, not only until graduation, but maybe until getting a PhD — Like this is something to keep looking forward to. So I was kind of in this group of people who were thinking that, yeah, maybe undergrad will not be the last stop, and we can take it further to that next step, similar to those other brilliant senior students that we’ve been interacting with.

Peter: You said there were 60 students, roughly, studying computer science at that time. Is it a four-year program? So is that roughly 15 per year?

Hazem: It’s a four-year program after what used to be called preparatory engineering — this is across all engineering disciplines. There’s no specialization in the first year. And then there is a four-year program. In this, people could go to electrical, mechanical or other engineering majors.

Peter: So did that mean that you were taking a lot of your classes with the same group of people? Did you like that part of it, having this cohort? Were you competitive with certain people?

Hazem: Yeah, I think we all enjoyed it in that sense — being such a small group, and always working together for four years in a row. Much of the education is project-based where you’ll form teams and work together. This is one of the nicest things about college life in general, and for computer science it was also really nice. Graduation projects are different in the sense that you pick your own project. You set your goal, you set your scope, and different projects can look completely different. But still they can all get presented in a nice way at the end. As opposed to class projects, where everyone is working on the same thing. So we have this mix, and I think overall it was very enjoyable. I’d love to go back if I had the choice.

Peter: Have you stayed in touch with any of your classmates?

Hazem: Yeah, absolutely. And the good thing, at least from my selfish viewpoint, is that many of them did make a similar move to the US. And interestingly, in the US if you are in the computer space, or in the software space, many people will end up in the Bay Area, too, so it’s also physically close by. So yeah, we’re maintaining a lot of connections up to now.

Peter: So are we talking about — of the 15 your year, are a couple of them in the Bay Area?

Hazem: Maybe of those 60 people, at least seven or eight at some point in time worked at Google. But people keep moving around. People started at different places in the US, for example, like joining different universities — I went to Purdue in Indiana; a friend went to Stanford, but did an MBA from the GSB; another one went to USCB; two of us went to Purdue. It’s across the board.

Part 2: Getting a PhD at Purdue University in Lafayette, Indiana

Peter: So let’s start talking about your PhD. Did you know that you wanted to study computer science abroad? Did you consider studying in Egypt? How did wind up at Purdue?

Hazem: So, as I said, there were so many precedents before me, including my brother too. So we have this, not just in college, but also in the family. My brother went to Rice University for his PhD. And even though we had this focus in the University on research, at the PhD level it was not as mature as as abroad. So they’ll try to get very high-quality master degrees with a research focus and all, but it would be a one-year, one-year-and-a-half-type thing, plus the coursework. PhDs, typically you need to travel for them. So this was not a very difficult decision to make. This was more about execution, like getting all the GRE tests, getting all the stuff, and doing the applications, and then talking to different professors in different places until I found a good match.

And at Purdue, there was a pretty sizable database lab. They had a history of working on different types of data management problems, and they were growing the lab even more and more, with at least three / four professors focusing on different aspects of the problem — Like from a privacy angle, maybe a systems angle, semantics. So that seemed pretty appealing to me. When I first joined I started trying to attend and listen and talk to as many people, and attend as many talks as possible to get myself into that new world. I was lucky also to have my advisor from the very beginning. I didn’t search for an advisor for a year or two, so I had the scope somewhat defined, I just needed to have my own personal scope for my own dissertation.

It took, maybe, let’s say a year and a half or so before it started to become clear: This is where I’ll be spending the rest of my PhD. My research wasn’t the systems aspect of building a database like the execution engines, optimizer optimizers, and so on, but it was more on the data integration aspect of it — like, given two databases that seem to be talking about a similar topic, more or less, how do we build correspondences between them? Maybe bringing them together into a single database, or maybe even link a federated system on top of them — having unified access to all of them. Where we’ll be talking one language, and then that would be translated down to each one of them, or maybe just being able to do data exchange across them, like allowing the data to flow seamlessly in one direction or the other. But then, how do you translate this data as it moves from here to there? So it was laid out in one way for the sake of the first database. And then how should we reorganize it to be stored in the other database? This problem has been there for decades, maybe, but the good thing about it is that it’s super challenging and no one can say that this is a solved problem — There would always be something to solve. And it was more at the intersection of the data world, and maybe a little bit of AI, because you’re trying to come up with those decisions that you want to be as trustworthy and as reliable as possible, but it’s still inexact. It’s not like processing where you send your SQL query and you’re expecting the exact same result each time you send the same query. So there is some room for error, which you want to lower. I like that. It had a bunch of challenges.

I tried to bring a new perspective there. I published a few papers, and while getting there I happened to work on a few other enabling areas. So at some point I was working with data streaming where I ended up publishing a paper on how you compress data streams online as they are being sent from one side to the other. I worked a little bit on privacy preservation type in the context of data integration, which was also cool. And one thing I loved about graduate school in the US, in general, were opportunities to go out and do internships in completely different environments to get out of your university, with all the familiar faces, and get embedded in a completely different place, different weather, which was very important, and with a bunch of other very smart people who are going to enrich your experience overall from a different angle. So I had the chance to work at Google Research back then during my PhD. Also at IBM T. J. Watson Research Center, and even outside of the US. I spent one summer in France, in INRIA, which is their national research lab. It was a very rich experience overall, my grad school time.

Peter: So there are a number of things I want to ask about. One of those is — Purdue is in Indiana, correct? — So what was it like going from living in Alexandria for your whole life up till then, to being in Indiana and going to Purdue, mixing with your classmates, many of whom are from the US, and probably from all over the world. What was that experience like?

Hazem: I loved meeting people from all over the world. I really loved it. That goes way beyond the formal education, and computer science, and so on. The US is one of the few places in the world where when you go to the US, it’s not just about visiting one country, but in fact you’re learning about almost everywhere in the world, and usually it’s some of the smartest people from those places in the world. So you get really nice opinions and viewpoints. That I did like a lot. There’s also that aspect of being in a city. Purdue was in West Lafayette, Indiana. It’s a college town, where the university campus was the main thing, and everything else is servicing that entity, more or less. So that was different. But I also liked that it was peaceful in that sense, no traffic jams. Parking is usually easy, unless you’re late for a class, and you want to park as close as possible to the computer science building. Then you’ll be stressed out, but usually it’s easy. Life is very easy there, where you can easily focus on what you’re doing, building friendships, and so on. But the hustle of a big city is not really there, and whenever we longed for it, and wanted to get involved in something more busy, we’d go to Chicago for a weekend or so. This was our outlet for that.

Peter: Yeah, I’m sure there were Egyptian restaurants in Chicago. Did they have that where you were in Indiana. Did you feel homesick? I visited Cairo before, for just a few days, and stayed with a family there, and it’s just such a different set of smells, and the feel of the air is different and the color palette is so different. I’ve never been to Alexandria, but the Cairo color palette was very different from anything I experienced before. We ate gebna, all sorts of wonderful foods. Did you find yourself homesick?

Hazem: Not really. Not overwhelmingly so, because, again, there was quite a sizable number of students from Egypt and Alexandria, and even a professor who used to teach in Alexandria and was teaching as part of this database lab at Purdue. So there was a sense of community there, in addition to getting exposed to people from all over the world. There was an inner circle that I could claim that I belonged to. Even food and restaurants — there was nothing that was specifically Egyptian, but there were restaurants from the region, like Middle Eastern, Mediterranean, which was not so different from what I’m used to. Plus, I found it a very good opportunity to try and experiment with new cuisines, and I didn’t find a lot of trouble. Because most of my eating was outside — I’m not that big on cooking for myself — I just had to acclimate, I guess, and I think I was successful in that, thankfully. Plus I was going back home at least once a year, very regularly. That also helped.

Peter: It sounds like when you went to Purdue, you went there knowing you wanted to do database work, and then, finding a PhD topic was a question of: Within the realm of databases, what are you going to focus on? Is that correct? Or when you got there, you weren’t that certain, and there were other possible areas?

Hazem: No, so from the beginning I was oriented towards the database space. During this journey, I wasn’t ever thinking about other areas. Perhaps, going to the conferences, and so on, of the database community, it felt like a very strong community, even within the computer science space overall. Maybe I got indoctrinated somehow, by going to so many conferences. You feel it’s a good bunch of people to be a part of. For example, Larry and Sergey who founded Google, they came from that community. It’s easy to have an impact while being part of this. So this is why I didn’t feel any urge to try something else. Plus, it’s at the center of so many things, like if you want to marry that to a little bit of privacy and security, that’s fine; if you want to marry it to a little bit of AI and machine learning, that’s fine; if you want to marry it with a little bit of networking and systems. It’s central enough not to leave behind.

Peter: So you had already done some database work as an undergrad, it sounds like. You had some exposure.

Hazem: Yeah, not to the level of publishing something, but maybe graduation projects where we tried to do something that has a little bit of novelty and a little bit of exploring new technologies. But we were not that experienced in trying to package this in a research paper and trying to write it in the right language that will get it accepted in a top journal. This was not the focus at that point, but that energy or that willingness to try to always bring something new has been there. And it felt like pursuing a PhD, or this is where those things can be nurtured, and then we can take it to the next level.

Peter: How helpful was the coursework portion of your PhD? Your undergraduate, it sounds like, was pretty extensive. Was there a lot of stuff that for you wasn’t very new, or did it feel like every single course you took changed the way you thought about that subject?

Hazem: No, I think this would be a strong statement to make. So I’m sure that there were overlaps, there were things that I already knew before, which was beneficial to some extent, where I didn’t need to spend too much time on those things because I had a reasonable background about them. But then there were also other areas that were pretty new to me. Some were maybe not as new, but maybe the practical aspect of that course was, not just learning concepts on the surface, but having to implement some of these things. Operating systems, for example, like going in and building actual functionality. So some of these things were really useful for sure.

Part 3: Working in industry at AT&T Labs, Turn, and Google

Peter: Let’s talk about your life post PhD. My understanding is that after your PhD, you went to work for AT&T. How did that come about? How did you decide? You had a lot of offers, I’m sure. How do you decide that you wanted to do research there? When did you decide that you wanted to do research housed in industry as opposed to academia? How did that unfold?

Hazem: This was the case for me, and I imagine it’s the case for other people who are coming out of grad school. Usually, the two big choices are industry versus academia. But there is another subtle choice here — within industry, it’s either more towards the pure development type thing versus the research roles, which can be very well defined, like in a research lab. You’ll be there as a research scientist. For me, I thought: I like research, I love being one of those few people in the world who’s coming up with the next thing. It felt special in some way. And this is exactly what research gives you. But academia versus industry — I felt that I’ve spent enough time in academia, in general, in grad school plus undergrad, and it’s time to get a sense of how the industry looks, so research labs felt like a very nice middle ground, where you’re embedded in a big industrial place, but at the same time you’re doing research and AT&T Labs had this long history of bringing all sorts of inventions to the world, and it had some of the top research-caliber people, including in the database space. So it felt like a nice first step, at least for me coming out of grad school. So there I spent a couple of years.

Peter: What kind of questions were you trying to tackle there?

Hazem: It was a mix of getting a better understanding of what problems the telecom industry in general — because AT&T is one of the biggest — has to solve, from a data perspective, and at the same time there were some pure research activities, things where it’s not immediately clear how they tie into AT&T’s everyday business, but researchers there can work on, and eventually they may have a good application for the business. So I was at the intersection of those two worlds within AT&T. I was working with some product teams who would have immediate problems that have to do with their price plans, or maybe subscriber retention — How do we increase the number of subscribers? How to give the best customer support possible to make sure that they are retained and they don’t move to other providers. And at the same time I was also working on some very data-research-oriented things with publications, and all of that. It was my first exposure as a full-time employee to a company of this scale. Learning how to set a goal — there is a deliverable that needs to be delivered within some time bound, and you have to navigate a ton of challenges and conflicts. Maybe different opinions from different stakeholders. Conflicting data sources, like it’s not very clear what is the single source of truth — for a given piece of information, there are multiple sources, and then you have to reconcile these all at the end with the goal of delivering something that’s useful to some very well identified beneficiary within a given time frame. Having to deal with this in such an environment was a great learning experience too.

Peter: I worked at the Federal Reserve Bank of New York after undergrad, because I thought I wanted to do an econ PhD. That’s kind of the route I was on. It sounds a little bit like the setup was similar to what economists at the Fed have, which is: There’s a bucket of what they call policy work, where the bank has questions, specific questions, it wants to answer for the benefit of the bank and the country, and then they have a big bucket of research where they’re allowed to pick their own questions, tackle the things they want to tackle, publish papers. Is that the right way to think about it, like you had a bucket of work where teams said: These are things that we would like you to work on, and then you have a big chunk of time to spend doing the research you had been pursuing in your PhD?

Hazem: Yes, it sounds like there are a lot of parallels.

Peter: So you’re at AT&T, and then after a few years, you went to Turn, and you were there for six years. How did that transition happen? What did you do at Turn? What made you decide to join Turn, and then stay for so long?

Hazem: So, as I said, there were a lot of interesting things that were happening at AT&T. But at some point, it felt to me that most of the action in the IT world seemed to be happening on the other coast, California. And it felt like there, you can work on something, and then, if you’re not so happy, it would be easy, relatively speaking, to find another good place to work on another interesting problem. And so I started building this willingness to be part of that world on the West Coast, and in the Bay Area specifically. And this seemed like a very good opportunity that came to me. At that point, Turn seemed like a very promising startup in the advertising business. Computational advertising, and so on, was pretty hot at that time. I didn’t know much about it. I got exposed to it slightly at AT&T. One of my projects had to do with ad campaigns that AT&T itself would build. So I got this little exposure, but it felt like this company is dedicated and very focused on that area which seems to be pretty demanding, intellectually speaking. You’re building those online auctions whenever any human being on earth is visiting any page on the Internet. For every one of these, you’ll have an online auction. On the fly, you’ll build it.

You’ll have maybe 20 / 30 different companies involved in that auction. They all have to come up with a decision in a very small split of a second, and then you keep doing that at an unprecedented rate. So for this to keep working seamlessly and flawlessly, there is a lot of infrastructure that has to be built. There are a lot of algorithms that need to be built. And there is huge room for improvement, and improvement here can very easily be measured. It can very quickly impact the profitability and revenues of your company, as well as your customers, who are the advertisers. So you can quickly see the impact of what you do there. This was a big attraction to me, and it felt like it was not that late-stage when I joined. When I was interviewing with them, it was perhaps 120 or so people. Then by the time I joined it was like 140 / 160. We were hiring fast. So yeah, I was happy to make that transition. And the good thing is that — with the help of a lot of brilliant people over there, some of them are coming from PhD backgrounds — so even though it was not that big of a startup, we had a lot of research activity, and we published a lot of papers because simply we were facing problems that at least no one talked about in the public sphere. Maybe others have faced and come up with solutions, but maybe did not talk as much about them, but we felt that there are things that are worth sharing with the bigger audience. So it was fulfilling from that perspective too — not just pure building, and nice business problems to have. But there were also nice research problems to have as well.

Peter: Your title at AT&T Labs was Senior Member of Technical Staff, and then I think you were an architect at Turn — a Senior Architect. And then in a moment we’ll talk about when you went to Google and worked on data infrastructure. How would you say the focus between doing applied problems versus more researchy things has shifted between those places. It sounds like at AT&T you had quite a bit of space to do the research you wanted to do. At Turn, it sounds like you were able to do some researchy things, but as a startup, probably there’s pressure to to build.

Hazem: So the difference is — At Turn, if you are working on something that is interesting research-wise for other researchers outside of Turn, then yes, you’ll have some bandwidth to package this in a research format, like in a paper format and go and publish it and present it, but it’s not like trying to think out of the box about something that may or may not be relevant to the lines of business of the company. It also has to be high priority in a sense — something that will likely bring a quick return either in the efficiency of something, or you lower the cost of something, and you’ll improve whatever metrics the advertisers care about. Yes, then, this is it. We had an open culture where it was okay to talk about things that we build, and when we feel that they are novel enough we’ll give it a shot to send to a conference, and many times they were accepted.

Peter: So it sounds like at Turn, the company was totally okay — maybe even excited about — the idea that as you do work that’s relevant to Turn, to the business priorities, you could share that, publicize it, publish it, get it out there in the conversation, which is a little different from AT&T where in the chunk of time you had to do more researchy stuff, it didn’t necessarily have to be as directly tied to short-term AT&T interests. So you eventually, after 6 years, chose to go to Google and you were there for four years, is that right? So what was that transition like? And then what was it like to work at Google?

Hazem: Yeah. So Turn eventually got acquired by another company, which itself was the digital arm or at least the advertising arm of another telco. This time it was outside of the US. It was Singapore telecom, Singtel, so after that acquisition, I think I spent a year or so, and then it felt like maybe now it’s a good time to try some big tech, and I already had my experience with Google before, like during my internship, I spent 6 months with them, so I was fascinated by their internal culture, the quality of their engineering work, and the emphasis on friendliness — what they call “googliness” across teammates. And my memories were very positive about what Google is and what it is to be part of Google. But I never experienced it in a more traditional way, as a full-time employee, and after the experience I’ve already accumulated, so it felt like maybe now is a good time to be part of this. So I joined, in general, the area of infrastructure and analysis. And Google, being as big as it is, there are many teams working on different aspects of their infrastructure and analysis, ranging from traditional SQL processing, query processing, and execution and optimization, all of that. And then you also have the online transactional processing with database transaction management and things like that. You also have the OLAP-style workloads, and there are systems that are built on purpose for these use cases. You have other teams that are built around maintaining the logs — there are a very large number of logging systems at Google, and they’re very sophisticated, and there is huge infrastructure that is built only for maintaining and curating these logs on a going-forward basis. And of course you have teams that are building infrastructure for developers, building their own pipelines in different languages, like C++, Python, Java, and so on, for different use cases, be it machine learning with ETL. Interestingly, there are teams that are dedicated to the internal use cases of Google and others that are more on the cloud side. Sometimes there is what seems to be a little bit of duplication, but they just want to make sure that there are things that are purely focusing on the outside world in the Google Cloud, and some teams that are purely focused on all the internal businesses and internal Google products.

For myself, I was focusing on the query engine, the SQL-based system. There was a system called F1, and I was fortunate to touch on different components of the system going from the query optimizer, the execution engine, the implementation of the different SQL operators. Also things like some cost-cutting, the scheduler of the system, remote UDFs, remote table functions, and more recently I focused on this interface across teams. So between the F1 execution engine, and also the pipelining systems — trying to make the interfaces between them, for the data to flow between them as efficiently and as reliably as possible. So I focused a little bit on this area. And this has been mostly my experience with Google, which was nothing less than than amazing. Getting this firsthand experience with how things have been built over the years, how they’re still very tightly coupled — the philosophy that Google has about always putting the quality of engineering first. They kind of have the luxury of not shipping anything until enough people with very high credibility are comfortable with this. There was a lot to learn during that journey, and I’m really fortunate to have been there.

Peter: I have two questions. The first one is: How did prioritization happen? Was this the kind of thing where your team looked at the systems, and you’d say: “We think we could improve on this and this and this,” and you set your own roadmap, and you set your timelines, and you do it? Or was it more driven by external partners, and they say: “Hey, this isn’t working very well. Can you fix this?” What was the balance between proactive roadmapping — you have a vision and you build it out — versus, no, its being driven by other stakeholders.

Hazem: Yeah, great question. I would say it was a mix of both. And even if you start from somewhere, you’ll try to bring the other side to it, like if it’s starting from internal folks who are just by the mere fact that they are very familiar and intimate with their own systems, and they identify some inefficiency, and maybe an opportunity to make things about better in a certain aspect, you’d still want to couple that with a confirmation and reassurance from the other stakeholders — like “This is what we’re thinking, making this investment. Will this help you?” And then once you get more and more buy-in, then you can start incrementally adding more resources, and the more promise you see coming back, the more resources you deploy, and so on. And sometimes it’s the other way around. Maybe you haven’t been, as the owner of a system or of component, paying as much attention to this potential deficiency and then your customers start complaining about certain things, like — “We would expect this to be better in this way, maybe we tried something else, and this is the experience we had, and so we hope we have a similar experience here too.” And then you start prioritizing that. So I’ve seen both scenarios play.

Peter: And then my second question is: You had a rare experience where you were at Google in 2007 / 2008, and then you were back again 10 years later, and I would say, the number of people who had a slice of Google life, and then came back into it ten years later, and so could compare — that’s not a huge group of people. How had things changed? How had things not changed? Were you surprised by the Google you encountered in 2018?

Hazem: I myself thought about this a number of times, and I think there are things that may not have changed a lot. Like, as I said, always prioritizing quality in engineering work. That remains. But I feel that the new Google, compared to — I was there in 2008 — it’s a much, much, much bigger entity now, where it’s much harder to get a sense of what’s going on in other parts of the company, what is the overall mission for the company as a whole that everybody needs to be driving towards. In 2008, even though I was just an intern, for some reason I had a stronger sense of this whole-company direction. So first of all, I happened to be, back then, in the same building where the founders were. I was on one floor, and they were just a few stairs away from me. I was attending every single TGIF, which happened weekly — three weeks on and then one week off. I would attend it live and I would see the founders, and all the C-level execs answering random questions from anyone, where a question crosses their mind and they just fire it off. And then they’ll get a a very deep and honest answer, and discussions. So I was amazed by being such an intruder, in my mind — I’m just an intern going there for a few months, and I have access to all this information. So now you can still get access to a lot of information at Google, but it’s just too much. So what I’m seeing is that people usually limit themselves to the project they are working on. They are not that interested in the bigger scheme of things. Because it’s really too big, trying to keep track of all of that, you lose all your time, basically, and you’ll not succeed. So maybe that changed the perception in a sense. But I think this is just how life is. As things grow, it exceeds the capabilities of our little human minds. But I feel that some fun went away also with this, going to more maturity and more growth.

Part 4: Why I Joined Ponder, and advice for computer scientists earlier in their careers

Peter: Now we’re getting to the title of this series, which is: “Why I Joined Ponder?” So I’m going to ask it without any adornment: Why did you join Ponder?

Hazem: I’ve made a few transitions, right. We’ve already gone through that. This transition is special in a number of ways. For one, during all those stops in my career, I’ve always been thinking about being early in something. Something you want to join in a very early stage, or even start if you have the opportunity to do so. But knowing that making such a move comes with a huge amount of risk, compared to the other type of places that we talked about. Going along with something that is just starting, by default, it comes with that. So you have to be very careful in choosing. If you are to make such a move, you have to have enough reasons to believe that this is the place you want to join at a very early stage. So you want to make sure that the problem being addressed is a real one. It’s serving a really large number of people. It’s not like a repetition of something that’s already out there. It’s unique in that sense. And then you need to feel comfortable and confident and happy with the team that’s working on it, and you want to think that this is the right team to take this solution to the problem to completion, or at least to the next level. And both those things I found very clearly in Ponder.

For the problem, to be honest, I wasn’t that much into the data science world, with all the Python. Most of my work before that was in C++ / Java type things in systems serving those kind of developers. So initially, when I heard about Ponder, I thought that this was a foreign space to me, but digging a little bit deeper, it felt like — no, no, no, no, this is super relevant. And not just that: It turned out that there is this huge community of data scientists that is growing at a much, much faster pace than the other programmers in other languages. And they are not as well served as, for example, people who are using databases. The amount of brain cycles that have been invested in building awesome database management systems over the past few decades — I don’t think it’s as comparable to the amount of brain cycles and effort, and work that has gone to serve this other group of people who are doing something that is super important as well. So that gives you an opportunity. And you know that saying that software is eating the world? I think it’s very true and we’re seeing it happen as time goes, but for this to really come to its full potential, what this means is that people who are completely outside of the computer science world, who are specialists and experts in completely other areas — be it medicine, be it biology, be it other parts of science, chemistry, physics, or business or whatnot. They need to get closer to the computer science software world, they need to build their own programs. And for that to happen easily, they need an easy programming language to start working with, an easy API to express their needs. And Pandas and Python seem to be doing a great job in that already, enlisting more and more people every day. So the only remaining thing is making sure that those tools that have already done a great job in attracting more people to make sure that the are up to the level where other systems like databases and other things that have been around, maybe for longer — They are both at the same level in terms of reliability, scalability, usability, all of that. And Ponder seems to take this as its mission, which is a world-changing mission.

And the team is world-class, clearly. For any outsider, I think they can recognize that. But to me I was a little bit more than just an outsider. It also happened that I have this direct relationship and direct interactions with the founders long before they started Ponder. So I had this advantage, if you will, knowing how good of a team that is. So that was another big, big, big attraction to me. And so yes, there was this sense of: If not now, then when? And the timing for Ponder also — Like I always said, companies are more like humans, like little kids. At the very beginning, a year can make a huge difference. If you have a one-year-old — from one year old to two years old, it’s a completely different person. So if you didn’t experience that period, it’s gone forever. Whereas as they grow older, for example, from 39 to 40, you can easily afford to not see someone for three years in a row, and then see them again. You’ll still find the same person, and you can catch up. But for little kids, and for very little companies, it’s important to be there while they are growing, at least it’s something to be missed. So yeah, this is how I convinced myself to make the jump.

Peter: That’s great, that’s great. Did you know all three of the founders?

Hazem: No, I knew Doris and Aditya, and we even worked together. We published together, and so on. But then I got introduced to Devin, and this only improved my perception a lot. It gave me the same type of impression which I already had.

Peter: I have two more questions, and then we’ll pull to a close. The first one is about Ponder culture. What are your observations about the culture of the team? And for context, for those who are reading or listening to this, at Ponder we’re in this 15-20-person range and pretty much everybody is an engineer, except for a product manager; a Chief of Staff; Doris is the CEO; and we have a Solution Architect. But even there, it’s a pretty technical group of people. So what’s your sense of Ponder culture?

Hazem: If I’d summarize it in two words, I’d say “infectious energy.” I feel everyone is, besides being really good at what they’re doing — there’s this strong feeling that each one is trying to come up with one way or even 10 ways to push the company forward and to push their teammates forward. You can easily see this on Slack, in meetings, in group meetings, one-on-one meetings. Each one is just trying to find: How can I help the company? How can I help my coworker? And I think this type of culture, if we manage to keep it and grow it, continuing to hire people with the same caliber, like what we have today, these are the ingredients for success, in my mind. So yeah, it’s just adding to my enthusiasm about the company.

Peter: My last question is a question about advice you have for computer scientists who are earlier in their careers. So at this point, you’ve done your undergrad and you’ve finished your PhD, worked at internships, you’ve worked in multiple places for multiple years, and you’re now at Ponder. What are some things you know now about life as a computer scientist that you didn’t know, say, when you were starting undergrad?

Hazem: It’s something which perhaps is being said in a number of places, but I think it’s really, really true and really, really important, which is: Maximize your learning opportunities. You can be creative about this. So most people would say as soon as you don’t feel you’re learning enough, maybe that’s the time to find another place to work. So yes, that works. But sometimes it’s also possible that even if you feel that you’re at a place where you’re not learning enough, perhaps you can do things where you get yourself to learn more things, even without changing positions or changing roles. Just think outside the scope that you’re already assigned to. See what your colleagues are working on. Help them do what they’re doing. Even outside of the entire function that you’re a part of, if you’re a software engineer, maybe learn a little bit about how the business is being conducted. Learn a little bit about what customers want. Learn a little bit about how HR happens, how managers are managing their reports. Always try to expand your scope, and that will make you ready for another transition at that point, whether the same place or not. And that also involves taking risks. Of course, risk taking is a function of the stage of life you’re in. So if you’re just fresh out of college, I think this is the time where you should maximize your risk. And the number one channel for this is joining small startups, understanding how this game is played, how to do it the right way. Make sure that you’re joining the right team working on the right problem. This is really a time for expanding one’s perspectives and learning skills and all that. So it’s a good time also to capitalize on this, if the opportunity is there.

Peter: Thank you so much for this chat. And thank you for being at Ponder.

Ready to level up your Pandas game?

Try Ponder now