My interview process at Citi for the Data Engineer role had a straightforward structure: a video screening round followed by an in-person technical round with two senior leaders. The video call was conversational — mostly walking through my background, the tools I'd worked with, and specific projects from my resume. They didn't dig too deep, but it set the stage for what came next.
The in-person round was where things got technical. One interviewer focused heavily on migration projects and optimization strategies in the Hadoop ecosystem. We talked through handling SCD Type 2 scenarios in Hive, which led into deeper questions about Oozie orchestration — where jobs get scheduled, how to invoke them, where to monitor execution, what the coordinator does, and how to set up dependencies between actions. The second interviewer took a different angle, asking about shell scripting fundamentals: how to diff files, execute backend code, and schedule jobs using cron or shell scripts.
They also probed Spark optimization hard — partitioning, bucketing, salting, repartition versus coalesce, file format tradeoffs. One scenario-based question stuck with me: a job that suddenly started running longer than usual. How would you diagnose that? They wanted to see my debugging methodology, not just a textbook answer. I had to write a word count program on the spot as well, which they ran through to check correctness and logic.
The technical bar felt pitched at someone with solid hands-on experience in Hadoop pipelines and Spark tuning. They weren't looking for theoretical deep dives — they wanted to know if I could optimize queries, troubleshoot production issues, and navigate Oozie workflows. The process was direct and efficient, but the breadth of topics covered made it clear this role demanded versatility across big data tooling.
Prep tip from this candidate
Citi's Data Engineer interviews test practical Hadoop and Spark knowledge heavily — drill Oozie scheduler internals (coordinator, dependencies, job submission), SCD Type 2 implementations in Hive, and Spark tuning (partitioning, bucketing, file formats). Be ready to troubleshoot why a job suddenly runs slower and to write working code under time pressure; scenario-based debugging matters as much as the code itself.
