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:
- Skyscanner fullstack takehome test
- Just Eat takehome tests (frontend, data engineer & DevOps)
- Shoppad takehome test
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
camelCasevariable naming inJavaScriptall the way to correct usage ofRxlibraries 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.
Top comments (5)
From half a century of interviews in past 11 months, I'd also like to add that one should definitely if it really qualifies as a take-home task I've had several with me and my juniors that all they wanted was a base code repo for their product. Though I know I shouldn't cry but such bad experiences have put me in a emotional turmoil
In my experience reviewers also look at things other than just how well someone can code. Coding can be learnt but having good attention to detail and a solid problem solving attitude is harder to come by. At Rexlabs we ask the interviewee to make notes and have a few questions around how they plan to complete the test. We also look at; problem solving skills, the reasons behind which problems were solved first and why in a particular order, which external libraries were added and how they decided upon a specific library, how comfortable are they with git and what kind of commits have they made.
The code is a good indication of how comfortable they are with a language or framework, but it doesn't cover if they are a good fit. Also, a senior might be a great programmer but not under a time restriction which will essentially cause them to make more mistakes than usual.
So to recap, I think having extra questioning as apart of the code test is key, the answers should be submitted with the test so that it's fresh in their mind. Answering these questions during an in-person interview can be daunting and they might have forgotten by that point.
Welp literally just submitted a takehome project and now I wish I could redo the whole thing 😩
Fingers crossed, Lynn! Regardless of how a takehome project goes, you usually learn a lot from it, when you get feedback. If you get to the next round - hooray! If not, then hopefully you get specific feedback on what parts to improve on. And if no feedback, it's fair to ask about what parts were missing.
I hope it goes well for you.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.