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:

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

Technology Stack

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

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:

The .gitignore excludes standard IDE and OS artifacts:

*.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:

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

./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 proposes renaming existing chapters. Any renaming would require updating references in the README.

Known Issues (from GitHub)

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:

// 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:

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:

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.

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).

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:

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:

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:

// 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.
6. Company expansion — Add more companies per issue #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 and #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.*