Cibc Data Engineer interview typically runs multiple rounds: technical interviews and live SQL/coding rounds. It usually takes a few weeks and can feel disorganized, with verbal signals not always matching the final outcome.
$81K
Avg. Base Comp
$143K
Avg. Total Comp
3-4
Typical Rounds
2-4 weeks
Process Length
Our candidates report that CIBC leans heavily on schema-based SQL that feels close to day-to-day engineering work, not abstract puzzle solving. In the experience we saw, the interviewer handed over a database schema and expected the candidate to reason through table relationships and write clean queries on the spot. That tells us the bar is less about memorizing syntax and more about whether you can translate a business question into correct, readable SQL under pressure.
A recurring theme is that the coding side is present, but it tends to be secondary to the database work. The LeetCode-style questions described were easy-to-medium, which suggests CIBC is using them more as a baseline screen than as the main differentiator. What seems to matter most is whether candidates can stay precise when the prompt is practical and slightly messy, especially in a live setting where small mistakes in joins or filters can change the result.
We also noticed a non-technical signal that candidates should not ignore: communication can be inconsistent. One candidate was verbally told an offer was coming and even discussed logistics, only to be told days later they were no longer being considered, with no written confirmation in between. That kind of experience suggests the process may reward patience and caution; we’d treat verbal momentum as provisional until something is in writing.
Synthetized from 1 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Cibc process.
The part that stood out most was how much of the interview was split between SQL and a couple of easy-to-medium algorithm questions. I went through multiple rounds, and in the technical portion I was given a database schema during the interview and asked to write SQL queries against it. That part felt very practical and close to real work, so I had to think carefully about the table relationships and how to express the logic cleanly rather than just solving a textbook problem.
There were also a couple of LeetCode-style questions, but they were not especially hard compared with the SQL. I’d describe the overall difficulty as moderate, mostly because of the mix of formats and the pressure of doing it live. What made the process frustrating was the communication afterward. I was later told by phone that an offer would be issued, and the conversation even moved into logistics like start date, relocation, and compensation, which made it feel like things were finalized. Then a few days later I was told I was no longer being considered. There was no written confirmation at any point, which made the whole experience feel disorganized. My main takeaway is to be ready for schema-based SQL questions and a few straightforward coding problems, but also to be cautious about reading too much into verbal signals during the process.
Prep tip from this candidate
Practice writing SQL directly from a schema under interview conditions, especially queries that require you to reason through table relationships on the spot. Also be ready for a couple of easy-to-medium LeetCode-style problems rather than only SQL.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Cibc
How would you answer when an Interviewer asks why you applied to their company?
| Question | |
|---|---|
| Your Strengths and Weaknesses | |
| 2nd Highest Salary | |
| Empty Neighborhoods | |
| Merge Sorted Lists | |
| Comments Histogram | |
| Employee Salaries | |
| Top Three Salaries | |
| Subscription Overlap | |
| Experiment Validity | |
| Find the Missing Number | |
| Cumulative Distribution | |
| Prime to N | |
| Rolling Bank Transactions | |
| String Shift | |
| Last Transaction | |
| Closest SAT Scores | |
| Random SQL Sample | |
| Alphabet Sum | |
| Paired Products | |
| Hurdles In Data Projects | |
| Rectangle Overlap | |
| Over-Budget Projects | |
| Slacking Employees Salaries | |
| Third Purchase | |
| Top 3 Users | |
| Size of Joins | |
| Level Of Rain Water In 2D Terrain | |
| Total Spent on Products | |
| Cumulative Sales Since Last Restocking |
Synthesized from candidate reports. Individual experiences may vary.
The process appears to begin with an initial conversation to discuss the role and candidate fit. In this case, later phone communication also covered logistics such as start date, relocation, and compensation, suggesting recruiter involvement throughout the process.
The main evaluation consisted of several live technical rounds split heavily between SQL and a couple of easy-to-medium algorithm questions. Candidates were given a database schema and asked to write SQL queries against it, with emphasis on understanding table relationships and expressing logic clearly.
After the technical rounds, the candidate received a phone call indicating that an offer would be issued and discussing offer logistics. However, there was no written confirmation, and the candidate was later told they were no longer being considered.