33 An Interview with Israel Ferrer Camacho

Israel Ferrer Camacho was born in Barcelona and studied Computer Science at Lasalle University Barcelona. The last year of university, he dropped out to co-found Bubiloop.com with Luis Moreno, where he was in charge of technology. At the same time he and other tech enthusiasts started the GTUG in Barcelona, the Google Technology User Group, which later was renamed to GDG. In 2012, he moved to San Francisco where he started to work for Lookout, a mobile security company, working as an engineer in the security team. From 2014 to 2018, he worked at Twitter as an engineer and contributed in a wide variety of projects in the Fabric team, Twitter for Android and Periscope. In 2018, he moved to Tokyo to work for Mercari as an Android engineer leading the project to scale a five-year-old codebase which would allow for faster development. Currently, he is working at Line corporation in Tokyo. Currently, he is working as a Software Engineer for Dropbox in New York City, US.

Israel Ferrer Camacho

Connect with Israel

Twitter: @rallat

Interview

What are you reading or listening to these days?

I listen to a lot of podcasts about politics, economics and history. I can recommend several. The New York Times The Daily podcast with Michael Barbaro is in my favorites podcast to listen every morning. The NPR Politics podcast is really good, but really any NPR podcast about any topic is always a pleasure and really valuable to listen. One of my favorite podcasts about history is called Stuff You Missed in History Class; the podcast does research about history and not only from the U.S. For example, one episode was about the Spanish dictator Franco. I learned more in that podcast than I had learned about it in school. Right now, I am temporarily living in Japan, so I’m trying to pick up the language by listening to Japanese podcasts News in Slow Japanese.

Some of the most influential books that changed me as an engineer were Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, Effective Java by Joshua Bloch, How to Win Friends & Influence People by Dale Carnegie, The Growth Mindset Coach: A Teacher’s Month-by-Month Handbook for Empowering Students to Achieve by Annie Brock and Heather Hundley, and Nonviolent Communication: A Language of Life by Marshall B. Rosenberg. As you can see, those aren’t only technical and that is because when you work in a tech company, you are never working alone and more skills other than technical ones are important.

“The thing I really care about is to continuously learn and improve as a person. I am always thinking about what that means and how I can quantify that improvement and keep learning.”

You’ve relocated from Spain to the United States to Japan. What were these transitions like?

I’m from Spain, and I lived there for 27 years. Before I left Spain, I started a company as a co-founder with Luis Moreno, @carthesian on Twitter. We were building a modern app store back in 2009. At that time, the App Store was terrible. You needed an expert to help you find the best app. Mostly, you were downloading apps that didn’t work well. We were trying to fix that problem, by recommending the best apps for the type of user profile and location. At the same time, that experience led Luis and me to meet people in Silicon Valley, through those people and after we shut down our company, I landed a job in San Francisco at Lookout.

The work culture in San Francisco was totally different from what I was used to. I had worked for a Spanish supermarket chain called Caprabo. It’s like Wal-Mart. I worked in the IT department. In that company, technology was a tool to get things done, but it wasn’t the core business of the company. The tech culture there was nonexistent.

When I moved to San Francisco, I started to understand how to develop solutions and communicate effectively. I found that people in Silicon Valley communicated directly. It was shocking for me. At the same time, I was learning a lot. It was exciting to have so many mentors. I’m where I am today because of my mentors. I would especially like to mention Lien Mamitsuka and Ty Smith, with whom I worked together at Twitter in the Fabric team, and it was one of the teams where I learned more than ever. What makes Silicon Valley so interesting for our field is that there is a high density of really talented and knowledgeable people, not only engineers but designers and product managers too. Many product managers and designers can code, which makes collaboration easier and products better. Without a doubt, by being there and being able to work with the professionals there, I felt I was learning and growing every day and becoming better at my job.

Fabric was a new team at Twitter, built on the top of the Crashlytic team, which was a recently acquired company. I still remember like it was yesterday my first 1:1 with my Engineering Manager, and he asked, “What do you need to be effective and happy on the team?” I didn’t understand the question. I thought, “Wait, what? You want me to be happy?” It’s a really different approach to management than what I was used to.

