What it’s like to interview at Pinterest

Justin Mejorada-Pier | Software Engineer, Analytics Platform Tech Lead

Interviews have traditionally been thought of as an unpleasant but necessary experience. Candidates often find them stressful and many come in having had poor interview experiences in the past. However, interviews are the clearest opportunity for companies to articulate and demonstrate their company values, culture, and approach. It’s counterproductive for a candidate’s first live interaction with a company to risk being an unpleasant experience, stress them out with a tricky probability question, or cause them to feel out of place.

We think interviewing at a company can actually be a positive experience. Interviews should allow candidates to demonstrate their own way of solving real-world problems as well as learn more about what is it like to actually work for Pinterest.

So we set out to rethink how technical interviews work.

Here we’ll share our approach and describe in detail what it’s like to interview at Pinterest.

Real solutions, no gotchas.

• We allow candidates to use online resources like Google or Stack Overflow during the interview process to mimic as closely as possible what they’d see in a real work environment. We also provide a machine with the most common IDEs, like VSCode and Sublime, so candidates feel at home with the code completion, syntax highlighting, and shortcuts they’re used to.
• Our questions are made specifically to avoid “gotcha” moments. We retired a whole host of questions for this reason. We want to challenge candidates to show us diligent critical thinking skills, but we never want to trick them. We give candidates the opportunity to show us their best work. If our questions aren’t set up to do that, it’s on us, not them, and we take that very seriously.
• We look for problem solving skills that show candidates can tackle real-world technical challenges like those they may encounter in their daily work. You won’t be asked a question that requires, for example, dynamic programming. Instead, you’ll be asked to tackle a programming problem representative of the work engineers typically encounter, such as writing a tool to analyze a log file.

There’s not just one type of engineer.

• The Pinterest interview process cares about more than just a candidate’s ability to code. Showing a growth mindset is a signal we take into account during debriefs. We also purposefully split questions into several steps that gradually increase in difficulty, so everyone can find the correct level of challenge whether they’re a new or senior engineer. This also avoids that awful feeling of walking out of an interview having not gotten ANY part of the question.
• We understand different people have different interview styles — so don’t worry about trying to be someone you’re not. People have different approaches when solving problems. Some talk through it aloud as they write their code while others silently brainstorm before diving into solutions. As long as you solve the technical challenges and clearly explain your solution, you should feel free to talk as much or as little as you’d like.
• If you’re coming from a non-traditional background, going through a full software interview loop isn’t the only option — we also provide programs like our apprenticeship program, which still does rigorous vetting but is better able to identify passionate, motivated people that could be huge assets to any company regardless of whether they studied a particular topic in college.
• We take unconscious bias seriously. We have reminders and tips for checking unconscious bias every time we enter candidate feedback, and we have rules that prohibit discussing candidates with other interviewers to avoid opinion contamination.

The details.

Interviewing at Pinterest consists of three main steps:

1. Recruiter Call
2. Phone Screen
3. Onsite Interview

Recruiter Call: During this initial call with a Pinterest recruiter, you’ll learn more details about the role and your interview process. Be sure to ask any questions you might have; this is as much about Pinterest interviewing you as it is about you interviewing Pinterest.

Phone Screen: You’ll speak with a Pinterest engineer (or, for some roles, a Karat.io interviewer) for about 45 to 60 minutes. You may also use a collaborative coding tool so you can both see the code you write and, depending on the question, possibly even run your code. For example, we may use CoderPad for generic programming questions or JSFiddle for web development questions.

The purpose of the phone screen is to get to know your general programming skills, specialized domain knowledge (when applicable), and overall interests.

Here is the general format:

• Five minutes where interviewers introduce themselves and ask the candidate if they have any questions before starting
• One or two coding questions
• Five minutes where candidates may ask any additional questions about the role or Pinterest

The coding questions are usually around data structures and algorithms, but they may also include some domain knowledge elements depending on the role.

