Types of interviews

job-hunt
≡

FACEBOOK MANAGEMENT INTERVIEWING 101

OVERVIEW

Here is a synopsis of the four areas interview areas are:

  • Management: This area assesses your capability in supporting organizational health, people management and planning.

    • Showcase success stories and get to the situations that show how you as a leader navigate the complexity of developing, supporting, and scaling both your people and your teams.

  • Project Retrospective: Using example(s) from your past, discuss the non-technical skills needed to deliver a project from start to finish. Areas we cover include:

    • Business understanding, product/project planning;
    • How you negotiated with stakeholders and peers;
    • Setting and driving success metrics;
    • Your understanding of design tradeoffs, business vs operations vs development considerations;
    • How you scale systems and business processes.
  • System Design: Explore the design of a complex system and the tradeoffs within a design. The scope of the question can vary widely; it’s a challenging and deep technical discussion around product ideas, usability issues, scalability, data structures and technologies used. For this interview, there is no right or wrong answer. The interviewer wants to observe how you design and architect a system.
  • Problem Solving and Coding: Solve a basic computer science problem typical for a 1st- or 2nd-year computer science undergrad program. The problem will cover basics of algorithms, data structures, design patterns, system design, complexity and basic coding.

Most candidates are most concerned with the coding question — especially those who have not coded in many years. Our goal is not to see if you can still write production-quality, syntactically perfect code but to see how you apply basic CS principles to solve a concrete problem using a language of your choice.

In the notes below, you will see that we recommend you do not spend more that 10-20% of your time preparing for the coding question. Most candidates should focus on the system design questions.

Of equal importance are the management and project retrospective areas. As practitioners of software management, we are often very good at doing the job, but can sometimes be a bit rusty describing what it takes to manage people and projects. Reviewing basics management techniques will help you provide clear and concise explanations of the art of management; mapping those techniques onto your experience will enable you to discuss relevant examples that help demonstrate the real-life experience you have.

MANAGEMENT INTERVIEW

The purpose of the People Management interview is to assess your capability in supporting Organizational Health and People Management & Planning. Showcase success stories and get to the situations that show how you as a leader has navigated the complexity of growing, developing and supporting the people in their team/organization.

This will be a deep dive into management experience. Questions will include: How do you evaluate a good team, course-correct one that’s unhealthy, grow people. It is helpful to think about past examples of successes and failures where you have navigated the complexity of growing, developing and supporting the people in your team/org.

PREPARATION GUIDELINES

  • Pick one or two of your favorite management books and skim them to refresh yourself w.r.t the various aspects of management.
  • Outline or role play answers to the basic questions asked of managers (e.g., how to you deal with low performs, how to you recruit, what happens if your schedule slips).
  • Please prepare a few examples for each theme using the STAR methodology.

DURING THE INTERVIEW

  • Describe both the underlying management principle(s) AND provide brief examples of how you’ve applied them in real life.
  • Describe both the strengths and the pitfalls of various techniques
  • Be honest about areas where you do not have much experience (e.g., managing remote sites).
  • Differentiate between your previous employer(s) management culture and other models of management.

For example, if your previous organization has a top-down decision-making culture, ALSO discuss organizational models that are more bottom up and the tradeoffs.

  • Don’t hesitate to ask follow-up questions to help clarify what the interviewer is looking for.

COMMON ERRORS

  • Assuming that since you’ve managed for years, you know everything. Taking a bit of time to organize your thoughts before the interview can improve the structure of your answers, allowing you to relate them back to basic management principles AND demonstrate your experience by coupling them with solid examples from your past

ASSESSMENT CRITERIA

  • Conflict Resolution
  • Managing top and bottom performers
  • Coaching and recruiting talent
  • Cross Functional partnership
  • Feedback: Things you could do better, areas where you failed and what you have learned

PROJECT RETROSPECTIVE INTERVIEW

OVERVIEW

Using an example from your past, you are asked to discuss the non-technical skills needed to deliver a project. Areas we cover include:

  • Business understanding, product/project planning
  • How you negotiated with stakeholders and peers
  • Setting and driving success metrics
  • Your understanding of design tradeoffs, business vs operations vs development considerations
  • How you scale systems and business processes.

Think of this as like the system design question, except after the fact for a real project you were closely involved in. Why did it get built? What were its goals? How was it structured? What parts worked well? How did you adapt it to work better? What were some of the nitty gritty technical details that made a difference? Operating at Facebook This will be a general discussion on building management and Engineering culture.

