Maersk · Software Engineer
Updated · 2026-10-02

Maersk Software Engineer
Interview Guide

THE 60-SECOND BRIEF

Maersk is transforming from a traditional ocean carrier into an integrated end-to-end logistics partner powered by modern technology. As a Software Engineer, you will sit at the center of this massive digital evolution. Your primary focus is engineering high-scale, resilient systems that track global freight, optimize complex supply chain workflows, manage container logistics across air, sea, and land, and automate real-time messaging across international networks. The engineering organization at Maersk builds software that directly influences global trade efficiency. Whether you are developing event-driven microservices to handle high-volume container status updates, building intuitive user interfaces for logistics planners, or designing internal APIs for third-party logistics integration, your code directly impacts critical supply chain pipelines.

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

Maersk candidates report 5 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

Data Structures & Algorithms (DSA)JavaScriptAsynchronous Programming (Async/Await)

28 min read

Browse Software Engineer questions

See the practice prompts

1Candidate experiences ↗Read their reports
11Practice promptsAcross five skill areas

Maersk is transforming from a traditional ocean carrier into an integrated end-to-end logistics partner powered by modern technology. As a Software Engineer, you will sit at the center of this massive digital evolution. Your primary focus is engineering high-scale, resilient systems that track global freight, optimize complex supply chain workflows, manage container logistics across air, sea, and land, and automate real-time messaging across international networks. The engineering organization at Maersk builds software that directly influences global trade efficiency. Whether you are developing event-driven microservices to handle high-volume container status updates, building intuitive user interfaces for logistics planners, or designing internal APIs for third-party logistics integration, your code directly impacts critical supply chain pipelines. Developers at Maersk work heavily with backend technologies such as Java, C#/.NET, and Node.js, while relying on modern distributed infrastructure including Kafka, Redis, and cloud-native services (Azure/AWS). Candidates joining the tech team must navigate both modernizing legacy infrastructure and launching greenfield microservices. A strong engineering candidate combines robust foundational skills in Data Structures & Algorithms (DSA), clean system design, database optimization, and high-volume messaging with a practical understanding of how distributed software drives real-world operational workflows.

01

HR Recruiter Screen

reported

Initial screening conducted by an HR recruiter to assess candidate fit.

What to demonstrate

  • Initial screening conducted by an HR recruiter to assess candidate fit
  • Depth in Data Structures & Algorithms (DSA)

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.
Maersk Software Engineer candidate reports ↗
02

Online Assessment

reported

Candidates complete multiple-choice questions and algorithmic coding challenges on platforms like CoCubes or HackerRank.

What to demonstrate

  • Candidates complete multiple-choice questions and algorithmic coding challenges on platforms like CoCubes or HackerRank
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work JavaScript until you can explain it without notes
Maersk Software Engineer candidate reports ↗
03

Technical Rounds

reported

Candidates undergo 2 to 3 live virtual technical interviews focusing on Data Structures, Algorithms, and SQL.

What to demonstrate

  • Candidates undergo 2 to 3 live virtual technical interviews focusing on Data Structures, Algorithms, and SQL
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work JavaScript until you can explain it without notes
Maersk Software Engineer candidate reports ↗
04

System Design Interview

reported

Subsequent technical rounds focus on low-level/high-level system design and project deep dives.

What to demonstrate

  • Subsequent technical rounds focus on low-level/high-level system design and project deep dives
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work JavaScript until you can explain it without notes
Maersk Software Engineer candidate reports ↗
05

Managerial Interview

reported

Final interview discussing past achievements, operational challenges, and cultural fit.

What to demonstrate

  • Final interview discussing past achievements, operational challenges, and cultural fit
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work JavaScript until you can explain it without notes
Maersk Software Engineer candidate reports ↗

1 candidate reports. Individual accounts describe a particular role and hiring cycle.

Software Engineer

Software Engineer interview at Maersk: frontend machine coding

I had a frontend-focused process with two technical rounds and a hiring-manager-style discussion. The early technical work covered practical JavaScript and frontend tooling, including core JavaScript, asynchronous behavior, TypeScript, and Vue 3. It was easy to medium in tone and was about writing and reasoning through frontend code rather than theory alone. The second round became a machine-codi…

Read full experience

PracHub editorial advice for the preparation topics above.

01

Master Core SQL Querying

Live SQL query writing is a frequent component of technical screens. Practice complex multi-table JOIN statements, grouping (GROUP BY), aggregation filters (HAVING), subqueries, and window functions on live whiteboards or code editors.

02

Articulate System Design Trade-offs

When given a system design prompt—such as architecting a container management system or a dynamic pricing engine—never immediately present a static, final architecture. Walk the interviewer through functional requirements, non-functional constraints, data modeling choices, and explicitly address trade-offs regarding consistency, latency, and scalability.

