Takehome projects are typically one of the first steps in the frontend/mobile/full-stack recruitment process, after a call with the recruiter or hiring manager. I've had my fair share of takehomes, when interviewing for different companies. On the other side of the table, I reviewed dozens of web and mobile takehome projects. As a hiring manager, I've also put together a few and engineers on my team review hundreds of these every year.

This article shares advice on what to pay attention to, when completing one of these challenges, mentioning a lot of things I've learned from being on the "other side" of takehome submissions.

The typical takehome project

The goal of the takehome is for the company you're interviewing it to get a sense of how you'd solve a real-world problem. Creators of these challenges try to limit the scope so it can be done in a few hours with someone with enough experience. At the same time, they'd like to see developers using everyday concepts in practice. Concepts like fetching things over the network, manipulating the UI and handling edge cases. Sometimes even testing and documentation.

Here's how a common takehome would look like:

Build a web/mobile app using/not using $specificTechnology.
Use the API xzy.com/api, which is typically an API where you can search for some terms.
Build a nice UI where users can type a search term and then display visual results.
Pay attention to things like good usage of $specificTechnology, code separation, readability, maintainability, and error handling.
Common additional functionality that might be part of the exercise include pagination, lazy loading, and responsive layout. Often these are marked as bonus things to have.
Bonus points for testing, documentation and other things showing off that you're going above and beyond.

To check a few specific examples, see these takehome tests used by tech companies:

How will my takehome be evaluated?

Before we jump into the tips to complete a great takehome, it's good to understand who and why will be looking at your work.

In almost all cases, developers working at the company will go through your submission. Here's what they'll look at first glance:

Does it work at all? Can they grab your code and get it running, following the setup notes you provided?
Does it work correctly? As soon as it's up and running, the devs will stress-test it with a lot of edge cases. Don't forget: the reviewers are deeply familiar with the project. They had plenty of time to get to know the tricky cases - so they'll see how many of those your solution covered. If the takehome is a search based project, they'll try to enter nothing, special characters like ' or & search terms that return nothing or ones that possibly return invalid data.
Show me the code. They'll look through the code itself, reading it and figuring out how readable and clean it is.
Visuals. Especially when it's a frontend or mobile position, does the UI look nice and feel pleasant? Is it responsive? Is there a nice "extra touch" added that puts a smile on the reviewer's face?

More senior candidates. Assuming this all looks fine, for more experienced candidates, the reviewers might go deeper and check:

Following of framework/language best practices. Even when the framework was not defined, developers might look through if the framework and the language are used in line with industry standards. This could go from simple things like camelCase variable naming in JavaScript all the way to correct usage of Rx libraries in mobile projects.
Class structure. What classes were defined? Do classes follow the single responsibility principle, having a clear purpose?
Code architecture. How was the code structured? Is the business and presentation layer clearly separated? Are any design patterns, like MVC, MVVM, MVP patterns or similar used across the project? Was it built in a way that's easy to extend? Are directories/modules separated nicely?
Testing. Is business logic tested with unit tests? Do the tests pass? Are tests written clearly? Are tests single purposed by having one assert per test?
Documentation. Were the setup instructions clear? Does the documentation summarize what has and what has not been built? Are there notes on improvements or extension points?

... and that's about it! When I review submissions, I spend 5-20 minutes on each one, spending less time on ones that work well and are clear. I spend a bit more time on more borderline ones. I've observed other reviewers allocate similar time for each submission.

Tips for writing the takehome

Now we know what people will look at, time to get to work. Here are my suggestions to successfully clear this stage.

Tip #1: Know that it will take a (lot) longer the first time

Before you get down to coding, know this: your first takehome take far more time to complete than you (or the creators) assume. There is no good rule of thumb. However, for my first ever takehome I was told to take about 4 hours. I easily spent 12 hours on it. Candidates also often tell me they went beyond the suggested timeframe.

Why is this? It comes down to three main reasons. First, there's a good amount of setup that you need to put in place, from getting your "hello world" running to things like tests and documentation. Second, people don't want to submit poor quality work. And even if you know exactly how to do things, quality work takes time. Finally, people often use this exercise to try out something new, which takes additional time. And this is a great thing! It leads me to my next tip.

Tip #2: Use the takehome as a learning exercise, trying out better, new ways to do things

Look, you're already going to spend a bunch of time on the takehome. Might as well make it worth your time and learn something new on the way. By doing so, it also becomes a lot more interesting, over it being just a chore.

Try using a better approach than you usually do in your day to day. This can start with putting more structure in place than you usually do, using a new design pattern or styling the project with a recently popular approach.

Be vary in using frameworks that do the heavy lifting and leave you with little code to write. Most takehomes explicitly ask not to do this. This is because if you do so, the reviewers can only evaluate how great the third party library is and how clever you were to use it. They won't know how well you would have fared without that specific library.

Tip #3: Prototype quickly, build nicely after

