Deliveroo Salesforce Engineer Interview: Apex Code Review and Problem Solving

Deliveroo publishes a Salesforce Engineering interview guide that explicitly includes a 70-minute HackerRank assessment with a code-review task, a 60-minute Apex-focused coding conversation, and a 45-minute Salesforce-domain problem-solving conversation in the full loop. The useful preparation is not to memorize an imagined prompt. It is to review unfamiliar Apex code for correctness, bulk behavior, permissions, and tests; then explain a defensible solution under time pressure. The actual invitation and assessment instructions remain authoritative.

This article adds Deliveroo's official interview structure and an original worked review. It does not claim that the code below was used by Deliveroo or that every candidate sees the same HackerRank sections.

What Deliveroo's Salesforce guide confirms

The official Deliveroo guide describes a first-stage 70-minute take-home HackerRank test with four sections that can include multiple-choice, open-ended, and coding/code-review work. Its full loop has two or three conversations, including coding, problem solving, and behavioral topics. The Apex coding interview is listed as 60 minutes, with a 30–40-minute live coding section and a 10–15-minute walkthrough. The Salesforce-domain problem-solving interview is listed as 45 minutes, with a 30-minute working section and a 10–15-minute explanation.

Deliveroo's stated rubric names coding, problem solving, communication, and testing. It explicitly tells candidates to address requirements, share their thinking, cover happy and sad paths, and prioritize accomplishing the main task within the time limit even when the result is not optimal. That guidance is more precise than a generic “study Apex” checklist. It also means your final explanation matters: the interviewer needs to know what you fixed, why, and what remains.

I found no independent same-cycle candidate reports for this exact Salesforce role that could establish specific questions. The following scenario is an invented practice exercise, not a report of Deliveroo's test. Salesforce platform behavior also changes by API version and execution context, so check the version and current official documentation before asserting a security default in a real interview.

Build a review order before reading the code

Under a timer, review for faults that can make the task wrong or unsafe before commenting on style. First restate the business invariant: what should happen for one record, many records, repeated execution, and a user without access? Next inspect data access and DML inside loops, null and missing states, repeated side effects, and the transaction boundary. Then ask which tests would catch each fault. Only after that should you discuss names, formatting, and abstractions.

Suppose a hypothetical service should notify an account owner once when a case first enters a high-priority state. A weak implementation loops through every changed case, queries the owner for each case, and inserts one notification every time it sees high priority. It may pass a one-record happy-path test. It can still exhaust query limits in a batch, duplicate notifications when unrelated fields change, and notify the wrong person if ownership changes after the query. The design question is not merely “move SOQL out of the loop”; it is “define the transition and side-effect identity.”

Use a four-column review note: observed code behavior, violated requirement, minimum safe correction, and test. A reviewer who lists five best practices without tying any to a failing case has not yet solved the exercise. If the prompt provides an existing service architecture, follow it; do not import a trigger or queue merely because it is your favorite pattern.

Work through an original Apex review

Here is intentionally flawed pseudo-Apex. It is short enough for an interview discussion and deliberately leaves platform-specific notification details abstract. It has not been executed in a Salesforce org.

for (Case c : Trigger.new) {
    if (c.Priority == 'High') {
        Contact owner = [SELECT Id, Email FROM Contact WHERE Id = :c.ContactId];
        Notification__c n = new Notification__c(
            Case__c = c.Id, Recipient__c = owner.Id
        );
        insert n;
    }
}

The first question is whether ContactId is the intended recipient at all. In Salesforce, a Case can have an owner that is a User or Queue, while ContactId is the related contact; the hypothetical requirement says “account owner,” not “case contact.” Clarify the domain mapping rather than confidently changing a field based on a guess. The second question is whether this runs on insert, update, or both. If it runs on every update, the code creates duplicate notifications whenever a high-priority Case is edited. The third question is batch safety: one query and one insert per record scale with batch size.

A minimal answer would establish the transition predicate from old to new priority, collect the relevant account or owner IDs, query the needed records once, build notifications in memory, and insert them as a list. It would define what “once” means if a case leaves high priority and later re-enters. If retries or multiple automation paths can repeat the work, a durable uniqueness rule or idempotency key may be necessary. Do not claim that a static boolean recursion guard proves business idempotency; it often hides legitimate later work.

This review is the first article-specific asset. It lets you demonstrate Deliveroo's stated combination of code review, construction, and explanation. A strong walkthrough would identify the incorrect recipient assumption before polishing syntax, because that changes the business outcome. It would then explain which limit or duplicate path each structural fix addresses.

Explain bulkification without chanting a slogan

Salesforce's bulkification guidance explains why queries and DML should be planned around collections rather than repeated per record. In the practice case, identify the maximum set of source Cases you need to process, gather keys, perform a bounded query, build a map by key, and issue one or a small number of DML operations. Then ask what happens if some keys are missing or some rows fail. “Use a map” is only useful when you can state what the key means and how missing matches are handled.

Do not optimize away correctness. If a notification is emitted to an external system, the transaction and retry boundary matters more than saving a query. What happens if Salesforce commits the Case change but a downstream call times out? What observation will tell you whether the notification was already sent? If the assessment is purely local Apex, describe the integration risk as a follow-up, not as a requirement that justifies a huge architecture detour.