The manager’s response was to frame his role as the coach of a team. They are the people trying to help everyone work together and give us the necessary resources so we can build products faster and better. That really changed my perspective on leadership, and my manager quickly became a true mentor. I am who I am because of what I learned from my mentors and, in retrospect, my time at Twitter was the period when I learned more knowledge as an engineer and team player.

Twitter’s culture allows people changing teams, which keeps talented people challenged and happy. If you’re a high-performing engineer, your manager is likely to let you work on whatever product you’re most interested in. After Shipping the Fabric SDK, I joined Twitter for Android, which is the first time I’ve worked in such a gigantic codebase. It’s also one of the oldest Android apps that is still around. We faced challenges there in terms of scale and the amount of legacy code.

The problem with the infamously named “legacy code” is that it makes the team slower, and it makes it easier for an engineer to produce user defects. Moreover, it is difficult to quantify and detect early that your code quality is decreasing. That’s why every company that survives after five years will 100% hit this rock bottom of not being able to build product as fast as before even if the company hires 100 engineers; the code will break 100 times faster.

I think the code has to be ready for the number of developers you put on it. The codebase needs to be done consistently, allowing everyone to work independently to avoid conflict.

I was at Twitter for Android during a turbulent time. They were going through a reorganization, and it was difficult to get anything done. I ended up moving to the Moments team based in New York. After that, I joined the Periscope team and reconnected with one of the first engineers that I worked with at Twitter, Lien. She was an Engineer Manager at that time, and one of the best engineers I ever worked with. Lien has great leadership skills. She helped me improve a lot, especially in terms of the way I communicate and how I approach collaboration.

At the end of the day, you don’t build the product alone, but with a team. When there’s a team involved, there are relationship problems. It’s really important to be able to collaborate and communicate effectively with others.

In 2018, I moved to Japan, where I’d always wanted to live, but never found a company that hired non-Japanese speakers. A company called Mercari believed in me, despite my lack of Japanese skills. I decided to try it and see what happened. It was scary to come to Japan, but I don’t want to make decisions based on fear. The worst-case scenario was a failure. In that case, I’d return to the U.S. or Europe. It is always good to have a backup plan or at least be ready for failure and how big that fail can be so you can be prepared better in case that happens. Through all of these transitions, the thing I really care about is to continuously learn and improve as a person. I am always thinking about what that means and how I can quantify that improvement and keep learning, but that is another story.

Of all the interview paradigms, what do you think is the best way to interview software engineers?

It’s difficult to objectively know whether an engineer is good or not. Therefore, the team needs to optimize the process to minimize false positives and investing a fair amount of time for each candidate process. Nowadays, in the industry, there are a few standard ways to determine if a candidate is talented: the whiteboard algorithm or a tech assignment with a real domain-specific problem. In my opinion, the whiteboard algorithm interview will produce many false negatives because it doesn’t weigh the experience of the candidate. However, everyone who has worked with an experienced engineer knows that they are key players that help to avoid making the same mistakes, to be able to scale systems or ship robust products. Personally, I prefer a hybrid model of interviews that have domain-specific problems, behavioral questions and an algorithmic question that don’t require knowing an obscure or specific technique.

How can companies navigate this problem?

After a few years of experience, you realize that the top performers are also really good at building relationships and helping the team get things done. With my current team, we have a tech assignment that I know is very time-consuming for the candidate. We conduct on-site interviews, too. One of those is a conversation with the hiring manager that doesn’t involve coding. One is a code review, in which we ask the candidates questions, especially about how to scale assignments. The answer to these kinds of questions can only come with experience. After you work on the same app for many years, you realize how bad your early code was, and you learn to scale it. It’s important to talk with the candidates about how they envision the future of their code.

During the coding interview, we provide a laptop, and we do whiteboard work, too. We don’t expect perfect syntax or for them to finish the code in any way. We’re looking to see how the person breaks down the problem. The problems we use for the interview aren’t extremely complex. We ask the candidate to parse some data, transform it, and then with optimal performance. It’s basically an input, a function, and an output.

