Man Group Technology Graduate Program 2027: Coding Assessment, System Design, and Timeline

Preparing for Man Group’s Technology Graduate Program 2027 starts with a naming and timing check: the official route is the Technology Foundation Programme, but its public page still shows an Autumn 2025 application opening. A confirmed 2027 technology intake schedule was not available in the official sources checked on September 7, 2026. Treat this as a preparation guide, not an announcement that applications are open. Official graduate programmes

The useful preparation theme is engineering judgment: implement a precise requirement, find the actual bottleneck, and explain how a data service behaves when its inputs change. Historical software-engineer reports provide context for coding and design discussions, but do not establish the next graduate cohort’s interview sequence.

The selected questions below are cross-company exercises, not a Man Group question bank or predictions of your assessment.

Read the Technology Foundation entry separately

Official programme description: Man lists Platform Engineering, Software Engineering with Python/C++/Java, and Software Engineering with C#/.NET pathways. It describes six-month rotations over a maximum of two years, with earlier permanent placement possible. Its graduate-stage outline is CV submission, online test, technical interview, and final interview. Programme description

These pathways should change the evidence you bring to an application. For a platform-oriented role, a project that made development environments more dependable may be relevant. For software engineering, you might discuss an application’s behavior, interfaces, or performance. These are preparation choices, not published selection criteria for an unconfirmed vacancy.

Choose the track whose problems you can explain with interest and detail. A language list does not explain your choice. Describe what you built, who used it, and what you learned when the first implementation failed. If your experience crosses tracks, make the connection explicit instead of presenting an undifferentiated list of tools.

Current availability check: All three linked technology applications redirected to the general board with an error indicator during research. We did not find a confirmed 2027 Foundation vacancy there. Current Man Group openings

When a new listing appears, check its graduation-year requirements, degree expectations, location, start date, and work-authorization terms. Do not assume that conditions from a quant internship or another office apply to this programme. Keep the exact role title and job ID so that later invitations can be matched to the application you submitted.

What the timing evidence does—and does not—say

The public pages contain different programmes and different publication cycles. That makes the section heading as important as the date itself.

Evidence available now	What you can conclude	What remains unconfirmed
Foundation overview’s Autumn 2025 label	This is an older application-opening label.	The technology programme’s 2027 opening and deadline.
Other graduate entries with Autumn 2026 labels	Those entries have their own schedule.	Whether Technology follows the same calendar.
Detailed interview durations beneath Technology Summer Internship	Internship material provides adjacent context.	Whether those durations apply to graduate applicants.
An invitation for your exact vacancy	It can establish your next action and deadline.	Stages or response times it does not specify.

The first three rows refer to the official programme page. Their practical purpose is to prevent a mixed-programme timeline from looking more certain than its sources.

Official general guidance: Man says recruitment varies by programme; job adverts identify relevant assessments, and invitations provide details of later stages. Student and graduate candidate resources

For your own calendar, record the submission date, assessment deadline, interview appointment, and any recruiter-promised update. Keep the completion window separate from the timed session. A week in which to start or submit an exercise does not mean the exercise lasts a week.

This research does not establish a reliable 2027 end-to-end duration. If a promised update passes, ask a concise question about next steps. Silence alone cannot tell you whether a score was sufficient or whether the team is still reviewing applications.

Prepare for coding without assuming one universal format

Historical candidate report: A software-engineer account posted January 23, 2026 describes a HackerRank invitation and a seven-calendar-day completion window. It does not identify a 2027 Foundation cohort. January software-engineer report

A different historical report: A London software-engineer candidate, applying through a recruiter, described homework, a code-review discussion, and system design in July 2026. That account is not labelled as graduate recruitment. July software-engineer report

These are separate reported experiences. Together they justify practicing both implementation and explanation; they do not prove that every applicant receives both formats. We did not find two independent reports from the 2027 technology-graduate cycle.

Original preparation advice: Start with one language you can use accurately under time pressure. Practice collections, sorting, indexing, and simple interfaces through complete tasks. Before implementing, state the input contract and the expected behavior when data is empty, malformed, repeated, or missing.

Then test the places where interpretation becomes code. If output ordering matters, demonstrate it. If a missing lookup should return an error, do not silently substitute a value. If duplicate keys are allowed, specify how they affect the result. These decisions often matter more than adding another data structure to an otherwise ambiguous solution.

If your actual invitation contains homework, make the submission easy to run and review. Include the required setup, a small test command, and a short explanation of assumptions. Follow its rules on tools, libraries, collaboration, and time limits. Do not treat an older candidate’s permitted language as authorization for your assessment.

Use Man’s profiling work to improve your technical explanations

Official engineering example: Man’s July 2025 article on improving pip describes profiling work that uncovered repeated package lookups while preparing installation summaries. Time that appeared to be spent elsewhere included costly summary preparation. Man’s pip performance case study

Original practice exercise: Build a small package-summary function. You receive an inventory of unique package names and versions, plus an ordered list of requested names. Return the requested versions in request order; missing names should be reported explicitly. This simplified exercise is inspired by the engineering lesson, not a reported interview task.

A straightforward implementation scans the inventory for every requested name. For an inventory ordered A, B, C and requests C, B, A, it performs three, two, and one name comparisons respectively: six comparisons altogether. Every answer is correct, yet the repeated search is visible even in this tiny example.

