Why Effort Isn't Enough

Some rejections hurt more than others. The hardest is not failing to answer a question; at least then you know what to study. It is solving the problem, leaving the interview convinced it went well, and still being rejected without feedback or any idea why.

If you have had one of those, this book is for you. If you have had three, it is especially for you, because three is the point at which most people conclude the problem is them.

It usually is not. It is usually that you have been optimizing the wrong thing.

1.1 The Effectiveness Gap

The standard advice is simple: solve more problems. Two hundred, three hundred, or the 150 on a curated list. Keep grinding.

People do. They give up evenings and weekends to work through problem sets. They get measurably faster at familiar problems, then fail interviews anyway. The effort was real. The improvement was real. The outcome did not change.

The gap is not effort. It is effectiveness: whether you spend those hours on the things that decide the result.

Here is the uncomfortable part, which Section 3 backs up. Of the eight things an interviewer assesses, the one most candidates train is the one that decides the fewest outcomes. The factor that decides the most is one you cannot train by solving problems alone in a room.

That is the whole thesis. Everything else is detail.

1.2 Who This Is For

You, if: you can already program comfortably in at least one language; you have done some interview practice and it has not converted; you freeze, ramble, or go silent under observation; or you can solve problems at home and not in front of people.

Also you, if you are interviewing for something adjacent to software engineering, such as machine learning, data science or research, where algorithm rounds appear in the loop but are not the centre of the job. That was my situation, and most of this material was written for it before it was written for anyone else.

Not you, if you are learning to program. This book assumes loops, functions, recursion and a working relationship with a debugger. It will not teach them, and starting here would be frustrating and slow.

Also not you, if you want a problem bank. There are excellent ones, several of them free, and Section 19 points at them. This book is the thing to use with one: a method for making the problems count, not a supply of problems.

1.3 What You Need to Know Already

Honestly, so you can stop now if the answer is no:

• A language you are fluent in. Examples here are Python, chosen for brevity. Nothing depends on Python specifically; if you read it well enough to follow, you are fine.
• Basic data structures as concepts. Arrays, lists, dictionaries, sets. You do not need to know their performance characteristics, because Section 5 and Section 8 cover that.
• Recursion, at least uncomfortably. If a function calling itself still feels like a trick, spend an hour on it before Section 10.

You do not need prior Big-O knowledge. Section 5 assumes none.

1.4 What Makes This Different

Three things distinguish this book. The first matters most.

It works backwards from the scorecard. Most preparation material teaches algorithms and hopes that covers the interview. This one starts with what interviewers actually assess, eight nameable factors, and works backwards to what you should practise. That reframing is the book, and it is why a reader who only gets through Section 3 will still have got something.

It is a method, not a catalogue. Section 4 gives you eight steps that run when you are nervous and your judgement is not at its best. The techniques matter, but the method is what you reach for when the problem is unfamiliar, which is the only situation that counts.

It is short on purpose. You can read it in an evening. The competing volumes run to six and seven hundred pages, and they are good, and almost nobody finishes them. Brevity here is a design decision, not a shortage of material.

1.5 A Map

Five parts, nineteen short sections.

Part I · Orientation. Where you are, and what you are being scored on. Section 3 is the anchor: the eight assessment factors, which is the single most useful thing in the book.

Part II · The System. The eight-step method (Section 4), the complexity vocabulary you need to describe what your code costs (Section 5), and FGCC (Section 6), a framework for making months of practice accumulate instead of evaporating.

Part III · The Techniques. Eight techniques in six sections, grouped by what they have in common, ending with a procedure for choosing among them (Section 12), which is the part most books leave out.

Part IV · In Practice. One complete interview, minute by minute (Section 13), then four problem families worked in full.

Part V · The Modern Interview. What AI changed, what is being scored now, and how to study alongside a tool that will happily do your practice for you (Section 18). Then what this book deliberately leaves out, and where to go for it (Section 19).

1.6 How to Read It

Straight through if you are earlier in your preparation. The order is dependency-ordered: nothing uses an idea it has not introduced.

Section 3, Section 4, Section 12, then dip if you are further along and short on time. The rubric, the method, and the decision guide are the load-bearing parts; the technique sections are reference material you can visit when a problem sends you there.

Section 13 first if you want to know whether this book is for you before committing to it. It is one interview, start to finish, with everything running at once. If that transcript looks useful, the rest will be.

Read with a problem set open. This is not a book that works by being read.

1.7 The Practice Companion

There is a practice set that goes with this book, at:

solvealgorithms.com/practice

Problems grouped by level, with hints that escalate in tiers rather than jumping to solutions, which is deliberate, and Section 18.5 explains the research behind it. You write the solution in the browser and it runs against the same tests that verify every listing in this book.

The book works without it. The practice does not work without some problem set, and that one is built to fit.

1.8 What You Should Be Able to Do

By the end, you should be able to:

• Name what you are being assessed on, and say which of those eight things your preparation has been ignoring.
• Attack an unfamiliar problem with a procedure rather than with hope, including when you are stuck, which is the case the procedure is really for.
• State what your code costs, out loud, unprompted, and defend it when challenged.
• Recognize which technique a problem is asking for from the way it is worded, and say why.
• Make your practice accumulate, so that the hundredth problem is easier than the tenth rather than merely later.
• Handle an AI-permitted round, and know what to ask before you are in one.

None of that requires you to be faster, cleverer, or to have solved more problems than you already have. It requires the hours to be pointed somewhere else.