We proudly present

Elena Pérez

Software Engineer at Facebook

Published on

We are happy to publish the first Tech Insiders interview.

We sat down with Elena Pérez, Software Engineer at Facebook in London. We spoke about her day to day in the job, the things she likes about it, how she got there, and what her interview process was like. She even offered some advice on how to prepare for the interviews!

You can follow her on twitter: @ilnuska

Photo of Elena Pérez

Picture by Marina Filipovic Marinshe

What’s your team inside Facebook?

I’m working as a Software Engineer in the London office we opened around a year and a half ago. I’m part of the Internal Tools team. Our work consists in making the engineers' work more efficient. We engineers are very good programming, but we sometimes are very bad at organising ourselves. We are trying to make all the project management and organisation work as seamless as possible.

How long have you been in Facebook for?

On February 11th it’ll make one year.

That means you joined not long after the London office opened?

Yes, on August 2012 Facebook opened the London office with a "landing team" of 12 engineers from the USA. They moved to London to kick-off the new office while preserving the Facebook culture. Then some of us started joining the London office to be based in London permanently. When I started we were around 30 or 35 and we are about 80 engineers now.

What’s your day to day developing Internal Tools like?

One of my favourite things from Facebook is that you get to create your own day to day work. We work around tasks and you are the one who decides which tasks to work on. Nobody tells you what you must be doing or which meetings you have to attend.

Each team is in charge of it’s own organisation. A team could be doing SCRUM if they work best that way or they could be doing something else because it suits them better.

In our case, the team currently has around 8 people, but we all work in very different tasks. We currently have a weekly meeting to get up to speed on what each of us is working on.

On a normal day, when I get to work and don’t have anything pending from the previous day, I just check what is the next task I should close and start working on it. I’m currently in charge of the task management tool that is used by every employee in the company, it’s called Tasks. Great part of what I do work is implementing new features, since we are always changing in the company and we always need new things and get new feature requests. Apart from new features, I have to maintain the tool, fix any bugs, and provide support to the tool users. In the company we use internal Facebook groups that are just like the groups available to Facebook users but restricted to employees. Based on the questions and issues discussed on the tools group, we provide support to the users and also decide what we should work next based on their feedback.

You decide what tasks to work on, implement new features and do user support. Do you do any other things like QA?

Yes, we do everything, including QA and having somebody on call in case something breaks. The good part of this team is that, since we work in internal tools, we have more leeway to work faster and launch new features before they are 100% polished. Once we launch something, we can iterate and refine.

Obviously, other teams working on the product need to work differently. Each team in the company has it’s own way of working depending on what they need to accomplish.

You have mentioned you need to have people on call. Do all teams need to have somebody on call?

Most teams do. Basically, there’s always somebody from the team on call 24x7. That person gets notified about all the tasks, bugs and issues related to the team. When something important breaks, it’s their responsibility to fix it or get the right person to fix it.

It’s not too bad in our team. We don’t usually get a call in the middle of the night, but it might happen to some teams. Especially it can happen to product teams in charge of the core Facebook features.

How do you manage it? How often are you on call?

Our team currently has a 7-day shift and, since we are around 8, I have to be on call approximately one week every two months. Depending on how big a team is you’ll need to be on call more or less frequently. It’s important to always have somebody on call, but everyone’s quite flexible and you can always get a teammate to cover for you.

You have mentioned you are around 8. Is not the team size something fixed?

We have a lot people changing teams internally. We have some people leaving our team right now, and some other people joining. That’s why I said we are around 8.

At Facebook changing teams is not an issue. Actually, the company encourages you to change teams every 6/18 months, depending on your circumstances. That way you don’t get stuck and get to learn more from different parts of the company, because you are usually more motivated when starting something new.

Is everyone based in London or do some team members work remotely?

We are only 8 in London. We’ve got a similar team working on Internal Tools in California that is about the same size, but they work on different tools. As you can imagine, we have lots of internal tools. Because we work in different time zones, we split the work so that both teams can function on their own. We have daily calls, but since we are independent we don’t need to wait on each other with the 8-hour time difference. They have their tools and we’ve got ours. Even though we work on different tools to reduce dependencies, we work very closely.