What’s your view on companies that do interviews based on computer science theory, mathematics, algebra, and data structures?

I think those interviews are a really cost-effective way to know if the candidate is smart. If you fail, it doesn’t mean you aren’t a good engineer. It just means you didn’t prepare for that type of interview. You have to be mentally ready, and you have to have the knowledge relevant to those questions fresh because in 45 minutes there is no time for doubts. The more interviews you do, the better you get at it.

I think it’s somewhat dehumanizing. Companies that interview this way are treating people like nothing more than a brain. They put the brain in a high-pressure situation and see how the brain handles it. They do it because they can. They have so many people applying every day that they can afford to miss talented people who might not want to go through that process. The companies doing this are the big four. They have similar minds. I don’t like it.

It seems to skew the process in favor of junior developers. Senior developers working at a high level of abstraction might not perform as well as someone fresh out of university who’s been focusing on data structures and algorithms. I think this is especially true when you are working on something like Android. If you are working in the back end, you have those types of problems more often. Not everything is so complex.

How does leadership fit in? What makes a good leader?

I used to think everything was about data, but at the end of the day, we’re humans. What I mean by that is that during my career, the best-performing managers have all been very sympathetic and caring humans, but at the same time, really sharp engineering managers that constantly provide feedback and collaborate with their reporters. The way they collaborate is by helping their reports by giving them the tools and unblocking them rather than the old fashioned top-down management style.

Is a good leader made or born?

Mostly, you can train yourself to do anything. Your genes and experience can give you advantages, but I believe everyone can develop leadership skills. The only time I think that’s not true is if your motivation comes from wanting to be more powerful. I don’t think that kind of mindset makes for a good leader.

How do we make leadership more of a servant position, rather than a power position?

I always say you’re only a manager because you have this knowledge. You need to help the team, or you won’t be useful to them. When the team fails, it’s the manager’s fault. Hopefully, companies are measuring their managers. Often, you’ll see 90% of the company leave suddenly. In those cases, the problem may be management.

I think the key is to have a culture in which the manager gives and receives feedback and uses the feedback to improve. Then, the manager’s manager should measure the satisfaction of the engineers. There should be strong metrics for leadership skills in an organization. It doesn’t mean we all have to be friends, but we need to have professional relationships that let us improve and work together.

How can a developer make the leap into a leadership position?

I’m asking myself that question right now. I’ve been reading books, trying to learn the best way. If you have a good mentor, they can help guide you through that process. If your manager is a good role model, consider asking whether he or she will help you put together a road map to take on a management role.

It’s culturally dependent, too. I really like the book Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott, but the problem with being too candid is that some cultures perceive it as aggression.

Is Japanese culture an example?

Yes. I don’t think the strategies in Radical Candor are relevant in Japanese culture. There’s a great book called The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer that explains with real cases how different cultures approach engineering work, and how leadership is understood in those cultures.

Israel, you mentioned that you follow some mentors on Twitter. Who are they, and how do you check them out and see how their philosophy fits?

My favorite Twitter mentors for leadership @kimballscott author of Radical Candor. Another favorite one Lara Hogan @lara_hogan, and Marco Rogers @polotek, Tracy Chuo @triketoraand Tracy Miranda @tracymiranda

What’s something you wish you’d known when you started out in the industry?

In the beginning, I wanted to see everything and show that I didn’t need help. In reality, the most important thing is to ask questions and ask for help. Some people jump into management when they realize they don’t want to be a developer forever. Is management the logical exit path? If you’re in a culture that only values quantity and speed, you may not want to stay in that position. It’s important to find the right environment that allows you to have a healthy balance.

I’m 35 now, and I just don’t want to open a new watermelon. I just want to stay in a good company with a good team of people where we can all collaborate and build better products together. Once you find that sweet spot where you have enough income and you have a good company culture, you want to stay there and try to progress as much as you can, career-wise.

How can a company cultivate an environment where people want to stay?

Engineers value different things. I want to be in a place that’s solving a unique problem but one that’s broad enough to help others in the community. I want a company that allows me to use my time to learn. I would like to be in a company that values more than just my output.