If there are n inventory entries and m requests, repeated scans can require O(nm) work. Building a name-to-version dictionary once gives expected O(n + m) processing time, using O(n) additional storage. Preserve the requested order by iterating over the request list, not by returning dictionary values wholesale.

Now discuss the limits. For very small input, the simpler implementation might be adequate. If inventory names are not unique, dictionary construction needs a conflict policy. If the inventory changes while requests are processed, the exercise needs a defined consistency rule. An optimization is not complete if it quietly changes the contract.

In a review conversation, distinguish three statements: what you observed, what you suspect causes it, and what you measured after a change. Do not claim a speedup from complexity analysis alone. Run comparable inputs, preserve correctness tests, and explain the extra memory cost. This turns “I optimized it” into an account another engineer can examine.

Practice system design through a reproducible-data service

Evidence boundary: System design appears in the July software-engineer report, but a separate system-design round is not confirmed for the 2027 Foundation programme. Prepare the skill without presenting a particular architecture problem as compulsory.

Official technology context: Man highlights ArcticDB among its technology projects. ArcticDB’s documentation describes a Python-oriented DataFrame database with object-storage backing and versioned data. That offers a concrete subject for learning about research infrastructure. Technology at Man, ArcticDB documentation

Original design scenario: An analyst needs to rerun yesterday’s experiment while another user wants today’s corrected dataset. Design a small read service that supports both requests. This is a simplified interview-practice problem, not a description of Man’s internal systems or ArcticDB’s implementation.

Begin with the user-visible promise. A request for an explicit dataset version must use that version or return a clear error. A request for the latest version may resolve differently later. Resolve “latest” once at the start of a request, then return the chosen version with the data so the caller can record it.

For example, yesterday’s experiment used prices version 41. Today, version 42 corrects several records. A rerun pinned to 41 should not silently receive 42 merely because it is newer. Conversely, a request that explicitly asks for the current dataset should not receive a stale cached result without an agreed freshness policy.

A useful first design separates a dataset catalogue, immutable data objects, and the read interface. The catalogue maps a dataset identifier and version to the stored object. The interface accepts the requested version, date range, and columns, checks access, and returns both data and identifying metadata.

Cache keys need to distinguish results that are different by contract. In this scenario, include dataset, resolved version, range, and requested columns; apply authorization before sharing cached data. Caching only by dataset name would conflate yesterday’s reproducible run with today’s latest-data request.

Discuss failure before adding scale. What happens if the catalogue points to an unavailable object? What if an old version was deleted? A clear failure is preferable to silently falling forward to newer data. If retention is limited, expose that policy so analysts know whether an experiment can be reproduced later.

Only then discuss larger workloads: repeated slices, concurrent readers, large responses, and storage costs. Ask which constraint matters before proposing more services. A graduate-level practice answer can be valuable with a small architecture if its correctness and failure behavior are precise.

Show why this engineering environment interests you

The profiling and research-data examples give you two specific ways to investigate Man’s technology work. Read one public engineering article closely enough to explain the problem, the evidence, and a limitation. You do not need to imply that you could redesign the firm’s platform after reading a blog post.

Original preparation advice: Connect that observation to your own experience. Perhaps you discovered that repeated setup slowed a development workflow, or that a dataset update made an experiment difficult to reproduce. Describe the concrete connection and what you want to learn next.

For a rotation programme, curiosity should coexist with contribution. Explain a skill you could bring to an initial team and an area where another placement could broaden your judgment. “I want exposure to everything” is less informative than identifying a relationship you want to understand, such as how application requirements shape platform choices.

Prepare one example of receiving technical feedback. State what another person noticed, how you checked the concern, and whether the design changed. If the original choice remained appropriate, explain the evidence without casting the discussion as a contest you won.

Five cross-company questions for focused practice

Some involve advanced systems; use a small, clearly scoped version first. Their presence here does not imply they were asked by Man Group.

Question	Focus for this preparation
Implement a crash-resilient LRU cache	Make the cache contract explicit before discussing persistence or recovery.
Implement frequency + distance top‑K queries	Preserve ranking rules while explaining the cost of repeated queries.
Design a single-node persistent in-memory cache	Start with a bounded system and reason about what survives a crash.
Design a Large-File Upload and Analysis Flow	Separate validation, asynchronous work, and the result a user can retrieve.
Design a CI/CD Job Scheduler	Explain dependencies, execution state, and failures in a developer-facing platform.

Choose one problem and produce two deliverables: a working implementation or small design, and a short explanation of one rejected alternative. Revisit the exact official vacancy when it appears, then adjust your preparation to the confirmed pathway and invitation. That keeps the work useful while the 2027 details remain unsettled.

Sources and Further Reading

• Man Group Graduate Programmes — Foundation description, older opening label, and separate internship material.
• Current Man Group openings — check for the exact vacancy and intake.
• Students and Graduates — programme-dependent recruitment guidance and candidate resources.
• January 2026 software-engineer report — historical online-assessment account, not confirmed graduate-cycle evidence.
• July 2026 software-engineer report — historical homework, review, and design account.
• Improving Python: How we made pip install twice as fast — official engineering case study from July 2025.
• Technology at Man — public engineering context.
• ArcticDB documentation — primary technical documentation for the data-engineering background.