# How to Solve a Coding Challenge as a Beginner

# What is an Algorithm?

Scary word. You’ve probably heard it many times.

It’s just a series of steps to solve a given/specific problem. An algorithm can even be one line thanks to arrow functions.

`const myFunc = something => console.log(something)`

This algorithm doesn’t solve much but it still accomplishes a task. That’s all an algorithm has to do.

# Understand the Problem

If it’s a live coding session, then you can ask the interviewer any clarifying questions. During my last assessment at Flatiron, my assessor told me that coding challenges are meant to be confusing at first.

This may sound counterintuitive, right? However, asking you to solve a confusing question forces you to communicate with the interviewer. You can claim to be good at communicating with your team but you can really show them that you mean it by asking clarifying questions.

Make sure you know what the problem is asking. Can you paraphrase the question?

## Other Questions to Ask Yourself or the Interviewer:

- Do you understand what is the given input and expected output?
- Are there any restrictions or limitations for the input?
- What is the data type of the given input?
- How to label the function(s)/parameter(s)/other variables?

# Exploring Examples

Start with simple examples of inputs and outputs to make sure you understand what is expected.

Then try coming up with harder inputs. Next will be invalid inputs or exception cases.

# Break it Down

Try using comments to break down the steps of the algorithm. Comment the layout of the `if`

statements/loops/methods you plan on using.

This step forces you to think about the problem from beginning to end. It’s possible that there might be some questions along the way.

It doesn’t have to be pseudo-code as long as you’re breaking it down.

# Solve/Simplify

Try coding the solution with the comments! If you can’t write the whole solution, simplify the solution. If there is a part that is giving you a problem, try to ignore that part at the moment and continue to code a simpler solution.

Sometimes skipping the issue will help you click all the pieces together once you reach a simplified solution.

Then incorporate the blocker back in.

# Refactor (as needed)

This is where Big-O comes into use. There may be times when your interviewer may ask you to refactor your code so it runs faster. See which methods take up time and refactor as necessary.

Or if you just see that the algorithm is too long, then you can either refactor it to take up fewer lines.

## Questions to ask yourself:

- Is your code easy to read?
- Is it intuitive?
- Can you think of another way to solve it?
- Do you get the expected outputs for all cases that you can think of?
- How do you think other people will solve it?

That is what being a software engineer is all about, right? Our most valuable skill is not being able to code but being able to break down problems!