Algorithmic Edge Archives - ChoralSoft

How to Explain Algorithm Correctness in an Interview

alavingi — Wed, 21 Oct 2026 15:41:29 +0000

A correct program is stronger when you can explain why it must work. A short proof also exposes bugs before the interviewer has to find them.

State the invariant

Describe what is true before and after every iteration or recursive call. For binary search, any existing target remains inside the current interval. For a sliding window, the stored counts match exactly the elements between its boundaries.

Connect the steps

Explain initialization, preservation, and termination. Show that the invariant is true initially, that each update keeps it true, and that the stopping condition converts it into the desired answer. This structure is concise and works for many algorithm families.

Address boundaries and complexity

Mention empty input, duplicates, missing answers, overflow, and maximum depth where relevant. Then derive time and space costs from the operations performed rather than reciting a label. Clear reasoning often matters as much as the final code.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post How to Explain Algorithm Correctness in an Interview appeared first on ChoralSoft.

Greedy or Dynamic Programming? Test the Irreversible Choice

alavingi — Wed, 21 Oct 2026 15:41:24 +0000

← Back to Blog & Articles

Greedy algorithms commit to a locally attractive choice. Dynamic programming keeps alternatives alive through reusable subproblems. The difference is whether an early decision can safely become irreversible.

What a greedy proof needs

A plausible rule is not enough. Show that an optimal solution can be transformed to include the greedy choice without becoming worse, or show that the choice always stays ahead of every competitor. Interval scheduling works because selecting the earliest finishing compatible interval leaves maximal room for what follows.

When dynamic programming is safer

If a locally good decision changes which future options remain, and no exchange argument protects it, model the alternatives. Knapsack-style problems are classic examples: the highest value or best value-per-weight item can block a better combination.

Use counterexamples early

Try to break a proposed greedy rule with the smallest instance you can invent. Counterexamples expose hidden interactions quickly. If the rule survives, articulate the invariant; if it fails, identify the state needed to represent the unresolved choices.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post Greedy or Dynamic Programming? Test the Irreversible Choice appeared first on ChoralSoft.

Dynamic Programming Starts with a State, Not a Table

alavingi — Wed, 21 Oct 2026 15:41:19 +0000

← Back to Blog & Articles

Dynamic programming becomes much easier when you stop beginning with an array. Begin by defining a question whose answer can be reused.

Define the state in a sentence

A state should specify exactly what its inputs mean. For example: dp[i] is the best score obtainable from the first i items, or solve(i, remaining) is the number of valid completions from position i with a given balance. If the sentence is ambiguous, the implementation will be too.

Derive the transition

List the choices available from one state and identify the smaller states they lead to. Then decide how those results combine: minimum, maximum, sum, or boolean OR. The transition should follow from the problem, not from a memorized template.

Finish the model

Name the base cases, the evaluation order, and the answer state. Memoization evaluates only requested states; tabulation makes ordering explicit and may reduce overhead. Before optimizing memory, write a correct recurrence and test tiny cases by hand.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post Dynamic Programming Starts with a State, Not a Table appeared first on ChoralSoft.

BFS or DFS? A Practical Interview Decision Guide

alavingi — Wed, 21 Oct 2026 15:41:14 +0000

← Back to Blog & Articles

Breadth-first search and depth-first search visit the same graph in different orders. The right choice follows from the information the problem asks you to preserve.

Choose breadth-first search

BFS explores by distance from the start. In an unweighted graph it naturally finds a path with the fewest edges. It is also a good fit for level-order tree traversal, minimum-step transformations, and problems where the earliest reachable state is the answer.

Choose depth-first search

DFS follows one branch before returning. It fits exhaustive exploration, connected components, cycle detection, topological reasoning, backtracking, and tree calculations that depend on child results. Its recursive form can be concise, although an explicit stack avoids recursion-depth limits.

Explain the trade-off

Both traversals are typically linear in vertices plus edges when adjacency lists are used. Their memory profiles differ with graph shape: BFS may hold a wide frontier, while DFS may hold a deep path. Always track visited states unless revisiting is intentional, and clarify whether the graph is directed.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post BFS or DFS? A Practical Interview Decision Guide appeared first on ChoralSoft.

Sliding Windows: Fixed Size or Variable Size?

alavingi — Wed, 21 Oct 2026 15:40:58 +0000

← Back to Blog & Articles

A sliding window reuses information about a contiguous range instead of recomputing that range after every move. The first decision is whether the window size is fixed or controlled by a condition.

Fixed-size windows

Use a fixed window when every candidate contains exactly k items: the largest sum of k values, a k-day moving average, or the most frequent symbol in a substring of length k. Add the entering item, remove the leaving item, and update the answer.

Variable-size windows

Use a variable window when the prompt asks for the shortest or longest range satisfying a rule. Expand the right edge to gather information, then move the left edge while the condition remains valid or must be repaired. This works best when the condition changes monotonically as the window grows or shrinks.

Know when it does not fit

A window is not automatically valid for every substring problem. Negative numbers can break sum-based monotonicity, and a requirement involving arbitrary rearrangement may need a different structure. Define the stored state, the validity test, and the exact moment the answer is recorded before coding.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post Sliding Windows: Fixed Size or Variable Size? appeared first on ChoralSoft.

Two Pointers: Recognizing the Pattern Before You Code

alavingi — Wed, 21 Oct 2026 15:40:32 +0000

← Back to Blog & Articles

Two pointers is less a single algorithm than a way to avoid repeating work. The pattern becomes useful when two positions can move through ordered data while preserving a clear invariant.

Signals that suggest two pointers

Look for a sorted sequence, a pair or interval, or a requirement to compare values from opposite ends. Common prompts ask for a target sum, removal of duplicates, interval contraction, or an in-place partition. The strongest clue is that moving one pointer lets you rule out many candidates at once.

Choose the movement rule first

Suppose a sorted list must contain two values whose sum equals a target. If the current sum is too small, advancing the left pointer is the only move that can increase it. If the sum is too large, retreating the right pointer is the only move that can decrease it. State this rule before writing the loop.

Protect the invariant

A good explanation names what remains true: every discarded pair is impossible, and any valid answer still lies between the pointers. Test an empty list, one item, duplicates, negative values, and the case where no pair exists. This turns a coding trick into a defensible algorithm.

Continue with the book

Explore the full treatment, worked examples, and exercises in Algorithmic Edge.

The post Two Pointers: Recognizing the Pattern Before You Code appeared first on ChoralSoft.