5 things employers look for in a take-home coding challenge


So you’ve been matched with an employer, made it through your initial screening and are now moving on to the technical assessment. At that point, you might be faced with a whiteboard, pair programming or take-home coding assignment.

There can be a lot to like in take-home coding challenges: you’ll most likely get to approach the problem at your own pace, on your preferred IDE and using all the searches you want. But all that wide open space can be a bit overwhelming.

After all, it’s not only about completing your assignment with functional code—there’s a large spectrum of “it works.” Slack, for example, uses 30 factors to grade coding challenges. While every employer will vary in exactly how they grade their challenges, expect that the following will play a role in whether you advance or not to the next stage.

Your questions

Don’t be afraid to ask qualifying questions—part of what you’re measured on may be your ability to suss out gaps in the requirements or gauge how many assumptions you make. If you have a challenge that includes time and date fields, for instance, you could be making any manner of incorrect assumptions about time.

Asking about time zones, when the week starts or holidays isn’t obnoxious (though asking about time distortions in a black hole might be)—it could be relevant to the solution and lets your interviewer know that you don’t jump into a coding project without knowing which direction you’re headed.

The same goes for anything you find confusing or vague in the instructions. If you’ve been provided with seemingly conflicting objectives, ask. This might again be intentional or a holdover from a previous challenge.

Your approach to the assignment

Next, how do you tackle the problem at hand? Part of that is the language you use. There isn’t necessarily a right or wrong (unless a coding challenge specifically asks you to use Ruby and you use Java). Weigh the languages you know the team uses (either based on your initial discussion, open source code or from the role’s description) with what you’re most comfortable in.

That doesn’t always mean using the team’s language of choice—if you haven’t worked in Python in a few years and the company you’re interviewing with writes exclusively in Python, you may be better off writing in Java. Also, as Atlassian puts it, don’t use “some odd or shiny things in order to impress” the interviewer if it doesn’t perfectly align to the task at hand.

Beyond language, companies will also review your overall strategy. Have you made complex design choices that contain more than a few bugs? Or do you opt for the simple route and nail it? Do you go for every bonus task or stick to the basics? Again, there’s no right or wrong here, but make sure how you tackle the assignment reflects the work you’ll do if you get the position.

Your testing approach

Your challenge requirements may explicitly ask for tests, but tests might be expected without a specific request from the interviewer—particularly if you’re interviewing for a smaller company without a dedicated QA function.

How many tests should you run? Sometimes the exercise will provide some tests, but it won’t hurt to add a few of your own. Test the golden path (your default scenario), but look at a few edge cases, too. Unless it’s a tester role, you don’t need to dedicate the majority of your time to find exceptions, but show the reviewer that you’ve thought through major scenarios.

How you speak to—and debug—your code

Once you’ve hit send on your assignment, don’t totally put it out of mind. Sosh, a restaurant app, used their coding assignments to inform their next interview:

If the code submission had a bug in it (spoiler warning: they usually did!), the candidate’s in-person technical test was to debug it with me. I’d point out a case that failed and we’d spend time fixing it together. The ability to debug code you wrote a week ago and haven’t thought about since is a vital skill for an engineer!

The company may also want to explore the rationale behind why you took a certain route. Be prepared to justify your decisions or explain code. Did you have to head to Stack Overflow for help with a component of the assignment? Nobody’s going to ding you for “cheating” unless you paste code without a full understanding of it.

Think through your approach before you get started, mark up any complex code and add references to any necessary additional documentation. Not only will this help the code reviewer, but it will help you refresh yourself on the assignment before a follow-up interview or even debug on site.

Engagement with the problem

Lastly, how much you enjoyed the task is just as much for you as it is for employers. A well-designed challenge is made to be as close to what you’ll be expected to do in your day-to-day. Too easy? Discuss that with the interviewer. Too tedious? Ask yourself whether this is really the role for you.

Your take-home coding challenge shouldn’t be another hoop to jump through—it should help you and the employer uncover not only whether you’re a good technical fit, but whether you’re right for the role (and the role is right for you). Keep these tips in mind and both you and the interviewer will get more out of your take-home assignment.

Learn how Seen can help better match you with employers and help you find your next dream role (and do fewer coding challenges).

Recommended posts