How to Take This Course

Why algorithms show up in interviews at all

You know the feeling: you've been shipping real code for years, and then an interview asks you to "find two numbers that add up to a target." It's fair to wonder what that has to do with the actual job.

An algorithms round tests how you think, not what you've memorized. Think of the interviewer as a teammate on a hard problem. What they really want to know is what it's like to work with you:

• how you get your bearings in something unfamiliar;
• whether you spot the traps;
• whether you can explain your thinking;
• whether the code you write is something you'd be happy to show.

The problem itself is just an excuse for that conversation. So don't panic if you don't remember a ready-made solution. Almost nobody expects one right away.

What actually gets evaluated

Skill	What it looks like	What makes interviewers nervous
Thinking out loud	You talk through your ideas, even half-formed ones	Ten minutes of silence, then finished code
Complexity	You state time and space: O(n), O(n log n)	"Well, it seems pretty fast"
Edge cases	Empty input, a single element, duplicates, negative numbers	The code crashes on []
Clean code	Clear names, no extra branches, logic you can follow	a, b, tmp2 and five nested ifs

An imperfect solution with a good explanation often scores higher than an optimal one written in silence.

You're not taking an exam. You're showing how you'll work on a team. Talk, reason, ask questions: all of it counts.

How the course works

Every chapter follows the same three-step pattern.

1. Lesson. A short explanation of the technique: first the intuition and a real-life analogy, then a diagram, a code template, complexity, and common mistakes. A lesson like this one takes five to ten minutes to read.
2. Auto-graded problems. You write the solution yourself, and it runs against tests, including the sneaky edge cases. This is your main practice.
3. Explain it out loud. You walk the interviewer through your solution just as you would in a real interview: the idea, why it works, the complexity, the edge cases. The interviewer asks follow-up questions.

The third step is easy to skip, but don't. Plenty of people solve problems on their own and then freeze in the interview when they have to talk. Practicing out loud is the fastest way to get past that fear.

If a problem isn't working out after 20–30 minutes, go back to the lesson, reread the template, and try again. That's a normal part of learning, not a failure.

How to solve a problem in an interview: 7 steps

This order will come in handy for every problem in the course. Over time it becomes a habit.

1. Clarify the problem. Restate it in your own words and ask about anything unclear. How big is the input? Can there be negative numbers or duplicates? Is the array sorted? What should you return if there's no answer?

2. Work through examples. Take a small example and run it by hand. Say you need two numbers that add up to 9:

Then come up with a trickier one: an empty array, a single element, no answer at all.

3. Propose a brute-force solution. Start with the simplest thing, even if it's slow, like checking every pair. State its complexity. This shows you already understand the problem, and it gives you and the interviewer a baseline.

4. Improve it. Ask yourself where the extra work is. Would sorting help, or two pointers, or a hash map? Those techniques are exactly what this course is about. Discuss the idea with the interviewer before you start coding.

5. Write the code. Use clear names and write in small, logical pieces. Briefly narrate what you're doing as you go.

6. Test it on examples. Trace your code by eye on your example, line by line. Then check the edge cases. Finding a bug in your own code is a plus, not a minus.

7. State the complexity. Give the time and extra space, and explain where they come from.

What it sounds like out loud

Something like this:

"Just to confirm: the array isn't sorted, and there's always an answer? The first thing that comes to mind is checking every pair, which is O(n²). We can do better: walk the array and keep the numbers we've seen in a hash map. Then for each number I check whether target − x has appeared. That's O(n) time and O(n) space. Let me write it."

Notice there's nothing complicated here, just a sequence: clarify, brute force, improve, analyze.

Common mistakes

• Jumping straight into code. Without clarifying, it's easy to solve the wrong problem.
• Going quiet. The interviewer can't see your thoughts and can't help you.
• Being shy about the brute-force solution. It shows you understand the problem and gives you a base to improve on.
• Forgetting edge cases. Empty input and a single element break solutions more often than anything else.
• Not testing your code. A couple of minutes checking an example saves a lot of awkwardness.
• Confusing "complex" with "slow." Complexity describes how the time grows as the input grows, not how many seconds the program runs.

What's next

Next come the real techniques, and each one is built the same way: intuition, diagram, template, practice, voice. You don't have to remember everything at once. Every problem you solve makes the next one easier.

You've already taken the first step: you know the rules of the game. Let's go.