Code Challenge 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?"
Deadlines
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.
Follow the Single Responsibility Principle. Keep your modules, classes, and methods as small as possible.
If you’re a sofwtare 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.
Last updated