Navigating our engineering interview process: coding

As one of the world’s fastest-growing companies, Uber is always looking for new engineers to help people go where they want and get what they need. To accomplish this, we are developing technologies—from machine learning algorithms, to data visualization platforms, to mobile frameworks—at an unprecedented scale.

Up for the challenge? If so, your first step (after applying, of course) is to meet with our team. Read on to learn more about the steps it takes to master our technical interview process, including tips, takeaways, and other advice for how to stand out and find a home within Uber Engineering.

After submitting an application on our careers site, a member of our Talent Acquisition team will review your résumé and reach out to schedule a short phone call. During this call, they will ask you:

If the opportunity seems like a good fit for both your career goals and our needs, your Recruiter or Sourcer will schedule a technical phone screen between you and a Software Engineer or Engineering Manager on the team you are applying to. If the role you applied for has already been filled or we learn that there is an even better fit for your interests and skillset elsewhere in the company, we will suggest other openings for you to consider applying to. If all goes well, we will invite you to a team interview. 

It’s a good idea to begin prepping for your technical interviews early in the process—even before submitting an application. Your preparation should include three key components: preparing to talk about yourself, reviewing Computer Science fundamentals, and working on practice problems.

The first step is the easiest one to overlook, but it is important to be able to give an elevator pitch about your background and why you are interested in the position that you are interviewing for. When talking about your previous experience, be sure to explain your personal contribution. For example, if you were part of a team developing a full-stack web application, be specific about what you contributed to the project. After all, “I was responsible for designing our database schema and the back-end API endpoints” is a stronger response then “we built an app that showed photos.” During this process, you should also feel empowered to be honest about what you are looking for with your next career move. This is critical in helping us identify the best role(s) to meet both your needs and ours.

Your memory of Computer Science fundamentals may be a bit rusty. Reviewing basic data structures and algorithms in advance of your interview will help you recognize when they could play a role in solving interview problems, for example, recognizing that the data for a question naturally fits into a tree structure might push you toward a recursive solution. Discussing these basic concepts is often an afterthought for more seasoned professionals compared to discussing actual work experience, but it never hurts to be prepared.

Another question that you and your interviewers will discuss is, “how well does your solution scale?” When this comes up, you should be prepared to talk about the runtime and memory requirements of the solutions you have worked on in terms of their Big O complexity. In fact, your first attempt at solving a problem might result in a naive O(n^2) solution, and recognizing this could give you an idea of how to solve the same problem in O(n log n) time. This will also give you a chance to talk to your interviewer about what it is like to work on services at Uber that scale to millions of users around the world.

Once you have refreshed your knowledge of data structures and algorithms, go through as many programming practice problems as you can. Good sources of such problems include the ACM-ICPC archive from its past programming contests, CodeWars, and the book Cracking the Coding Interview. To simulate a realistic interview you should give yourself a time limit of about 30 minutes. If you have a friend who is willing to read your solutions and provide feedback that can also be a helpful way to improve—and of course you should be willing to do the same for them in return!

Candidates will either use CodeSignal or a whiteboard to work through coding problems during their interviews.

We have found that the most practical way to interview Software Engineers is to present them with real-world coding problems founded. This means that we will not present you with logic puzzles or brain teasers such as “how many golf balls could fit in a school bus?” In short, what we are interested in seeing is how you translate your thoughts into code, and whether or not our approach to engineering matches well with yours.

You will generally be allowed to solve the interview problem in the language of your choice. However, what we really mean is that you should not choose to conduct an interview in Go or Haskell if you are not familiar with these languages just because the team you are interviewing for uses them and you think it will impress your hiring manager. It is much better to get a working solution in a language with which you are familiar. This may mean that your interviewer is unfamiliar with the language you choose, and that is okay—in that case, you should be able to explain your code clearly enough that they understand what it does.

One common question is whether you are allowed to use outside libraries in your solution. (For example, you could ask about using NumPy for problems dealing with matrices in Python or MomentJS for handling dates and times in Node.) As a general rule, it is best to limit yourself to the standard library of the language that you choose. However, if you know of a common library or set of libraries that would help with a certain type of problem, you could mention this to your interviewer so that they gain a better understanding of your familiarity with the ecosystem of this chosen language.