Onsite interview: During the onsite interview, you’ll come to the Pinterest office to participate in (usually) five interviews spread across the following interview types:

• Data Structures / Algorithms
• Architecture / Systems Design
• Domain Specific
• Lunch Interview / Hiring Manager / Values

You can find out more about each one below.

Types of interviews

Data Structures / Algorithms

You’ll be asked to solve a general programming question involving real-world data structures and algorithms you may use to solve problems in your day-to-day work. You won’t be asked to solve a question using seldom used methods like dynamic programming, and you’ll be encouraged to use whichever programming language(s) you’re most comfortable with. Normally, the question asked has several potential solutions, ranging from a naive, brute force approach to more optimal, elegant approaches. It tends to be one question, but you may be asked other questions if time allows. The goal is to test your practical skills used in everyday programming.

Tips

Practice — Brush up on your CS fundamentals, data structures, and algorithms, and make sure you’ve practiced in your preferred programming language(s).

Resources — There are many resources online to help you practice. For example, you might check out sites like CareerCup, various online courses and apps, and books like Cracking the Coding Interview. Use these to build intuitive pattern recognition as you see more and more samples of the underlying subproblems and the algorithms and approaches commonly used to solve them. The goal is to use those building blocks to compose solutions to the more complex, unique problems you may see in your interview.

Naturally, if you encounter a problem you’ve already seen, you should point that out during the interview. For example, you might say something like, “I saw this problem last month, and I know it can be solved by x, y, or z methods. Do you want me to proceed with either of these methods?” Don’t be surprised if your interviewer still decides to have you work the problem.

Additional tips:

• Whiteboard vs. Laptop: Laptops are provided for candidates since that’s the environment that most closely mirrors day-to-day work. However, whiteboarding is an option if that’s where you’re most comfortable. It can be harder to improve and refactor code on the whiteboard compared to an IDE, so you may want to take this into account.
• Real code: Even though it’s okay if you prefer to start by wireframing your solution using pseudocode, you’re expected to be able to write your final solution in code that would actually run. Communicating your plan is important, and pseudocode is one way to do this. But talking through your plan or making a diagram may be faster for this purpose.
• Your programming language: We highly encourage you to use the programming language you feel most comfortable with. Most candidates tend to pick languages like Python, Java, JavaScript, Ruby, C/C++, or C#. However, it’s completely acceptable if you prefer using less common languages; just keep in mind that it may take a bit more time to explain your solution to your interviewer if they are not very familiar with your chosen language.
• Validation: Remember to validate your inputs and to ask the interviewer for their constraints or characteristics. Ideally your solution should fail gracefully when invalid inputs are provided, or at the very least it should not yield incorrect results.
• Testing: Remember to ask the interviewer whether you should add tests for your solution and describe or implement the tests based on their answer. Regardless of whether you write explicit tests or describe them out loud, you should make sure your solution works as planned and is able to work across the possible inputs.
• Think through the problem first: Don’t jump into solving the problem. First, spend some time thinking through the problem end to end while being cognizant of the time you have. Only after you’ve thought through the problem and clarified your approach with your interviewer should you start coding. However, if you do decide later on to change your approach, that’s ok. It’s incredibly important to remain open to new information and adjust your path accordingly. Here are a few questions to ask yourself:

— Do I fully understand the problem, its constraints, input and expected output?

— Do I know how much time I have available?

— Based on the above, what are some possible ways to solve the problem? Which one do I prefer and why? What are the tradeoffs between them?