Mention limits with context instead of reciting a memorized number. A batch can invoke code multiple times; tests should exercise enough records to expose a query-in-loop pattern and assert the intended business result for every eligible record. Platform limits and API behavior evolve, so verify the exact constraints in current Salesforce documentation and in the interview environment when you can.

Treat data access and permissions as a separate review pass

Apex security cannot be reduced to with sharing alone. Sharing governs record access in certain contexts, while object and field permissions require their own treatment. Salesforce's Apex security documentation discusses user-mode operations and the behavior of newer API versions. In a code review, ask which user initiates the operation, what records and fields they should see or change, and whether the chosen query/DML mode enforces that boundary in the actual API version.

For the hypothetical notification service, a system-owned background action may legitimately require different access from a user-facing edit. Do not guess. State the authorization rule and test it with a low-permission user. Avoid dynamically building SOQL from untrusted strings; if the scenario requires dynamic search, ask which inputs can be bound and which identifiers must come from an allowlist. Security comments are meaningful only when they connect to a real data path.

Test the happy and sad paths Deliveroo names

Deliveroo explicitly asks candidates to cover happy and sad paths. Build a small test matrix for the practice case. On the happy side: one Case newly becomes high priority; a batch of eligible Cases creates one notification per intended recipient; an unchanged high-priority Case creates none. On the sad side: a missing related record, inaccessible field, duplicate automation attempt, partial DML failure where allowed, and a Case that changes owner or priority during the workflow. For each test, assert the output and the absence of extra side effects.

The point is not to write six long test methods within a 30-minute session. State which two tests reveal the highest-risk defects, implement the essential path if the environment permits, and describe the rest in the walkthrough. A test that only checks “no exception” cannot catch a notification sent twice. A test that inserts one record cannot expose a per-record query. A bulk test with only eligible rows may miss a null dereference on ineligible or incomplete data.

Approach the Salesforce-domain problem-solving round

The official guide says the separate problem-solving conversation presents requirements and asks for at least one solution, with trade-offs and user impact. Start by identifying actors, record ownership, volume, latency, audit needs, and failure recovery. Decide whether configuration, Flow, Apex, or an integration is appropriate only after you know the boundary. Custom code is not automatically the strongest answer; declarative automation is not automatically safe at scale.

Here is another original practice brief: support agents need to mark a merchant onboarding case complete, trigger a downstream provisioning request, and show a reliable status to the merchant team. The important questions are who may mark completion, what prevents duplicate provisioning, how failures are retried, and whether the UI reports “requested” or “finished.” Propose a minimal workflow first, then explain a more scalable option if volume or reliability requirements demand it.

Requirement	First design question	Verification
Authorized completion	Which role may transition the case?	Low-permission and allowed-user tests
One provisioning intent	What durable key identifies an attempt?	Replay same event without duplicate work
External failure	Where is retry state visible?	Simulate timeout after request accepted
Useful status	Which state is shown to an agent?	Confirm UI distinguishes pending and complete

This is the second article-specific asset. It models how to move from a vague requirement to an operable Salesforce solution without pretending Deliveroo will use this exact business scenario. In the walkthrough, identify the trade-off you accepted and the signal that would make you revisit it.

Use the time box deliberately

For the 60-minute Apex interview described by Deliveroo, reserve the first minutes to restate requirements and inspect code, the main working block to implement the highest-risk correction, and the final minutes to test and explain. The posting gives a 30–40-minute working section and a 10–15-minute walkthrough, so do not plan to code until the interviewer stops you. If you cannot finish every improvement, say which requirement is complete, what remains, and why you prioritized this order.

For the 70-minute HackerRank stage, familiarize yourself with the platform's editor and navigation beforehand as Deliveroo advises. Work in the order your actual assessment specifies. A four-section structure does not tell you how many questions or their difficulty. Avoid inventing a fixed allocation such as “ten minutes per section”; instead, scan instructions, identify hard time limits, and leave a small review buffer if allowed.

Practice five transferable questions

Question	Practice focus	Salesforce transfer
Prioritize Critical Findings in a High-Load Batch Processor Review	Review order	Fix data loss or duplication before style
Implement an Idempotent Versioned Database Update	Repeated events	Define one intended notification or transition
Write good tests and define integration tests	Test boundaries	Separate Apex unit behavior from external delivery
Design input validation and error handling	Rejection versus silent loss	Handle missing related data explicitly
Scale an Authorization Checker	Permission model	Explain who may read or change each record

After each exercise, ask what a single-record test would miss and how a batch or low-permission user would change the answer.

A concise final walkthrough

End your solution with four sentences: “The main invariant is X. The original code violated it under Y. I changed Z and verified A. I would next test B because it remains a risk.” If you made an assumption about ownership, permissions, or retry behavior, say so explicitly. Deliveroo's guide values communication and completing the main task under a time limit; a transparent partial solution with correct priorities can be stronger than a polished but untested detour.

Your own invitation determines the current format and permitted tools.

Sources and Further Reading

• Deliveroo's official Salesforce Engineering interview guide
• Salesforce Developers on bulkification patterns
• Salesforce Developer documentation on secure Apex classes

Research note: Sources were checked on September 27, 2026. The Case notification and merchant provisioning scenarios are original practice material, not reported Deliveroo prompts. Check API-version-specific Salesforce behavior in your environment.