Algorithms for interviews: the beginner's minimum

How much you really need

Far less than the scare stories suggest. Beginners get problems solvable in fifteen or twenty minutes that don't require exotic data structures.

Months with a thick textbook aren't necessary. Twenty or thirty simple problems are enough to feel steady.

What you need to know

Arrays and strings. Iterating, searching, reversing, counting, removing duplicates. That's the basis of most junior problems.

Dictionaries and sets. Understanding that lookup in them is fast and in a list it's slow. Half of these problems are solved by realising a dictionary is the answer.

Sorting, as a user. Know it exists, be able to sort by your own criterion. Nobody asks you to write quicksort from scratch.

Complexity, informally. Enough to tell the difference between "we pass through once" and "for every element we scan the whole list again". A rough answer about logarithms is fine.

Recursion, basically. Understand the idea and be able to write something simple: factorial, walking a tree.

What you don't need

Dynamic programming, graphs, elaborate trees, clever search algorithms. If a junior gets asked those, it's usually either overreach by the company or a bonus problem you aren't obliged to solve.

The standard problems

Work through two or three of each kind:

1. Reverse a string or array.
2. Find duplicate elements.
3. Count character or word frequency.
4. Check that brackets are balanced.
5. Find two numbers with a given sum.
6. Merge two sorted lists.
7. Check a palindrome.
8. Find the most frequent value.
9. Remove duplicates preserving order.
10. Count something in a text.

That set covers the overwhelming majority of entry-level interviews.

How to prepare

Solve out loud. The main skill isn't solving but explaining. Practise narrating: what I understood, which approach, why that one, how I'll check it.

Record yourself. Unpleasant but useful: you'll hear where you mumble and where you swallow the reasoning.

Don't memorise solutions. Memorised answers are obvious, and a small change to the problem sinks you.

In the interview itself

1. Clarify the problem. What if the input is empty? Can the numbers be negative? One question before starting makes a very good impression.
2. State the approach before writing code. "I'll pass through once, accumulate into a dictionary, then take the maximum."
3. Write and explain simultaneously. Silence is the worst thing you can do.
4. Check the edge cases. Empty input, one element, all identical. Almost everyone forgets — remembering is a visible plus.

An interview problem is a conversation, not an exam. They're assessing a colleague, not a competitor.