cswork / libraryOpen practice workspace

Interview guides · Shell

Shell Software Engineer Interview Guide

Shell Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Shell, you sit at the intersection of global energy infrastructure, digital transformation, and modern enterprise technology. Shell relies on advanced software engineering to power everything from complex energy trading systems—such as Endur—to renewable asset optimization, smart mobility platforms, subsea data processing, and enterprise resource planning. In this role, your code directly influences how one of the world's largest energy providers manages resources, delivers low-carbon solutions, and maintains operational safety across global markets. Software engineering at Shell is not limited to standard web development; it spans high-performance computing, cloud-native backend development, real-time telemetry, and enterprise integration. You will work in multi-disciplinary agile squads alongside domain experts, data scientists, and solution architects.

This guide is scoped to a Software Engineer candidate at Shell.

Focus areas

  • Data Structures & Algorithms (DSA)
  • Programming Practice / Coding Assessment
  • Problem Solving

The Shell interview process

Shell candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Online Screening

Candidates complete cognitive aptitude, logical reasoning, and situational judgement tests, along with an automated programming assessment.

What to demonstrate

  • Candidates complete cognitive aptitude, logical reasoning, and situational judgement tests, along with an automated programming assessment
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Answer aloud and timed: Explain the primary principles of Object-Oriented Programming (OOP) and how you apply them in system design.
  • Answer aloud and timed: What is the difference between a virtual function and a friend function in C++?

On-Demand Video Interview

Candidates record responses to structured workplace scenarios and motivation-based questions.

What to demonstrate

  • Candidates record responses to structured workplace scenarios and motivation-based questions
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Answer aloud and timed: How does a Binary Search Tree (BST) work, and what are its best, average, and worst-case time complexities?
  • Answer aloud and timed: Explain key SQL joins and how you optimize slow-running database queries.

Live Panel Interviews

Candidates engage in deep technical discussions, architecture reviews, live problem-solving, and structured behavioral evaluations with senior engineers and HR.

What to demonstrate

  • Candidates engage in deep technical discussions, architecture reviews, live problem-solving, and structured behavioral evaluations with senior engineers and HR
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Answer aloud and timed: Describe basic networking concepts, such as how TCP/IP differs from UDP and how RESTful APIs manage stateless communication.
  • Answer aloud and timed: Walk me through the architecture of a major software application you designed or contributed to significantly.

Where candidates lose points

Leverage the re-record functionality during the On-Demand Video Interview (ODVI)

Draft your main bullet points mentally during the prep time before submitting your final recording.

Master the STAR Method

Structure all behavioral responses using Situation, Task, Action, and Result. Ensure that the "Action" portion highlights your specific technical contribution rather than just what the broader team accomplished.

Review Core CS Concepts

Revisit fundamental Object-Oriented paradigms (OOP), binary search trees, array manipulation, and relational database queries before technical rounds.

Questions & practice

How does a Binary Search Tree (BST) work, and what are its best, average, and worst-case time complexities?

Medium · Technical Core & Computer Science Fundam

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Give an example of how you handled a situation where project requirements were ambiguous or changed late in th

Medium · Behavioral & Situational Judgement

Give an example of how you handled a situation where project requirements were ambiguous or changed late in the development cycle.

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

  1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
  2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
  3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
  4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

  • The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
  • How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Explain key SQL joins and how you optimize slow-running database queries.

Medium · Technical Core & Computer Science Fundam

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

  1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
  2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
  3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
  4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

  • Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
  • Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain the primary principles of Object-Oriented Programming (OOP) and how you apply them in system design.

Medium · Technical Core & Computer Science Fundam

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

What is the difference between a virtual function and a friend function in C++?

Medium · Technical Core & Computer Science Fundam

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Describe basic networking concepts, such as how TCP/IP differs from UDP and how RESTful APIs manage stateless

Medium · Technical Core & Computer Science Fundam

Describe basic networking concepts, such as how TCP/IP differs from UDP and how RESTful APIs manage stateless communication.

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Walk me through the architecture of a major software application you designed or contributed to significantly.