Did you join Facebook to work in the team you’re now part of?

Not exactly. Many people usually know what they like to work on, in what areas they have more experience or what the specialised in while studying. In my case, before joining Facebook, I had a company where we made Android products. I used to do some other work besides Android, like our analytics dashboard, but that was because I liked it. I was actually coding Android apps before joining Facebook.

When I started interviewing for Facebook, my interview process was more oriented towards Android. However, once you join Facebook you get to choose what team you want to work at. We think you work better when you are doing what you want. In my case, once I joined the company, I liked the Internal Tools better than the Android team. I talked to the team, and they gave me some tasks to see if they liked me and I liked them. We liked each other and I joined the team.

I had not done any actual web development. I had done some small projects on my company like the analytics dashboard, but that was it. I didn’t have any relevant professional experience, but now I’m working on the web full-time and I really like it.

You are working on PHP?

Yes, I’m doing PHP and lots of JavaScript

Did you have some experience with PHP and JavaScript before?

I barely had any experience with PHP. But the learning curve has been pretty smooth because we have some very good internal frameworks to develop in PHP and you get up to speed very quickly. You don’t need to know all the language details because the frameworks already provide you with a good structure and, believe it or not, it makes it really clean and easy to work with PHP.

I had a bit more experience with JavaScript, but not even close to my Android experience.

You have been learning while working then

Yes, but I believe that’s one of the advantages programmers have. Once you have the basis and you know how to code, the language is just another tool you can learn. You can obviously be an expert in a language, and that’s very useful, but you can learn to be productive using new languages with just a bit of effort.

Some jobs require you to have a deep knowledge of a specific language or be an expert on some topics, but this wasn’t the case. They saw that although I didn’t know PHP, I could learn how to use it quite easily. Now I feel very comfortable and I’m very productive, even though I’m not an expert.

Speaking of learning about programming. How long have you been coding and what did you study in university?

I usually joke saying I’m not a real engineer because I had not programmed until I got to university. I had tinkered a little bit with plain HTML before, but not with JavaScript, PHP, etc. At university I enrolled to study two degrees: Mathematics and Computer Science. I did Mathematics because I really like it, and CS because I had always been tinkering with computers and I liked it as well.

I started coding on my first CS course. It linked to some logical thinking I knew from maths, and I liked it. On my first CS lesson they showed me Pascal and and my initial reaction was: “OMG, what is this?”, but I really liked it and kept coding. Back then I didn’t have any personal projects and just coded in uni.

Later on, I got a grant to study in the US for a year. Lessons in the USA were really good, but I had tons of spare time, so I started to learn Android development in my spare time. I started helping a friend of mine who was developing for Android too and we started to launch some Android apps. We started our own company from there.

I think I learned a lot in university about the basis of computer science, architecture, etc. However, a big part of CS is about self-learning, looking at what’s going on in the industry, what that might be good for your profile, and learning what you need on your own. You shouldn’t expect the university to teach you Ruby or some other trendy language in the industry. The curricula at most universities don’t necessarily align with the tools and trends from the industry. They are more focused on teaching you the fundamentals that will work across trends.

How did you decide to learn Android rather than something else?

It was a bit by chance. My friend was doing some Android development and it looked like it was gaining traction. I didn’t research work offers to see what was demanded, I just wanted to learn something cool. Later on, when I was in my company and I had to do the analytics dashboard, I did a bit of research on different languages and frameworks, Python and Django looked good and I started learning.

Nowadays you can find statistics about the most demanded languages in companies, but those are just a bit orientative. When you are starting out you need to choose something you like to keep you motivated. You shouldn’t choose a language because it’s on high demand, but because you like the language and what you are going to do with it.

Later in your career you’ll sure need to learn some things because you need them. I have learned PHP because I had to use it at Facebook, and I quite enjoy working in PHP with the frameworks we have.

