Ramp · Primly Community

Ramp data engineer interview, pipelines and SQL

ds_dmitri · 4 replies

Interviewed for a data engineering role at Ramp about six weeks ago. Didn't get the offer (I think I bombed the system design round) but the process was interesting enough to document.

Ramp's data platform is apparently heavily Snowflake and dbt. That context shapes a lot of the interview.

SQL round: This is real and it's hard. Not "write a basic JOIN" hard. More like: multi-step analytical query over a transactions schema, window functions required, and you need to think about performance. I got a question that was essentially: for each corporate card, calculate the rolling 30-day spend by category, flagging any categories that exceeded their limit on at least 3 days in the window. That's a real fintech business problem, not a leetcode SQL puzzle.

Expect to write it live, talk through your assumptions, and handle follow-ups about how you'd optimize it on a large dataset (billions of rows, partitioning, clustering strategies).

Pipeline design: This is where I slipped. They asked me to design an ingestion pipeline for merchant transaction data coming in from card networks, with late-arriving events, idempotency requirements, and the need to backfill historical data. I knew the components (Kafka for streaming, dbt for transforms, Snowflake for storage) but I didn't clearly explain the deduplication logic and they pushed me hard on that.

If you prep nothing else, prep idempotency in streaming pipelines. Especially in fintech. It comes up.

Behavioral / culture: Shorter for data roles, about 30 minutes. They asked about a time I owned a data quality incident. Have a specific story ready.

Overall: the bar is high. Know your SQL, know dbt patterns, know how to design for late-arriving data.

4 replies

alex_design

The window function + rolling 30 day thing tracks with what I've heard from other data interviews at fintech companies. Good practice: build a few of these from scratch on a real transactions dataset before going in.

analyst_ana

Did they test anything on the Python/Spark side or was it mostly SQL plus pipeline architecture? Asking because I'm coming from a mostly SQL background.

de_derek

No Spark in my loop. One question touched on Python for scripting a data validation check but it wasn't deep. SQL and pipeline design were the core. If you know dbt well that's probably more relevant than Spark for their stack.

content_cole

"I knew the components but couldn't explain the deduplication logic" is relatable in a painful way. I failed a design round for almost the same reason in a different domain. Knowing the tools and knowing how to explain the tradeoffs are two different skills.