Medium · Project Architecture & Practical Executi

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

How did you handle trade-offs between performance, scalability, and delivery speed in your recent engineering

Medium · Project Architecture & Practical Executi

How did you handle trade-offs between performance, scalability, and delivery speed in your recent engineering work?

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Describe a situation where you had to refactor a legacy codebase or optimize an inefficient backend service.

Medium · Project Architecture & Practical Executi

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

What was the most challenging bug or system failure you encountered in your past project, and how did you debu

Medium · Project Architecture & Practical Executi

What was the most challenging bug or system failure you encountered in your past project, and how did you debug and resolve it?

Approach

  1. Establish what changed and when, before forming any theory.
  2. Pick a bisection that eliminates candidates whichever way it turns out.
  3. Check the instrumentation before believing the symptom.
  4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

  • What would you look at first, and what would it rule out?
  • How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics Shell candidates report.

Day 1 — Map the Shell loop

  • Write out the reported sequence: Online Screening, On-Demand Video Interview, Live Panel Interviews.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work Data Structures & Algorithms (DSA)

  • Spend the session on Data Structures & Algorithms (DSA), which Shell candidates report being tested on.
  • Write one worked example in Data Structures & Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Data Structures & Algorithms (DSA).

Day 3 — Work Programming Practice / Coding Assessment

  • Spend the session on Programming Practice / Coding Assessment, which Shell candidates report being tested on.
  • Write one worked example in Programming Practice / Coding Assessment and time yourself on it.

Deliverable: One timed worked example in Programming Practice / Coding Assessment.

Day 4 — Work Problem Solving

  • Spend the session on Problem Solving, which Shell candidates report being tested on.
  • Write one worked example in Problem Solving and time yourself on it.

Deliverable: One timed worked example in Problem Solving.

Day 5 — Answer out loud: Technical Core & Computer Science Fundamentals

  • Answer aloud, timed: Explain the primary principles of Object-Oriented Programming (OOP) and how you apply them in system design.
  • Answer aloud, timed: What is the difference between a virtual function and a friend function in C++?

Deliverable: Spoken answers to 2 reported Technical Core & Computer Science Fundamentals question(s), under time.

Day 6 — Answer out loud: Project Architecture & Practical Execution

  • Answer aloud, timed: Walk me through the architecture of a major software application you designed or contributed to significantly.
  • Answer aloud, timed: What was the most challenging bug or system failure you encountered in your past project, and how did you debug and resolve it?

Deliverable: Spoken answers to 2 reported Project Architecture & Practical Execution question(s), under time.

Day 7 — Answer out loud: Behavioral & Situational Judgement

  • Answer aloud, timed: Why do you want to work as a Software Engineer at Shell, and how do your career goals align with our mission?
  • Answer aloud, timed: Describe a time when you had to work with a diverse, cross-functional team or manage conflicting stakeholder priorities.

Deliverable: Spoken answers to 2 reported Behavioral & Situational Judgement question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

How do you ensure code quality through testing, code reviews, and continuous integration pipelines in your cur

Medium · Project Architecture & Practical Executi

How do you ensure code quality through testing, code reviews, and continuous integration pipelines in your current workflow?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Why do you want to work as a Software Engineer at Shell, and how do your career goals align with our mission?

Medium · Behavioral & Situational Judgement

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Describe a time when you had to work with a diverse, cross-functional team or manage conflicting stakeholder p

Medium · Behavioral & Situational Judgement

Describe a time when you had to work with a diverse, cross-functional team or manage conflicting stakeholder priorities.

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Tell me about a time when you noticed a potential mistake or safety/compliance risk in a project. What action

Medium · Behavioral & Situational Judgement

Tell me about a time when you noticed a potential mistake or safety/compliance risk in a project. What action did you take?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Describe a scenario where you failed to meet a deadline or technical objective. What did you learn, and how di

Medium · Behavioral & Situational Judgement

Describe a scenario where you failed to meet a deadline or technical objective. What did you learn, and how did you adapt?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?