← Rbcroyalbank Interview Insights

Rbcroyalbank·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Jun 2026

Summary

Interviewed for a Data Engineer role at RBC Royal Bank. The technical questions were pretty focused on pandas fundamentals and SQL, nothing too wild, but the duplicate-finding problem had a part B that tripped me up a bit.

Questions Asked (4)

Q1

What is the difference between a pandas Series and a pandas DataFrame?

Technical Trade-offs
Author's notes

Knew this cold.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining each structure clearly: a Series is a one-dimensional labeled array, while a DataFrame is a two-dimensional labeled data structure with columns of potentially different types. Then highlight the key differences in dimensionality, mutability, and use cases, and provide a concrete example to illustrate when you would use each.

Pro tip: Mention that a DataFrame can be thought of as a dictionary of Series objects (each column is a Series), which demonstrates a deeper understanding of pandas internals and how operations propagate.

1. Define Series

Describe a Series as a one-dimensional labeled array capable of holding any data type, with an index for labeling.

2. Define DataFrame

Describe a DataFrame as a two-dimensional labeled data structure with columns of potentially different types, akin to a spreadsheet or SQL table.

3. Compare dimensionality and structure

Explain that Series is 1D (like a single column) while DataFrame is 2D (like a table with rows and columns).

4. Discuss operations and use cases

Highlight that DataFrame supports column-wise operations and heterogeneous data, while Series is used for single-variable analysis and operations.

5. Provide a concrete example

Give a brief example, such as a Series representing temperatures over days, and a DataFrame representing temperatures and humidity across multiple cities.

Key Points to Mention

  • Dimensionality: Series is 1D, DataFrame is 2D.
  • Index: Both have an index, but DataFrame has both row and column indices.
  • Data types: Series holds homogeneous data, DataFrame can hold heterogeneous data per column.
  • Mutability: Both are mutable, but DataFrame operations often return new objects.
  • Relationship: A DataFrame can be seen as a collection of Series (columns).
  • Use cases: Series for single-variable analysis, DataFrame for tabular data manipulation.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

What is the difference between WHERE and HAVING in SQL, and when do you use each with GROUP BY and aggregates?

Technical Trade-offs
Author's notes

Blanked for a second on phrasing it cleanly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clearly defining WHERE as a row-level filter applied before grouping, and HAVING as a group-level filter applied after aggregation. Then explain their interaction with GROUP BY and aggregates, using a concrete SQL example to illustrate when each is valid. Finally, mention performance considerations and best practices.

Pro tip: Emphasize that filtering with WHERE before grouping reduces the data set early, which is more efficient than filtering after aggregation with HAVING. This shows you understand query optimization, not just syntax.

1. Define WHERE

Explain that WHERE filters individual rows before any grouping or aggregation occurs. It cannot contain aggregate functions.

2. Define HAVING

Explain that HAVING filters groups after GROUP BY and aggregation. It can use aggregate functions like COUNT, SUM, AVG.

3. Explain execution order

Describe the logical order: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY. This clarifies why WHERE cannot use aggregates and HAVING can.

4. Provide a concrete example

Give a SQL query that uses both WHERE and HAVING, e.g., SELECT department, AVG(salary) FROM employees WHERE status = 'active' GROUP BY department HAVING AVG(salary) > 50000;

5. Discuss performance and best practices

Mention that WHERE is more efficient for row-level filtering because it reduces data before grouping. Use HAVING only for aggregate conditions.

Key Points to Mention

  • WHERE filters rows before grouping; HAVING filters groups after grouping.
  • WHERE cannot use aggregate functions; HAVING can.
  • GROUP BY creates groups; HAVING is applied to those groups.
  • Execution order: WHERE before GROUP BY, HAVING after.
  • Use WHERE for row-level conditions and HAVING for aggregate conditions.
  • Filtering early with WHERE improves performance.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Write SQL to return emails that appear more than once in a users table, along with their duplicate count.

Algorithms & Data Structures
Author's notes

GROUP BY email, COUNT(*) as dup_count, then HAVING COUNT(*) > 1.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Use a GROUP BY on the email column with a HAVING clause to filter groups having COUNT(*) > 1. Then select the email and the count to return duplicates and their frequency.

Pro tip: Mention that you would also consider case-insensitivity and trimming whitespace if the data might have inconsistencies, and discuss indexing on the email column for performance.

1. Identify the table and column

Confirm the table name (e.g., users) and the column containing emails (e.g., email).

2. Group by email

Use GROUP BY email to aggregate rows with the same email address.

3. Count occurrences

Apply COUNT(*) to count how many times each email appears.

4. Filter duplicates

Add a HAVING clause with COUNT(*) > 1 to keep only emails that appear more than once.

5. Select email and count

In the SELECT clause, include the email and the count (aliased, e.g., AS duplicate_count).

Key Points to Mention

  • GROUP BY clause to aggregate by email
  • HAVING clause to filter groups after aggregation
  • COUNT(*) or COUNT(email) to count occurrences
  • Aliasing the count column for clarity (e.g., AS duplicate_count)
  • Consideration of case sensitivity and whitespace trimming
  • Indexing on email column for performance

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

Now return the full rows for every user whose email is duplicated, not just the email itself.

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

This is where I slowed down.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the schema and what 'duplicated' means (e.g., exact email match, case-insensitive). Then present a SQL solution using a subquery or window function to return all columns for rows whose email appears more than once, and discuss trade-offs between approaches.

Pro tip: Mention that you'd verify the query's performance on large datasets and consider indexing the email column; also note that in production you might need to handle NULLs or case sensitivity based on business rules.

1. Clarify requirements and schema

Ask about the table structure, whether duplicates are case-sensitive, and if NULL emails should be considered. Confirm the expected output format.

2. Choose an approach

Decide between using a subquery with GROUP BY and HAVING COUNT(*) > 1, a self-join, or a window function like COUNT(*) OVER (PARTITION BY email).

3. Write the query

Construct the SQL statement to select all columns from the table where the email is in the list of duplicated emails, ensuring correct filtering.

4. Discuss trade-offs

Compare performance and readability of different methods, and mention indexing or other optimizations for large datasets.

5. Test and validate

Explain how you would test the query with sample data, including edge cases like multiple duplicates and NULL values.

Key Points to Mention

  • Use of GROUP BY with HAVING COUNT(*) > 1 to identify duplicate emails
  • Subquery or JOIN to retrieve all columns for those emails
  • Window functions (e.g., COUNT(*) OVER (PARTITION BY email)) as an alternative
  • Performance considerations: indexing the email column, avoiding full table scans
  • Handling NULLs and case sensitivity based on business rules
  • Testing with edge cases: multiple duplicates, no duplicates, NULL emails

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.