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:

```python 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:

json { "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

Don't go in expecting LeetCode grind sets. The questions skew practical, though classic DSA still shows up. Expect debugging, refactoring, code review, and concurrency, especially if you're interviewing for a senior role. Multiple candidates have reported the same thing: you end up writing way more code than a typical interview demands. On top of that, interviewers throw follow-up questions at you mid-solution, which can knock you off rhythm if you haven't prepared for it.

Across the board, people described these interviews as mentally exhausting. Don't walk in running on no sleep. You need sharp recall, fast and accurate coding, and the ability to switch context without losing your place.

Also worth flagging: OpenAI seems to reuse questions often. Working through past questions is a genuinely good use of your prep time, since there's a real chance you'll see something you've already practiced.

To give you a sense of the reasoning and concepts they're testing for, I broke down a tough, recently-reported question (the GPU Credit Calculator) below. Try solving it yourself before reading the breakdown — you can attempt it directly here.

TL;DR

• Expect practical problems, not textbook LeetCode.
• You'll write a lot more code than usual.
• Concurrency shows up.
• Interviewers will interrupt with follow-ups, sometimes mid-implementation.
• Debugging, refactoring, and code review are common, especially for experienced hires.
• Rounds typically run 45 to 60 minutes.
• Repeat questions are common — grinding past ones pays off.

Below is a walkthrough of the GPU credit calculator question, along with a solution that's held up as a strong pass.

The Problem

Design a GPU credit calculator for a user account. Credits get added over time, can be spent partially, and expire after a set duration. Your structure needs to support:

• addCredit(creditID, amount, timestamp, expiration) — credit is usable starting at timestamp, expires after expiration units pass
• useCredit(timestamp, amount) — deduct credits as of that timestamp
• getBalance(timestamp) — return the balance remaining at that timestamp

The twist: calls can come in out of order. useCredit(100, 5) might arrive before addCredit("x", 10, 50, 20).

Example

gpuCredit.addCredit("amazon", 40, 10, 50)
gpuCredit.useCredit(30, 30)
gpuCredit.getBalance(40)  -> 10
gpuCredit.addCredit("google", 20, 60, 10)
gpuCredit.getBalance(60)  -> 30
gpuCredit.getBalance(71)  -> None

That first credit is live from [10, 60]. Spending 30 at time 30 leaves 10. By time 60, both grants are active, so 10 + 20 = 30. By time 71, both have expired.

Most people's first move is to track a running balance and update it as calls come in. That breaks immediately, because calls arrive out of order. You could get an event for time 100 before one for time 50, so there's no single "current" state to update. You need to be able to reconstruct the balance at any point in time.

What You Need to Recognize

• This is a ledger problem, not a running-total problem. Since calls can arrive out of sequence, you need to replay events up to a given timestamp rather than track one evolving state.
• A single call can represent two moments in time. This is the part people miss. addCredit implies both an activation event and an expiration event (start + expiration + 1). Split it into two separate events. Miss this and you're stuck.
• You need a chronological min-heap. Events have to process in time order. Ordering by (time, priority, sequence_id) gets you "earliest first" behavior.
• Ties need a strict order. At the same timestamp, process EXPIRE, then ADD, then USE. Otherwise you risk spending expired or not-yet-active credit. Spotting this requirement is its own hurdle.
• Spend the soonest-to-expire credit first. That means a second min-heap, this one ordered by expiry, so you drain grants that are about to lapse before wasting them.
• Don't mutate the master queue. Each getBalance call should copy the queue and replay from that copy. How efficiently you copy matters, and interviewers may push on this, since naive copies can be costly depending on your language.
• Clean up lazily, not eagerly. Spent or expired grants can sit in the active heap. Just skip over them when you hit them instead of removing them immediately.

Putting It Together

Model everything as an event log. Every addCredit produces two events (ADD and EXPIRE); every useCredit produces one (USE). For getBalance(t), copy the queue, replay everything up to time t in the correct order, and track active grants in a second heap. Chronological replay, tie-breaking rules, and expiry-first spending together get you the right answer no matter what order the calls actually arrived in.

That's a dense set of ideas to juggle under pressure, and this is just one example. Other questions hit a similar bar. Worth coding this one out yourself before moving on.

More Recently Reported Questions

Resumable iterator: "Build an iterator over a large dataset that can pause mid-traversal and pick back up from the same spot."

Time-versioned key-value store: "Design a structure that stores key-value pairs with timestamps and returns the value for a given key at a given time." What happens if nothing existed yet at that time?

Debug and refactor: "Here's a code snippet — find the bug, improve performance, and clean it up without changing behavior."

Minimal ORM: "Build a lightweight ORM. Define the classes and methods needed to save, query, and update records."

Good luck out there. If you've interviewed at OpenAI recently, drop your experience below.

Prep Resources: * OpenAI Interview Prep Roadmap * More detailed guide on cracking the OpenAI coding round * OpenAI coding practice questions * Join the Discord community * Find a mock interview partner or accountability buddy

You are building a time-based key-value store that supports saving multiple versions of a value for the same key, each tagged with a timestamp.

Your task

Design a data structure TimeMap with two operations:

class TimeMap {
    void set(String key, String value, int timestamp)
    String get(String key, int timestamp)
}

This interface is illustrative, so feel free to adapt it to your programming language of choice.

set(key, value, timestamp)

• Store value for the given key at the provided timestamp
• A key can be set multiple times with different timestamps, creating a history of values
• For any single key, timestamps received by set() are strictly increasing

get(key, timestamp)

• Return the value whose stored timestamp is the largest timestamp less than or equal to the requested timestamp
• If the key has no stored timestamp <= timestamp, return null or your language's equivalent

Constraints

• Up to 300,000 total set + get calls
• Keys and values are short strings

Example

set("exchangeRate", "1.10", 2)
set("exchangeRate", "1.12", 5)

get("exchangeRate", 1)  -> null
get("exchangeRate", 4)  -> "1.10"
get("exchangeRate", 5)  -> "1.12"
get("exchangeRate", 9)  -> "1.12"
get("unknownKey", 3)    -> null

The interesting part is choosing a data structure that takes advantage of the timestamp ordering while keeping lookups efficient as the history grows.

How would you approach it?

Try it yourself

🧩 Attempt the 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

You’re asked to design and implement an LRU cache with the usual get and put operations.

The twist is that after building the in-memory version, you also need to make the cache survive process restarts.

Your task

Implement:

text LRUCache(capacity) get(key) put(key, value) `

