← All posts
general

40 Meta Behavioral Interview Questions by Signal

Meta behavioral interview questions look like the questions every company asks. Tell me about a conflict with a teammate. What differs is the grading. Meta's interviewers, by consistent accounts, score a handful of signals rather than a list of named principles, and the question is only a prompt to get evidence for one of them. Candidates who prepare answers to questions do fine on the question and badly on the signal.

This is a question bank organized the way the interviewer thinks: by signal. Forty questions in seven groups, each with what a strong answer contains and a short sketch of one. For how the round fits in the loop and a four-week plan, read Meta's behavioral interview; for the six company values and questions built on them, read Meta's core values in the interview. Neither is repeated here.

How the round is graded

The behavioral round at Meta (informally the "Jedi" round, a nickname candidates widely report) is about 45 minutes of questions about your past work, with follow-ups that take at least as much time as your opening answers. The interviewer writes up what they heard against a set of signals, and the write-up is read alongside your coding and design rounds. Meta does not publish the rubric and the signal names differ between accounts, but feedback consistently clusters around seven dimensions:

  • Resolving conflict
  • Handling ambiguity
  • Growth and feedback
  • Scope and impact
  • Motivation and values
  • Collaboration and communication
  • Perseverance

Each interviewer typically carries three or four of these and probes until they have evidence or decide there is none. One story can serve two or three signals, but you need to know which, because the interviewer is deciding where to file it while you talk. The follow-up is the test: the opening question sets the signal, the follow-ups decide the grade. And every signal needs something concrete to write down, a number, a decision, a named change in behavior. "I am good at handling ambiguity" is not writable.

Resolving conflict

Conflict questions test whether you can disagree with someone and reach an outcome without a manager deciding for you. The interviewer wants a real disagreement with a real resolution, and will ask how fairly you can state the other person's view.

  1. Tell me about a disagreement with a peer where you were the one who changed your mind.
  2. Describe a time you and your manager wanted different things for the same project. How did it end?
  3. Tell me about a time another team's decision blocked yours. What did you do first?
  4. Describe a code review or design review that turned into an argument. How did you get to a decision?
  5. Tell me about a conflict you escalated. Why that moment, and not earlier or later?
  6. Tell me about working with someone whose style clashed with yours for months, not days.

What a strong answer contains: the other person's position stated well enough that they would agree with the summary; a mechanism that settled it (data, a prototype, an agreed criterion), not just persuasion; a decision that was reached and held; and something you took from their side. A story where you were right from the start scores low, because the interviewer cannot tell conflict resolution from stubbornness.

Sketch, invented, for question 4: a backend engineer disagrees with a peer in a design review about whether a new feature needs a second datastore. Instead of continuing in the comment thread, she proposes a one-day load test of the existing store at the projected traffic, and they agree in advance on the latency number that will decide it. The test passes with a schema change. The peer's worry about hot partitions turns out to be valid and shapes the schema. The decision closes in two days rather than two weeks of comments.

Handling ambiguity

Ambiguity questions test what you do when the problem is undefined, the data is missing, or the direction changes while you are mid-flight. The weakest answers describe waiting for clarity; the strongest describe creating it.

  1. Tell me about a project where the goal was unclear when you started. How did you decide what to build?
  2. Describe a time the data you needed did not exist. What did you do instead?
  3. Tell me about a time a reorg or a strategy change made your current work pointless.
  4. Describe a problem where the hardest part was deciding what the problem was.
  5. Tell me about a time you had to commit to a direction knowing you might be wrong.
  6. Tell me about a time you were handed a large, vague area and told to own it.

What a strong answer contains: the problem statement you wrote yourself and who you checked it with; the decision you made with incomplete information and what would have changed it; a correction made in the open when new information arrived; and a result you can measure against the definition you set. The interviewer is listening for structure imposed, not structure received.

Sketch, invented, for question 12: an engineer is given "notifications reliability" with no metric and no deadline. He spends the first week defining what unreliable means: three failure types pulled from support tickets, one metric (delivered within sixty seconds), and a quick instrument to measure it. The baseline comes out at about 91 percent. He gets the definition reviewed by two product managers before building, changes it once, sets a target of 99 percent for the quarter, and ships the first fix (a retry on one specific error class) in week three. The point of the story is the week of defining, not the fix.

Growth and feedback