03

Structure Behavioral Answers Using the STAR Method

Frame behavioral responses around specific engineering projects using the Situation, Task, Action, and Result format. Emphasize your specific individual code contributions, how you solved complex technical challenges, and how you communicated under pressure.

04

Review common Java and.NET runtime execution details before your technical interview

Panels frequently ask about memory management, execution lifecycles, and garbage collection mechanisms.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

8 technical prompts0 include a worked solution

Track a rolling failure rate per destination for circuit decisions

easy
sliding windowring buffercircuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach
  1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
  2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
  3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
  4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
  • The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
  • A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

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

easy
hashingat-least-onceaggregation

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?

Archive a resource graph without breaking live references or recursing

medium
graph traversaltopological ordertenant 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?

Built from the rounds and topics Maersk candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Maersk loop
  • Write out the reported sequence: HR Recruiter Screen, Online Assessment, Technical Rounds, System Design Interview, Managerial Interview.
  • 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 5 reported rounds, with the weakest marked.

02Work Data Structures & Algorithms (DSA)
  • Spend the session on Data Structures & Algorithms (DSA), which Maersk 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).

03Work JavaScript
  • Spend the session on JavaScript, which Maersk candidates report being tested on.
  • Write one worked example in JavaScript and time yourself on it.

Deliverable: One timed worked example in JavaScript.

04Work Asynchronous Programming (Async/Await)
  • Spend the session on Asynchronous Programming (Async/Await), which Maersk candidates report being tested on.
  • Write one worked example in Asynchronous Programming (Async/Await) and time yourself on it.

Deliverable: One timed worked example in Asynchronous Programming (Async/Await).

05Consolidate
  • Re-work the problem you got wrong earliest in the week, from scratch, without looking at your previous attempt.

Deliverable: A second, cleaner solution to the problem you got wrong first.

06Rehearse your own examples
  • Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

07Dry run for Maersk
  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Expand any day for tasks and deliverables. Your progress is saved on this device.

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

Turn a code review disagreement into a decision

easy
code reviewoptimistic concurrencycommunication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach
  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.
Follow-up
  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?

Estimate work you have never done and defend the range

hard
estimationbackfillsexpand-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?

Narrate an outage you owned from page to postmortem

hard
incident responseblast radiuspostmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach
  1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
  2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
  3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
  4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.
Follow-up
  • What would you do differently in the first five minutes, given the same dashboard and no more information?
  • Which follow-up action did you deliberately not take, and why was dropping it the right call?
  • 01

    A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

  • 02

    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.

  • 03

    Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

PracHub preparation framework ↗
What is the typical difficulty level of the coding questions at Maersk?

The coding questions generally fall into the easy-to-medium range on standard competitive programming platforms, focus on fundamental data structures (arrays, binary trees, strings, hash maps), binary search variations, and classic sorting algorithms. However, candidates are expected to write production-grade, bug-free code and clearly explain both time and space complexity.

Maersk Software Engineer candidate reports ↗
How long does the entire Maersk recruitment process typically take?

The entire process generally takes between 2 to 4 weeks from the initial application screen to a formal offer. However, candidates have occasionally reported minor delays between technical rounds due to panel availability across different time zones.

Maersk Software Engineer candidate reports ↗
Does Maersk focus heavily on domain-specific logistics knowledge during technical rounds?

While prior experience in supply chain, logistics, or transportation systems is an added advantage, it is not strictly required for general software engineering positions. Technical interviewers focus primarily on your core computer science fundamentals, system design capacity, and code quality. Scenario-based domain questions (e.g., pricing shipping containers) evaluate your logical breakdown of complex business rules.

Maersk Software Engineer candidate reports ↗
What development tech stacks are most widely used across Maersk engineering teams?

Maersk uses a diverse set of technologies, but core backend services heavily utilize Java (Spring Boot) and C# (.NET Core). Cloud infrastructure is largely built on Azure and AWS, utilizing Apache Kafka for event-driven messaging, Docker/Kubernetes for containerization, and SQL/NoSQL databases (PostgreSQL, Redis, Cosmos DB). Frontend applications typically use Angular, React, or Vue.js.

Maersk Software Engineer candidate reports ↗
Are remote or hybrid working arrangements supported for software engineering roles?

Yes, Maersk generally supports hybrid work models across its major technology hubs (including Bengaluru, Pune, Copenhagen, and Maidenhead). Specific hybrid expectations vary by local office, engineering team, and project operational requirements.

Maersk Software Engineer candidate reports ↗
What topics does Maersk test in interviews?

Maersk interviews most often cover SQL, Problem Solving, Python, Case Study Analysis, and DSA (Data Structures and Algorithms). The exact emphasis depends on the specific role you apply for.

Maersk Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.