# Interviews — Administrator & Developer Guide

## 1. Architecture Overview

**Interviews** is a curated collection of 500+ Java solutions for coding interview preparation, organized as a flat-file repository with no runtime, no build system, and no external dependencies. The entire project consists of standalone `.java` files grouped into a directory hierarchy that serves as both the organizational schema and the navigation interface.

### Structural Design

The repository follows a **topic-first filing system** where the directory path encodes the problem's metadata:

```text
interviews/
├── leetcode/                          ← Algorithm-categorized LeetCode solutions
│   ├── array/                         ← 29 solutions
│   ├── hash-table/                    ← 24 solutions
│   ├── string/                        ← 22 solutions
│   ├── dynamic-programming/           ← 20 solutions
│   ├── two-pointers/                  ← 10 solutions
│   ├── tree/                          ← 8 solutions
│   ├── bit-manipulation/              ← 8 solutions
│   ├── depth-first-search/            ← 7 solutions
│   ├── breadth-first-search/          ← 7 solutions
│   ├── stack/                         ← 7 solutions
│   ├── linked-list/                   ← 7 solutions
│   ├── math/                          ← 7 solutions
│   ├── backtracking/                  ← 5 solutions
│   ├── binary-search/                 ← 5 solutions
│   ├── trie/                          ← 3 solutions
│   ├── design/                        ← 3 solutions
│   ├── divide-and-conquer/            ← 2 solutions
│   ├── sort/                          ← 2 solutions
│   ├── greedy/                        ← 1 solution
│   ├── queue/                         ← 1 solution
│   └── brainteaser/                   ← 1 solution
├── company/                           ← Company-tagged interview problems
│   ├── facebook/                      ← 65 solutions
│   ├── google/                        ← 60 solutions
│   ├── amazon/                        ← 27 solutions
│   ├── uber/                          ← 27 solutions
│   ├── linkedin/                      ← 21 solutions
│   ├── twitter/                       ← 12 solutions
│   ├── airbnb/                        ← 9 solutions
│   ├── microsoft/                     ← 9 solutions
│   ├── bloomberg/                     ← 6 solutions
│   ├── snapchat/                      ← 3 solutions
│   ├── adobe/                         ← 2 solutions
│   ├── apple/                         ← 2 solutions
│   ├── palantir/                      ← 2 solutions
│   ├── yahoo/                         ← 2 solutions
│   └── yelp/                          ← 2 solutions
├── cracking-the-coding-interview/     ← CTCI book chapter exercises
│   ├── chapter-one-arrays-and-strings/              ← 6 solutions
│   ├── chapter-two-linked-lists/                    ← 5 solutions
│   ├── chapter-three-stacks-and-queues/             ← 8 solutions
│   ├── chapter-four-trees-and-graphs/               ← 7 solutions
│   ├── chapter-five-bit-manipulation/               ← 4 solutions
│   ├── chapter-seven-mathematics-and-probability/   ← 2 solutions
│   └── chapter-nine-recursion-and-dynamic-programming/ ← 7 solutions
├── uva/                               ← 47 UVA Online Judge solutions
└── images/                            ← Diagrams for README (not solutions)
```

> [!NOTE]
> The directory structure is the architecture. There is no runtime component, no build system, no configuration, no database, and no API. The repository is a static collection of source files whose value comes entirely from its organizational scheme and the quality of its solutions.

### Component Inventory

| Component | Path | Role | File Count |
|---|---|---|---|
| LeetCode solutions | `leetcode/` | Algorithm-categorized problem solutions | ~179 |
| Company solutions | `company/` | Employer-tagged interview problems | ~249 |
| CTCI solutions | `cracking-the-coding-interview/` | Book chapter exercises | ~39 |
| UVA solutions | `uva/` | Competitive programming solutions | 47 |
| Images | `images/` | README diagrams (data structure visualizations, algorithm animations) | 24 |
| IDE project files | Root + section roots | IntelliJ IDEA module definitions | 4 |

### Technology Stack

| Layer | Technology |
|---|---|
| Language | Java 8+ (no Java 9+ module system, no lambdas) |
| Build system | None — standalone file compilation |
| Dependencies | None — Java standard library only (`java.util.*`, `java.math.*`) |
| IDE support | IntelliJ IDEA `.iml` project files |
| Version control | Git |

### Content Duplication Model

