10 questions for Hortonworks CTO Eric Baldeschwieler

Name: Eric Baldeschwieler

Age: 47

Time with company: Since its inception, July 1, 2011; with the Hadoop project since 2006.

Education: Master's degree in computer science from the University of California, Berkeley, and a bachelor's degree in applied mathematics (computer science) from Carnegie Mellon University

Company headquarters: Sunnyvale, California

Number of employees total: 80

Number of employees the CTO oversees: 3

About the company: Hortonworks provides support and services for Apache Hadoop. It builds and distributes the Hortonworks Data Platform, which is open-source data management software powered by Hadoop.

1. Where did you start your career and what experiences led you to the job you have today?

It goes way back, all the way to tinkering in junior high school. We had some early microcomputers that we used to play with back then, so we'd make our own games and stuff like that, and I did some work in my father's lab at Cal Tech, helping with the automation of some of their experiments. That was fun and led to my first internships and my first job out of college.

I worked with a man named Steve Crane, who was doing a postdoc with my father. He was a co-founder of a company called Cubico and then joined a company called Digital F/X . Then I worked for him again in '92 at Electronic Arts. I worked with him first on lab systems at Cal Tech. Then we were doing 3D rendering, really early 3D graphics, and then finally digital effects for video post-production.

So, I started doing games at school and then summer work in my father's lab. It just kind of grew naturally from there. When it was time to choose a college and what to major in, computers seemed the obvious thing to do.

I was lucky enough in grad school to wind up working with Eric Brewer, who was a co-founder of Inktomi. Joining Inktomi was a pivotal decision for me since it was the source of a lot of excitement in the Valley. I started there in '96 and that led to our acquisition by Yahoo. I moved up the chain there until I was chief architect of Web search in 2005 and started to focus on the big-data problem, and that was the work that ultimately became Hadoop in 2006.

I think one of the things that's central to my current work [in big data] is really understanding how computers work. Back in the '80s computers weren't really fast and you had to really understand the machine very well to get as much out of it as you could. In the work I was doing in video and games the same applied, you had to understand the machine. That led to a natural transition to doing the work in search, where you wanted to answer the most questions as possible, using the most data as possible, as fast as possible.

2. Who was an influential boss for you and what lessons did they teach you about management and leadership?

I've had the good luck to work with a lot of great people. Steve Crane, who was my first boss and who I followed to a number of different jobs, we did a lot of very different things together, and one of the things I learned from him is that you could switch domains and take what you needed to a lot of different contexts, which is something I've continued to do across my career. That was a great lesson.

He was also a great technical leader, who really understood the work he was supervising (and doing), and a great person to work with as well. He was a great friend and mentor.

When I started working at Inktomi, I was working with Paul Gauthier, who was one of the founders. He's a polymath, a real technical achiever. What I learned from him was a sense of pragmatism. Especially now as computers are getting more powerful, the best solution is often the simplest and most direct one. I think that was key learning that I took out of Inktomi. Sometimes you can take a big sledgehammer and really flatten your problems and if you can do that, you can move on. So don't be afraid to solve your problems with the most simple solution. There's no shortage of problems, so that sense of pragmatism I learned from Paul was really important.

Raymie Stata, who was recently the CTO of Yahoo, I was lucky enough to have him as a friend and mentor. The thing that I've learned from him is a sense of optimism. That is incredibly important. It's in the value statement of our company. We have relentless optimism as one of our values [at Hortonworks] and he gets a lot of credit for that being there.

The thing that I really appreciate from him was this idea that open source is not a zero-sum game -- there's big returns to being in an open conversation with the community you're engaging with. In this business, there's so much competition and co-opetition, you have to be willing to personally engage folks, even when your goals are only partially aligned. If you do that, you create a lot of value.

A property that all of these guys excelled at was a confidence that hard things can be done. You've got to be pragmatic, but you've got to have confidence that these problems can be solved. I've had great luck working with people who aren't shy about attacking really hard problems and solving them in interesting ways.

3. What are the biggest challenges facing CTOs today?

I think there's often a real struggle between the pragmatic short-term things that must be done -- establish customers, generate revenue, the short-term things that sustain your business -- and the big opportunities that are out there. It's your job to think about those things, so finding the balance between the transformational short term and the long term is a challenge.

There's no shortage of opportunities. We're working on a huge portfolio of technical projects. The challenge is to figure out what things you can do that are both pragmatic and that will move you forward, but that are setting you up for long-term success. I think that balance is a hard one.

In my previous job before taking on Hadoop, in the years I was at Inktomi and Yahoo, I was trying to figure out how to build the infrastructure to crawl the Web and build search projects. It's the same problem -- you have a really large team, but you have to pick projects that move the ball forward in the short term and not lose sight of that long-term goal.