For this interview you will be asked to walk through a project you have been working on – your role is to impart an understanding of the project at both high and low levels to the interviewer. This will take the form of a discussion and not a presentation, slide decks are not needed and discouraged, but code examples and architectural diagrams are reasonable

PREPARATION GUIDELINES

  • Recall one or two different projects you have been responsible for and map out the various aspects of the project, focusing on the questions outlined above.
  • Map out a pithy description of the project, it’s goals, and the various efforts.

DURING THE INTERVIEW

  • Be clear and concise. Since interviewer will not have any background knowledge of your example, make sure to provide enough context. BUT watch out for overly complex examples that are difficult to describe or require too much context (e.g., watch out for company specific knowledge that will not make sense to the interviewer)
  • Map your project retrospective back to basic management principles
  • Provide clear examples that do not require too many details. You will have approx. 35-40 minutes to talk about the project - but assume there will be many questions, so try to map your answer into a 25-minute story.
  • Focus on your ability to zoom out and look at each project/product more holistically

COMMON ERRORS

  • Spending too much time on the technical aspects of the project
  • Spending too much time on aspects that require too many details

INTERVIEW ASSESSMENT CRITERIA

  • Business understanding, product/project planning
  • How you handle cross-function relationships (e.g., stakeholders, partner teams, customers)
  • Setting and driving success metrics
  • Your understanding of design tradeoffs, business vs operations vs development considerations
  • How you scale systems and business processes.

SYSTEM DESIGN INTERVIEW

OVERVIEW

The design of complex systems and the tradeoffs within your design. The scope of the question can vary widely; it’s a challenging and deep technical discussion around product ideas, usability issues, scalability, data structures and technologies used. One question will typically draw directly on your previous experience (e.g., file system design, device drivers, ad serving systems, web caching systems). Examples include: design a hotel reservation system, design Facebook’s News Feed. For this interview, there is no right or wrong answer; the interviewer wants to observe how you design and architect a system. We will look to you as the expert here and ask you to drive the design, starting with defining the high-level goals and then proposing a solution.

You’ll be given an open-ended system design problem and asked to walk through and whiteboard the system design, as well as think through issues around scaling, etc. System design. We’ll give you a realistic and fairly open-ended technical problem from the real world. An example might be “build typeahead suggestions for YouTube” (please ask your interviewer to use another question if they pick this!), where there’s a huge amount of data (hundreds of millions, maybe billions of titles), a load of traffic (hundreds of millions of queries per day), and a lot of dynamism in what people search for (new uploads, trending topics, etc.).

Such a system would have to be fast, reliable, cost effective, scale globally, and able to adapt quickly to trends. We’d want you to lead the discussion around what such a system needs to be capable of, then start with a particular area to flesh out the constraints on and major components of.

It’s really helpful to have a decent “these are the important black boxes” knowledge of modern distributed systems design, to be able to do arithmetic around sizing in your head, to roughly know about memory, disk, and latency capabilities of systems, etc. Here is crib sheet of relevant work we’ve done in this area, check out our research web site.

PREPARATION GUIDELINES

  • Refresh your senior level and/or master’s level CS background (e.g., operating systems, networking, distributed systems). Most people have not covered all areas — so focus on those you already have studied or worked in.

  • Recall the design of a few systems you worked on in the past and try to answer for those systems the questions below (see “What to do in the interview bullet”). We will NOT be asking you for confidential information about your previous projects - but your experience makes them a good starting point for you to think about how you would answer these types of questions.
  • Read a bit about how the hyper-scale companies have built their systems (e.g., Google File System, Facebook Tao Cache, Amazon S3). The goal is not to learn each of these systems in detail, but to build out a short list of the basic concepts used across many of these systems (e.g., sharding, containers and isolation, failure handling, durability). Those concepts are a good place to refresh your senior level CS background.
  • Review the basics of hardware (e.g., cost, performance, limits) across CPU, network, and storage to give you a physical sense of what systems are currently capable of.
  • Find a few system design questions on the internet. Take them and try to answer them on paper in 30 minutes per question.

DURING THE INTERVIEW

Be able to demonstrate an understanding of the low-level restraints and how they affect the high-level goals. and make sure to talk through your solutions keeping in mind different tradeoffs. When analyzing your system, you should discuss several of the following areas:

  • Testability: ability to formally, or otherwise, gain confidence that the components of the software system are correct.
  • Usability: the customer’s experience with the software system and the ability to evolve this quickly.
  • Extensibility: the ability to change the software system over time.
  • Security: ability of the system to survive DDOS, spoofing, tampering, repudiation, information disclosure or elevation of privilege attacks.
  • Portability: ability of the system to execute in different environments, on heterogenous tiers, on different hardware, or even operating systems.
  • Availability: ability for the system to survive failures.
  • Scalability: ability for the system to grow over time.
  • Operational characteristics: ability to diagnose or debug problems when they occur. Sev avoidance or mitigation.

