Careers Code Challenges Best Practices

What To Do First

As soon as you receive a code/data challenge, you should immediately spend one hour on it.

This is to make sure you understand the directions, that the APIs/data sources they provided still work, and to make sure any other incidental things won’t pop up 24 hours before the challenge is due.

Clarify any issues early on and reach out to your point of contact if you have any questions. Do not be afraid to do this.

Managing Expectations

Managing expectations are extremely important. Whether you work for a large enterprise company or as a solo contractor, you always want to agree on the requirements. This allows both parties to understand the scope of the work and avoid (negative) surprises.

The last thing you want is to spend hours or days of work on something irrelevant to the employer.

That means:

  • making sure you understand the instructions and requirements
  • knowing the deadline
  • clarifying any questions you have regarding the technology, functionality, features, etc.

Be aware of any communication delays (e.g. if you send an email on a weekend, you may not get an answer back until the next workday)

Remember to keep it simple!

Try not to waste time making things too “fancy” - or risk not meeting the deadline because you want to add to the solution. It can be easy to spend more time on the challenge than is necessary to pass the round, and you may be doing more harm than good.

Our advice? Complete the challenge as if it were a real client assignment, not a competition. The team might be asking themselves: "Would I be happy to build upon this code/data myself?” or “Would it be relatively straight-forward to pair with someone on this?"


Challenges usually have a deadline and they can range from a few hours to as much as one week. Three to seven days is pretty common.

Employers normally give you a deadline for submitting challenges. If however, they ask you to come up with a deadline, before you reply, spend another hour working on the challenge and think about how long it might take to finish. Double that number.

If the employer doesn’t specify a timeframe/deadline at all, you should suggest one. Avoid ambiguous timelines.

No matter what, do not spend more than seven days on a challenge. If you aren’t satisfied with your solution within seven days, submit what you do have.

Doing the Work

The bulk of your work will involve you reaching flow state and crushing code. When not in flow, you’ll likely watch tutorials, scour Stack Overflow or Cross Validated, read books, and do tons of research.

This isn’t unlike what a typical day would look like in the job of your choice, by the way. In the professional world, your days will often consist of gathering requirements, research/analysis, implementing features/methods, testing, and interacting with people.

You might have questions. We advise you spend some time researching before you fire off a question to your point of contact. If possible, group multiple questions in one message instead of piecemealing them.

Employers will assume the way you work through the challenge is how you’ll work in their real environment. Be diligent, thoughtful, and deliver on time.

Pay Attention to the Details!

Details are critical. Your whole job is paying attention to the details. Missing a semicolon, forgetting to close a quote, using the wrong key to retrieve a map value, all these lead to errors. It behooves you to be meticulous.

This is especially true when it comes to code challenges.

Code quality and readability are particularly important. If a fellow professional can easily understand your programming, they will enjoy working with you.

Have a sensible Git log.

Follow the Single Responsibility Principle. Keep your modules, classes, and methods as small as possible.

If you’re a software engineering student and building a front end, something as simple as slapping on the company logo or matching the company colors goes a long way.

Make sure you test repeatedly before you submit.

Don’t Cheat

Cheating is never okay.

Don’t copy and paste other people’s code and pass it off as your own.

Employers will find out.

What if You Need More Time?

Ask for it! But don’t wait until the very last minute.

Issues may pop up and require you to delay a submission. Maybe the internet went out in your apartment or Github went down and you couldn’t push your changes. Or maybe you had a family emergency come up.

Things happen.

And that’s okay.

Just make sure you communicate with the employer and alert them right away if something comes up (call or send an email via your phone if need be) to set new expectations around when you will be able to submit the assignment.

Time to Submit

First rule of technical challenges: Always submit on time.

Second rule of technical challenges: Always submit on time!

Other rules:

  • Make sure you’ve tested it twice, thrice, dozens of times before you submit.
  • Show it to a friend (or a few friends). See what they think.
  • Make sure your submission satisfies all the minimum requirements

In some cases, you may find that your final product is a little off, or not what you were hoping to submit. Some companies are looking at more than just the code itself, and it can be beneficial to provide well written instructions (e.g. ReadMe) or comments walking readers through what you have created. In the event that your product could not be completed, or lacked a specific feature, include that content. Let employers know what you would have done differently, added/removed, or problem solved to strengthen your final code.

Record It!

If there are a lot of features, elements, or a flow to navigating your app or project, record a video!

Videos are great for showcasing everything you built and adding context behind your choices.

  • If you built a CRUD app, spend a minute showing the upload and download functions as you narrate the steps.
  • If you built an API, show the different responses you get when you hit different endpoints or send different payloads.
  • etc.

How to Handle Feedback

Sometimes, an employer may provide feedback about your submitted challenge. This feedback can be negative or positive. How you respond is important because it may impact your advancement into future rounds of the interview process.

Do: Reply back with comments about what you appreciated or learned from the feedback. Show that you can not only take constructive criticism, but also apply it to future projects. It would be a good idea to re-submit the challenge with the applied feedback, to show enthusiasm and passion (although this is not required or expected).

Don’t: Become defensive. That can be a big red flag to recruiters/employers. It is important to remember that feedback is not personal, and that being able to receive constructive feedback is an essential part of your professional development and career growth. Don't defend your choice to the employer if they made it clear they thought you went about solving the problem in the wrong way.

Unlock your future in tech
Learn to code.

Learn about Flatiron School's Mission

With a new take on education that falls somewhere between self-taught prodigy and four-year computer science degree, the Flatiron School promises to turn students with little programming experience into developers.

In the six months since the Manhattan coding school was acquired by WeWork, it has spawned locations in Washington, D.C., Brooklyn, and London. Now, WeWork is opening a fourth Flatiron School location, this time in Houston.

Adam Enbar, Flatiron School's cofounder, believes now is the time to grow. "How the world is changing has impacted working and learning in very similar ways. We think education fundamentally is about one thing: enabling people to pursue a better life."

Learn. Love. Code.
Students come to Flatiron School to change their lives. Join our driven community of career-changers and master the skills you need to become a software engineer or a data scientist.
Find Us