If the takehome is something that you've not built tens of times before, you can make better progress by building a quick-n-dirty prototype. A version that gets the data and displays it on the screen. Sometimes, just getting the API keys for the data source can take a while. Once you have something functional, it's a lot easier to start a new project, where things like UI and business logic are separated.

Tip #4: Make a list of edge cases before you code

One of the most common reasons I see reviewers rejecting takehomes that do work is sloppy work. Most often this means not handling pretty basic edge cases. Like when searching with no input, nothing happens. Or the app breaking when inserting a special character. Or - for web projects - resizing the window messing up the UI.

Most of these issues all come from "edge cases" not being defined in the assignment. Most developers work really well when they know what edge cases to cover. So come up with your list of edge cases! Spend five minutes thinking about possible weird cases and make a list of them. Then make sure to cover these, as part of completing the task. This is another reason why the work will take longer than you expected.

Tip #5: The more experienced position you're after, the more ground you'll need to cover

Takehome exercises are a "binary" gate in the interview process. After this step, you either get to the next round - usually the onsite - or the process will stop here. The more senior the position the company is hiring for, the more they'll expect higher quality. Beyond readable and functional code, they'll also expect to follow best practices and paying attention to architecture and testing.

I've seen experienced candidates get rejected who focused on the "X hour" suggestion, submitting a lower quality solution. Had they put in another hour or two, it might have been a yes: as it was, it ended up being a waste for both parties.

Tip #6: It's okay to ask for more time

If you followed my advice and it's one of the first takehomes you're doing, you're probably spending more time on the takehome than you thought. You might also be running out the arbitrary time you were told that you had. Or perhaps, something else came up, that stopped you from working on the project.

Here's a little known secret: 95% of hiring managers don't care how long you take to complete the takehome.. The thing is, recruiters, who you are talking with, sometimes don't know this. Most of the time they do, but their goal is to get people quickly to a potential onsite. This is why they communicate a tight deadline. And saying "you have X days to complete this" is a surprisingly efficient way to motivate people to send it over.

As a hiring manager, I have never said "no" to anyone who delayed their submission, assuming they communicated about this and did not just disappear. When evaluating the takehome, reviewers don't look at - often do not even know - how long the person worked on it.

I am, by no means suggesting you take all the time in the world to come up with a perfect takehome. I am just saying, don't stress if something else comes up in your life or if you decide you'd like to spend more time working on it.

Tip #7: Add (basic) documentation

This one is such a miss on 80% of submissions I've seen. After spending hours on the solution, very few people spend 10 minutes typing up basic documentation, that help gives context and helps them shine. Here's what the remaining 20% do:

Notes on starting the app or setting it up, for the reviewer.
Summary of what was built and what was (deliberately) not. It saves a lot of nitpicking when e.g. the reviewer knows that of the bonus tasks, pagination was implemented, but lazy loading was not. And it helps call attention to all the extra work you've done. Did you put in additional creativity to handle one of the edge cases? Write it down, else the reviewer might completely skip it.
Context on design decisions and framework choices. WIt's good to give context if you've tried out a new framework or why you've chosen a specific architecture pattern. This is especially true for more experienced candidates. Don't underestimate the impact: reviewers will take the context into account. They are less likely to be super strict if they understand you experimented with something new.
Areas for improvements. You probably ran out of time and could have done a lot more. So list these things! It goes a long way when reviewers see that you knew what else was missing. It's also good to mention what the things are that you would have worked on if this was a project that went into production.

Tip #8: Publish your code on Github

If it's either no secret that you are looking for a job, or you'd like to add something new to your Github profile, do consider publishing the code you wrote. Assuming you have nice documentation and the code is thoughtfully written, it can serve as another data point in the future for other employers. By publishing it, you can also share this much easier with anyone, who might be looking for guidance from you, in the future.

If you don't want to publicize that you're doing takehomes, you can still potentially publish your code without mentioning that it's a takehome. It is always a good exercise to experiment with new technologies and to share this publicly.

Tip #9: It will take a lot less time to do further takehomes

Completing your first takehome, or a takehome in a very long while will feel exhausting. But there's light at the end of the tunnel. Since most takehomes are similar, a lot of your work will be reusable for the next time. Sure, the next takehome will have you talk to a different API, perhaps doing something other than search. But there almost certainly will be networking, displaying of lists, UI tweaking, handling of edge cases, testing and documenting involved. All the things you spent a good amount of work on.

I hope this guide gave some ideas and inspiration for the next time when you have to complete a takehome, as part of an interview process. What additional tips do you have to share for acing the takehome project, that you did not see listed here?

About me: I'm an engineer turned engineering manager, working at the intersection of Silicon Valley & European startups and tech companies. Follow me here and on Twitter. I write longer essays on software engineering on my blog, The Pragmatic Engineer. I also send a monthly newsletter with extended notes on software engineering and tech leadership topics.

9 Tips to Ace Your Takehome Project for Frontend, Fullstack and Mobile Interviews