What do you think is broken in our industry? How would you fix it?

We’ve discussed interviews. I think that system is broken, but I don’t think there’s an easy way to fix it. Do you want to make it cost-effective, or to ensure that all the candidates are talented? There are a few movable variables, but there’s no perfect process. The system of accreditation may need changing, too. I have 90% of the credits for a degree in computer science, but I started my own company instead of finishing the degree. Because I didn’t finish, I’ve had problems with immigration in both the U.S. and Japan. Having the degree opens the doors for immigration.

As well, I think the computer science degree taught in universities is too scientific. The curriculum isn’t necessarily relevant to the workplace. After entering the workforce, I felt there was a huge gap of knowledge between what I had learned and what I actually needed to do as a software developer in a company.

A software engineering degree may equip you better for software development than a computer science degree. A computer science degree gives you a broad knowledge. You can’t navigate Qualcomm doing CPUs and GPUs right, you know how to do them all. I actually built a CPU in college. It was fun. You can learn that going to Qualcomm, but then you can learn that going to some electronics company, too, like by building hardware, software, etherware, and front-end, too. A computer science degree teaches you a broad knowledge, but I don’t think it helps you to get a specific job.

Performance reviews are another area of our industry that troubles me. If it’s difficult to hire people and be sure that you’re hiring the right candidate, of course, it’s difficult to review the performance of your employees. At the end of the day, it seems subjective. That’s not great because it leaves room for bias. Performance reviews need to be more objective and more based on metrics, and those metrics need to be totally objective.

How can we do performance reviews more objectively?

Companies need to define their engineering values, and those values should be publicly visible and level-based. If you are level one, this is what we expect from you. Level two, this is what we’re going to expect from you. Some of them will be about communication and style and leadership. Those are less objective, but those should not be very important until you become a principal. Performance reviews should be based on level-appropriate metric measurements.

How do you stay productive?

I sleep well, and I start my day by focusing on what I want to get out of it. Before going to the office, I check my tasks for the day and ensure that I know what I’m going to achieve. At the end of every day, I write down what I wanted to do and what I actually did. I set goals and check in occasionally. At the end of the year, I review everything and consider my five-year plan.

What is your five-year plan?

I’m 35 now, and I wonder whether I’ll still be a developer when I’m 40. I’m starting to realize that I care about coding, and I’ve decided to care more about themes and people. I don’t think I’m ready, but I want to move towards helping people to get better. When I find the right place, I’ll likely try to become a manager, or I’ll lead my own company.

What’s an across-the-board drain on productivity you’ve observed?

The lack of a process consumes a lot of time. I’ve seen this across countries and companies. There’s a lot of chaos at the start of each project. A standardized process for project implementation would save a lot of time that’s now wasted. I think questions open doors to knowledge. We need to ask whether we can be doing better.

Is there any sport that you do regularly that helps you maintain sanity?

I really enjoy yoga. It really helps with all the classic pains. When I was working at Twitter, we had a yoga class for free. It was magical. I would do yoga for an hour and go back and code, and I had seemingly endless energy to code.

What final advice can you give to someone new to this industry?

Something that made me a better engineer is developing my critical thinking. It’s important to know why you do something. Being analytical is the key to being a good engineer. I’m in a phase in which I’m interested in people and things. We’re on the shoulders of giants. Learning all of these things allows you to understand what you’re doing now to fix the machine, including the process. The deeper we go into the knowledge, the better work we’ll do.

I’m interested in assumptions. When I came to Japan, I had a set of assumptions and found that they weren’t shared. In order to work with people, you need to share a common foundation, right? It turns out, that’s not obvious. We come from different backgrounds and sets of experiences. When someone new joins our team, it’s important to share how we communicate, code review, and build code, for example. I think people often miss this step.

Israel’s Recommendations

• Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity | Kim Scott
• The Mythical Man-Month: Essays on Software Engineering | Frederick P. Brooks, Jr.
• Mindset: The New Psychology of Success Paperback | Carol S. Dweck