Growth questions test whether you change your behavior when you learn something, including when the learning was unwelcome. Interviewers are calibrated to spot a failure that costs nothing and a lesson that changed nothing.

  1. Tell me about feedback you initially disagreed with and later acted on.
  2. Describe a skill you were weak at two years ago. How do you know you are better now?
  3. Tell me about a mistake that affected other people. What did you do in the first hour, and what did you change afterwards?
  4. Describe a time you asked for feedback and did not like the answer.
  5. Tell me about a time you realized your approach was wrong halfway through.
  6. What is the most recent thing you changed about how you work, and what triggered it?

What a strong answer contains: the feedback or failure stated plainly, with its cost; the specific change you made, not a resolution to try harder; and evidence from a later situation that the change stuck.

Sketch, invented, for question 13: a senior engineer is told in a review that her design documents are "hard to disagree with", meaning they present a decision rather than options. She reads it as a style preference. Two documents later a reviewer misses a flaw because the document never showed the alternative. She changes her template to list the rejected options and the reason for rejecting each, and in the following quarter reviewers catch two problems before build instead of after.

Scope and impact

Impact is the signal Meta is best known for, and it is the one where "we" answers fail fastest. The interviewer wants to know what moved, by how much, how you know, and which part of it was yours.

  1. Tell me about the work you have done with the largest measurable effect. How do you know the number is right?
  2. Describe a project you stopped because the impact did not justify the cost.
  3. Tell me about a time you chose between two projects. How did you compare them?
  4. Describe a time your work changed what another team did.
  5. Tell me about a time you delivered impact without writing much code.
  6. Tell me about a project whose result was smaller than you expected. What did you do with that?

What a strong answer contains: a metric with a baseline and the method of measurement; your share of it stated honestly; the reasoning you used to pick this work over other work; and, for senior candidates, impact that reached beyond your own team. A number you cannot defend under "how did you measure that?" is worse than an honest "we did not measure it, and here is what I would measure now".

Sketch, invented, for question 20: a product engineer stops a three-month personalization project at the six-week mark after an early experiment shows a lift of about 0.3 percent against the cost of a new serving tier. He writes a one-page stop memo with the experiment numbers and the projected cost, moves the two engineers on the project to a latency fix whose first change moves conversion more than the experiment did, and keeps the experiment data for a later attempt. Stopping was the impact.

Motivation and values

Motivation questions test whether you drive yourself or wait to be driven. The interviewer is looking for the problem nobody asked you to solve, and for an honest account of what kind of work you actually want.

  1. Tell me about a problem you took on that nobody asked you to.
  2. What do you do in your first week on a new team, before anyone has given you a task?
  3. Describe a time you kept pushing on something after your team had moved on.
  4. Tell me about work you found boring but did well anyway. Why did you bother?
  5. What kind of work makes you lose track of time, and when did you last do it?

What a strong answer contains: initiative with judgment, meaning you picked something that mattered rather than something that was fun; a result that others noticed; and self-knowledge about what you want to do more of. "I am passionate about technology" is not a motivation; "I keep ending up as the person who fixes on-call, this is the third time" is.

Sketch, invented, for question 25: a mid-level engineer gets paged at two in the morning and finds the runbook for the alert is two years out of date. Nobody owns runbooks. She rewrites the pages for the three noisiest alerts over two Fridays, adds a CI check that fails when a new alert has no runbook link, and tracks time to acknowledge over the next two months, which falls by roughly a third. She tells her manager after the first page is done rather than asking permission first, and says why.

Collaboration and communication

Collaboration questions test whether you make other people more effective and whether you can be understood by people outside your specialty. The interviewer is also grading how you tell the story: a clear three-minute answer is itself evidence.

  1. Tell me about explaining a technical decision to someone who did not have the background to judge it.
  2. Describe a time you changed how you communicate because the first way was not working.
  3. Tell me about helping someone on your team get unstuck without taking the work over.
  4. Describe a time you had to deliver bad news about a project to people who did not want to hear it.
  5. Tell me about working with a team in another time zone or office. What broke, and what did you fix?
  6. Tell me about a time you brought in someone else's expertise instead of working it out yourself.

What a strong answer contains: the other person's goals, not just yours; a specific change in how you communicated and what it produced; credit given accurately; and, for senior candidates, a team or partner that worked better afterwards because of a structure you set up.

Sketch, invented, for question 33: a tech lead learns ten days before a launch that a partner team's dependency will slip by a month. Instead of a hopeful status update he writes three options (launch without the feature, delay the launch, build a stub and swap it later) with the cost of each, sends it to the product manager and the partner team the same afternoon, and recommends the stub. The group picks the stub, the launch ships on time, and the full feature follows a month later.

