More companies are beginning to see the light and have started replacing the traditional whiteboarding session in their hiring process with take-home coding challenges.
A take-home coding challenge is usually a mini project of moderate complexity that a prospective employer gives you to gauge your technical capabilities. These coding challenges are typically expected to be completed in a day or two.
If you’re job hunting and have just received a take-home coding challenge, then you’re in luck. This article will walk you through everything you need to know about take-home coding challenges and how to ace them. But first, let’s consider some examples of take-home coding challenges to give you an example of what to expect.
Different Types of Take-Home Coding Challenges
- Front-end: If you’re a front-end developer, you’ll typically get a take-home coding challenge to complete tasks that a front-end developer will normally be responsible for in their day-to-day job. For example, you can be given tasks like “code a pixel-perfect duplicate of a Figma web page design”, “create a simple app interface and consume APIs”, or “create and style a popular webpage component like a carousel”. Here’s an actual coding challenge given by Buycoins, a cryptocurrency exchange startup, for hiring a front-end developer:
- Back-end: As a back-end developer, you’re expected to have knowledge of implementing server-side logic for web applications, including how to set up/use databases and how to design APIs. Here’s an example of a back-end developer take-home challenge from Brianna Veenstra.
Pro-tip: If you want to find more examples of take-home coding challenges, google “specialization” + “take-home coding challenge GitHub”. For example, “front-end coding challenge GitHub” or “android coding challenge GitHub”.
Common Mistakes to Avoid When Doing Take-Home Coding Challenges
Before we look at tips on tackling a take-home coding assessment properly, let’s first look at some common mistakes that prevent developers from nailing their take-home challenge and giving recruiters what they want.
- Do not make assumptions:
Sometimes, instructions in your take-home challenge may be vague, or you may not fully understand them. That is perfectly okay. Instead of making assumptions and building a solution that doesn’t meet the specified requirements, ask clarifying questions. That will ensure you don’t deviate from the challenge and show your prospective employers that you are not afraid of asking questions or communicating.
- Do not jump into writing code immediately:
When you receive a take-home challenge, do not start writing code head-on. First, take time to properly make sense of all the technical requirements and visualize your solution from a high level. Then, select the stack and libraries you’ll be using (if allowed) and draft out how you will tackle each requirement. In other words, before you write a single line of code, make sure you have a clear vision of the final product and a plan of every single task you need to do. It will help you save time and finish your task on time.
- Do not overestimate your capabilities:
Sometimes, you may get take-home challenges that are way beyond your technical knowledge and capabilities. They may require you to use technologies you’re not familiar with and cannot learn to use within the submission window. It’s okay to admit that you do not have the right skill set to tackle a challenge. A take-home coding challenge can end up being a frustrating waste of time both for you and the company if you don’t have the right skillset for it.
- Do not overreach or over engineer things:
It’s straightforward to fall into the trap of adding unnecessary complexity to your solution to seem cool or using all the in-vogue technologies to impress your interviewers, especially if you have lesser experience in them. Remember that take-home challenges are time scoped. If your take-home challenge does not require a particular library or framework, it’s better to use what you already know and write the best code possible because time is limited.
How to Ace your Take-Home Coding Challenges—Step by Step
We’ve covered some very important don’ts when doing a take-home coding challenge. Now, let’s look at what you should do.
- Plan—get organized.
Before you write a single line of code, start by properly understanding and visualizing what you have been asked to do. If you come across any blockers, email back immediately with your questions, and do not write a single line of code until you understand everything you’re expected to do. A company may keep its requirements deliberately vague to see how you approach problems.
After clearly understanding what you’re supposed to be building, the next step is to identify any technical decisions you need to make. Make a list of all the technical decisions at the beginning. This is the point where you decide what languages and frameworks to use if none have been specified. Remember: it’s better to use technologies that you’re already familiar with. It would be best if you also determined at this point whether you need any utility library or generator and which one to use.
The next step in this planning phase is drawing out your architectural design or wireframes, depending on the scope of your project. Here, you draw out how different parts of your solution interact to achieve the final result. Thinking through and planning out these decisions will clarify any difficulties you have if you get stuck or confused along the line and serve as a reference for the next interview stage, where you’ll discuss why you made certain decisions.
The last step in the planning phase is to break down and organize your tasks. List out step-by-step what you have to do to complete your take-home coding challenge. This will be your game plan and will help you keep track of how far you’ve gone.
For example, for the Buycoins take-home challenge, here’s how I broke down my tasks:
You’ll notice that I have broken down these tasks into high-level tasks. You can go the extra mile by breaking down each step into smaller steps. This ensures that you know exactly what you’re supposed to do before you even write a single line of code—which is the entire purpose of the planning phase.
- Code—make it work, then make it pretty.
Next, it’s time to start writing your code. As the title of this section suggests, your focus should be on making your solution work and satisfy all functional requirements before trying to make it look pretty.
Forget all coding best practices. Focus on writing code that gets all the functional requirements working. Even if you end up without going back and refactor your code, having a working app to present is more important. Also, do not forget to commit and push to GitHub incrementally after every milestone. For further information on this, read more about writing good commit messages.
Once you’ve incorporated the required functionality into your app, you can think about making your solution pretty, depending on the time left. This can be in terms of making your UI prettier or making your code shine.
At this point, you can go back and refactor your code to provide a more elegant solution. Some best practices you should follow are ensuring that your code has the following features:
- easy to follow
- properly indented
- effectively commented
- has properly named variables
- has function names that communicate the intent of the function
- error handling
- data validation
- writing tests
For example, for our Buycoins challenge, we could go the extra mile and add data validation to ensure that users enter input in the correct format. We can also improve our UX so that when a user enters a username that does not exist, they get an alert error or popup. If any bonus features have been mentioned in the instructions, you can include them in your app.
- Document your solution.
Last but not least, remember to write a detailed README.md for the GitHub repo. You should actually write this README file after getting all the functionality to work before you start making the extra effort to make your code shine. Remember: make it work—make it pretty—make it fast—make it work.
Including a README communicates to your interviewees that you care about documentation, which is an essential skill for software developers. Your README.md should answer questions like:
- Installation instructions: They should tell the interviewee how to set up and run your app on a local machine. They should also include instructions to set up tests (if any).
- Technologies: Mention the technologies used in building the app and highlight how and for what each was used.
- Requirements and functionalities: There should be a brief section describing what your app does and how you were able to meet the requirements.
Before you submit
Excellent! You’ve done a great job and finished your take-home coding challenge. It’s now time for you to submit. But before you do that, double-check your code and review your work using the checklist below:
- Re-read your take-home assignment’s instructions and verify you didn’t miss any detail.
- Go through your code to ensure that it shines and everything is in order.
- Run your app’s automated tests (if any) and make sure they are all passing.
- Test your app manually and make sure everything is functioning as expected.
- Test your app installation instructions from your README.md and make sure that the process described is entirely accurate.
After you submit
You’ve finally submitted. Congratulations! We hope you learned from this guide. But, the hard work doesn’t end here. Now it’s time for you to prepare to discuss your take-home coding challenge. That will be the next stage of the interview process, and if you follow this guide, your chances of moving to the next stage have been maximized. Be prepared to talk about any challenges, trade-offs, or possibly controversial decisions you made.
Here are some questions you may be asked:
- What did you find most challenging about the assignment?
- What did you find most fun about the assignment?
- Is there a specific section of the code that you are most proud of?
- If you had more time, what features would you want to add to this app?
- Why did you architect your app this way?
- Why did you build your UI this way?
- How could you scale this app?
- Did any interesting bugs come up? How did you solve them?
It might help you practice your answers to these questions with a friend or in front of a mirror. That’s all we have for you right now. Good Luck!