What would you say are the key skills for your current job?

I think the most important thing as a software engineer is curiosity. If you don’t know something, learn it. If you are struggling with a problem, find a way to solve it: ask other people, look it up on books, look around in the web… You have all the resources you need. “I don’t know how to do this” is not an option. It can be done, so do some research and do it.

It’s not just “I don’t know how to do this with language I’m using”. If you need to learn a new language that is more appropriate, learn it. Teaching yourself is very important.

Another area I’m valuing more now that I’m in Facebook is being self-sufficient. I’ve got a manager dealing with the big picture, but I’m the one who has to decide how to address my tasks, what things should I prioritize, etc. This will probably change a lot depending on the job you’re doing. Even inside Facebook, this leeway may change depending on the team. In my case, being self-sufficient is very important.

What’s the thing that you value the most from your job in Facebook?

You’ve got the usuals: the office, the perks, the environment… Those are great. Also, we don’t have a fixed schedule: you know how you can handle your time in order to be productive, so you get to decide. Maybe you are more productive at some point by working less hours or working on a different schedule to the rest of the teammates’. You can do that. Besides, we don’t work based on objectives, but on impact. You must choose the projects and tasks that would have the biggest impact and you get to choose how you can work best to accomplish it.

Those are the most obvious points. Another thing I’ve appreciated since I started working here is that we are all at the same personal level. We’ve got some people who are very senior, others have just finished uni, and we have people like Lars Rasmussen - one of the creators of Google Maps -, but we are all at the same level. If you have a doubt or would like somebody to give a talk, you can just approach them to ask. There’s some management hierarchy, but we are all at the same personal level. This helps a lot when you want to move fast and learn. Sometimes I think I can learn just by working here side by side with so many great people. Also, whatever you want to learn about, there’s probably somebody from that area of expertise.

Following on that, some people think that at companies like Facebook all employees are extremely intelligent. What’s your take on that?

I don’t think we are all geniuses. I think we all have a similar profile. We all fit very well with the company culture: we work fast, trust our colleagues, etc. With regards to knowledge, I believe it’s more important knowing how to learn rather than having lots of previous knowledge. I don’t regard myself as a very intelligent person and I don’t believe that’s the only thing we look for when employing people, but I think being a fast learner goes a long way.

Is it more about having people who want to learn and do new things rather than very intelligent people?

Exactly. There’s a lot of concentrated knowledge, but we are not all brainiacs. We are curious people who want to learn new things.

You think you all have a very similar profile. What’s would you say that profile is?

That’s a good question. It’s not that we are all the same, not at all, but everybody is quite relaxed and professional at the same time. We are quite curious and we like to move fast, but we also like to do things properly. Also, we are not competitive between each other. We are competitive with ourselves, because we want to keep improving, but not with each other. We are always helping each other.

How did you end up in Facebook?

I used to attend various conferences in my previous company. Around year and a half ago I attended Droidcon London and met some Facebook engineers from the Android team. They were all very nice, loved their job, and had fun doing very interesting things. At that moment I had my own company and I was not considering changing jobs. Later on, I wanted a change in my life so I left my company and moved to London. Once I was here I started looking for an interesting job, so I got in touch with them and asked whether they thought I should send my CV. They thought it was a great idea, so I applied and started the interview process.

What was the interview process like?

The process is the same for everybody. It starts with a phone screening where you have a conversation to get to know you a little and you get a couple of coding problems to solve in your computer while you tell the interviewer what you are doing.

How does the coding test work? Does the candidate write the code and submits it at the end of the interview?

No, you use an app that allows the interviewer to watch what you type as you are typing it. Actually, that code is not even compiled or run. You can choose any language you want. It’s just to see that your code is organised, you know what you are doing and how you are doing it. It’s not about being fast or having a perfect syntax. It’s about getting a general feeling on whether you know how to code.

What happens after the phone screening?

If you pass the phone screening, the next part is 4 interviews on site. You visit us at one of our offices, whichever is closest to you, and we have 4 interviews of 3 different types.

