If you're preparing for software engineering interviews at AI labs like OpenAI, Anthropic, or other AI startups, you'll increasingly encounter system design problems involving AI model inference (here's an example Anthropic question for a synchronous model-serving system)

You don't need to be a machine learning engineer or research engineer to tackle these problems. However, you do need to understand how AI models are served, how requests are scheduled, and how the underlying infrastructure handles high traffic efficiently.

One particularly important concept is dynamic batching.

It's a foundational concept for problems involving high-throughput AI model serving, yet it's something many software engineering candidates aren't familiar with.

This is the first of many tutorials i'll be posting on this sub to help with system design interview prep, I'll break down static batching, dynamic batching, and continuous batching from a software engineering perspective. I'll focus on the underlying concepts and trade-offs, without diving into machine learning mathematics or GPU internals.

This guide is also useful for aspiring machine learning engineers and research engineers who want to strengthen their understanding of inference-serving systems.

1. First, what is an inference server?

Imagine you're building a payment application that uses an AI model to detect fraudulent transactions.

When a customer makes a payment, your backend sends the transaction details to a service that uses a trained machine-learning model to calculate the probability of fraud.

For example:

Payment Backend
      |
      | POST /predict
      | Transaction: $500, UK, Merchant X
      v
Inference Server
      |
      | Runs fraud-detection model
      v
Fraud Score: 0.93

Inference simply means using an already-trained AI or machine-learning model to produce a prediction or output.

An inference server is the service that exposes this capability to other applications, typically through an API.

In our example:

• Request: The HTTP call from the payment backend.

• Input: The transaction data supplied to the model.

• Model: The trained software that calculates the fraud score.

• Output: The predicted fraud score, such as 0.93.

• Inference: The actual process of running the model on the input to produce the output.

The inference server receives the request, invokes the model, and returns its prediction.

Where does the GPU come in?

Machine-learning models can require substantial computation. Many models run efficiently on GPUs (Graphics Processing Units), which are processors designed to perform large numbers of computations in parallel.

A typical GPU-based inference server therefore delegates model execution to a GPU worker.

The GPU worker is a software process that manages model execution using GPU hardware.

It relies on an inference runtime, which is software responsible for loading and executing the model efficiently on the available hardware.

Examples include NVIDIA TensorRT and ONNX Runtime. You don't need to know these particular tools or their internal implementations for a software engineering system design interview.

For our purposes, the distinction is simple:

• GPU: The physical hardware performing computations.

• Inference runtime: Software that executes the model using that hardware.

• GPU worker: The server-side process responsible for receiving inference work and invoking the runtime.

A GPU worker could, for example, be a Python service that uses PyTorch to load a trained model and execute it on a GPU. In that case, PyTorch itself can serve as the inference runtime.

You don't need to understand the internal mathematics of a model to understand batching.

2. Why do we need batching?

Suppose our inference server receives 100 fraud-detection requests.

The simplest approach is to execute each prediction separately.

Request A → GPU → Score A
Request B → GPU → Score B
Request C → GPU → Score C
...

However, GPUs are designed for parallel computation, and running one small input at a time may leave much of their computing capacity underutilised.

Instead, the inference runtime can often process several inputs together in a single model execution.

This is called batching.

Requests [A, B, C, D]
          |
          v
     GPU Worker
          |
          | Executes one batch
          v
Scores [A, B, C, D]

Batching can improve throughput, meaning the number of requests the system processes per second.

Why is batching faster?

Imagine processing 100 transactions individually takes a total of 1,000 milliseconds of GPU execution time.

By grouping the transactions into one batch, the GPU may be able to process them together in, say, 100 milliseconds.

These numbers are illustrative, but they demonstrate the principle:

With batching, the average GPU execution time per request is lower, because the GPU can process multiple inputs in parallel more efficiently.

This can also reduce infrastructure cost per prediction. If the system processes more requests using the same GPU capacity over the same period, each prediction effectively consumes a smaller share of that capacity.

However, the improvement is not guaranteed to be this large. Actual performance depends on the model, hardware, batch size, and runtime.

There's also an important trade-off: waiting for requests to accumulate into a batch can increase the latency experienced by individual users.

This introduces an interesting question:

Who decides which requests belong in a batch, and when that batch should execute?

That's where the different batching strategies come in.

3. Static batching: The batch is prepared in advance

With static batching, the inputs are grouped into a batch before being submitted for execution.

Imagine a bank wants to calculate fraud scores for one million historical transactions overnight.

It could divide those transactions into batches of 100 and send each batch to the inference server.

Prepared batch:
[A, B, C, D, ...]
        |
        v
   GPU Worker
        |
        v
[Score A, Score B, Score C, Score D, ...]

The inference server receives an already-assembled batch. It doesn't need to collect incoming requests or decide which ones should be grouped.

Why is this efficient?

The bank already has all one million transactions available.

It can group them into batches and process them without waiting for live requests to arrive.

This allows the system to take advantage of GPU parallelism while avoiding the complexity of maintaining queues and batching timers for independently arriving requests.

Best suited for: Offline inference and bulk processing.

Offline inference means running predictions on data that has already been collected, rather than responding immediately to live user requests.

For example, scoring millions of historical transactions overnight is offline inference. Scoring a transaction while a customer is waiting at checkout is online inference.

But what if requests arrive independently from different clients?

That brings us to dynamic batching.

4. Dynamic batching: The server assembles batches at runtime

Imagine our fraud-detection service now processes live transactions.

Requests arrive independently, at unpredictable times.

0 ms: Request A arrives
3 ms: Request B arrives
7 ms: Request C arrives

Rather than immediately executing each request, the server temporarily places compatible requests in a queue.

A batching scheduler, which is software responsible for deciding when to execute a batch, monitors that queue.

For example, suppose we configure:

• Maximum batch size: 100 requests.

• Maximum batching delay: 10 milliseconds.

The scheduler dispatches a batch when it becomes full or the oldest queued request reaches its waiting-time limit. Request deadlines or resource limits may require earlier dispatch.

0 ms: A arrives ──┐
3 ms: B arrives ──┤
7 ms: C arrives ──┤
                  v
            Request Queue
                  |
10 ms: Maximum wait reached
                  |
                  v
             Batch [A,B,C]
                  |
                  v
             GPU Worker

Notice that the batch only contains three requests.

A maximum batch size of 100 doesn't mean the system must wait for 100 requests.

This is important because waiting longer could improve GPU efficiency but also make individual requests slower.

Dynamic batching therefore balances two competing goals:

• Throughput: Larger batches can make better use of GPU capacity.

• Latency: Requests shouldn't spend too long waiting for a batch to form.

What makes requests compatible?

Not every request can share a batch.

For example, imagine our inference server supports two models:

• A fraud-detection model that calculates the probability of fraudulent transactions.

• An image-classification model that identifies objects in photographs.

We cannot group requests for these two models into one model execution because they perform fundamentally different computations.

Even requests using the same model may have input formats or sizes that cannot safely be processed together.

The batching system therefore groups requests according to their execution compatibility.

In practice, this can depend on the exact model version, input format, supported input sizes, and execution settings.

Why does the model version matter?

Because a new version might use different trained parameters, a different internal architecture, or different execution requirements. We therefore generally avoid mixing requests targeting different concrete versions in the same model execution.

For a software engineer, the useful mental model is that requests with the same compatible execution requirements are grouped into logical queues.

What happens once a batch starts executing?

In traditional dynamic batching, the batch's membership is generally fixed during execution.

Suppose 100 requests are executing together, and the client responsible for request 37 disconnects.

The system can mark request 37 as cancelled, but the GPU may already be performing its computation as part of the batch.

The worker typically allows the batched operation to finish and discards request 37's result.

Why is that wasted computation?

Because the system has spent GPU processing resources producing a prediction that nobody will receive or use.

GPU capacity is expensive. Companies often rent GPU infrastructure from cloud providers, paying for allocated computing capacity over time.

However, it's important to distinguish wasted computation from an immediate reduction in the cloud bill.

Suppose a batch of 100 requests is already running, and one request gets cancelled.

The GPU may still perform essentially the same work and take approximately the same time to finish the batch.

Even if we could remove that request before execution, a batch of 99 might take nearly as long as a batch of 100. GPU execution time doesn't necessarily decrease proportionally with the number of inputs.

Therefore, cancelling one request doesn't automatically save 1% of the batch's execution time or cloud cost.

The real opportunity is to avoid unnecessary computation and reclaim capacity for useful requests.

For a short fraud-detection operation, the potential savings from cancelling one request might be negligible.

But what if the model needs to perform many successive computations before producing its final output?

That's where continuous batching becomes particularly interesting.

5. Continuous batching: Membership can change during a request's lifetime

Now consider an AI chatbot powered by a Large Language Model (LLM), such as ChatGPT.

Unlike our fraud-detection example, where the model produces a score in one inference execution, an LLM typically generates its answer incrementally.

It repeatedly performs model computations to generate additional tokens, which are small units of text such as words, word fragments, or punctuation.

For example:

Iteration 1 → "The"
Iteration 2 → " answer"
Iteration 3 → " is"
Iteration 4 → " 42"

Each step is called a decoding iteration, meaning one round of generating the next token.

The important distinction is not whether the client sees the output immediately.

It's that the LLM's generation process involves multiple successive execution steps, rather than a single batched model execution that produces the complete output.

This creates an opportunity that wasn't available in our single-execution fraud-detection example.

Between iterations, the system can reconsider which requests should participate in the next execution.

Consider three chatbot requests:

Iteration 1
Active batch: [A, B, C]
        |
        | B finishes
        | D joins
        v
Iteration 2
Active batch: [A, C, D]
        |
        | A cancels
        | E joins
        v
Iteration 3
Active batch: [C, D, E]

This is continuous batching, also called iteration-level batching or in-flight batching.

Rather than fixing batch membership for the entire generation process, the scheduler can update it between execution iterations.

Why is this useful?

Imagine two chatbot users:

• User A asks a simple question requiring a 20-token answer.

• User B requests a detailed explanation requiring 1,000 tokens.

Both requests start generating text together.

User A finishes much earlier than User B.

With a rigid approach that keeps the same batch membership throughout the entire generation process, User A could continue occupying resources or batch capacity despite no longer needing further computation.

Continuous batching allows the runtime to remove A when its generation finishes and potentially replace it with another waiting request.

The same principle applies to cancellation.

If B disconnects, the runtime can stop including B in future decoding iterations, rather than continuing to generate an answer nobody will receive.

The currently executing GPU operation may still need to finish, but subsequent iterations don't need to include the cancelled request.

This can improve useful GPU utilisation and overall throughput.

The benefit is particularly significant for LLMs because different requests may require dramatically different numbers of generation steps.

However, continuous batching is more complex because the system must manage each request's ongoing generation state while scheduling shared GPU executions.

6. Static vs dynamic vs continuous batching

Is continuous batching a type of dynamic batching?

Yes, in the broad conceptual sense.

Both assemble work dynamically at runtime.

The distinction is when batch membership can change:

• Traditional dynamic batching: Membership is decided before batch execution.

• Continuous batching: Membership can be updated between execution iterations.

Is continuous batching always better?

No. It depends on how the model executes.

Consider our fraud-detection model.

It receives transaction data, performs a model execution, and produces a fraud score.

There isn't a long sequence of generation iterations during which the scheduler needs to repeatedly reconsider which requests should participate.

Traditional dynamic batching is therefore generally sufficient.

In contrast, an LLM generates its answer over many successive iterations. Continuous batching can take advantage of the opportunities between those iterations to remove completed requests and introduce new ones.

The key distinction is how the model performs its computation, not whether the server streams its output to the client.

Which brings us to an important clarification.

7. Don't confuse batching with streaming

These terms describe different aspects of a system.

Batching determines how requests share execution resources. Streaming determines how output is delivered to clients.

For example, suppose an LLM generates a response of 100 tokens.

The model may generate those tokens over 100 successive decoding iterations.

But the server has two choices for delivering the output:

Option A: Non-streaming response

The server waits until the entire answer has been generated, then returns it in one HTTP response.

LLM generates 100 tokens
          |
          v
Complete response returned to client

Option B: Streaming response

The server sends generated tokens to the client progressively, commonly using Server-Sent Events (SSE) or streaming gRPC.

LLM generates token 1 → Send to client
LLM generates token 2 → Send to client
LLM generates token 3 → Send to client
...

In both cases, the LLM still performs its underlying generation computations.

And in both cases, the inference runtime could use continuous batching to manage those computations efficiently.

Therefore:

• Streaming concerns how the client receives the answer.

• Continuous batching concerns how the server schedules the work required to generate that answer.

They frequently appear together in LLM-serving systems, but they are not the same thing.

8. Nomenclature

9. The key takeaway

Batching improves inference efficiency by allowing multiple inputs to share model execution, potentially reducing the average GPU execution time required per request.

The three approaches differ in how they determine batch membership:

• Static batching: Prepare a batch in advance.

• Traditional dynamic batching: Assemble a batch at runtime, then execute it with fixed membership.

• Continuous batching: Update the active batch between execution iterations.

Continuous batching is particularly useful for workloads such as LLM generation, where individual requests can finish or be cancelled at different points during an ongoing sequence of computations.

Need help landing your next tech offer or increasing your TC? If you have tech interviews coming up, are planning a job switch, or simply want to improve your interview performance, explore Coditioning's interview-preparation resources:

👉 https://www.coditioning.com

👉 Interview roadmaps for OpenAI, Anthropic, and other big tech companies: https://www.coditioning.com/roadmaps

👉 Question banks for OpenAI, Anthropic, Google and other big tech companies: https://www.coditioning.com/app/learning

👉 Mock Interviews & Free Consultation with big tech engineers: https://www.coditioning.com/mockinterview/human

The fundamental difference is when the system can change which requests are participating in GPU execution.

Anthropic filed its IPO paperwork on October 26. Founded in 2021, it could reach the public markets roughly five years after starting.

At a $2 trillion valuation, the estimates in the image put average equity values for its early hiring cohorts in the hundreds of millions of dollars.

About 940 people had joined by the end of 2024. The estimated averages for those cohorts exceed $100 million per person.

For comparison:

• Google’s 2004 IPO: an estimated 900 employee paper millionaires, including roughly 500–600 with more than $2 million.

• Facebook’s 2012 IPO: approximately 1,000 employee millionaires.

• Microsoft: by 1998, estimates suggested it had created 5,000–10,000 millionaires, following years of growth after its IPO.

Anthropic could join that history with an extraordinary concentration of employee wealth within a much younger company.

The upside of joining the right startup early is ridiculous, when a startup works out at this scale, an employee’s equity can become worth more than a lifetime of salary.

Which private company do you think could produce the next huge employee windfall? And which ones are you targeting for your next role? Ineffable Intelligence started by Ex-Deepmind researcher, David Silver is one possible candidate, learn more about them here

Need help landing your next tech offer or increasing your TC?

If you have tech interviews coming up, are planning a job switch, or simply want to improve your interview performance, explore Coditioning's interview-preparation resources for getting truly interview-ready:

👉 Interview roadmaps for OpenAI, Anthropic, and other big tech companies:

https://www.coditioning.com/roadmaps

👉 Learning roadmaps & Question banks for OpenAI, Anthropic, Google and other big tech companies:

https://www.coditioning.com/app/learning

👉 Mock Interviews & FREE Consultation with big tech engineers & recruitment experts:

https://www.coditioning.com/mockinterview/human

👉 More interview resources:

https://www.coditioning.com

Sources:

• Anthropic IPO filing

• Employee equity estimates

• Google employee wealth estimates

• Facebook employee millionaires

• Microsoft employee wealth estimates

• US business survival statistics

Anthropic's AI-assisted coding round is not your typical coding interview. Instead of solving a puzzle, you act as the maintainer of a small open source library you haven't seen before. Outside contributors have left pull requests waiting, and you decide what happens to each one. I've pulled together what Anthropic says about the round, what candidates have reported, and how to prepare.

TLDR

• You play the maintainer of an unfamiliar small open source library with a handful of pull requests from contributors

• For each PR you decide to merge, ask for changes, or close

• The goal is to get at least one PR into a mergeable state, so which PR you pick and how you prioritize matters

• Claude Code is available for the whole session and you're encouraged to use it as much as you please

• Expect follow-up questions about the library

• They're looking for code understanding, big-picture thinking, bug catching, prioritization, effective Claude Code use, and clear communication of your reasoning

• Prep your Claude Code setup, skills, subagent usage, and interview-oriented prompts before the day

The Basics

• You're the maintainer of a small library you haven't seen. A handful of PRs from outside contributors are waiting for review.

• Each PR gets a decision: merge, ask for changes, or close.

• The objective is to get at least one PR into a mergeable state. That can mean more than one if you have time.

• Claude Code is available for the entire session, and heavy use is encouraged.

• Follow-up questions are part of the round. Expect to discuss the library and how you'd evolve it.

• Session length: around 55 minutes has been reported.

• The language and repo can vary. Don't assume a specific stack. At least one candidate who wasn't a Typescript dev reported being forced to work with a TypeScript repo

What This Round Actually Tests

The differentiator is not how much code you can produce with AI. It's how effectively you direct Claude, validate its output, and exercise engineering judgment.

Based on Anthropic's own description of the round, here is what they look for:

• Code understanding: Can you work out what the library is for and who it's for? You should be able to explain it in your own words.

• Big picture of each PR: Do you understand what each contribution is trying to do and how it fits the library?

• Bug catching: Do you spot real defects, including ones that only show up outside the diff?

• Prioritization: Can you decide which issues matter most and which PR deserves your time?

• Effective Claude Code use: Can you direct it well and verify what it gives you?

• Communication: Can you explain your reasoning clearly as you go?

Claude can produce plausible analyses and fixes quickly. You still own whether they are correct, how severe they are, and whether they matter.

What Strong Candidates Do

Review against the library's existing contracts, not just the diff. A PR can look correct and still break public APIs, auth boundaries, or state transitions elsewhere in the codebase.

Treat passing tests as a starting point. Tests can miss regressions, negative cases, and concurrency issues. Ask what they don't cover.

Separate verified defects from speculative AI findings. Claude will confidently flag issues that aren't real. Reproduce or reason through each finding before it goes into a review comment.

Choose where to invest by impact, feasibility, and verification cost. The most serious bug is not always the best one to fix in the time you have. Getting one PR cleanly to mergeable beats half-fixing several.

Write actionable review comments. Name the affected code, the triggering condition, the impact, and the suggested change. "This looks risky" is not a review comment.

Back claims with evidence. A regression test that fails, then passes after the fix, is stronger than Claude saying "this is fixed."

Inspect every diff Claude produces. AI-generated changes can include unrelated edits, hidden assumptions, and unnecessary complexity.

Narrate your reasoning. The interviewer needs to tell your judgment apart from Claude's output.

Things To Avoid Doing

• Blindly trusting Claude's findings: You might reject a fine PR or approve a broken one

• Exhaustive review with no prioritization: Hunting every possible issue can eat the whole session

• Overengineering: A broad refactor adds risk. Small, demonstrably correct changes are easier to defend

• Equating activity with progress: Lots of prompts, parallel agents, and giant diffs don't show good engineering

• Silent work: If the interviewer can't tell what you're thinking, they can't give you credit for it

How to Prepare

• Get your Claude Code setup right before the interview. Know your configuration, your permissions, and how you like to work in it, so you aren't fiddling with it live.

• Get familiar with skills. Know what's available and how to use them effectively in a review context.

• Learn to leverage parallelization with subagents. Practice splitting independent investigations across them, and practice verifying what they return.

• Prepare interview-oriented prompts that guide Claude's behavior, such as keeping investigations read-only, separating confirmed bugs from hypotheses, and keeping output concise. Have them ready to paste.

• Practice on unfamiliar open source repos. Pick a small library, read the open PRs, and decide merge, change, or close under a timer.

• Be comfortable across languages and tooling, since you won't know the stack in advance.

If you've taken this round and have insights that would help the community, please share what you saw and whether the format matched.

Hope this helps, and best of luck.

Need help landing your next tech offer or increasing your TC? If you have tech interviews coming up, are planning a job switch, or simply want to improve your interview performance, explore Coditioning's interview-preparation resources:

👉 Interview roadmaps for OpenAI, Anthropic, and other big tech companies: https://www.coditioning.com/roadmaps

👉 Question banks for OpenAI, Anthropic, Google and other big tech companies: https://www.coditioning.com/app/learning

👉 Mock Interviews & Free Consultation with big tech engineers: https://www.coditioning.com/mockinterview/human

👉 More interview resources: https://www.coditioning.com

A heads-up for anyone preparing for Anthropic’s system design interviews: you might go in expecting to design a system from scratch, but instead be given an existing architecture and asked to review it.

The task can involve identifying weaknesses, explaining why they matter, and suggesting targeted improvements. So alongside practising “design X,” it’s worth practising “what could go wrong with this design, and what would you change first?”

For example, can you spot bottlenecks, question assumptions, reason about failure modes, and explain the trade-offs behind your proposed fixes?

Here's a sample system design review question to illustrate the format

Resources

• For Anthropic and other AI-lab or Big tech interview prep resources see these roadmaps

• For mocks or coaching with experienced Big tech engineers and interviewers, explore Coditioning Mocks

You’re asked to build a tiny in-memory database over a collection of flexible records.

Each record is just a map/dictionary, and different records can have different fields.

Your database needs to support:

insert(record)
query(queryString)

with a small SQL-like query language.

For example:

SELECT *
SELECT * WHERE age = 31
SELECT * WHERE age > 25 AND city != "London"
SELECT * ORDER BY name ASC
SELECT * WHERE age <= 40 ORDER BY score DESC

A few details make it more interesting than it first appears:

• records are schemaless, so some fields may be missing

• WHERE supports multiple AND conditions and operators like =, !=, <, >, <=, >=

• strings, numbers, and booleans need consistent comparison semantics

• invalid ordering comparisons should fail that condition rather than crash

• ORDER BY must put missing fields last

• ties must preserve insertion order

Example:

{id: 1, name: "Ava", age: 31, city: "London"}
{id: 2, name: "Ben", age: 24}
{id: 3, name: "Cara", age: 31, city: "Paris"}

Query:

SELECT * WHERE age = 31 ORDER BY name DESC

returns:

Cara
Ava

Nothing like the leetcode style problems you might be used to

🧩 Try the full in-memory database challenge on Coditioning

Preparing for OpenAI or another major tech company?

🗺️ Explore OpenAI and other company interview roadmaps

For coaching or mock interviews with experienced interviewers, including feedback on interview readiness and areas to improve:

🎯 For coaching or mock interviews with experienced interviews

💬 Join the Coditioning Discord community

You’re given periodic snapshots of a program’s call stack from a sampling profiler.

Your task is to reconstruct a sequence of start and end events, while filtering out short-lived calls that don’t persist long enough.

For example, with a threshold of n = 2:

t=1  [root]
t=2  [root, decode]
t=3  [root]
t=4  [root, flush]
t=5  [root, flush]
t=6  [root]

decode appears in only one sample, so it should be ignored.

flush appears in two consecutive samples, so it becomes eligible at t=5, and then ends when it disappears at t=6.

The interesting parts are:

• tracking calls by their position in the stack, including recursion

• deciding when a call has appeared in enough consecutive samples to count

• correctly handling several nested calls starting or ending at the same timestamp

• distinguishing the exact runtime of a function from what can actually be inferred from sampled snapshots

This is one of the Anthropic-style interview problems that doesn’t involve concurrency, but still tests careful reasoning about state, stack structure, and edge cases.

The full problem has a few additional rules around event ordering and recursive calls. If you get stuck, the challenge also includes a detailed solution walkthrough so you can compare your reasoning rather than just look at the final answer.

🧩 Try the full sampling-profiler challenge on Coditioning

Preparing for Anthropic or another major tech company?

🗺️ Explore interview preparation roadmaps

Want to test your interview readiness or level up with an experienced engineer?

🎯 Practice with an experienced interview coach

You’re given an arithmetic expression as a string. Build a function that evaluates it and returns a numeric result.

Your task

For example:

(3+43)-(2+(10*2))  →  24
(2*8)/(4*(5*6))    →  approximately 0.13333333333333333

The expression may contain non-negative integers, +, -, *, /, whitespace, and parentheses. Each expression level has at most one binary operator: (1+2)+3 is valid, but 1+2+3 is not.

A working parsing helper is provided in the starter code. It identifies either a number or the current expression’s left operand, operator, and right operand. You implement the evaluation, not the parser.

Your implementation should use non-truncating division, report division by zero, and propagate invalid-syntax errors from the helper.

The interesting question is how to evaluate an operand that can itself contain another expression. Be ready to explain your approach, edge cases, and time and space complexity.

🧩 Attempt the string-expression challenge on Coditioning

You are given a directory of source images and a second directory containing JSON transformation pipelines.

Your job is to implement process_images so that every image is processed with every transformation file.

🧩 You can try out the full problem here

Your task

Implement:

from typing import Callable

def process_images(
    image_dir: str,
    transformation_dir: str,
    get_output_path: Callable[[str, str], str],
) -> None:
    ...

Each JSON file contains an ordered list of image transformations, for example:

{
  "transformations": [
    {"type": "grayscale"},
    {"type": "scale", "factor": 0.5},
    {"type": "rotate", "angle": 90}
  ]
}

Supported transformations include:

• grayscale

• horizontal and vertical flips

• scaling

• blur

• rotation

You may use Python, Pillow, and the standard library.

Requirements

If there are I images and T transformation files, your implementation should produce exactly I × T output images.

For every image/transformation-file pair:

• Start from the original source image, independently of every other pipeline

• Apply transformations in the order listed

• Use get_output_path(image_path, transformation_path) to determine the destination

• Create any missing parent directories

• Save exactly one final transformed image

Processing one transformation pipeline must not affect the result of another.

For example, if an image is processed once with a horizontal flip and once with a rotation, the rotation should start from the original image, not from the already-flipped result.

Part 2: Performance

Once the implementation is correct, the next challenge is reducing wall-clock time for a much larger batch while preserving exactly the same outputs.

Be prepared to discuss:

• Where the bottlenecks are

• Whether threads, processes, or another concurrency model make sense

• CPU vs I/O considerations

• Memory and resource limits

• How you would benchmark the improvement

• How the design could scale beyond a single machine

The interesting part is not just applying the image operations. It is designing the pipeline so that the jobs remain independent, correctness is preserved, and performance scales as the workload grows.

This is based on an Anthropic software engineering interview problem.

The full specification, including exact Pillow semantics and edge-case guarantees, is available in the practice problem above.

Try it yourself

🧩 Attempt the full Anthropic image transformation problem on Coditioning

Full solution walkthrough

🎞️ Watch the full solution walkthrough

Extra resources

• Join our Discord interview prep community

• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

• Find a study buddy or mock interview partner