Two minutes into the second coding round of my Meta E5 backend onsite, the interviewer dropped a graph problem and I felt my chest tighten. Not because the problem was unfamiliar. The opposite. I had solved this exact shape twice in mocks the week before. That recognition, which should have been an advantage, was the thing that broke me. I wrote bad code for the next 35 minutes and the round ended with a no-hire. The packet came back as rejection a week later. I want to write down what actually happened, because the failure mode was specific enough that I think I can describe it in a way that another candidate can use.

What I expected the round to look like

The E5 onsite at Meta in 2024 was four rounds: two coding (45 min each), one system design, one behavioral. The two coding rounds are independently scored and the panel needs both at hire or above for the packet to clear. I had practiced for both coding rounds with a heavy emphasis on the kind of medium-hard graph and tree problems that the public prep guides flag for this loop. By the time I walked in, I had done about 40 mock-style problems in three weeks, with a partner critiquing me on each one.

The first coding round went cleanly. Standard medium problem, I solved it in 25 minutes, follow-up in 10, the interviewer seemed positive. I left round one feeling calibrated.

The specific way round two went wrong

Round two was a graph reachability problem. Not exactly a problem I had seen, but the shape was familiar enough that within 90 seconds I had pattern-matched to two different mock problems and was trying to choose between them. That was the first failure: I tried to choose between memorized solutions instead of working the problem. The interviewer asked a clarifying question (specifically about edge weights) that I half-heard, because I was running through the two memorized solutions in my head, and I gave a wrong-shaped answer that committed me to the harder of the two.

For the next ten minutes I implemented the harder solution, increasingly aware that the code was not coming together. The interviewer asked, gently, if I wanted to walk through the problem from scratch. I said yes and re-stated the problem, but I did not actually re-derive the solution. I kept the harder solution in my head and tried to patch it. By minute 25 my code did not compile. By minute 35 it compiled but was wrong on the second test case. By minute 40 I had reverted to a simpler approach and was racing the clock. I produced a solution at minute 43 that was correct on the small case but had the wrong asymptotic behavior on the constraints the interviewer had stated up front.

The round ended with a polite "thanks for your time." I knew it was over.

The problem and the answer I should have written

I cannot reproduce the exact prompt without violating the spirit of anonymization, but the shape was: given a directed graph with edge constraints, find whether a target is reachable from a source under a per-traversal budget. The right approach is a modified BFS where the state is (node, remaining_budget) and you cache visits keyed on that tuple. I knew this. I did not write it.

The code I should have written, in around 20 minutes:

from collections import deque

def reachable_within_budget(graph, source, target, budget):
    # State: (current node, remaining budget). BFS over states.
    seen = set()
    queue = deque([(source, budget)])
    while queue:
        node, remaining = queue.popleft()
        if node == target:
            return True
        if (node, remaining) in seen:
            continue
        seen.add((node, remaining))
        for neighbor, edge_cost in graph[node]:
            if edge_cost <= remaining:
                queue.append((neighbor, remaining - edge_cost))
    return False

This is 12 lines. It is the answer I have written, in mocks, more than once. The failure was not knowledge. The failure was that I tried to retrieve a memorized solution instead of solving the problem in front of me.

The actual lesson, which is not the one I expected

When the recruiter called with the rejection, I assumed the lesson was "do more graph problems." That was not the lesson. I had done plenty of graph problems. The recruiter, off-script, said something I have thought about a lot since: "The panel's note was that you knew the material and got tangled in retrieval. They suggested you work on starting from the problem rather than from your memory."

That note is the lesson. The failure mode is not under-preparation. The failure mode is over-preparation in a shape that encourages pattern-matching against memorized solutions, when the round rewards re-deriving the solution from the problem statement. The two activities feel similar in mocks (you arrive at the right answer, the interviewer is happy) and they are different in the real round, where the time pressure surfaces the difference.

What I changed before the next loop

I did three things differently for the next big-tech loop I sat. First, I started every mock by re-stating the problem in my own words, with the constraints written down as bullets, before I started thinking about a solution. That habit forced me to engage with the actual problem rather than the rhyme-shape of a problem. Second, I cut my mock volume in half and replaced it with deeper analysis of fewer problems, where I would solve a problem, then deliberately solve it a second way, and force myself to articulate which solution I would use under what constraints. The second-way habit broke the muscle memory that had locked me into the wrong solution at Meta. Third, I added a 90-second rule: in the first 90 seconds of any round, I do not allow myself to write code. I write the constraints, I write the candidate approaches, I name the one I am picking, and only then do I start typing.

I cleared a comparable senior backend loop at a different big-tech company three months later. The first round was similar in shape to the round I had bombed at Meta. I solved it cleanly. The 90-second rule was the difference. The rejection at Meta was the lesson, and the lesson was specific: practice retrieving solutions and you will pass mocks; practice re-deriving solutions and you will pass the real round.