The other thing that stands out for me is that it's a very interesting time right now to be in business, especially in our business, where we're building technology that's really potentially transformative and can allow companies to do a lot more for less. You've got a climate where the technology is changing very quickly, budgets are constrained, and yet companies are seeking opportunities. We're working in a very interesting market, where there's a lot of excitement and opportunity but also a tremendous amount of uncertainty, and financial uncertainty.

So you have to be ambitious and you have to be pragmatic.

4. What is a good day at work like for you?

There's so many different things going on. Careers aren't linear. A lot of my time, I've spent doing line management. The majority of my time since 1996, I've spent managing a large team. When you manage a large team, your day is very structured. In a CTO role, if you don't have a direct line and a large team, you have the luxury of a bit more space.

So there are two things that I really enjoy. One is very outbound -- I get to talk to a lot of people using our technology and the thought leaders in our space and adjacent spaces, so on a good day I learn a lot. There's nothing like getting a download about how a person in a different space has wrestled with the same set of problems but come to different answers or looking at how really bright people use your technology and what works and what doesn't work. Those outbound conversations that show you what to do and how to do it better are very exciting.

Internally, it's similar. You get to work on the more ambitious parts of the agenda. I get to work with really bright people on designing the next generation of technology.

The nice thing about the CTO role is that you have to do both, so it's a real fusion of looking outbound and learning and the big picture and then coming in internally and solving problems, merging that big canvas view with what's happening in our industry.

5. How would you characterize your management style?

As a CTO, I'm managing fewer people directly. In my previous roles, I've managed teams of 60 to 100 people. In this role I'm not.

My focus is on vision and goal setting and problem solving. That's the real value I bring to the table, figuring out what is the big picture, what are we trying to achieve, and communicating that and setting goals, then working with the team to unstick the trains. Most of the time, once you set the goals, execution follows pretty naturally, but sometimes a set of local decisions will get made that in aggregate don't get things done efficiently. Occasionally, I have to look in on such problems.

I'm much more of a technology leader than a process leader, which is why I've been quite comfortable with the transition to CTO.

6. What strengths and qualities do you look for in job candidates?

I like to hire very smart, inquisitive people. Beyond that, obviously, I look for a couple of things -- they have to have achieved something concrete. They need to be able to tell me how what they've done works and how they did it. They also need to be able to tell me about the mistakes they've made, to talk about their mistakes and how they overcame them. I think you learn a lot more from mistakes than from success. You have to have overcome challenges in order to be able to do any job well. If someone tells me they haven't made mistakes, that worries me.

I look for people who will be able to work well with others. I really value diversity on the team. When you're doing something like Hadoop, there's no playbook. There's not an obvious way to solve the problems, so it's useful to have people coming from different parts of the industry, different disciplines in engineering, but I like people to have solid computer science fundamentals as well. A lot of companies will do logic puzzles and things like that [with job candidates], but I want to make sure that people have the fundamentals of computer science.

So, I look for people who are bright, know the fundamentals and can talk about failures and mistakes.

The last one that I would highlight is that we have a no-prima donna rule. I think it's so important to avoid the big egos and poisonous people. That's one of my hot buttons. I look for people who are going to get along, who are going to be willing to give credit where credit is due and move the ball forward. I think that's important in all organizations, but especially in an open-source organization where all of your people are spokespeople.

It's challenging because I think genius and ego are often one package. If you find someone who is smart enough for the job but just isn't going to fit into your culture, I've learned the hard way that you just cannot compromise on the soft skills. People have to be able to get along with their teammates.

7. What are some of your favorite interview questions or techniques to elicit information to determine whether a candidate will be successful at your company? What sort of answers send up red flags for you and make you think a job candidate wouldn't be a good fit?

I'm giving away my toolbox here. I would really go back to mistakes. One of my favorite things to do is to ask people what went wrong, what decision did you make that didn't work and why. If they haven't really done what their résumé says they've done, that [question] will show this right away. The answer will show whether they've worked through the problem and you can learn a lot right away by their answer.

I also mentioned earlier that I like asking people about the fundamentals of computer science. The reason is that with a problem like ours, you have to really understand efficiency and data structures and algorithms or you can come up with things that look like solutions on one machine but you scale them up and they quickly fall apart if they're not correct in a computer science sense. I like to make sure that people really understand how computers work. That's kind of a vanishing skill. I don't think you can do systems software unless you really understand how computers work.

And then I like to ask people what they're proud of and listen. You learn a lot by asking people what they've done in their career that they're most proud of.

Then what I ask really depends on the role. For senior roles, I like to ask people about who they've mentored and what those people have gone on to do. When we were recruiting for our VP of engineering, that's one I used. You learn really fast when they start to answer questions like that with names of people who are all over the industry.

I don't have a specific set of questions to weed out toxic people, but you really have to listen for that.

8. What is it about your current job, at this particular company, that sets it apart from other chief technology positions?

1 2 Page 1
Page 1 of 2
It’s time to break the ChatGPT habit
Shop Tech Products at Amazon