Stop Making These Coding Challenge Mistakes (From Someone Who Reviews Them)

Most developers feel somewhat uncomfortable when asked, and why wouldn’t they. It’s a tough thing to go through. It’s a whole load of extra work, your skills will be under really close scrutiny and you’re not guaranteed to get anything out of it.

I’ve been on the other side of coding challenges for a while now. I’ve had the pleasure of reviewing plenty of code. I’m always on the lookout for a few things. It’s nothing surprising either.

Here is a list of things I personally look for when reviewing code (It’s frontend/React related but the tips still apply to any coding challenge). I’m interested on your opinions on the last tip (AI related). I share this in the hopes that it could help you succeed on your next coding challenge. Or at least do slightly better.

Make sure it works

This one is so frustrating!

Issues range from the likes of environmental variables not being set, docker containers configured incorrectly, an import missing, a type error… Take care of the details.

In these challenges you want to get off to a good start. If the reviewer has to start debugging right away when using your app then you’re already in trouble.

Write Tests

Tests have a couple of purposes. They make sure a piece of code does what it’s supposed to do under different conditions. But it also gives new developers to the codebase a much better idea of what a certain chunk of code is supposed to be doing.

By writing tests in your submission, not only are you verifying your code is working you are also helping the reviewer see what you think the code should be doing.

At least have some unit tests in there. Use Vitest or Jest. If you have time throw in some e2e tests with Cypress or Playwright. Nothing overly complex but cover the basics. With AI these days, this is a no brainer.

It shows you don’t just build something and hope for the best. You are the type of developer that likes to put the odds in your favour as much as possible.

Don’t leave in commented out code

This is one of my pet peeves and drives me crazy in code bases. Why is this code commented out? Will it be needed in the future? Did the developer forget to uncomment it? Did they forget to delete it?

It just raises questions and shows a lack of care about the codebase you are working on. Don’t do it. Uncomment it and use it or delete it.

Structure your code for scalability

I received a code submission to review recently for a React app. All the code was declared in the App.tsx file. 17 declarations of useState , svg icons, handler functions. You name it, it was all in that one file.

Not only does this make a long file and make it difficult to read, it also doesn’t scale well at all. If you want to reuse one of the icons, you can’t without some refactoring. If you want to use a piece of that state somewhere else in the codebase, you can’t without some refactoring.

Calling an api? Put that in a separate function in a services folder. This way if another part of the app needs to use the same api in the future it can just import this function and be done. Have some piece of state that might be needed somewhere else in the future? Then put it in some context or a global state library like Redux or Zustand.

The point is apps naturally grow over time, and you want to show you are thinking ahead. You don’t want to be refactoring every time you want to add a new feature. Show that you are the type of developer who takes this into consideration.

Separation of concerns

This connects in some way to the last point. Don’t put all your logic in one big function. Don’t combine clearly separate parts of the data.

If you’re going to use a global state library, don’t put everything into one big piece of state, separate it out. Maybe you have users and products. Deal with the logic for handling state updates separately. Make it clear what are the “groups” of state that are important in this app.

I’m not saying you have to go down a functional programming rabbit hole but separate logic out where it makes sense and show the reviewer this is something you care and think about.

Have Clear READMEs

The reviewer’s time to review your code is likely to be short. You want to make it as easy as possible for them to understand your code and how to get it up and running.

You can even elaborate here stating your approach, why you made certain decisions and what you think is the most interesting part of the submission to focus on.

Don’t write a novel but put yourself in the reviewers’ shoes for a moment and write what would be useful when viewing your code for the first time.

Use Linting and Typechecking

Bit of a no brainer this one. We live in 2025 and we have established tools to check both linting and types. Use them! I am still amazed how many different code bases I see where the existence of basic linting or types is nowhere to be seen. Use Typescript btw, not plain Javascript.

Format Your Code

This is just basic 101 stuff for a developer in this day and age. Reviewers shouldn’t be having trouble reading your code due to formatting. I would advise to use Prettier as it’s the goto library most teams use these days.

Remember, you are applying for a job to work in a team and having these basic tools in your workflow really help a team work together. You want to show reviewers you care about this stuff.

Leave 1 Day Before Submitting

If you have the luxury of time then I always suggest you wait a day between when you completed the coding challenge and before you submit. This gives you time to take a breath and then review the code one last time.

When you are in the middle of doing the code challenge you are concentrating so much on the challenge it’s easy to miss some details.

By giving yourself that little gap you can come back with flesh eyes, do a little clean up and make sure you didn’t miss anything obvious. These small tweaks in the clean up phase can make all the difference.

Be Transparent With Your AI usage

This is probably the most relevant at the time of this writing. More and more companies are allowing or even requesting you use AI during your code challenge.

The important thing here though is transparency of usage. It can be very revealing to the reviewer how you are thinking by the questions/prompts you ask the AI.

I would therefore advise two things:

• Be wary of the questions you ask AI
• Be honest with the reviewer which prompts you used, why you used them and what you did with the results.

The reviewer wants to gauge as much as possible how you will be using AI were you to get the job. Are you asking basic things you should already know? Are you offloading everything and vibing your way to a result? How clearly can you express yourself? How good is your technical communication?

Conclusion

There are many aspects to a successful job application and plenty of those aren’t related to coding and are outside of your control. However, when it does come to things you can control you want to do your best to put the odds in your favour.

Covering the basics in the coding challenge is one of those things. I’m not saying by covering the basics you will pass this part of the application but I am saying if you don’t, then it could very easily eliminate you.

All these practices are good practices to have in your day to day job anyway. These are things that a company expect from future employees. Cover your basics.

Subscribe to My Weekly Updates on Medium!

Enjoyed This Post?

If you found this blog post helpful, why not stay updated with my latest content? Subscribe to receive email notifications every time I publish.

If you're feeling really generous you can buy me a coffee. (Btw, I really like coffee…)

What You'll Get

• Exciting Discoveries: Be the first to know about the latest tools and libraries.
• How-To Guides: Step-by-step articles to enhance your development skills.
• Opinion Pieces: Thought-provoking insights into the world of frontend development.

Join Our Community

I live in the vibrant city of Prague, Czech Republic, with my family. My blog is more than just articles; it's a community of like-minded developers who share a love for innovation and learning.

About me

I'm a passionate Frontend Developer specialising in React and TypeScript. My professional journey revolves around exploring and mastering new tools and libraries within the JavaScript ecosystem.

Check out my LinkedIn and Github if you are interested.