A key architectural decision is **intentional file duplication** across the company folders. When multiple companies ask the same problem, the solution file is copied into each company's directory rather than symlinked or referenced. This means:

- `MergeKSortedLists.java` exists in 7 company folders plus `leetcode/linked-list/`
- `InsertDeleteGetRandomO1.java` exists in 7 company folders plus `leetcode/design/`
- `ValidParentheses.java` exists in 5 company folders

The duplication is by design — it enables per-company browsing without cross-referencing. The trade-off is maintenance burden: updating a solution requires touching every copy.

## 2. System Requirements

| Requirement | Details |
|---|---|
| Java JDK | 8 or later (solutions use `HashMap`, `ArrayList`, `Arrays`, `Scanner`, `BigInteger` — all in `java.util` and `java.math`) |
| Git | Any version supporting `clone` |
| Disk | ~10 MB for the full repository |
| OS | Any (Java is cross-platform) |

> [!IMPORTANT]
> There are no external dependencies. No `pom.xml`, no `build.gradle`, no `package.json`. The repository is self-contained with zero third-party libraries.

## 3. Configuration Reference

The repository has no configuration files, no environment variables, and no runtime settings. The four `.iml` files are IDE metadata, not application configuration:

| File | Purpose |
|---|---|
| `interviews.iml` | Root IntelliJ project module |
| `leetcode/LeetCode.iml` | LeetCode section module |
| `cracking-the-coding-interview/CrackingTheCodingInterview.iml` | CTCI section module |
| `company/Company.iml` | Company section module |

The `.gitignore` excludes standard IDE and OS artifacts:

```text
*.class
*.DS_Store
.idea/
out/
```

## 4. Operations

### Content Maintenance

#### Adding a New Problem

1. Identify the problem's primary algorithm category
2. Create `ProblemName.java` in the appropriate `leetcode/{category}/` folder
3. If the problem is asked by specific companies, copy the file into each `company/{name}/` folder
4. If the problem is from CTCI, place it in the matching `cracking-the-coding-interview/chapter-{N}-{topic}/` folder

> [!TIP]
> Follow the existing naming convention: PascalCase file names matching the problem title with spaces removed (e.g., "Best Time to Buy and Sell Stock" becomes `BestTimeToBuyAndSellStock.java`).

#### Updating an Existing Solution

When updating a solution that exists in multiple folders, update every copy. Use `find` to locate all instances:

```bash
find . -name "TwoSum.java" -type f
```

```text
./company/airbnb/TwoSum.java
./company/amazon/TwoSum.java
./company/facebook/TwoSum.java
./company/linkedin/TwoSum.java
./company/uber/TwoSum.java
./leetcode/hash-table/TwoSum.java
```

> [!WARNING]
> Failing to update all copies creates inconsistency. There is no automated mechanism to keep duplicated files in sync. Consider scripting bulk updates for widely-duplicated problems.

#### Adding a New Company

1. Create `company/{companyname}/` (lowercase, no spaces)
2. Copy relevant solution files from `leetcode/` or other company folders
3. Add a `.iml` entry if maintaining IntelliJ project structure (optional)

#### Adding a New CTCI Chapter

1. Create `cracking-the-coding-interview/chapter-{N}-{topic}/` using the word-spelled-number convention (e.g., `chapter-six-brain-teasers`)
2. Add solution files named after the exercise

