Oracle · Primly Community

Oracle data engineer interview: pipelines, SQL, and what they actually care about

analyst_ana · 4 replies

just wrapped up an oracle data engineer interview loop, sharing the notes while they're fresh. role was on a team building internal data infrastructure for oracle's SaaS analytics products. not OCI itself, but closely adjacent.

four rounds total, all remote.

round 1: sql (live, 45 min). not basic SQL. they had me write a query to do incremental aggregation: given a raw events table that gets new rows every hour, write a query to compute a daily rollup that only processes new data since the last run. they wanted me to think through watermarks, handling late-arriving data, and idempotency. if you've worked with dbt or spark, this clicks naturally. if you've only written reporting queries, this will be unfamiliar territory.

round 2: data pipeline design (60 min). design an end-to-end pipeline: source is oracle transactional databases, destination is a data warehouse used by internal BI teams. they wanted: ingestion strategy (CDC vs batch, i argued for CDC and defended it), transformation layer design, schema evolution handling, and how you'd manage SLA monitoring. this is the system design equivalent for data engineers. be ready to go deep on any component.

round 3: coding / scripting (45 min). python problem: write a script to detect anomalies in a streaming metric (cpu utilization across tenants). i wrote a rolling z-score approach. they asked follow-up questions about what happens when the distribution shifts over time, how you'd tune sensitivity. this wasn't leetcode at all. it was 'write code a data engineer would actually write.'

round 4: behavioral. same signals as any oracle loop: ownership, cross-functional influence, customer impact. they specifically asked about a time i had to improve pipeline reliability after an outage. they care about the postmortem as much as the fix.

overall take: oracle DE interviews are legitimately technical. the SQL and pipeline design rounds are the hardest parts. if your background is heavy on tool configuration (airflow DAGs, dbt models) but light on the underlying concepts (exactly-once semantics, late data handling, watermarks), you'll want to fill those gaps before going in.

4 replies

backend_bekah

the CDC vs batch argument question is one i've gotten in basically every data eng loop i've observed. what tipped you toward CDC and how did you handle their pushback?

de_derek

i argued CDC for lower latency and reduced load on the source databases (batch windows do a full scan, CDC captures the change stream). their pushback was operational complexity and what happens when the change stream gets corrupted or lags behind. i said we'd add a daily full reconciliation pass to catch drift. they seemed to like that it acknowledged the tradeoff rather than pretending CDC is always better.

consultant_cam

the 'write code a data engineer would actually write' framing is a good way to describe what separates good DE interviews from bad ones. you're not proving you can sort a linked list. you're proving you can handle a real operational problem.

ops_omar

how long did the full loop take from application to final decision? i've heard oracle can be slow but i'm curious if the DE track has a different pace.