Download App
The Challenge: Choosing Data Engineering When Everyone Else Wanted SDE
SRM's placement season for our batch kicked off in August 2025, and the pattern was predictable: everyone wanted an SDE role, the WhatsApp groups were obsessed with which companies were "core coding" versus "not real tech," and Data Engineer openings got quietly dismissed by a chunk of my classmates as the backup option for people who couldn't crack DSA-heavy interviews. I'd actually enjoyed a data warehousing elective more than most of my core CS electives, and a summer project involving cleaning and pipelining a genuinely messy dataset had stuck with me more than any LeetCode grind had. So when Barclays put up a Data Engineer opening through our placement office, I registered without much second-guessing, though I did get a "why not just try for the SDE role too" comment from at least three different friends that week.
Our placement cell ran the standard pre-placement talk in the Tech Park auditorium a week before the drive, walking through the role, eligibility (7.0 CGPA cutoff, no standing arrears), and the round structure. I remember being slightly relieved that the JD explicitly mentioned SQL and data pipelines rather than pure DSA, since that's where my actual interest was.
My Prep Timeline: SQL, Python, and Relearning Data Concepts Properly
I had about four weeks between registration and the actual drive date. I split prep roughly into three chunks: SQL, Python with a data-handling focus, and core data engineering concepts like ETL, data warehousing, and batch versus streaming processing.
The SQL part is where I got humbled early. I could write basic joins and group-bys fine, but the moment I tried window functions, ranking rows within partitions, running totals, I realized I'd never actually used them outside a single lecture example. I spent almost a full week just working through messy, realistic datasets instead of clean textbook tables, since the neat examples had clearly given me false confidence. Python prep was lighter since I was already comfortable with it from coursework, mostly revisiting pandas operations and basic scripting patterns for data cleaning. For the conceptual side, I read through data warehousing fundamentals and star-schema design until I could explain the difference between OLTP and OLAP without stumbling, which came up more than once during the actual rounds.
Inside Barclays' Online Assessment: Aptitude, Coding, and a SQL Section
The online assessment had three sections: a standard aptitude section, two coding problems, and a dedicated SQL section with about five queries against a given schema. The coding problems were moderate, an array manipulation question and a basic string processing one, nothing that felt data-engineer-specific. The SQL section is where the role's actual flavor showed up: one question asked me to find the second-highest transaction amount per account using a window function, exactly the pattern I'd been drilling the week before out of sheer luck in timing. I finished the assessment with about ten minutes to spare and felt cautiously good about it, though the two-week wait for the shortlist afterward was its own kind of stressful, refreshing the placement portal between classes more times than I'd like to admit.
The First Technical Round: SQL Under Pressure and a Genuine Stumble
The first technical round opened with a coding problem, reverse a string in place, that I finished quickly, and then moved almost entirely into SQL. The interviewer shared a schema with three tables, transactions, accounts, and branches, and asked me to write a query finding the top three branches by transaction volume for each month. I started confidently, then blanked halfway through structuring the partition clause for the ranking function, staring at the query editor for a good ten seconds before admitting out loud, "give me a second, I want to think through the partitioning logic properly instead of guessing." Saying that out loud actually helped me slow down and rebuild the query correctly instead of rushing into a wrong answer. The interviewer didn't seem bothered by the pause at all, and we spent the remaining time discussing how I'd optimize the query if the table had a few hundred million rows, which I answered honestly by talking through indexing and partitioning strategies rather than pretending I had hands-on experience with that scale.
What actually mattered: the SQL stumble didn't sink the round. Saying I needed a second to think it through, instead of guessing at the partition clause, is what let me recover into a correct answer.
The Second Technical Round: Designing a Data Pipeline, Not Reciting Definitions
The second round had almost no coding. It opened with a case study: "Barclays receives daily transaction files from multiple regional systems. Design a pipeline to ingest, validate, and load this data into a central warehouse, and tell me what could go wrong." I talked through a batch ingestion approach, staging the raw files, validating schema and null checks before loading, and flagging failed records for reconciliation rather than silently dropping them. The interviewer pushed on a specific point I hadn't fully considered: what happens if the same file gets uploaded twice by mistake. I hadn't planned for that case cleanly, so I thought out loud about deduplication using a file-level checksum or a load-batch ID, which the interviewer seemed satisfied with even though it clearly wasn't a rehearsed answer.
We also spent time on my summer project, and unlike the generic resume-walkthrough I'd expected, the interviewer asked specific questions about why I'd chosen a particular cleaning approach for missing values in that dataset, which I could answer properly since I'd actually made that decision myself rather than following a tutorial.
The HR and Managerial Round: Why Barclays, and Why Data Engineering Specifically
The final round was behavioral, conducted by someone from the actual data engineering team rather than a generic HR panel. Questions included why Barclays, why a Data Engineer role specifically given that most of my batch was applying for SDE positions, and a values-based question about a time I'd handled conflicting priorities. For the "why Data Engineering" question, I dropped any rehearsed line and just said that the summer project had shown me I found more satisfaction in making messy data usable than in optimizing an algorithm's runtime by a few milliseconds, which felt more honest than anything I'd prepared. He nodded and moved on, and I got the sense that answer landed better than a polished one would have.
The Result: My Barclays Offer Letter
The result came through the placement portal about eight days later, an email from our placement office with the subject line "Barclays Offer" and a shared list that had my name along with six others from across departments who'd gone for the same role. I read it sitting in the college library, and the first person I told wasn't my parents, it was the friend who'd asked why I wasn't going for an SDE role instead. I joined Barclays a couple of months after graduating, and the pipeline design work I do now traces pretty directly back to that case-study question about duplicate file uploads.
Key Takeaways for Anyone Considering a Data Engineer Role Out of Campus Placements
Looking back, the Data Engineer track was never the backup option my batch treated it as. If I were prepping again:
I would treat SQL practice as seriously as DSA from day one, especially window functions and query optimization, since that's where the role's real technical bar sits.
I would stop assuming a data engineering case-study answer needs to be perfect on the first pass. Thinking out loud about an edge case you hadn't considered, like duplicate file loads, showed more than a memorized textbook answer would have.
I would trust the elective or project that actually interested me over the track everyone else in my batch was chasing.
If you're prepping for something similar right now, wondering whether a Data Engineer role is worth choosing over the usual SDE rush, the mock interviews and resume feedback I used on devsunite.com/resources helped me get comfortable explaining data-pipeline decisions out loud instead of just reciting ETL definitions from a textbook.
Frequently Asked Questions About Barclays' Data Engineer Campus Hiring Process
What does Barclays' campus interview process for Data Engineer roles look like?In my case at SRM, it was an online assessment covering aptitude, coding, and SQL, followed by two technical rounds and one HR/managerial round. The technical rounds leaned heavily on SQL and data pipeline design rather than pure DSA.
Do you need advanced SQL knowledge for a Data Engineer interview at Barclays?Window functions, partitioning, and query optimization for large tables came up directly in my first technical round. Basic joins and group-bys alone weren't enough to handle the actual questions asked.
Is a Data Engineer role a downgrade compared to an SDE role in campus placements?Not in my experience. The role gave me hands-on pipeline design work almost immediately, tied directly to a case-study question I was asked in my final technical round about handling duplicate file uploads.
How should you prepare for a data-pipeline design question in an interview?Think out loud about edge cases as they come up rather than trying to have a perfect answer ready. My interviewer's follow-up question about duplicate file uploads wasn't something I had prepared for, and reasoning through it live is what made the answer work.
Conclusion
Getting a Data Engineer offer from Barclays through SRM's campus placements wasn't about picking the flashiest role on the list. It was choosing the track that actually interested me despite the peer pressure toward SDE roles, closing a real SQL gap in four weeks, and being honest about an edge case I hadn't considered instead of bluffing through it. If your batch is doing the same thing mine did, quietly ranking roles by how "core coding" they sound, that ranking is worth ignoring.