Chariot·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

Interviewed for a software engineering role at Chariot and got a coding round built around HTTP-based maze traversal. Two parts: a cleaner BFS problem first, then a messier follow-up with retries, locked doors, and key collection. The kind of problem that feels manageable until you're actually writing it.

Questions Asked (2)

You're given an HTTP API representing a maze. Starting from a fixed endpoint, write a program that explores locations by making GET requests and stops when it finds the exit, printing its id. Use breadth-first search to prefer shallower paths, and handle cycles.

Algorithms & Data StructuresAPI & Integrations

Author's notes

BFS over HTTP is a slightly unusual framing but the mechanics are the same as graph traversal, just with network calls instead of an adjacency list.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Model the maze as a graph where each location is a node and GET requests reveal neighbors. Use BFS with a queue and a visited set to explore level by level, avoiding cycles, and stop when the exit is found. Print the exit's id and ensure the solution is efficient and handles API errors gracefully.

Pro tip: Before coding, clarify the API response format and whether the exit is identified by a specific field or status code. Also, consider rate limits and implement retry logic for robustness.

1. Understand the API and maze structure

Inspect the API documentation or sample responses to determine how to get the start location, how neighbors are represented, and how the exit is indicated. Clarify if the maze is directed or undirected.

2. Design the BFS algorithm

Use a queue to track locations to visit, starting with the fixed endpoint. Maintain a set of visited location ids to avoid cycles. For each location, make a GET request to retrieve its neighbors.

3. Implement exploration and exit detection

While the queue is not empty, dequeue a location, check if it's the exit (based on API response), and if so, print its id and terminate. Otherwise, enqueue all unvisited neighbors and mark them as visited.

4. Handle edge cases and errors

Account for API failures, timeouts, or rate limits by adding retries or backoff. Also handle cases where the exit is unreachable or the start is the exit.

5. Test and optimize

Test with small mazes and verify BFS order. Consider optimizations like caching responses or parallel requests if allowed, but prioritize correctness.

Key Points to Mention

Breadth-first search ensures shortest path in terms of number of requests.
Use a visited set to prevent infinite loops due to cycles.
Handle API errors and rate limiting with retries and exponential backoff.
Clarify the exit condition from the API response (e.g., specific field or status).
Consider memory usage for large mazes; BFS queue can grow large.
Print the exit id immediately upon discovery and terminate the program.

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

Extend your maze-solving program to handle transient server errors (500/502/503 with retries), locked doors that require specific keys, and locations that provide keys. Your program should collect keys as it explores and revisit previously blocked paths once the right key is available.

API & IntegrationsAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

This is where I started sweating.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, then outline a modified BFS/DFS that tracks collected keys and revisits blocked paths when new keys are acquired. Emphasize robust error handling with retries and idempotency, and discuss trade-offs between different traversal strategies.

Pro tip: Treat the maze as a state-space search where the state includes both position and key set; this avoids infinite loops and ensures completeness. Also, implement retries with exponential backoff and jitter to handle transient errors gracefully.

1. Clarify requirements and constraints

Ask about the maze representation, error rates, retry limits, and whether keys are reusable. Confirm if the goal is to find any path or the shortest path.

2. Design the state representation

Define state as (position, keys_collected) to handle locked doors. Use a set or bitmask for keys and a visited set to avoid revisiting the same state.

3. Implement robust API calls with retries

Wrap server calls in a retry mechanism with exponential backoff and jitter for 500/502/503 errors. Ensure idempotency to avoid duplicate actions.

4. Modify traversal to handle keys and locked doors

Use BFS/DFS to explore; when encountering a locked door, if the key is held, proceed; otherwise, record the door's location and revisit when the key is acquired.

5. Test and discuss trade-offs

Test with scenarios like multiple keys, dead ends, and persistent errors. Discuss trade-offs between BFS (shortest path) and DFS (memory), and between retry strategies.

Key Points to Mention

State-space search with (position, keys) to handle locked doors and avoid cycles.
Retry logic with exponential backoff and jitter for transient server errors.
Idempotency of API calls to prevent duplicate side effects during retries.
Data structures: queue for BFS, stack for DFS, set/bitmask for keys, visited set for states.
Revisiting blocked paths: store locked doors and re-evaluate when new keys are collected.
Trade-offs: BFS vs DFS, retry limits, and handling of persistent errors.

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