An algorithm is a set of instructions written in a specific order to solve a problem or complete a task
When you write an algorithm, you are breaking down what you want the computer to do into small, clear steps that follow one after another. The computer reads these steps in order and carries out each one. An algorithm is not code yet — it is the plan you make before you write code. You might write it in plain English, in a numbered list, or in a diagram. The point is to think through the problem completely before you start typing into a programming language.
Think of an algorithm like a recipe. A recipe tells you to gather ingredients first, then mix them in a certain order, then bake at a specific temperature for a specific time. If you skip a step or do them out of order, the result fails. An algorithm works the same way. The computer needs to know what to do first, what to do second, and when to stop.
Key Takeaways
- An algorithm is a plan written in plain language or straightforward steps before you write actual code, and it solves one specific problem.
- Every algorithm needs a starting point, a set of steps that happen in order, and a stopping point or end result.
- You can write an algorithm as a numbered list, a flowchart, or pseudocode — whichever helps you think through the problem clearly.
- Testing your algorithm on paper with real examples before you code saves time and catches mistakes early.
- straightforward algorithms like sorting a list or finding the largest number are good starting points to understand how algorithms work.
Understand the problem you are trying to solve
Before you write a single step, you need to know exactly what problem you are solving. Write it down in one sentence. Are you trying to find the fastest route between two cities? Sort a list of names alphabetically? Check whether a password is strong enough? The clearer your problem statement, the easier the algorithm becomes.
Next, think about what information you will have when you start. If you are sorting names, you have a list of names. If you are finding the fastest route, you have a map with distances. These are your inputs. Then think about what the answer should look like. Do you want a sorted list? A single number? A yes or no answer? This is your output. Write these down too.
Break the problem into small, manageable steps
Take your problem and divide it into pieces small enough that you could explain each one to someone who has never done it before. If your algorithm is "sort a list of names," you cannot just write "sort the names." That is too big. Instead, you might write: compare the first name to the second name, swap them if they are in the wrong order, move to the next pair, and repeat until no more swaps are needed.
Each step should do one thing. If a step says "get the user's name and check if it is valid," split it into two steps: first get the name, then check if it is valid. This makes it easier to test each part and easier to turn into code later. Write the steps in the order they must happen. If step three depends on the result of step two, step two must come first.
Write your algorithm in plain language or pseudocode
Pseudocode looks like code but uses plain English words instead of programming language syntax. It is easier to read and easier to share with people who do not know your programming language. Here is an example of pseudocode for finding the largest number in a list:
Set largest to the first number in the list For each remaining number in the list If that number is bigger than largest Set largest to that number Return largest
You can also write your algorithm as a numbered list in plain English. The key is that someone reading it should understand exactly what the computer will do, step by step, without needing to know any programming language. Avoid vague words like "process" or "handle." Use specific words: "add," "compare," "repeat," "stop when."
Draw a flowchart if the steps branch or repeat
Some algorithms have decisions — if this is true, do that; otherwise, do something else. Some algorithms repeat the same steps many times. A flowchart shows these branches and loops visually. Start with a circle or oval for the beginning. Use rectangles for steps. Use diamonds for decisions (yes or no questions). Use arrows to show which step comes next. End with another circle or oval.
A flowchart is especially helpful when you are learning because it forces you to think about every possible path through your algorithm. What happens if the answer to your yes-or-no question is no? Where does the algorithm go then? A flowchart makes you answer these questions before you code. You can draw a flowchart on paper, in a document, or with free online tools like Lucidchart or Draw.io.
Test your algorithm with real examples on paper
Before you write any code, run through your algorithm by hand using real data. If your algorithm sorts names, write down a list of five names and follow your steps exactly as you wrote them. Do you end up with the names in alphabetical order? If not, your algorithm has a bug. Fix it on paper before you code.
Test with different kinds of input. What if the list has only one name? What if two names are the same? What if the list is already sorted? These edge cases often break algorithms that work fine on normal data. Testing on paper is fast and cheap. Testing after you code takes longer and is more frustrating.
Common mistakes to avoid when writing algorithms
The most common mistake is skipping steps or assuming the computer knows what you mean. The computer does not. If you write "sort the list," the computer does not know how. You must write the exact steps: compare pairs, swap if needed, repeat. Another mistake is forgetting what happens at the end. Does your algorithm stop? Does it return a value? Does it print something? Write this down.
A third mistake is not testing with edge cases. An algorithm that works on a list of ten items might fail on an empty list or a list with one item. Test these cases on paper. A fourth mistake is making steps too big. "Check if the password is strong" is too big. Break it into smaller steps: check if it has at least eight characters, check if it has a number, check if it has a capital letter, and so on.
Frequently Asked Questions
What is the difference between an algorithm and code?
An algorithm is the plan — the steps written in plain language or pseudocode. Code is the actual program written in a programming language like Python or JavaScript. You write the algorithm first to make sure your plan works. Then you translate that plan into code.
Do I need to draw a flowchart for every algorithm?
No. straightforward algorithms with a few straight steps do not need a flowchart. Use a flowchart when your algorithm has decisions (if-then-else) or loops (repeat until). A flowchart helps you see the full picture and catch mistakes before you code.
How do I know if my algorithm is correct?
Test it on paper with real examples. Run through each step exactly as you wrote it. If you get the right answer, your algorithm is probably correct. Test with edge cases too — empty lists, single items, or unusual inputs. If your algorithm handles these correctly, it is solid.
Can I write an algorithm in a programming language instead of pseudocode?
Yes, but pseudocode is usually better for learning and for sharing with others. Pseudocode is easier to read and does not require you to know a specific programming language. Once your algorithm is clear, translating it to code is straightforward.
What makes a good algorithm?
A good algorithm solves the problem correctly, works on all kinds of input, and is clear enough that someone else can understand it. It does not need to be the fastest or shortest — it needs to work and be understandable. As you learn more, you can optimize for speed or memory later.