• Break problems into smaller ones: Be sure to break big problems into smaller ones that can be composed to solve the bigger one. If you have solved any of the smaller problems before (most likely you have), think about the difference between them and the bigger problem. Can you modify them or compose them to solve the bigger one?
• Describe your planned solution: Once you have a plan to tackle a problem, describe it to your interviewer before starting it. They may be able to point out issues or provide tips before you start. Interviewers are encouraged to conduct the interview in a collaborative environment, so feel free to talk through how you’re thinking of tackling the problem.
• Runtime complexity: Be aware of the runtime complexity of your problem and be able to talk about it. Ideally mention it to your interviewer when you’re describing your solution.
• Ask questions, and if stuck, ask for tips: It’s ok to ask for tips if you’re truly stuck. While ideally no tips would be necessary, it’s better to ask for tips and be able to solve the problem than staying stuck.
• Code quality: The more readable, simple, and concise your code is, the better.
• Bugs: While ideally there’d be no bugs, it’s okay if you find bugs and solve them. If your interviewer spots bugs for you, ask questions to better understand, and work to solve them.

Architecture / Systems Design

In this interview, you’ll be asked to solve an open ended problem by designing a technical solution for it, describing and communicating it effectively to your interviewer, and iterating on it as needed to polish it and address any concerns. These problems are generally broad and may include some aspects of API design, online and offline (jobs) computation, client vs. server computation and storage decisions, communication with the web/mobile clients, database model design, database/storage selection, local or distributed algorithms, code architecture, caching, scaling considerations, common architectures, or communication approaches (like push, pull, pubsub, etc).

Domain-specific roles tend to have somewhat more domain-specific versions of this question.

Most times these interviews don’t require writing any code. However, they may require making basic architecture diagrams or otherwise communicating your technical solution to your interviewer effectively and being able to answer their questions about your solution.

Tips

• Requirements: Be sure you fully understand the problem, its final high level goal, and technical and non-technical constraints (such as whether this is a design for a prototype or long term product, a 3-person team or n-person team, and how long the team has to implement it).
• Success: What does success mean for your solution, and what are you optimizing for? How would you measure success? Be sure to describe and discuss with your interviewer this before starting.
• Brainstorming: There are often many approaches to solving these questions. Some are less optimal, others a bit more. First, brainstorm many possible ways to solve the problem, from the most simple to the most optimal. Explain their tradeoffs. Be open to any new idea or solution that your interviewer may propose or you may think about. Don’t be afraid to change your mind.
• Trade-offs: Clearly explain the pros and cons between different possible solutions, why you would propose one solution versus another, and under which circumstances would that proposal change.
• Considerations: Make sure you have thought through and explained the different aspects of your solution, such as scalability, possible bottlenecks, single points of failure, monitoring considerations, and possible improvements. The proposed solution should fit the requirements and constraints and explain what could be improved if, for example, the constraints were more lenient.

Domain-Specific

This one helps assess the interviewee’s skills and expertise on a given domain. This might focus on iOS, Android, Web, machine learning, distributed systems, data processing, infrastructure, or other specific areas. Depending on the role you’re applying for, this may be broad (like backend programming), or specific (like data processing systems). It may also require you to use the programming language of that domain when applicable, for example Objective-C or Swift for iOS roles and Java or Kotlin for Android roles. The specifics of this interview depend on the domain, but many of the general tips mentioned for the other types of interviews would still apply, so be sure to keep them in mind!

Lunch Interview / Hiring Manager / Values

Many times there’ll also be a hiring manager and values interview during lunch time so you and your interviewer can get to know one another a bit better. The main goal is to see how your values align with our company values, but it’s also a great opportunity for you to ask any questions you may have about the role, team, and life at Pinterest.

What’s next?

After your interviews, you’ll hear from your recruiter in the days following to discuss the outcome. If there was a match for the role (congrats!) they’ll let you know the next steps, including compensation and specifics, and you should feel free to ask them anything, including for another conversation or lunch with the hiring manager or team members. We’ll then look forward to welcoming you on your first day at Pinterest!

For more tips on interviewing at Pinterest, check out A Pinterest Engineering Guide to technical interviews.

If you haven’t yet, check out our open roles at https://careers.pinterest.com/ and our open source projects at https://opensource.pinterest.com/.