The first interview is to see whether you fit in the company. It’s 45 minutes talking to the interviewer and you usually don’t have to write any code. If you have to write some code it’ll probably be something very small. It’s more of a discussion. In my case, we talked about my previous company and about Facebook: what are the things that I liked the most, the things that I liked the least, etc. It’s not so much about the typical questions asking to explain the experience you mention in your CV. The conversation is more focused on getting to know you, what’s your mindset and whether you do things because you want or because you are told to. Something that is says a lot about somebody, even before the interview, is whether that person has had any personal projects. Having personal projects usually means that person is proactive and does things because they want to. It might seem hard to believe, but it’s not very common to find people who work on personal projects.

The next two interviews are about code. You have to solve some programming problems on the whiteboard. I felt very weird on those ones. It’s very different writing code and not being able to re-indent the code, insert a new line in the middle of a function, and so on. I would recommend people to do some training beforehand by writing code on a whiteboard or on paper. It may sound silly, but you might know how to code and not know how to code on a whiteboard. That might make you feel insecure and come across as if you don’t really know how to do something that you really know. Those two interviews are 45 minutes each and, in my case, it I had to solve 4 or 5 problems.

What do you look for in a candidate when you’re in charge of the coding interviews?

I want to see their train of thought. Have them explain me what’s what they are thinking and why. I like to listen what the candidate is thinking and have a discussion where I can see their thinking and how that is transferred onto the whiteboard. Also, while we are discussing what they are thinking, they might realise they are not on the right path and change it. That’s something natural that happens to all of us while we are working. I might think of a solution and, when I start to dig deeper and implement it, I might realise it’s very wrong. That’s normal and it’s not a problem. We are not looking for somebody who can come up with the right solution for a problem at the first try. We want to know how they are reasoning about the problem until they get to the solution, and then we want them to test their solution. Testing your solution is something very important and it’s not so common.

What do you mean by testing the solution?

You are obviously coding on a whiteboard. That code is never going to be typed on a computer or executed. However, you can look for example inputs to your problem, come up with corner cases, and trace your algorithm to make sure it does what is supposed to. This is especially important since most problems you’ll get might have some special case to consider. If we gave you a simple straight forward problem we would not have the opportunity to see their reasoning so much. When I choose coding problems for interviews, I choose problems that are going to tell me something about how the person addresses the problem.

You’ve got to stay calm, reason what cases you might find, how you are going to solve the problem, write it, and check the solution does what you were asked to. In many cases it helps coming up with some corner cases before you start writing code, because that’ll help you find the solution.

The exercises are not brainteasers, they are just problems so you have to do some reasoning and demonstrate what you can do. Training for this is as simple as solving some problems in front of somebody else while you explain your train of thought.

When you do these problems, you’ll be able to choose any language you want. It’s very important that you choose the one that you are most comfortable with. Some people pick a language because they think it’s going to look better, but that can be problematic. Using a language you are not comfortable with would just make things harder for you and won’t give you any extra credit.

What about the fourth interview?

The fourth interview is more about code structure and systems. This one is more targeted to your profile: if you are an iOS developer, it will be more about iOS. In my case it was a conversation about Andriod.

Even though this interview is more targeted, it’s still very general about how you would design a problem and what your knowledge is. It’s not about going into detail on how you would implement something, but how you would address the task. Rather than solving a problem it feels more like a conversation. When I did my interview we started talking about lists in Android, I mentioned the cache and we started talking about caching in more detail. They didn’t ask me a specific question about how caching worked, we just got there from the conversation.

If you had to give one tip to somebody who is going to go through your interview process, what would it be?

Speak your mind.

When you are doing the coding interviews, explain what you are doing and why. This might even also give you an idea on whether you are going on the right direction by the interviewer's reaction. It can also be like rubber ducking and help you realise your solution is wrong while you speak it out loud.

What do you mean by Rubber Ducking?