For both phone screens and in-person interviews, you will typically have about an hour with each interviewer. The main difference is that when interviewing with the team (in person or virtually) you will have up to six interviews back-to-back, with short breaks in between and a longer break for lunch. Each interview will start with you introducing yourself to the interviewer. This is your chance to make a good impression and let the interviewer know why you are interested in the position.

You will then spend 30-40 minutes working through a coding exercise, as described above. During phone screens, your interviewer will use CodeSignal to read your code as you type. Your interviewer will also likely have prepared a few test examples for the problem in order to see whether your code works as expected. For in-person or virtual interviews, you will either use CodeSignal or work through these problems on a whiteboard, depending on the preference of your interviewers—in fact, you will probably have a mix of formats during the day of the interview.

After the coding exercise, you and your interviewer will spend about 5-10 minutes discussing questions about your previous work experience. This will likely include behavioral questions, such as: “tell me about a time that you resolved a technical disagreement with a team member” or “describe a time that you needed to acquire information from someone who was not very responsive—how did you handle it?” Being able to talk about your past experiences and what you learned from them gives your interviewer a better sense of your work style.

The final 5-10 minutes of each interview session is reserved for you to ask questions of your interviewer. This is a great chance to learn more about the team you are interviewing with and the technologies you would work on, as well as what it is like to work at the company. This time is also an excellent opportunity to demonstrate your excitement for the opportunity. Candidates who do not have any questions to ask their interviewer are often viewed as uninterested, so spend some time before your interview thinking of a few topics that pique your interest and would like to learn more about from your interviewer. Keep in mind that the interview is not just an opportunity for us to ask questions, it is also a chance for you to ask your potential teammates and manager about what it is like to work on these projects.

Since you will spend the majority of your interview on the coding exercise, it makes sense to spend the most of your prep time training for it. The biggest thing to remember is to communicate with your interviewer. For instance, when they present example problems, ask clarifying questions to make sure you understand the exercise. If the problem is about finding anagrams in a list of words, it is a good idea to make sure you know what an anagram is in the first place. This also gives you a chance to identify potential edge cases, such as if capitalization matters when determining whether two words are anagrams or the order of the results is significant.

Although this may seem self-evident, thinking out loud while you work through a problem gives your interviewer insight into your thought process. Talk about the approach you are taking and any trade-offs you can identify. If you arrive at a point where you have to choose between two different data structures, explain why you chose the one you did. Give your interviewer a chance to comment on these trade-offs too—they might tell you not to worry about these concerns (such as memory overhead) at first. Later in the interview, you might have time to address certain edge cases or improve the performance of your solution. This latter step is highly recommended if the chance presents itself: enhancing your results shows that you can iterate on existing solutions to improve your code.

Your goal for the coding exercise should be to get to a working solution (if it is not, there is probably a good reason!). Although identifying edge cases is impressive, you should always focus on solving the problem first. Writing a few tests to help check your solution is also very valuable; this will help you to catch any regressions you might accidentally introduce as you optimize the code later.

Something that is often overlooked but extremely important is using this exercise to showcase your ability to write readable and clearly organized code. To accomplish this, consider choosing clear variable and function names and separating parts of your solution into distinct functions, particularly if your interviewer introduces additional complications to the problem later during the interview. Like in a real world engineering environment, clear, concise code demonstrates an ability to collaborate and work well with others.

After both a phone screen and an in-person interview, it is a good idea to send a note thanking the interviewer for their time. You can also send this to the recruiter you are working with if you do not have the interviewer’s contact information.

Within a few days after your team interview, you will hear back from the recruiter about the result of your interview, and they will provide guidance on next steps. 

If the team you interviewed with decided not extend an offer, you can ask the recruiter for advice about what you can do better next time or if there are any other open opportunities that might be a better fit. You are also welcome to give the recruiter feedback about how the interview process went. We are constantly working to improve our hiring process, and we welcome suggestions!

Our new headquarters in San Francisco Mission Bay is home to many Eng teams across Uber. 

Many of these tips can be applied to technical interviews beyond Uber, but you will find that each company offers a slightly different variation on the process. Most importantly, use your technical interviews as a way to determine if the role is a good match for your career goals and skill set. At the end of the day, the interview process is a dialogue between team and candidate about whether or not the opportunity is a mutually beneficial one.

Now that you know how to navigate the Uber Engineering interview process, consider applying for a role on our team.