Passing the Technical Take-Home Assignment

Take-home assignments, tests, and even projects have become a central part of the engineering interview process. You might like them, you might hate them, you might not really care, but you’ll probably encounter them if you look for a job as an engineer. This post is not here to tell you if they’re good or bad, it’s here to offer you some advice on how to approach them.

This advice is based mainly on my own experience. I’ve completed many of these assignments, helped other engineers prepare for them, and designed and reviewed them. I’ve also chatted with friends who have experience with them to ask for their thoughts and what they look for when they review take-homes. I hope you find it helpful and pass your next take-home with ease.

#1: Read the instructions

I know, it’s obvious. But when you’re in the moment, you’re nervous, you’re excited, you can miss things. Take your time to double and triple check the instructions, take notes, and think about what assumptions you’re making. Are you assuming that you have to use a certain language or framework? Did you already set up a database when the instructions actually say that persistence doesn’t matter? Are you starting from goals that are clearly marked as “extra points” instead of focusing on the main requirements?

You might get instructions that seem pretty vague, don’t panic. This could be intentional, if the company wants to see how you handle ambiguity, or it could be more of an oversight. Especially at startups you might find that the interview process itself is a bit of a work in progress, so things may be unclear or wonky at times. Either way, don’t panic. If you have the option of asking clarifying questions — try to do that, otherwise make whatever assumptions you need to complete the task, and just be sure to document them.

#2: Identify the core problem

Every code challenge will have different requirements. Some are focused on front-end, some on back-end. Some will have one task, some five. Some will have you build a service from scratch, some will ask you to fill in existing functions. But in my experience, most (good) take-homes will have a core logic component.

When you read the prompt, even it asks you to accomplish many small tasks, try to identify the core problem you’ll be solving. You might ask yourself what’s challenging about the assignment or what part requires you to make design choices— that’s probably the core. It might be integrating with an API, writing a reusable component, figuring out a performant algorithm, or designing a service with a few endpoints. Make sure you solve that first and well, before moving on to any extras.

I should mention that especially for junior candidates, you might find that the core problem is just proving that you can code. That’s totally normal, don’t look for a trick where there isn’t one. Focus on completing the task and showing that you know how to write clean, functioning code.

#3: Keep it simple

Have you ever watched Jeopardy when there’s a really obvious question, but all the contestants get it wrong because they think “it can’t be that easy” and give a more obscure answer? The same can happen in technical interviews. We show up ready to show off our skills, and sometimes get a little ahead of ourselves.

Especially in a take-home, if you find yourself writing really convoluted logic or using some obscure libraries or tools, pause and rethink your approach. Often the most obvious path is the right one, and most take-homes aren’t going to require extremely complex logic. Take a break if you feel yourself going down a rabbit hole, and go back to the instructions and the task at hand before you keep coding.

#4: Treat it (almost) like production

The code you write will never see the light of day, but since you’re trying to get hired for a job writing production code — you should show that you can do that! This doesn’t mean that your code should be deployable (if your setup needs to use a json file instead of a database, that’s okay), but it does mean that it should work and read like production-ready code. Make sure to consider the following:

• Scalability and performance: If you’re working with a dataset, it will probably be small, and so whatever design you choose will probably be fast. But knowing that this wouldn’t be the case in real life, try to plan your design to work well with larger inputs. If there’s something you would change at a certain scale but wouldn’t make sense to implement right now — make sure you mention it in a comment.
• Readability, maintainability, organization: If someone else tried working on your code, would they be able to understand it? Would they be able to navigate the codebase and find what they need? These things are always important, but since you’re writing code meant specifically to be reviewed, they should be top priority. Be sure to follow linting rules, break your logic into readable functions, organize your work in modules that make sense, use meaningful variable names, and document your code as you would in production.
• Future-proofing and extendability: One of the things employers often look for is your ability to abstract your code correctly. That means that even if the assignment asks for very specific behavior, you probably don’t want your code to be too tightly coupled to that behavior. You also don’t want it to be so abstracted that it’s overly complex without providing any benefit. Try to keep your code appropriately flexible, defensive against unexpected inputs, and organized by separation of concerns.
• Testing: Even if your assignment doesn’t mention testing, you should still strongly consider implementing some tests. It doesn’t have to be a complete end-to-end testing suite, but some unit tests for your main logic components can go a long way. It serves two benefits: showing that you know how to write good tests, and just like in normal development — helping you in the process of coding and debugging.

#5: Explain yourself

I mentioned comments a few times, but wanted to reiterate. Especially when thinking about the previous section, some of the decisions you make might not be obvious from reading your code. You should feel comfortable leaving comments in the code to explain your thought process. It shouldn't be an essay, but quick comments like “storing data in an object will allow us to do quick lookups” can help the reviewer understand the decisions you made.

In addition to normal documentation of your code (explaining what your main functions do) you can also leave comments about tradeoffs you made, the time/space complexity of the code, future-proofing you considered, and any optimizations you made or would make. You can also include a section explaining what you would have done if you had more time (maybe refactoring a specific section, adding more tests, or adding handling for another edge case).

A note (not only) for junior engineers

Lastly, I wanted to include a few pieces of advice meant mostly for more junior engineers, who might find these assignments especially challenging. One of the hardest things about doing take-homes as a junior engineer is that you might be used to a very specific setup and structure, and suddenly you have to work in a completely different codebase or implement something you’ve never implemented before.

I know it’s intimidating, but don’t panic. If you’re provided with existing code as a starting point — try to follow the existing logic and understand what every part is doing. It might be using different tools or architecture than you’re used to, but it’s just code, and you know how to code. Use your debugging tools to understand the flow of logic and what’s similar or different from the setup you’re used to.

If you’re allowed to look things up, be sure to check out official documentation. Googling is great, but if you’re working with a library you’re less familiar with, reading its official documentation first can be super helpful. Medium posts about how to use a certain library are great, but they can also be very specific and not applicable to your use-case, so just make sure to take a look at official documentation too (most will have a “quick start” guide — try starting there).

I know every take-home is different and they can be stressful and time consuming, but I really hope this helps a bit. Try to enjoy the challenge of your assignment, focus on the basics, and don’t go down too many rabbit holes. Remember — it’s just a coding assignment, and you know how to code. Good luck!