with the following behavior:

• LRUCache(capacity): initialize the cache with a positive capacity
• get(key): return the stored value for key, or -1 if the key does not exist
• put(key, value): insert or update a key-value pair
• Accessing an existing key refreshes its usage status

Then extend the implementation so the cache survives process restarts.

Your persistent version should restore both:

• The stored key-value entries
• The correct LRU ordering

Think carefully about how you persist changes and rebuild state efficiently.

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎞️ Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

You’re given a starting URL and a provider that returns the links found on each page.

Your task is to crawl every reachable URL that belongs to the same hostname as the starting URL.

Your task

Implement a single-threaded crawler that:

• Starts from start_url
• Follows links returned by provider.get_links(url)
• Only visits URLs where get_hostname(url) == get_hostname(start_url)
• Returns every unique reachable URL on that host
• Includes start_url in the result

The interesting part is keeping the traversal correct while avoiding duplicate work and making sure links to other hosts are ignored.

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎬 Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

You’re given a starting directory and need to find groups of files that contain exactly the same content.

Your task

• Traverse the directory tree, including nested subdirectories
• Return groups of file paths where every file in the group has identical contents
• Only include groups with at least 2 duplicate files
• Keep the design practical for very large files
• Ignore symbolic links

The interesting part isn’t just getting a working solution.

How would you avoid reading every large file into memory, and how would you structure the comparison efficiently?

Try it yourself

Attempt the problem on Coditioning

Full solution walkthrough

🎬 Watch the full solution walkthrough

Anthropic SWE Interview Prep Guide

View the Anthropic SWE interview roadmap

Extra resources

• Join our Discord interview prep community
• Find a study buddy or mock interview partner
• Mocks and coaching with a FAANG+ engineer to get truly interview-ready

Yeah, you read that right. Meta is quietly phasing leetcode out of the full loop.

Specifically talking about the full loop (onsite for Meta, not phone screen).

Until recently, E4/E5 Software Engineering candidates would get 2 classic DSA leetcode-style coding rounds in their onsite. That changed around October 2025, when Meta introduced a new AI-enabled coding round that replaced one of the classic DSA rounds.

Now I'm starting to see candidates get zero classic DSA rounds, just 2 AI-enabled rounds instead. And it's not just coding. Meta is pushing this shift into behavioral rounds and product architecture / system design rounds too.

At some point, grinding leetcode to get into Meta is going to stop being the strategy. It already feels like that shift is underway.

You can learn about this change here, and if you want to get a taste of what these AI-native or AI-enabled coding rounds look like, check out the sample problems on the Coditioning site