Perseverance

Perseverance questions test what you do when the work is slow, blocked or unrewarding. The interviewer wants to see that you kept going for a reason, and that you knew the difference between persisting and refusing to update.

  1. Tell me about the longest you have worked on a single problem before it worked.
  2. Describe a time a project was cancelled or paused and later came back. What did you do in between?
  3. Tell me about a time you were told no and asked again. What changed in your second attempt?
  4. Tell me about a bug or incident that took days to understand. How did you keep going?
  5. Describe a time you had to deliver with a team that was shrinking or demoralized.

What a strong answer contains: the reason you persisted, stated as a judgment about value rather than pride; the method that kept you moving (a log, a smaller goal, a different angle); the point at which you would have stopped; and what the persistence produced. The interviewer will ask what you would have done if it had not worked, and "the same thing for longer" is the wrong answer.

Sketch, invented, for question 39: an engineer chases an intermittent data corruption that shows up about once a day and never under a debugger. She keeps a dated log of every hypothesis and what ruled it out, adds a tripwire that captures state at the moment of corruption, and after four days finds a race between a retry path and a cache write. The log goes into the postmortem so the next person does not repeat the dead ends, and the tripwire stays in production, where it catches an unrelated bug a month later. She also says when she would have escalated: day five.

The values questions

Two questions sit outside the signal groups and almost always come up: "why Meta?" and some form of "what do you value most about how Meta works?" They are graded on motivation and values, and they fail in one specific way: candidates recite the website back to the people who wrote it.

Answer with evidence from your own work instead. Name one thing about how Meta operates that matches how you already work, give the story that proves it, and say what you expect to be harder about it here than where you are now. "I ship behind flags and roll back within the hour, and I want to do that at a scale where the rollback matters" is an answer. "I am excited by Meta's mission" is not.

The core values guide gives you the vocabulary; do not quote it back.

How level changes the bar

Meta does not publish its level definitions, and the round is graded against the level you are being considered for. The same question earns a different grade at each level because the interviewer expects a different scope of story. The pattern candidates and former interviewers describe, in broad strokes:

Level Scope of your strongest stories Ambiguity you are expected to handle Influence the interviewer wants to see
E4 A feature or component you owned end to end Unclear requirements inside a defined project Your own team: peers and your manager
E5 A project spanning a team or a quarter, with trade-offs you chose An undefined problem you turned into a plan Adjacent teams, product partners, decisions others followed
E6 A system or area across several teams, over more than one quarter A direction set without anyone framing the problem for you Organization level: standards, and other engineers made more effective
Manager A team's results and health, not your own output Reorgs, shifting priorities, people problems with no clean answer Up and across: your manager's peers, partner organizations, your reports' growth

If every story you have is a level below your target, the interviewer does not round up; they recommend the lower level. At E6 and for managers, stories about your own output stop counting for much; the interviewer wants stories where your decisions changed what other people did. The staff engineer interview guide and the engineering manager interview guide cover those bars in detail.

Mistakes that cost the round

  • Answering the question you prepared instead of the one asked. Question 1 asks for a time you changed your mind; a story about convincing someone else fails it, however good the story.
  • One story for every signal. Interviewers notice the third time the same project appears. Eight to ten stories is the working minimum.
  • The villain story. A conflict story where the other person was unreasonable and you were patient tells the interviewer you cannot describe a disagreement fairly.
  • Hiding the negative result. A project that missed is a fine story if you know why and what you did next. Dressing it as a success invites the follow-up that exposes it.
  • Treating "why Meta" as a warm-up. It is graded, and it is often the first question, so it sets the interviewer's expectation for the rest.
  • A growth story with no later evidence. "I learned to communicate earlier" is a claim. The interviewer wants the next story where you did.

Where coaching fits

The fastest way to find out which of these forty you cannot yet answer is to be asked them out loud by someone who follows up. The free practice interview on techinterview.coach does that with an AI interviewer: choose the behavioral round, paste the Meta job ad so the questions are grounded in it, and read the written recap to see which stories carried a signal and which collapsed under the second question. It is free; sign in with LinkedIn. When the recap keeps naming the same gap, a coach who has graded behavioral rounds can hear the problem in one session and give you written feedback in the form an interviewer would write. Browse the behavioral interview coaches by company history.

Related guides