Meta Production Engineer OA Interview Experience (2026) - Powers of k, Orchard Rot, Lamp Coverage, Offer

Problem: You are monitoring a smart grid. You are given an array of integer energy readings and a base k . Count how many readings are exact non-negative integer powers of k , meaning expressible as k raised to some non-negative integer exponent. For k = 2 and readings [2, 4, 7, 8, 16, 32, 120] , the answer is 5 because 2, 4, 8, 16, 32 all match.

There are two clean approaches. The naive path is O(readings.length squared) and the statement explicitly greenlights it: for each reading, try dividing by k repeatedly and check that you land on exactly 1. The cleaner path is to pre-enumerate all powers of k within the max possible reading value, store them in a set, and then do a one-shot membership test for each reading. That gives you linear time in the input plus a tiny logarithmic factor for enumerating powers.

The trap on this one is k = 1 . Every power of 1 is 1, so any reading equal to 1 is a power of 1 but no other value is. Handle that as a special case up front. I also guarded k = 0 as undefined and returned the count of zero-valued readings, which is defensible but probably not tested.

Meta's practice catalog has a good counting-family problem that sits close to this one in structure.

Practice it: [[problem/54?company=2|Subarray Sum Equals K]]

Round 2 — Orchard Rot Simulation

Problem: A 2D grid orchard has cells marked - (empty), T (healthy tree), or R (rotten tree). Each day rot spreads from every rotten cell to all healthy trees orthogonally adjacent. Given an integer days , return the orchard state after exactly that many days. The statement is explicit that O(days rows cols) is acceptable.

This is multi-source BFS layered over time, which is a dead-ringer for the "Rotting Oranges" family. Collect all initially rotten cells into a queue, then peel off one full layer per day. Each iteration drains whatever is in the queue at the start of the step, turns each healthy neighbor rotten, and enqueues the newly rotten cells. Stop after days iterations, or earlier if the queue empties.

The wrinkle that caught me on a practice run was the stop condition. The problem wants the exact state after days steps, even if rot has already finished spreading at day five and you were asked about day ten. So the loop has to run days iterations regardless, gracefully exiting early only when the queue is empty. I botched this on my first attempt and returned a fully-rotten orchard on a test case where two healthy trees were actually unreachable.

Also beware of the mutable-grid bug: if you write a list of lists in Python and do [[char] cols] rows you will get aliased rows that all mutate together. Use a comprehension.

Practice it: [[problem/61?company=2|Walls and Gates]]

Round 3 — Lamps Illuminating Points on a Number Line

Problem: You are given lamps[i] = [l, r] where each lamp illuminates the inclusive segment [l, r] on a number line, and points[j] is a list of query positions. For each point, return how many lamps cover it.

Three approaches with different tradeoffs. The quadratic approach checks every lamp against every point and is fine when both inputs are small. The sweep-line approach creates events at every l (start) and r + 1 (end) endpoint, sorts them, then scans left to right tracking the active lamp count and answering each point query along the way. The coordinate-compression + difference-array approach is the fastest for tight constraints: build a delta array where you increment at every l and decrement at every r + 1 , prefix-sum it to get the active count at every position, and look up each query in O(1) .

I wrote the sweep-line version because I trust myself to not mess up sort stability in Python. Runtime is O((N + M) log (N + M)) dominated by the sort. The gotcha: if a lamp's r equals a point's x , that lamp still covers the point. I missed this on first pass, used a strict-less comparison on the end-event, and failed two hidden tests until I switched to r + 1 as the end boundary.

PE loves interval-counting shapes like this because operationally they look like "how many nodes were up at timestamp X" problems. The practice piece closest in shape:

Practice it: [[problem/62?company=2|Employee Free Time]]

Result

I finished all three with about eight minutes to spare and did one pass of hand-crafted edge cases: empty arrays, k = 1 , days = 0 , zero lamps covering any point. The phone screen was scheduled six days later, and after a full onsite three weeks after that I had an offer in hand. PE L4-equivalent band.

Tips

1. Practice multi-source BFS until the layer-peel feels automatic. Every PE OA I have seen or heard about includes one simulation problem with a layered-spread flavor. Rot, fire, flooding, infection: the variants are endless and the pattern is identical.
2. Read the complexity hint in the problem. Meta's PE statements explicitly tell you "a quadratic solution will fit." If you see that note, do not waste minutes on a clever log-factor optimization. Write the quadratic, ship it, move on.
3. Pre-enumerate powers for base-`k` problems. Linear-time membership beats repeated division, and it sidesteps floating-point pitfalls entirely. `k = 1` is the single special case, handle it first.
4. Use coordinate compression or sweep-line for interval-coverage problems. The quadratic approach is allowed by the statement but the sweep-line version is cleaner to debug and finishes faster even at moderate input sizes.
5. PE problems are not SWE problems. The setting is operational. Your solution will be read as "could this person stay on-call." Name variables like `rotten_cells`, `active_lamps`, `day_index`. The reviewer notices.
6. Keep a local `scratchpad.py` open for quick arithmetic checks. Verifying `230 < 109` takes three seconds in a Python prompt and can save you from a subtle overflow or edge-case miss.