Algorithm design is the process of specifying a step-by-step procedure to solve a problem correctly and efficiently. Foundational techniques include linear search (scan until found), binary search (halve the search space each step), selection sort, and insertion sort. Before coding, writing pseudocode makes the logic explicit without syntactic noise. Algorithm correctness is verified by tracing examples; efficiency is characterized by how runtime and memory scale with input size, expressed informally with Big-O notation.
Implement search and sort algorithms from scratch without looking up the code. Trace them on small arrays by hand. Measure runtime experimentally on different-sized inputs and compare to Big-O predictions.
An algorithm is a step-by-step procedure that solves a problem — but a correct answer is only half the job. A procedure that takes 10 steps for a 10-element list but 1,000,000 steps for a 1,000-element list will collapse in real use. The central design challenge is building algorithms that are both correct and efficient, and expressing that efficiency precisely using notation like O(n).
Two fundamental search strategies illustrate the stakes. Linear search scans each element from the start until a match is found — O(n) in the worst case. Binary search works only on sorted data, but eliminates half the remaining candidates at each step by comparing against the midpoint — O(log n). For a list of one million elements, binary search finds the target in at most 20 comparisons; linear search may need a million. The price of binary search is that the data must be sorted first. If you search frequently and sort once, that cost is worth paying. If you search only once, linear may be faster overall.
Sorting reveals a similar design landscape. Selection sort scans for the minimum, places it, and repeats — O(n²). Insertion sort builds a sorted prefix one element at a time — also O(n²) in the worst case, but very fast on nearly-sorted data. More sophisticated algorithms like merge sort and quicksort achieve O(n log n) by splitting the problem in half recursively. The misconception to resist is that O(n²) is always bad and O(n log n) is always better: for small inputs, the simpler algorithms often win due to lower overhead. Big-O describes asymptotic behavior for large inputs, not absolute runtime for small ones.
Pseudocode is not bureaucratic ceremony — it is a discipline that forces you to commit to the logic before getting tangled in syntax. A line like "if the list is empty, return -1" makes an edge case explicit. When you translate to Python or Java, you are filling in syntax around an already-correct structure, not discovering the structure as you type. Skipping pseudocode buries logical confusion under implementation decisions, making debugging much harder.
Tracing an algorithm by hand on a small example is the most reliable correctness check before running code. Walk through a 5-element array step by step, tracking every comparison and swap. This builds the mental model needed to debug when the algorithm fails on edge cases — empty arrays, duplicates, already-sorted inputs — that automated tests may not initially surface. Algorithm fluency is built through this kind of deliberate, slow tracing before you can reliably write code that works the first time.