> [!NOTE]
> Currently chapters 6, 8, 10, and above are missing. GitHub issue [#211](https://github.com/kdn251/interviews/issues/211) proposes renaming existing chapters. Any renaming would require updating references in the README.

### Known Issues (from GitHub)

| Issue | Status | Description |
|---|---|---|
| [#261](https://github.com/kdn251/interviews/issues/261) | Open | Duplication in Queue Data Structure section |
| [#200](https://github.com/kdn251/interviews/issues/200) | Open | Misleading example in Greedy Algorithms section |
| [#211](https://github.com/kdn251/interviews/issues/211) | Open | Proposal to rename CTCI chapter directories |
| [#144](https://github.com/kdn251/interviews/issues/144) | Open | Request for more Adobe problems |
| [#94](https://github.com/kdn251/interviews/issues/94) | Open | Issue with `leetcode/hash-table/TwoSum.java` |
| [#247](https://github.com/kdn251/interviews/issues/247) | Open | Translation to Spanish |

## 5. Security

> [!NOTE]
> This repository has no runtime component, no network access, no user input processing (except UVA solutions reading stdin), and no authentication. The security surface is minimal.

### Code Safety Considerations

- **No external dependencies** — eliminates supply chain risk entirely
- **No file I/O** — solutions operate on in-memory data structures only (except UVA `Scanner` input)
- **No network calls** — no HTTP clients, no socket connections, no URL fetching
- **No reflection or dynamic class loading** — all code is statically typed
- **UVA solutions** read from `System.in` via `Scanner` — safe for local testing; designed for sandboxed online judge environments

### Repository Security

- The repository is public on GitHub — no secrets, credentials, or sensitive data are stored
- `.gitignore` excludes `.idea/` (IDE settings) and `*.class` (compiled bytecode)
- No CI/CD pipeline, no deployment scripts, no infrastructure-as-code

## 6. Developer Internals

### Solution File Convention

Every solution file follows this structure:

```java
// Problem statement as line comments or Javadoc block comment
// Example input/output included in comments
// Constraints and follow-up questions in comments

public class ProblemName {
    public ReturnType methodName(ParamType param) {
        // Inline comments explaining the algorithm approach
        // Implementation
    }
}
```

**Conventions observed across the codebase:**

| Convention | Pattern |
|---|---|
| File naming | PascalCase matching problem title: `BestTimeToBuyAndSellStock.java` |
| Class naming | Matches filename (with occasional inconsistencies — see below) |
| Method naming | camelCase, matches LeetCode's expected method signature |
| Comments | Problem statement as `//` line comments at top; algorithm notes inline |
| Imports | Usually omitted (solutions assume `java.util.*` is available) |
| Access modifiers | Classes are usually `public`; some use default (package-private) access |
| Main methods | Absent in LeetCode/company/CTCI; present in UVA solutions |

> [!WARNING]
> Several files have mismatched class/file names. Known instances:
> - `cracking-the-coding-interview/chapter-one-arrays-and-strings/DeleteDups.java` declares `class RemoveDups`
> - `company/google/RegularExpressionMatching.javaa` has a malformed `.javaa` extension

### Algorithm Patterns Reference

The solutions demonstrate these core algorithm patterns:

| Pattern | Example Solutions | Technique |
|---|---|---|
| **Sliding Window** | `MinimumWindowSubstring`, `LongestSubstringWithAtMostKDistinctCharacters` | Two pointers maintaining a window with HashMap frequency counts |
| **Two Pointers** | `3Sum`, `MoveZeros`, `SortColors` | Left/right pointers on sorted array, or fast/slow for cycle detection |
| **BFS/DFS** | `NumberOfIslands`, `CloneGraph`, `WallsAndGates` | Queue-based level order (BFS) or recursive/stack-based (DFS) traversal |
| **Dynamic Programming** | `CoinChange`, `EditDistance`, `WordBreak` | Bottom-up tabulation with 1D or 2D arrays |
| **Backtracking** | `Permutations`, `GenerateParentheses`, `LetterCombinations` | Recursive exploration with state rollback |
| **Binary Search** | `SearchInRotatedSortedArray`, `FirstBadVersion` | Modified binary search on sorted or rotated arrays |
| **Divide & Conquer** | `KthLargestElementInAnArray`, `ExpressionAddOperators` | Partitioning via quickselect or recursive decomposition |
| **Stack-based** | `MinStack`, `DecodeString`, `TrappingRainWater` | Monotonic stack or auxiliary stack tracking state |
| **Trie** | `ImplementTrie`, `AddAndSearchWord`, `WordSquares` | 26-child node arrays with terminal markers |
| **Bit Manipulation** | `HammingDistance`, `SingleNumber`, `CountingBits` | XOR, AND masking, Brian Kernighan's algorithm |
| **Greedy** | `BestTimeToBuyAndSellStockII` | Local optimal choices yielding global optimum |

### Data Structure Implementations

The repository includes from-scratch implementations of several data structures:

#### MinStack (`leetcode/design/MinStack.java`)

Uses a linked-list approach where each node stores both its value and the minimum value seen so far in the stack below it. This achieves O(1) `push`, `pop`, `top`, and `getMin`.

```java
class Node {
    int data;
    int min;
    Node next;
    public Node(int data, int min) {
        this.data = data;
        this.min = min;
    }
}
```

#### Trie (`leetcode/trie/ImplementTrie.java`)

Standard trie with a 26-element `TrieNode[]` children array. Supports `insert`, `search`, and `startsWith` operations.

#### RandomizedSet (`leetcode/design/InsertDeleteGetRandomO1.java`)

Combines a `HashMap<Integer, Integer>` with an `ArrayList<Integer>` to achieve O(1) average time for `insert`, `remove`, and `getRandom`. The HashMap maps values to their ArrayList indices.

#### ZigzagIterator (`leetcode/design/ZigZagIterator.java`)

Alternates between two iterators by swapping `i` and `j` references on each `next()` call. If the primary iterator is exhausted, the secondary iterator continues.

### Module Reference

#### LeetCode Section (`leetcode/`)

21 algorithm category subdirectories containing ~179 total solutions. Each subdirectory contains solutions for a single algorithm technique. The largest categories are `array` (29), `hash-table` (24), `string` (22), and `dynamic-programming` (20).

**Key implementation patterns by category:**

- **`array/`** — In-place manipulation, prefix products (`ProductOfArrayExceptSelf`), matrix traversal (`SpiralMatrix`, `RotateImage`), interval merging (`MergeIntervals`)
- **`hash-table/`** — Frequency counting (`GroupAnagrams`), index mapping (`TwoSum`), sliding window with map (`MinimumWindowSubstring`)
- **`string/`** — Expand-around-center palindromes (`LongestPalindromicSubstring`), character frequency arrays (`ValidAnagram`), recursive parsing (`DecodeWays`)
- **`dynamic-programming/`** — 1D tabulation (`ClimbingStairs`, `HouseRobber`), 2D tabulation (`EditDistance`, `UniquePaths`), knapsack variants (`CoinChange`), regex matching (`RegularExpressionMatching`)
- **`tree/`** — Recursive traversal (`BinaryTreePaths`), BST validation (`ValidateBinarySearchTree`), path sum computation (`BinaryTreeMaximumPathSum`)
- **`stack/`** — Monotonic stack (`TrappingRainWater`, `DailyTemperatures`), recursive descent parsing (`DecodeString`), iterator flattening (`FlattenNestedListIterator`)

#### Company Section (`company/`)

15 company subdirectories containing ~249 total solutions. Files are copies of LeetCode solutions tagged by employer. The Facebook and Google folders are the largest, containing 65 and 60 solutions respectively.

> [!TIP]
> For a contribution that adds a new company, create the directory, copy the relevant solution files, and verify each copy compiles. The community has requested more Adobe problems ([#144](https://github.com/kdn251/interviews/issues/144)).

#### CTCI Section (`cracking-the-coding-interview/`)

7 chapter subdirectories containing ~39 total solutions. Chapters use word-spelled directory names (e.g., `chapter-one-arrays-and-strings` rather than `chapter-1-arrays-and-strings`). Not all CTCI chapters are covered — chapters 6, 8, 10+ are absent.

**Chapter coverage:**

| Chapter | Topic | Solutions | Notable Implementations |
|---|---|---|---|
| 1 | Arrays & Strings | 6 | `IsUniqueChars` (bit manipulation), `ReplaceSpaces` (in-place with reverse fill) |
| 2 | Linked Lists | 5 | `DeleteDups` (HashSet dedup), `FindBeginning` (Floyd's cycle detection) |
| 3 | Stacks & Queues | 8 | `ThreeStacks` (single array), `TowersOfHanoi` (recursive), `SetOfStacks` |
| 4 | Trees & Graphs | 7 | `CreateBinarySearchTree` (sorted array to BST), `FindPath` (BFS), `ValidBinarySearchTree` |
| 5 | Bit Manipulation | 4 | `InsertMIntoN` (bit masking), `BinaryRepresentation` (double to binary string) |
| 7 | Math & Probability | 2 | `Operations` (add/subtract/multiply/divide using only add), `WouldIntersect` |
| 9 | Recursion & DP | 7 | `EightQueens` (backtracking), `AllPermutations`, `StackBoxes` (memoized recursion) |

#### UVA Section (`uva/`)

47 competitive programming solutions, each with a `main` method reading from `Scanner` and writing to `System.out`. These are complete, submission-ready programs unlike the other sections.

**Notable solutions:**

| Problem | Algorithm Used |
|---|---|
| `AddingReversedNumbers` | BigInteger arithmetic with string reversal |
| `VirtualFriends` | Union-Find (disjoint set) |
| `TheSettlersOfCatan` | DFS on graphs |
| `EightQueens` (via `MischievousChildren`) | Permutation counting |
| `BigMod` | Modular exponentiation |
| `FiveHundredFactorial` | BigInteger factorial |
| `GoldbachConjecture` | Prime sieve + pair finding |

### Code Quality Analysis

**Strengths:**

- Consistent file naming convention (PascalCase)
- Problem statements included as comments in every file
- Clean, readable implementations prioritizing clarity over cleverness
- Good coverage of fundamental algorithm categories
- Inline comments explain algorithm choices (e.g., "Kadane's algorithm" in `BestTimeToBuyAndSellStock`)

**Areas for improvement:**

- Missing imports in most files — solutions assume `java.util.*` is globally available
- No unit tests — solutions are verified on LeetCode/UVA platforms, not locally
- Intentional file duplication across company folders creates maintenance burden (~70% of company files are duplicates of LeetCode solutions)
- Inconsistent class/file name matching in some CTCI solutions
- Malformed file extension: `company/google/RegularExpressionMatching.javaa`
- No package declarations — all classes are in the default package
- Some solutions use suboptimal approaches (e.g., `FindAllNumbersDisappearedInAnArray` uses HashMap where in-place marking achieves O(1) space)

> [!CAUTION]
> The lack of package declarations means all classes exist in the default package. If you compile multiple solutions in the same directory that define helper classes with the same name (e.g., multiple `Node` or `ListNode` definitions), you will get compilation conflicts. Compile solutions individually or add package declarations.

### Testing Strategy

The repository has no automated tests. Solutions are validated through:

1. **Online judge submission** — LeetCode and UVA solutions are verified by submitting to the respective platforms
2. **Manual testing** — creating ad-hoc `main` methods or test drivers (not committed)
3. **Code review** — pull request review by maintainers

**Recommended testing approach for contributors:**

```java
// Create a test class in the same directory
public class TestSolution {
    public static void main(String[] args) {
        // Instantiate solution class
        TwoSum solution = new TwoSum();
        
        // Test with known inputs
        int[] result = solution.twoSum(new int[]{2, 7, 11, 15}, 9);
        assert result[0] == 0 && result[1] == 1 : "Test failed";
        
        System.out.println("All tests passed");
    }
}
```

> [!TIP]
> Consider adding JUnit tests in a `tests/` directory for systematic validation. This would catch regressions when solutions are updated and verify that duplicated files remain consistent.

### Potential Improvements

1. **Deduplication** — Replace copied files in `company/` with a metadata file or README that links to the canonical `leetcode/` solution. This eliminates ~150 duplicate files.
2. **Package declarations** — Add package declarations (e.g., `package leetcode.array;`) to avoid default-package conflicts and enable IDE navigation.
3. **Missing imports** — Add explicit imports to each file for standalone compilation.
4. **Test framework** — Add JUnit test classes covering at least the most-duplicated solutions.
5. **CTCI chapter completion** — Add chapters 6, 8, 10+ per issue [#211](https://github.com/kdn251/interviews/issues/211).
6. **Company expansion** — Add more companies per issue [#144](https://github.com/kdn251/interviews/issues/144) (Adobe requested).
7. **Fix file naming inconsistencies** — Rename `RegularExpressionMatching.javaa` to `.java`; align class names with file names in CTCI solutions.
8. **Difficulty annotations** — Add difficulty level (Easy/Medium/Hard) as a comment in each file, matching LeetCode's classification.
9. **Internationalization** — GitHub issues [#247](https://github.com/kdn251/interviews/issues/247) and [#248](https://github.com/kdn251/interviews/issues/248) request Spanish translation.

### Contributing

**File structure conventions:**

- One solution per file
- File name: PascalCase of the problem title (e.g., `BestTimeToBuyAndSellStock.java`)
- Problem statement as comments at the top of the file
- Class name matches file name
- Solution method uses the signature expected by the problem platform
- No package declaration (current convention, though adding packages is a recommended improvement)
- No explicit imports (current convention)

**Pull request checklist:**

- [ ] Solution file named correctly (PascalCase)
- [ ] Problem statement included as comments
- [ ] Solution compiles with `javac`
- [ ] Solution passes on the target platform (LeetCode, UVA, etc.)
- [ ] If company-tagged, file is copied to all relevant `company/` directories
- [ ] No unnecessary dependencies or imports beyond `java.util.*`

---

_Generated May 2026 from kdn251/interviews at 03fdcb2. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial; not affiliated with or reviewed by the project._