← Ramp Interview Insights

Ramp·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say
Jun 2026

Summary

Ramp SWE interview had a web crawling problem that started reasonable and then kept getting messier with each follow-up. The base question was fine but the auth key chaining bit caught me off guard.

Questions Asked (2)

Q1

Given a starting URL for a web-based maze where each URL is a room, write a function that performs BFS or DFS over HTTP requests to find whether any reachable room is an exit. Return the exit URL or None if no exit exists. You must handle cycles.

Algorithms & Data StructuresAPI & Integrations
Author's notes

The cycle-handling part I got immediately, just a visited set on URLs.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the problem: each URL is a room, and we need to traverse via HTTP requests to find an exit. Use BFS or DFS with a visited set to avoid cycles, making HTTP requests to fetch room contents and extract links. Return the exit URL if found, else None.

Pro tip: Mention that you would use a queue for BFS (or stack for DFS) and a set for visited URLs, and that you would handle HTTP errors and timeouts gracefully, possibly with retries or a session object for efficiency.

1. Clarify requirements and assumptions

Ask about the format of the room content (e.g., HTML with links), how to identify an exit (e.g., a specific marker), and whether the starting URL is guaranteed to be valid. Confirm that cycles are possible and must be handled.

2. Choose traversal strategy

Decide between BFS and DFS. BFS is often preferred for finding the shortest path to an exit, but DFS uses less memory. Either works; state your choice and rationale.

3. Implement traversal with cycle detection

Use a queue (BFS) or stack (DFS) to manage URLs to visit, and a set to track visited URLs. For each URL, make an HTTP GET request, parse the response to extract links, and check if the current room is an exit.

4. Handle HTTP and parsing details

Use an HTTP library (e.g., requests in Python) to fetch pages. Parse links using an HTML parser (e.g., BeautifulSoup) or regex. Handle errors (timeouts, non-200 status) by logging and skipping or retrying.

5. Return result and discuss optimizations

Return the exit URL as soon as it's found, or None if traversal completes without finding one. Mention potential optimizations like concurrent requests, caching, or respecting robots.txt.

Key Points to Mention

  • Use a visited set to avoid infinite loops due to cycles.
  • Choose BFS for shortest path or DFS for memory efficiency; justify your choice.
  • Make HTTP requests efficiently, possibly using a session to reuse connections.
  • Parse HTML to extract links; handle relative URLs by joining with base URL.
  • Handle HTTP errors and timeouts gracefully; consider retries or skipping.
  • Return the exit URL immediately upon discovery; otherwise return None after traversal.

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

Q2

Extend your maze-solving function to handle 503 responses with limited retries, and 401 responses by capturing authorization keys from successful room responses and forwarding them in subsequent requests.

API & IntegrationsTechnical Trade-offsSystem Design
Author's notes

This is where it got interesting and kind of messy.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, such as retry limits and backoff strategy, then outline a modular design that separates error handling from core maze logic. Explain how you would capture and store authorization keys from successful responses and inject them into subsequent requests, while ensuring thread safety and avoiding infinite loops.

Pro tip: Mention that you would use exponential backoff with jitter for 503 retries to avoid thundering herd, and that you would treat 401 as a signal to refresh credentials rather than retry immediately. Also, highlight the importance of logging and monitoring to detect patterns in failures.

1. Clarify requirements and constraints

Ask about retry limits, backoff strategy, and whether authorization keys are per-session or per-user. Confirm if the maze-solving function is synchronous or asynchronous.

2. Design error handling for 503

Implement a retry mechanism with exponential backoff and a maximum retry count. Ensure that retries are idempotent and do not cause duplicate side effects.

3. Handle 401 by capturing and forwarding auth keys

Extract authorization keys from successful room responses and store them securely. On 401, refresh the key if possible or fail gracefully, and forward the key in subsequent requests.

4. Integrate with maze-solving logic

Wrap the maze-solving function with a request handler that applies the retry and auth logic. Ensure that the core algorithm remains decoupled from HTTP concerns.

5. Test and monitor

Write unit tests for retry and auth scenarios, and add logging/metrics to track retry counts and auth failures. Consider circuit breakers for repeated failures.

Key Points to Mention

  • Exponential backoff with jitter for 503 retries to prevent overwhelming the server
  • Idempotency of requests to safely retry without side effects
  • Secure storage and forwarding of authorization keys, avoiding hardcoding
  • Handling 401 by refreshing tokens or re-authenticating, not just retrying
  • Decoupling HTTP error handling from core maze-solving logic for maintainability
  • Observability: logging, metrics, and alerting for retries and auth failures

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