Why Your Coding Take-Home Is Getting Rejected

We've all been there.

Coding take-homes can be great.. and they can be terribly stressful!

Once you've submitted a coding take-home for review, you can feel such a great sense of relief.... Or dread!

But what can you do if you've submitted your coding take-home and it was rejected?

Here are a few of the common reasons your coding take-home is getting rejected. Review carefully and try to figure out which of the mistakes you're making.

Time Management Issues

Even the very most experienced engineers struggle here so don't beat yourself up.

If you are having trouble finishing coding take homes, take a step back and figure out what you can actually complete in the time you've been given. It's going to be far more impressive if you can finish the take home opposed to building a bunch of features that don't work.

Submitting a complex application that isn’t finished < Submitting a simple application that is completed.

And take it easy on yourself. Most coding take-homes are sent home with 'guesstimates.' Meaning that, no actual engineer at the company did this take-home so everyone is just assuming it will take someone a certain amount of time.

These are rarely based in reality!

If you manage your time well and make the application a little more impressive, that’s good, but it’s best if you make finishing the application a priority.

If you email the company twice that you need more time because you created an overly complex application, it will count against you. Use the requirements and consider them an MVP. After all, time is money.

Make it work first and then make it look good.

You're Trying to Learn Too Much

This is not the time to learn a new framework. (Unless it happens to be the framework the company uses and you are really desperate to get the job. I did this and it actually worked).

While it's great to show you are eager to learn and ready to pick up new technologies for the company, it's not so great to spend so much time learning something new that you end up missing the opportunity to show off your skills.

Try to push yourself for a coding take-home and show you can learn, but don't push yourself so much that you end up unable to finish the coding take-home.

You didn't ask enough questions

It's going to look impressive to an interviewer if you review the requirements and ask questions right away. You know what's not going to look as impressive? If you ask three days after they send you the take-home challenge.

Before you started your coding take-home, did you spend enough time reviewing the requirements and planning?

Submitting messy code

Many developers have pet peeves about how code looks. Generally when you start at a new company, you should follow their style when it comes to tabs vs. spaces, indentations, and code comments.

Some of this is nitpicky, but it’s important that your coding challenge reads well and looks good. Think about it, an interviewer will be reading your code. You want to make it as easy as possible on them so it's a pleasant process.

Indentation issues

Make sure that you stick to the same indentation through the app. Choose space or tabs and stick with it. Choose two or four and stick with it!This will make your code easier to read and will showcase your attention to detail.

As you are writing code, clean up as you go! This will help keep you from feeling overwhelmed at the end when you TODO

Forgotten debugger statements or console.log statements

I shared previously that I do this all the time. It’s a running joke at my current company when people find my dog’s name throughout the app because I use it as a marker in the code. But in a coding challenge, make an extra effort to remove all of these statements to keep your code clean.

Messy leftover code

I’ve done this, but it’s sloppy and should be avoided. It also wastes the time of the engineer who will be reading your take-home challenge.

Remove your old unused code. I made this mistake when I was a junior engineer, thinking that it might show my thought process. Instead, it just made the file harder to read for the engineer examining it.

Unreadable code

Keep your code as clear and simple as possible. The best written code is easy to understand and to read. Use clear variable names and function names. Keep it modular and clean. 

Not being honest about your skills

If you don’t feel confident in completing the take-home challenge, be upfront about it. You might save yourself hours working on a take-home challenge for a company that is looking for someone more senior.

I was interviewing at a company for a full stack position with an emphasis on frontend, and they asked me if I felt confident completing the backend portion of the challenge in the time allotted.

I told them I didn’t feel confident enough to do the challenge, but I was willing to try. Instead, they were pleased I spoke up and paired down the challenge. By speaking up, I saved myself hours of time that I could have spent trying to figure out extra work that they didn’t really care about.

Sending in code you don’t understand

If you’re a junior engineer, don’t submit code you don’t understand. If you copied and pasted a few lines from Google, make sure you understand it.

One company I worked for had a candidate apply that was junior for a non-junior role, but they decided to take a chance and sent the applicant a take-home.

We sent the candidate the take-home challenge and when they sent it back, it was copied from a popular tutorial. We knew this because they had accidentally left a comment from the tutorial labeling where they found it online.

We clicked the link and saw the tutorial. One half of the code was copied and pasted from the tutorial.

They didn’t get the job.

Chances are a company will do their research, so don’t cheat. Do the work yourself. 

Many times when a company sends a take-home challenge, they'll ask you to build an extra feature on-site or they'll have you talk about the code you wrote.

I can't tell you how many times I've interviewed someone and they couldn't discuss a single line of code. You want to be ready and able to back up all your code!