Meta·Software Engineer·Onsite - Coding / Algorithms·Intermediate

IntermediatePrefer not to say

Apr 2026

Summary

Meta SWE coding round with a maze pathfinding problem that added a twist I wasn't fully prepared for. The core BFS logic wasn't the hard part, it was correctly wiring in the directional cell constraints without breaking existing movement rules.

Questions Asked (1)

You have a maze grid with standard movement rules. Now add two special one-way cell types: one that can only be entered moving left-to-right, and one that can only be entered moving right-to-left. Modify the existing move validation logic so BFS pathfinding correctly respects these constraints and passes unit tests. Grid size up to 200x200, four-directional movement.

Algorithms & Data StructuresTechnical Trade-offs

Author's notes

My first instinct was to just bolt the directional check onto the existing canMove function, but I kept second-guessing myself on which direction counts as 'entering' versus 'leaving'.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the exact movement rules for the special cells, then design a move validation function that checks both the destination cell type and the direction of entry. Integrate this function into BFS, ensuring that each neighbor is only enqueued if the move is valid, and handle edge cases like starting on a special cell.

Pro tip: Emphasize that the direction constraint applies to entering the cell, not leaving it, and that the start cell is exempt from entry constraints. This shows attention to detail and prevents off-by-one errors in unit tests.

1. Clarify rules and edge cases

Ask clarifying questions to confirm: Can you leave a special cell in any direction? Is the start cell exempt from entry constraints? What about the goal cell? These details are critical for correct implementation.

2. Design move validation

Create a function isValidMove(from, to, direction) that checks: destination is within bounds, not a wall, and if it's a special cell, the direction matches the allowed entry direction.

3. Integrate with BFS

Modify BFS to use isValidMove when exploring neighbors. For each direction, compute the neighbor and only enqueue if the move is valid. Ensure visited tracking prevents cycles.

4. Handle start and goal

Explicitly handle the start cell: it can be any type and is not subject to entry constraints. For the goal, if it's a special cell, the final move must satisfy its entry constraint.

5. Test and validate

Write unit tests covering: normal moves, blocked moves by special cells, valid entries, invalid entries, start on special cell, goal on special cell, and large grid performance.

Key Points to Mention

Direction of entry is determined by the move vector (e.g., moving right means entering from the left).
Special cells only restrict entry; leaving them is unrestricted unless otherwise specified.
The start cell is exempt from entry constraints because there is no incoming move.
BFS remains O(N*M) time and space, with N,M up to 200, so performance is fine.
Use a visited set or 2D array to avoid revisiting cells and infinite loops.
Unit tests should cover all combinations of cell types and movement directions.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.