Top Tech Transition Enroll now

Real Interview Experiences

Learn what to expect, straight from candidates who've been through it at top tech companies.

908 interviews243 companies286 offers
Loading experiences…

Browse by company

Browse by role

← Back to all experiences

Meta Software Engineer, Product Interview Experience

Meta · Mid level · Software Engineer

I think I was one of the first people to take Meta’s AI round, and the models I had were really bad, like ChatGPT mini. I tried asking for test cases and it would just spit out something completely wrong.
ResultRejected
Timespan2 months
DifficultyMedium
Rounds4

Interview process

I got into Meta through a referral, and the recruiter reached out quickly. The process was recruiter chat, then a pre-onsite package with CodeSignal, a live technical screen, and a weird multiple-choice engineering philosophy questionnaire, and then about a month later the onsite with DSA, system design, behavioral, and the AI-enabled coding round. Honestly, Meta gave me the best prep materials of any company I interviewed with: a long prep PDF, portal videos, mock system design resources, and even a practice environment for the AI round. Most of the coding questions were exactly the kind of stuff people tell you to study in the Meta-tagged LeetCode list, so I never felt like they were hiding the ball. I didn't get the offer, and I think the system design round was what sank me because I expected distributed systems and got an API-design style chess problem that I handled in a really unorganized way.

Interview rounds · 4

  1. 1

    Recruiter screen

    Behavioral

    I got in through a referral and the recruiter reached out really fast. It was more of a match-fit call than an evaluative screen, and at that point they told me the open roles they had were in Menlo Park.

    1. Q1. What kind of role do you want to interview for?
      How they answered

      I told them I was targeting the product-focused software engineer role. The call didn't feel like I was being judged much. It was mostly figuring out what kind of role I wanted and getting me started in the process.

  2. 2

    Online assessment

    CodingTechnicalBehavioral

    My first real batch was unusual because it came as a package: a CodeSignal exercise plus a separate multiple-choice questionnaire that felt like an engineering philosophy check. Both were pretty practical and gave me an early sense that Meta had this process very standardized.

    1. Q1. I got a progressive file system style CodeSignal where I had to extend or fix functions in an existing codebase.
      How they answered

      It wasn't LeetCode-style at all. I was working in real files, changing functions in an existing codebase, and there were tests in another file. It reminded me a bit of those banking-system style questions. I remember dictionary-style operations like adding and removing values, then sorting them lexicographically, and then a TTL piece where you associate items with an expiration and access them based on that.

      Follow-up questions
      • One step had me sort things in lexicographical order.
      • Another step added a time-to-live requirement for items in the system.
    2. Q2. What do you prioritize when you submit code or when you have a tight deadline?
      How they answered

      This one was all multiple choice, around 25 minutes, and it felt like Meta was checking my engineering preferences more than my personality. A lot of it was basically speed versus safety, how I work with teammates, and what I prioritize in delivery. I remember getting annoyed because some questions forced one answer when I really wanted to pick two. I answered with Meta's culture in mind because I already had a sense of what they value.

      Follow-up questions
      • Pick one option even if two of them feel right.
  3. 3

    Phone screen

    Data Structures & AlgorithmsCodingTechnical

    The live technical screen was very Meta in the sense that they wanted speed, but also a really clear explanation before code. The interviewer emphasized talking through the approach and time and space complexity up front, then doing a dry run to catch bugs.

    1. Q1. Is this a valid palindrome?
      How they answered

      Before I coded, I talked through the approach and complexity because that was clearly important to them. I also started by asking clarifying questions and writing out test cases, like whether spaces should count or be skipped. That helped surface prompt constraints early, which I think was useful signal for them.

      Follow-up questions
      • How would you handle it if you could change one or two elements?
    2. Q2. Vertical level order traversal of a binary tree.
      How they answered

      I treated this the same way: explain first, give time and space complexity before touching code, then implement and dry run carefully. My impression was that they did care whether the solution actually held up, even if you had to catch issues by reasoning through it instead of just running it.

  4. 4

    Final / onsite round

    Data Structures & AlgorithmsCodingSystem DesignBehavioralArtificial IntelligenceTechnical

    The onsite was four interviews: one DSA round, one system design, one behavioral, and the new AI-enabled coding round. The AI round was collaborative and interesting, the behavioral was very transactional, and the system design was the one that really threw me.

    1. Q1. Solve this maze traversal problem and use the AI tools however you normally would.
      How they answered

      The problem was basically BFS on a maze with obstacles, and it was level-based so each level added more requirements. I tried using the provided model for things like summarizing the codebase and making sample test cases, but the models I had were bad enough that they gave wrong answers. At one point I had AI add a variable into my BFS and I checked it quickly, and the interviewer stopped me and asked what the new code did. I explained exactly what changed and why, and after that I kept AI usage minimal and solved it mostly myself.

      Follow-up questions
      • What does this new code do?
    2. Q2. Design an online chess game.
      How they answered

      This was the round that caught me off guard. I had prepared for distributed systems, and instead he immediately narrowed it to API design, which threw me. I went down the path of storing moves so you could replay the game later, almost like watching it back, and then he asked about undoing a move. I struggled because I hadn't seen that pattern before, but eventually I got to the idea of storing an undo move to support replay and reversal. My real problem was that I was unorganized in how I presented things, so even when I got somewhere reasonable I don't think I projected confidence.

      Follow-up questions
      • Let's not think about distributed design. Just focus on the API design.
      • How would you handle undoing a move in the backend?
    3. Q3. Find a minimum element, basically a variation of the peak element problem.
      How they answered

      I solved it as a binary search variant where I keep moving down the slope until I reach a minimum. Compared to the system design round, this one felt much more in line with what I had prepared for.

    4. Q4. Solve a sliding window problem based on character frequencies inside a window.
      How they answered

      I remember this one as a character-frequency sliding window question where you track counts in a window and return something based on the window with the most distinct characters. I got to the one-pass solution for it.

    5. Q5. Tell me about working across multiple projects and juggling priorities.
      How they answered

      The behavioral felt very transactional. It was basically question, answer, next question, with very little probing. The biggest theme I remember was around juggling multiple projects, and I had to explain that in my current job I was mostly working on one main project with systems inside it, so there was probably some cultural mismatch there. They ended the round after about 30 minutes and said they had enough signal.

      Follow-up questions
      • Can you give a stronger example?

Tips from the candidate

I'd tell a friend to actually trust how open-book this process is and use every prep thing they give you, because Meta is unusually transparent. I would 100 percent do mock interviews, especially for system design, because just reading and watching videos was not enough for me. In the coding rounds, I would start by writing test cases and asking constraint questions, because they care about how you think before you code and they do want you to catch issues in a dry run. Also, if you get the AI round, don't blindly trust the model output. If you use AI, be ready to explain every line it gave you in plain English.

Company culture

My read was that Meta is extremely optimized and standardized right now. They felt more transparent than any other company I talked to, and I genuinely got the impression they want candidates to succeed because they hand you a ton of prep material instead of making you guess. At the same time, they seem very focused on speed and on whether your engineering instincts match their environment, which is probably why that questionnaire exists before the onsite. The interviewers themselves didn't feel adversarial to me. Even the AI round felt collaborative, like they wanted to see how I worked with the codebase and whether I could sanity-check AI instead of copy-pasting blindly.

Details

CompanyMeta
RoleSoftware Engineer
LevelMid level
LocationUnited States
InterviewedNov 2025
Questions asked10