Do you know when you get stuck solving a problem or finding a bug, you get a hold of somebody to explain the issue and, while you are explaining it the solution suddenly comes to your mind? Rubber Ducking is the same but, rather than talking with somebody, you are talking with a rubber duck. You don’t need to bother anybody. I’ve never talked to a rubber duck specifically, but during the interview you might figure out something just by speaking your mind. Even if the interviewer doesn’t actually give you feedback, just explaining what you are doing will help you.

Something else you would recommend?

There is something I really liked about the interview process and made me feel more comfortable despite being nervous. After each of the 4 onsite interviews, the last 5/10 minutes are your chance to ask anything you would like to your interviewer: what it’s like to work at Facebook, what’s their previous experience, or whatever you might be interested in. Obviously, there are some details they might not be able to disclose because they’re confidential, but you can ask almost anything. Also, this tells the interviewer a bit more about the candidate. It’s not the same having somebody who doesn’t have any questions versus somebody who show genuine interest about the job and their potential colleagues. It signals whether somebody is interested in working with you or not. It’s not about preparing some questions that might look good, but making the most of the chance learn about the company you want to work at.

What’s the part that you find more challenging about your job?

Personally, the most challenging part for me is negotiating features with our tool users. The tool I’m working on is used by every single employee on Facebook, from the engineers to User Operations. If the tool focuses too much on the needs from one group, it might not be good for other groups.

However, I really enjoy other parts of providing support and receiving feedback. It’s great when you get positive feedback, or when you have the opportunity to talk with somebody to understand their needs so that you can address them.

If you were not working on Facebook. What kind of job would you look for?

I had to think about that when I moved to London. I had my own company before that. I had a co-founder and employees to work with, but I was my own boss. It was weird looking for a job and knowing that I would have a boss to report to, and that I would work under somebody else’s rules. I had never worked for somebody else and it felt strange.

After I thought about it, I looked for a job where they would take my opinion into account. I don’t see myself on a consultancy company where you get some project and your job is limited to implementing it according to the specs. I like implementing a project, but I also like taking part on how it has to be implemented and, if possible, participate in the design phase and help define the project and its features. In that sense, I would see myself working in a company like Facebook or a smaller company, somewhere where I could manage how I work, and I could take part in the decisions on what to do and how.

As an extra, it would be nice to be able to get involved in other areas too. As an example, I hadn’t spoken a lot in public, but now I have the chance to do many talks in events and universities, meet people, and help with recruiting. I’m liking it a lot. It’s not my day to day job and it’s more disconnected with coding, but I really like it.

Given your experience talking in universities and interviewing people. What do you think students and graduates should be doing more?

In my opinion, the most important thing is doing some side-projects. You have to study and pass your courses, but you should also look for some project to develop outside of uni. Doing so will teach you how to make decisions, will improve your creativity and will teach you how to define what needs to be done. Out of your needs to develop a project, you get to learn many things that are not usually taught in universities. It complements your education.

Something else that would help is attending to talks and meeting people who are already working in the industry. Nowadays there are many groups around startups and technologies where people get together and talk about what they are working, how they are working, and get to meet each other. You’ll slowly get to meet many people and get in the industry. People will take you to learn new things, learning new things will motivate you to move forward, and that could take you somewhere cool. In my case, it took me to Facebook.

Must projects be big or polished?

Not at all. It’s not about creating a company or product. Develop your own projects even if they are small. Go where your curiosity takes you. Not because you’ll be able to show it or add it to your CV, but because it’ll help you grow as a person and a professional.

It’ll also help you identify what you would like to work with, wouldn’t it?

Of course. University teaches you some things, but there are many areas from computer science that you won’t even discover unless you work on other things outside your degree.

You mentioned you have helped recruiting. Are you looking for people now?

Sure! we are looking for lots of people: interns, graduates, and people with working experience. In general we are looking for any profile: backend, frontend, operations, search, Android, iOS, etc. We are growing a lot and we are looking for people who are excited about working with us.

We now have an office in London, where I’m based. I love it because it’s still quite small. But we are also looking for people in California, New York, Seattle… A couple of friends of mine just moved to California to join us.

If you would like to work with us, just send your CV.