Dfi Retail Group Software Engineer Interview Guide

The 60-second brief

As a Software Engineer at Dfi Retail Group, you play a vital role in powering the digital transformation of one of Asia’s largest retail conglomerates. Operating across multiple territories with a diverse portfolio of brands—including supermarkets, convenience stores, health and beauty outlets, and home furnishings—the company relies on robust, scalable technology to serve millions of customers daily. Your work directly impacts customer-facing digital platforms, loyalty programs, supply chain logistics, and point-of-sale systems. This position is highly critical because retail technology operates at an immense scale and requires near-zero downtime. You will contribute to platforms that process high volumes of concurrent transactions, manage complex inventory data, and deliver seamless omnichannel shopping experiences.

This guide is scoped to a Software Engineer candidate at Dfi Retail Group.

Focus areas

• Programming Languages
• SDLC (Software Development Life Cycle)
• SQL (Statements)

The Dfi Retail Group interview process

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

Application and Screening

Candidates submit an application and complete an aptitude test along with a technical quiz.

What to demonstrate

• Candidates submit an application and complete an aptitude test along with a technical quiz
• Depth in Programming Languages

How to prepare

• Answer aloud and timed: Explain the differences between various design patterns, such as the Singleton, Factory, and Observer patterns, and when you would use them.
• Answer aloud and timed: Write a SQL query to retrieve specific transaction data, joining multiple tables and using aggregation functions to filter retail purchase history.

Recruiter Screening Call

Discussion of professional background, career interests, and alignment with company culture.

What to demonstrate

• Discussion of professional background, career interests, and alignment with company culture
• Depth in Programming Languages

How to prepare

• Be able to walk your CV end to end in two minutes, and say why this company specifically.
• Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Evaluations

Deep-dive technical discussions with senior engineering managers focusing on SDLC and tools.

What to demonstrate

• Deep-dive technical discussions with senior engineering managers focusing on SDLC and tools
• Depth in Programming Languages

How to prepare

• Answer aloud and timed: What are the differences between abstract classes and interfaces, and how do you decide which one to implement?
• Answer aloud and timed: Walk us through your experience with the Software Development Lifecycle (SDLC). Which methodologies are you most comfortable with?

Assessment Center

Final stage may include group discussions and individual presentations to evaluate communication and teamwork.

What to demonstrate

• Final stage may include group discussions and individual presentations to evaluate communication and teamwork
• Depth in Programming Languages

How to prepare

• Answer aloud and timed: What is your understanding of the ITIL (Information Technology Infrastructure Library) framework, and how does it apply to software engineering and release management?
• Answer aloud and timed: How do you approach version control, branching strategies, and continuous integration/continuous deployment (CI/CD) pipelines?

Where candidates lose points

Do not underestimate the aptitude tests

The logic, IQ, and reading comprehension tests are used as a primary filter. Dedicate time to practicing timed cognitive puzzles and reading comprehension exercises before your test deadline.

Highlight retail-specific context

Whenever you discuss your past projects, emphasize how your work improved system reliability, handled scale, or enhanced the user experience. Aligning your achievements with retail-specific challenges (like transaction speed or inventory accuracy) will resonate strongly with hiring managers.

Retrying a write that is not safe to repeat

A timeout tells you nothing about whether the server applied the write, so a blind retry of a create or a charge can duplicate it. Either make the operation idempotent, with a caller-supplied key the server deduplicates on or a conditional update, or do not retry it; and use exponential backoff with jitter so the retries of many clients do not synchronise into a second outage.

Questions & practice

Group discussion scenario: How would your team prioritize engineering resources when migrating a legacy invent

Medium · Cognitive Ability & Collaborative Proble

Group discussion scenario: How would your team prioritize engineering resources when migrating a legacy inventory management system to a modern cloud-based platform?

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?

Logic and aptitude tasks: Solving structured pattern recognition, reading comprehension, and numerical reasoni

Medium · Cognitive Ability & Collaborative Proble

Logic and aptitude tasks: Solving structured pattern recognition, reading comprehension, and numerical reasoning questions under timed conditions.

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?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Write a SQL query to retrieve specific transaction data, joining multiple tables and using aggregation functio

Medium · Technical & Core Programming

Write a SQL query to retrieve specific transaction data, joining multiple tables and using aggregation functions to filter retail purchase history.

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?

How do you manage database indexing to optimize query performance in a high-volume transactional database?

Medium · Technical & Core Programming

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?

Explain the differences between various design patterns, such as the Singleton, Factory, and Observer patterns

Medium · Technical & Core Programming

Explain the differences between various design patterns, such as the Singleton, Factory, and Observer patterns, and when you would use them.

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 the core principles of Object-Oriented Programming (OOP) and how they contribute to writing maintaina

Medium · Technical & Core Programming

Describe the core principles of Object-Oriented Programming (OOP) and how they contribute to writing maintainable code.

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?

What are the differences between abstract classes and interfaces, and how do you decide which one to implement

Medium · Technical & Core Programming

What are the differences between abstract classes and interfaces, and how do you decide which one to implement?

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?

What is your understanding of the ITIL (Information Technology Infrastructure Library) framework, and how does

Medium · Systems, SDLC, & ITIL Frameworks

