Forward-deployed engineer at Ramp

As asked

A strategic customer says, 'We need a dashboard for operations', but cannot describe the workflow clearly. How do you get from that request to a useful shipped solution?

Sample answer outline

A strong forward-deployed engineer starts by observing the actual work, not collecting a feature wishlist. They identify the users, decisions, source systems, failure modes, and business metric the workflow should improve. The first version should be narrow enough to ship quickly, usually a thin vertical slice with real data and a clear owner on the customer side. The candidate should discuss expectation management, security review, data access, and how the learning feeds back into the core product. A common mistake is becoming a bespoke consultant and building a one-off surface that cannot be maintained.

Expect these follow-ups

• How do you tell whether this should become core product?
• What do you do when the executive buyer and daily users disagree?
• How do you avoid committing to a custom roadmap in the room?

As asked

A customer calls saying their integration stopped returning data an hour ago. No errors in their logs. Walk me through exactly how you diagnose this, starting from zero context.

Sample answer outline

Strong answers work outward from the symptom: check the customer's request shape, then the API gateway logs, then the upstream service logs, correlating by trace ID or timestamp. Candidates should mention reproducing the exact request locally or via curl, verifying auth tokens haven't expired, and checking whether a recent deploy or config change correlates with the failure window.

Expect these follow-ups

• How would your approach differ if the customer is in a timezone 8 hours ahead and you can't get them on a call?
• What do you add to the API response to make this kind of debugging easier next time?

As asked

You are building the outbound webhook system for a B2B product. A customer's endpoint goes down for 45 minutes. What does your retry strategy look like, and how do you prevent thundering herd when their server comes back up?

Sample answer outline

A strong answer covers exponential backoff with jitter, a max retry window (commonly 24 to 72 hours), dead-letter queuing for events that exhaust retries, and a status endpoint or notification so the customer knows what they missed. Thundering herd prevention means staggering retries across customers, not replaying all backlog events at once when the endpoint recovers.

Expect these follow-ups

• How do you handle idempotency so replays don't cause double-processing on the customer side?
• What do you tell the customer if 3 hours of events are lost because their endpoint was down longer than your retry window?

As asked

You are writing a data pipeline that polls a third-party API using OAuth2. Access tokens expire in 1 hour. How do you handle token refresh without breaking the pipeline or racing across multiple workers?

Sample answer outline

Candidates should describe proactive refresh (refresh before expiry, not on 401) using the expires_in field, storing the refresh token securely (not in plain env vars), and using a distributed lock or a single token-manager process to avoid multiple workers simultaneously refreshing. Strong answers also handle the case where the refresh token itself has expired, triggering a re-auth flow with alerting.

Expect these follow-ups

• How do you store the refresh token if this pipeline runs in a Kubernetes job with ephemeral containers?

As asked

A customer says their weekly summary report takes 4 minutes to load. It used to be 30 seconds. The report runs a single SQL query across 3 joined tables. Walk me through how you find and fix the regression.

Sample answer outline

Start with EXPLAIN ANALYZE to identify sequential scans or hash joins on large tables. Check whether indexes exist on the join columns and the WHERE clause predicates. Look for data volume growth (did the customer's dataset grow 10x since the query was written?). Fixes might include adding a composite index, rewriting a correlated subquery as a join, or adding a materialized view for the aggregation. Candidates should also mention query plan caching and statistics freshness (ANALYZE in Postgres).

Expect these follow-ups

• What if adding the index makes writes noticeably slower for this customer? How do you present that tradeoff?
• How do you prevent this from happening to other customers whose data will eventually reach the same size?

As asked

A customer emails you: 'Your API works in Postman but fails in our browser app with a CORS error.' What are the specific steps you take to diagnose and fix this?

Sample answer outline

The candidate should distinguish simple vs. preflighted requests (POST with JSON triggers preflight). Diagnosis: inspect the browser DevTools Network tab for the OPTIONS preflight and check the response headers. The fix is ensuring Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers match what the customer's frontend sends. Wildcards don't work with credentials. Strong candidates also mention that Postman bypasses CORS because it is not a browser.

Expect these follow-ups

• How do you set this up so internal dev, staging, and production all behave correctly without hard-coding origins?