Anthropic·Software Engineer·Technical Phone Screen·Senior

SeniorPrefer not to say

May 2026Remote

Summary

Interviewed for a software engineer role at Anthropic and got a mix of graph traversal, file system parsing, and a spicy LRU cache extension. The last one had more layers than I expected going in.

Questions Asked (3)

Implement a web crawler that starts from a given URL and only visits pages within the same hostname.

Algorithms & Data StructuresSystem Design

Author's notes

Straightforward BFS/DFS problem once you realize hostname filtering is the whole point.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then outline a BFS-based crawler with a visited set and same-hostname filter. Discuss politeness, scalability, and potential pitfalls like infinite loops or duplicate content.

Pro tip: Mention robots.txt and rate limiting early to show production awareness, and propose a distributed architecture with a URL frontier and deduplication for large-scale crawling.

1. Clarify Requirements

Ask about scale, politeness, depth limits, and whether to respect robots.txt. Confirm that only same-hostname pages should be visited.

2. Design Core Algorithm

Use BFS with a queue and a visited set to avoid cycles. Extract links from each page and enqueue only those with the same hostname.

3. Address Politeness and Scalability

Implement rate limiting per host, respect robots.txt, and consider distributed crawling with a URL frontier and deduplication for large-scale crawls.

4. Handle Edge Cases and Errors

Discuss handling redirects, non-HTML content, timeouts, and malformed URLs. Ensure the crawler is robust and doesn't crash on errors.

5. Analyze Trade-offs and Optimizations

Compare BFS vs DFS, discuss memory usage of visited set, and propose optimizations like bloom filters or partitioning for very large crawls.

Key Points to Mention

BFS traversal with a queue and visited set to avoid cycles and ensure completeness.
Same-hostname filtering: compare the hostname of extracted URLs to the starting URL's hostname.
Politeness: rate limiting, robots.txt compliance, and user-agent identification.
Scalability: distributed crawling, URL frontier, deduplication, and storage of visited URLs.
Handling dynamic content, JavaScript rendering, and infinite scroll (if relevant).
Error handling: timeouts, HTTP errors, and malformed URLs.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Given a list of file paths and their contents, find all groups of duplicate files based on content.

Algorithms & Data Structures

Author's notes

Parsing the input string format was the annoying part.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., file size limits, memory constraints, whether to consider file names). Then propose a multi-pass approach: first group by file size, then compute a hash (e.g., SHA-256) for files of the same size, and finally confirm duplicates by byte-by-byte comparison if needed. Discuss trade-offs between time and space, and consider edge cases like empty files or hash collisions.

Pro tip: Mention that you can optimize by only hashing files with matching sizes, and that using a cryptographic hash like SHA-256 makes collisions practically impossible, so you can skip byte-by-byte comparison in most cases. Also, note that you should handle large files by streaming the hash computation to avoid loading entire files into memory.

1. Clarify Requirements and Constraints

Ask about input format, expected file sizes, memory limits, and whether file names matter. Confirm if the solution should be exact or approximate.

2. Group by File Size

Create a map from file size to list of file paths. This quickly eliminates files that cannot be duplicates, reducing the number of files to hash.

3. Compute Hashes for Candidates

For each group of files with the same size, compute a strong hash (e.g., SHA-256) of each file's content. Use streaming to handle large files efficiently.

4. Group by Hash and Optionally Verify

Group files by their hash values. If using a cryptographic hash, you can consider these groups as duplicates. If extra safety is needed, perform byte-by-byte comparison within each hash group.

5. Return Groups of Duplicate Files

Output the groups of file paths that have identical content. Discuss how to handle empty files and whether to include them as duplicates.

Key Points to Mention

Time and space complexity: O(n) for grouping by size, O(n * m) for hashing where m is average file size, but streaming reduces memory.
Hash collision probability and why cryptographic hashes are preferred over checksums like MD5 for duplicate detection.
Handling large files: use streaming APIs to compute hashes without loading entire file into memory.
Edge cases: empty files, files with same content but different names, symbolic links, and permission issues.
Optimization: skip hashing for files with unique sizes, and use a two-level hash (e.g., quick hash then strong hash) if needed.
Real-world considerations: parallelizing hash computation, using external sorting for very large datasets, and memory management.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Extend a standard LRU cache implementation to work as a decorator that handles variable-length positional and keyword arguments, and also support serialization and deserialization for persistence.

Algorithms & Data StructuresTechnical Trade-offsAPI & Integrations

Author's notes

This one got me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, then design a decorator that wraps a function with an LRU cache, handling arbitrary positional and keyword arguments by creating a hashable key. For persistence, implement serialization of the cache state (e.g., using pickle or JSON) and deserialization on initialization, ensuring thread safety and eviction policy are maintained.

Pro tip: Mention that you would use functools.lru_cache as a reference but extend it to support persistence, and highlight the importance of handling unhashable arguments by either raising a clear error or converting them to a hashable form.

1. Clarify Requirements and Constraints

Ask about expected cache size, eviction policy, persistence format, thread safety, and whether arguments are guaranteed hashable. This ensures the solution meets the actual needs.

2. Design the Decorator and Key Generation

Create a decorator that wraps the target function, generates a unique key from *args and **kwargs (e.g., using a tuple of args and sorted kwargs), and manages an LRU cache with a doubly linked list and hash map.

3. Implement LRU Eviction and Cache Operations

Use an OrderedDict or custom linked list to track access order, evict the least recently used item when capacity is exceeded, and update order on cache hits.

4. Add Serialization and Deserialization

Implement methods to serialize the cache state (keys and values) to a file or string, and deserialize on initialization, ensuring the LRU order is preserved and the cache is repopulated correctly.

5. Address Edge Cases and Trade-offs

Discuss handling of unhashable arguments, thread safety (e.g., using locks), persistence format choices (pickle vs JSON), and performance implications of serialization.

Key Points to Mention

Handling variable arguments by creating a hashable key from *args and **kwargs, such as using a tuple of args and a frozenset of sorted kwargs items.
LRU eviction implementation using a combination of a dictionary and a doubly linked list (or OrderedDict) for O(1) operations.
Serialization considerations: choosing between pickle (supports arbitrary Python objects) and JSON (human-readable but limited types), and ensuring the LRU order is preserved.
Thread safety: using locks to protect cache operations if the decorator is used in a multithreaded environment.
Handling unhashable arguments: either raising a clear TypeError or attempting to convert to a hashable form, and documenting the limitation.
Persistence strategy: when to save (e.g., on every update, periodically, or on exit) and how to load (e.g., lazy loading or eager loading).

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.