What is your understanding of the ITIL (Information Technology Infrastructure Library) framework, and how does it apply to software engineering and release management?

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?

How do you approach version control, branching strategies, and continuous integration/continuous deployment (C

Medium · Systems, SDLC, & ITIL Frameworks

How do you approach version control, branching strategies, and continuous integration/continuous deployment (CI/CD) pipelines?

Approach

1. Say who the caller is and what they do when the call fails halfway.
2. Define the identity of a request so a retry cannot double-apply it.
3. Separate accepted, pending, failed and confirmed; they are different facts.
4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

• What happens if the caller retries after a timeout?
• How does a client discover it is on an old version of this contract?

Individual presentation: Walk us through a technical project you designed from scratch, explaining your archit

Medium · Cognitive Ability & Collaborative Proble

Individual presentation: Walk us through a technical project you designed from scratch, explaining your architectural choices and how you managed technical debt.

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 scenario where you had to debug a critical production issue. What steps did you take to identify th

Medium · Systems, SDLC, & ITIL Frameworks

Describe a scenario where you had to debug a critical production issue. What steps did you take to identify the root cause and minimize downtime?

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 Dfi Retail Group candidates report.

Day 1 — Map the Dfi Retail Group loop

• Write out the reported sequence: Application and Screening, Recruiter Screening Call, Technical Evaluations, Assessment Center.
• 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 4 reported rounds, with the weakest marked.

Day 2 — Work Programming Languages

• Spend the session on Programming Languages, which Dfi Retail Group candidates report being tested on.
• Write one worked example in Programming Languages and time yourself on it.

Deliverable: One timed worked example in Programming Languages.

Day 3 — Work SDLC (Software Development Life Cycle)

• Spend the session on SDLC (Software Development Life Cycle), which Dfi Retail Group candidates report being tested on.
• Write one worked example in SDLC (Software Development Life Cycle) and time yourself on it.

Deliverable: One timed worked example in SDLC (Software Development Life Cycle).

Day 4 — Work SQL (Statements)

• Spend the session on SQL (Statements), which Dfi Retail Group candidates report being tested on.
• Write one worked example in SQL (Statements) and time yourself on it.

Deliverable: One timed worked example in SQL (Statements).

Day 5 — Answer out loud: Technical & Core Programming

• Answer aloud, timed: Explain the differences between various design patterns, such as the Singleton, Factory, and Observer patterns, and when you would use them.
• Answer aloud, timed: Write a SQL query to retrieve specific transaction data, joining multiple tables and using aggregation functions to filter retail purchase history.

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

Day 6 — Answer out loud: Systems, SDLC, & ITIL Frameworks

• Answer aloud, timed: Walk us through your experience with the Software Development Lifecycle (SDLC). Which methodologies are you most comfortable with?
• Answer aloud, timed: What is your understanding of the ITIL (Information Technology Infrastructure Library) framework, and how does it apply to software engineering and release management?

Deliverable: Spoken answers to 2 reported Systems, SDLC, & ITIL Frameworks question(s), under time.

Day 7 — Answer out loud: Cognitive Ability & Collaborative Problem Solving

• Answer aloud, timed: Group discussion scenario: How would your team prioritize engineering resources when migrating a legacy inventory management system to a modern cloud-based platform?
• Answer aloud, timed: Individual presentation: Walk us through a technical project you designed from scratch, explaining your architectural choices and how you managed technical debt.

Deliverable: Spoken answers to 2 reported Cognitive Ability & Collaborative Problem Solving question(s), under time.

Behavioural preparation

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

Walk us through your experience with the Software Development Lifecycle (SDLC). Which methodologies are you mo

Medium · Systems, SDLC, & ITIL Frameworks

Walk us through your experience with the Software Development Lifecycle (SDLC). Which methodologies are you most comfortable with?

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?

Reverse your own decision and price the reversal

Medium · reversibility · measurement · migrations

Describe a technical decision you made and later reversed. Pick one that cost something: a service you split and merged back, a cache you added and removed, an index you created that pushed the planner onto a worse plan, a projection you rebuilt from scratch. State what you believed when you decided, the measurement that changed your mind, how long the wrong version ran in production, and what the reversal cost in migrations, dual writes, and a deprecation window for callers you did not own.

Approach

1. State the original rationale without irony, in the version you would still defend given what was known then. If it is not defensible, the story is about carelessness rather than judgement, and a different example serves you better.
2. Give the measurement that moved with a before and after: the p99 that did not improve, the cache hit rate that sat at 40%, the plan that flipped to a sequential scan once the table passed a size you can name.
3. Cost the reversal in steps, not adjectives: expand-and-contract deploys, the dual-write window, the callers who had to be notified, the rows already written in the wrong shape that had to be backfilled or abandoned.
4. Distinguish reversal from rewrite by naming what you kept. Most good reversals preserve the schema or the interface and undo one decision inside it, which is also why they were affordable.

Follow-up

• What in that decision was irreversible, and did you know it was irreversible when you made it?
• How did you tell the people who had already built on top of the original decision?

Estimate work you have never done and defend the range

Hard · estimation · backfills · expand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach

1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.

Follow-up

• How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
• Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?