COMMON ERRORS

  • Trying to master whole new areas of computer science. For example, if you kernel person, do not try to learn the details of distributed systems.
  • Focusing on optimal solutions - we are much more interested in seeing how you think though basic tradeoffs (e.g., should you use a hash table or an array) and how you think through those tradeoffs.

INTERVIEW ASSESSMENT CRITERIA

We are looking for how you can take an abstract problem definition in a field that is new to you. These interviews are intended to explore your ability to design a software component or system while looking at a number of dimensions of the design.

  • Problem exploration: understand the problem and flesh out the requirements
  • Handle data: segment the problem into pieces, build a logical and physical data model, and discuss the read/write/update path
  • Component responsibilities: tackle the individual parts of the problem while keeping in mind the larger goals
  • Completeness of the solution: generate a design for a system that addresses the requirements
  • Trade-offs: discuss the positives and negatives of the design that was proposed - System evolution: Show good intuition and judgement regarding what degrees of freedom within the system that are introduced. Evolve the software system in a coherent way as you introduce additional requirements
  • References:
    • https://github.com/donnemartin/system-design-primer
    • https://www.hiredintech.com/classrooms/system-design/lesson/52
    • https://www.educative.io/collection/5668639101419520/5649050225344512

CODING INTERVIEW: (NO MORE THAN 10% OF PREP)

OVERVIEW

  • Be prepared for 1-2 basic coding questions covering basic CS coding, algorithms, data structures, design patterns, system design and scalability.
  • You will whiteboard your solution using a programming language of your choice.
  • Solutions should focus on the basics in each area, not the more advanced and/or esoteric computer science skills — e.g., we are not focusing on syntactically perfect code nor advanced language usage (e.g., C++ templates, multiple inheritance).

PREPARATION GUIDELINES

  • Review core CS concepts (data structures, binary trees, link lists, object-oriented analysis, etc.) that are typically covered in freshman/sophomore CS programming courses.
  • Practice: Use your favorite language to solve some basic programming problems (e.g., print a binary tree in-order, add two binary numbers passed to a function as a string with the function call: string AddNumbers(string firstNum, string secondNum). Practice away from the computer, writing code and thinking out loud as you try to solve the problem, using basic data set(s) to test and debug your solution.

DURING THE INTERVIEW

  • Think out loud as you work through a solution, as the engineer/interviewer will want to know how you approach and troubleshoot problems
  • If the interviewer gives you hints to improve your code, take them and run with it; it’s good to adjust and work through problems to show the interviewer your problem-solving abilities
  • Don’t try to fake it nor worry about speed. Manager’s coding skills are often rusty and we don’t expect you to write lots of code (most questions can be answered in under 25 lines of code) nor write code fast. We do expect you to be able to solve 1 or 2 basic coding problems in 45 minutes.
  • Feel free to peruse the following coding resources that may give you a better idea of what you can expect and ways to prepare:
  • Cracking the Coding Interview (notably the best resource successful leadership candidates have used
  • Video on The Approach https://vimeo.com/157480836 Password: FB_IPS

COMMON ERRORS

  • Trying to learn a new language
  • Memorizing syntax rules, advanced language features, uncommon libraries

INTERVIEW ASSESSMENT CRITERIA

  • Communication: Think out loud while writing code; Ask questions to confirm understanding
  • Problem Solving: Check your solution before writing code
  • Coding: Check for bugs, try to not overcomplicate your code
  • Complexity Analysis: Time and space complexity
  • Debugging: Check your code proactively

Other Interview types

Cross Functional

The team is interested in how you think about and interact with other people. We like this to be “here’s a story about how I did something relative to your question.” We are big on self- awareness, so it’s really helpful here to be able to ‘fess up to working relationships you screwed up and learned from, conflicts you couldn’t resolve, and anything else that helps round out our picture of you. Can you work across the company? Can you handle different approaches, agendas and facilitate positive partnerships? How do you manage difficult partnerships?

Technical Discussion

For this interview you will be asked to walk through a project you have been working on – your role is to impart an understanding of the project at both high and low levels to the interviewer. This will take the form of a discussion and not a presentation, slide decks are not needed and discouraged, but code examples and architectural diagrams are reasonable