How to Prepare for a Take-Home Coding Test

A take-home is often the stage where Nigerian applicants either get through or quietly drop out of a remote developer process. Usually the reason isn't weak coding. It's a deadline misread across time zones, a NEPA outage on the last night, a repo the reviewer can't run, or a feature list so ambitious that the basics never got finished.

This guide covers what reviewers check, how to plan your hours, how to protect the work from power and internet problems, a README template, how to handle AI tools, and how to prepare for the call where they go through your code with you. It is for multi-day projects. Timed tests on platforms such as HackerRank are covered separately.

Quick answer

A take-home coding test is a small project you build in your own time, usually within a window of one to three days. Reviewers check that it runs and meets the brief, that the code is clear, that it has basic tests and a README covering setup, decisions and trade-offs, and that you can explain every line later. Confirm the deadline, the expected hours and the AI policy first. Finish the must-haves before any extras.

What a take-home coding test is (and what it is not)

A take-home coding test is an assignment you complete away from the interviewer, on your own machine, with your own tools. Typical examples are a small API, a front-end screen that calls an API, a data-processing script, or fixing and extending an existing codebase. OfferZen's guide to preparing for a technical assessment describes take-homes as building "a small app, API, or data tool" with a typical window of 24 to 72 hours.

Three formats get confused with each other:

If your test is the first kind, read our guide on completing a remote technical assessment instead. The rest of this page is about the third kind.

Some remote companies describe their take-homes publicly. Automattic, the company behind WordPress.com, says on its How we hire page that its coding challenge uses "near-real-world code" and covers security, performance, problem solving, communication and adapting to an unfamiliar codebase. Candidates "generally have about a week", and more time is available on request (as of October 2026). The community-maintained Hiring Without Whiteboards list records many remote companies, including Cabify, Close, Doist and Gruntwork, that use take-home projects rather than puzzle-style interviews.

None of these companies' hiring processes tells you whether they accept applicants living in Nigeria. That depends on the individual job ad, so always check where applicants may live before you invest days in a test.

What reviewers actually check

Reviewers read your submission the way they would read a pull request from a new colleague. OfferZen sums it up as "Reliability and clarity beat 'fancy' every time." In practice, a reviewer works through roughly this list:

1. Does it run? They follow your README on a clean machine. If setup fails, many reviewers stop there.
2. Does it meet the brief? Every stated requirement is present and works as described.
3. Is the code readable? Clear names, sensible file structure, no dead code, no commented-out experiments.
4. Are there tests? Basic unit tests for the core logic, plus a few edge cases (empty input, invalid data, duplicates).
5. Is the history sensible? Small, clearly named commits show how you worked.
6. Are trade-offs explained? A short honest note on shortcuts and what you would improve.
7. Are the basics safe? No API keys or passwords in the code. OfferZen specifically mentions loading secrets from environment variables, and semantic HTML for front-end work.

Reviewers rarely reward clever extras that go beyond the brief, but they do notice when one stated requirement is missing. A reviewer will usually rank a plain solution that does everything above an impressive one that skipped a requirement.

Before you write any code: the clarifying email

The guide to take-home tests from Code Your Future, a UK coding charity, advises asking for the deadline and the expected time commitment before starting. It also warns that companies often underestimate how long a task takes. It suggests asking what format to submit in, what the team cares about most (coding style, testing, or how you break down the problem) and what their preference on AI use is.

Send these questions in one short email, not five separate messages.

Example (hypothetical): a clarifying email

Hi Sarah, thanks for sending the assignment. Before I start, a few quick questions: 1. Is the deadline Friday 5pm Pacific time? I'm in Lagos (WAT), so I want to be sure I convert it correctly. 2. The brief says "about 4 hours". Should I stop at that point and note what's unfinished, or would you prefer a complete solution even if it takes longer? 3. Should I submit a GitHub link (private repo with access for your team) or a zip file? 4. Is it fine to use AI coding assistants, and if so, would you like me to note where I used them? 5. Is there anything you care about most: tests, structure or the API design? Thanks, Tunde

This takes five minutes and does three jobs. It removes guesswork, it shows the communication skills remote teams hire for, and it puts the agreed rules in writing.

Convert the deadline to West Africa Time

Nigeria is on WAT (UTC+1) all year, with no daylight saving. Many US and UK companies give deadlines in their own time, and the gap moves with the seasons:

UK clocks went back on 25 October 2026, and US clocks go back on 1 November 2026. A deadline set in the week between those dates has the UK on winter time and the US still on summer time. Put the converted deadline in your calendar, then set your own target 12 to 24 hours earlier.

Plan your hours before you open your editor

If the company says "about four hours", treat that as the size of the solution they want, not a challenge to see how much you can build. Spending 25 hours on a four-hour task often backfires. The submission becomes harder to review, and in the follow-up call they will ask about all of it.

OfferZen's advice is to read the brief twice and separate the must-haves from the nice-to-haves. Write both lists down before you start.

Example (hypothetical): a four-hour plan for "Build a REST API for library book loans: list books, borrow a book, return a book, prevent borrowing an unavailable book."

Only once blocks 1 to 5 are done should you look at extras such as pagination or a Dockerfile. If you add them, say so in the README so the reviewer knows they were deliberate.

Choose boring, familiar tools

Use the language and framework named in the brief. If none is named, use the stack you know best. A take-home is the wrong moment to try a new ORM or a framework you watched a YouTube video about last week. Every hour spent fighting unfamiliar tooling is an hour taken from tests and the README.

Protect your work from power cuts and bad internet

This is the part generic guides leave out. A 48-hour window in Nigeria may include a feeder outage, a dead inverter battery or a network that drops every evening. Plan for that from the first hour:

• Commit and push early and often. Push to a private remote repository at the end of every block. If your laptop dies or the light goes, nothing important is lost.
• Install dependencies on day one. Run npm install, pip install or docker pull as soon as you have the brief, on your most stable connection. Big downloads at midnight on a slow network are a common way to lose a deadline. Data costs add up too, so do it once, on Wi-Fi if you can.
• Have a second connection ready. A MiFi plus a phone hotspot on a different network, or two ISPs, means one outage doesn't stop you.
• Charge everything before the final push. Laptop, power bank, MiFi. If your inverter or solar setup is marginal, schedule the README writing (which needs little power) for the evening and the heavy work (Docker builds, test runs) for when power is steady.
• Submit early. Aim to submit with hours to spare, not minutes. A late submission caused by an outage looks the same to a reviewer abroad as one caused by poor planning.

If connectivity is a recurring problem for you, our guide on staying productive when your internet is unreliable covers longer-term fixes.

How to write the code reviewers want to read

Make small, named commits

OfferZen recommends small, clearly named commits (its example is feat: add email validation) rather than one huge final commit, because the history shows your step-by-step thinking. A reviewer who sees this:

• chore: set up project and linting
• feat: add list books endpoint
• feat: add borrow endpoint with availability check
• test: cover borrowing an unavailable book
• docs: add README with setup and trade-offs

learns more about how you work than they would from a single commit called "final".

Write tests that prove the rules

You don't need 100% coverage. You need tests that prove the business rules in the brief work, plus a few edge cases. For the library example, that means a test showing a borrowed book can't be borrowed again, and one showing a return makes it available. A short, readable test file is worth more than a sprawling one.

Handle errors like production code

Return sensible status codes and messages for bad input. Keep secrets and API keys in environment variables, and include a .env.example file showing which variables are needed without real values. Remove console.log debugging, unused files and commented-out code before submitting.

The README: your voice when you are not in the room

OfferZen points out that you won't be there to explain your work, so the README has to do it. GitHub's own guide to READMEs says a README should cover what the project does and how to get started, and should contain only what developers need. Put it in the repository root so it displays on the repo's front page.

A README structure that works for take-homes:

1. What this is. One or two lines restating the task.
2. Quick start. Prerequisites (for example, Node 20) and a single command to run it, plus the command to run tests.
3. What's implemented. A checklist of the requirements from the brief, each ticked.
4. Key decisions. Why you chose this library, this structure, this database (or an in-memory store).
5. Assumptions. Anything the brief left open and how you interpreted it.
6. Trade-offs and next steps. Shortcuts taken because of the time limit and what you would do with more time.
7. Time spent. An honest figure, for example "about 4.5 hours".
8. AI use. What you used, if anything, and for what (see the next section).

Before submitting, clone your own repo into a new folder and follow the README exactly, line by line. If it doesn't work for you on a fresh clone, it won't work for the reviewer.

Using AI tools on a take-home coding test

Company policies differ, so ask. Code Your Future notes that some companies want you to use AI tools the way you normally would, while others want unaided work. Using AI against the company's preference, or being unable to explain your own submission, puts you in a difficult position in the follow-up interview.

Doist's hiring FAQ is a good example of a published stance: "You can use AI as a tool, but we're really looking for your voice and your thinking", and it asks applicants to say if they used AI (as of October 2026). OfferZen suggests an AI disclosure in the README covering which parts AI generated, where it got things wrong, and what you wrote by hand. Its rule of thumb is to remove any AI-generated line you can't justify.

The practical test is simple: if an engineer pointed at any line in your code during the review call, could you explain why it is there?

Is the test fair? Unpaid work, paid tasks and red flags

Most take-homes are unpaid, and a few hours of unpaid work on a synthetic problem is normal in remote hiring. Some companies pay. Doist lists a "Paid task/assignment with feedback" as a standard hiring stage. Automattic's process includes a paid, part-time trial of two to eight weeks, about 15 to 35 hours in total, after the coding challenge (both as of October 2026).

Use this table to judge what you've been sent:

If a test looks like free labour, you can politely ask whether a shorter alternative exists or whether the work is paid. If anyone asks you to pay money at any stage, stop. Our guide on spotting remote job scams in Nigeria covers the wider warning signs.

One security habit is worth adopting: if the "test" is a repo someone sent you, read its package.json scripts or setup files before running anything. Run it inside a container or a separate user account if you aren't sure. A legitimate company won't mind you being careful.

After you submit: prepare for the code review call

Code Your Future notes that you will likely be asked to discuss your submission in a later stage, both to see how you work and to confirm you did it yourself. OfferZen suggests writing a quick "brain dump" straight after submitting: what was hard, which decisions you made, and what you would change before production.

Prepare for that call like this:

1. Reread your own code the day before. Know where everything lives.
2. List two or three things you'd improve, and say them before they're pointed out. Spotting your own weaknesses comes across as maturity, not failure.
3. Expect to be asked to extend it live: "How would you add user accounts?" or "What happens with 10,000 requests a minute?"
4. Check your setup: stable power, a backup connection, a working microphone, and your repo open and ready to share.

For general interview preparation and role-specific questions, see our software engineer interview questions and the guide on preparing for a remote job interview.

Submitting privately on GitHub

Some companies ask you not to publish their test publicly. A common approach is a private repository with the reviewer added as a collaborator. GitHub Docs explains how to invite a collaborator to a personal repository: Settings, then Collaborators, then Add people, using their GitHub username or email. They get access once they accept the emailed invitation, so send the invite early and confirm they received it.

Common mistakes that sink good developers

• Starting before clarifying. Building the wrong thing well still fails.
• Over-engineering. Microservices, three layers of abstraction and a CI pipeline for a four-hour CRUD task. OfferZen lists over-engineering as the classic take-home pitfall.
• Skipping the README. Or writing one that doesn't work on a fresh clone.
• Committing secrets. An API key in the repo is an instant red flag, and it stays in the git history even after you delete it.
• Ignoring the time zone. Submitting "on Friday" Lagos time when the deadline was Friday morning in London.
• Going silent. If something goes wrong, such as a dependency breaking or a long outage, email before the deadline and explain. Asking early for a few extra hours is far better than missing the deadline without a word.
• Submitting code you can't explain. Whether it came from AI, Stack Overflow or a tutorial.

If you want reviewers to see your work before a test even arrives, our guide on building a software portfolio that attracts remote employers shows what to put on your public GitHub.

Frequently asked questions

How long should a take-home coding test take?

Stick close to the time the company states. If the brief says three to four hours, aim for that, and note in the README what you would add with more time. Code Your Future warns that companies often underestimate task length, so ask in your clarifying email whether they'd rather you stop at the time limit or finish.

Should I use AI on a take-home coding test?

Only in the way the company allows, so ask first. Some companies welcome AI assistants and others want unaided work. Where AI is allowed, say in your README what you used it for, and make sure you can explain every line, because the follow-up interview will test that.

Is it okay to ask the company questions during a take-home test?

Yes. Sensible questions sent in one clear email show the written communication remote teams value. Ask about the deadline, expected hours, submission format, AI policy and what they care about most. Don't ask them to solve the problem for you.

What if I can't finish the take-home in time?

Email the recruiter before the deadline, explain briefly, and either ask for a short extension or submit what you have. If you submit something incomplete, make the README honest: list what's done, what isn't and how you would finish it. A clean, honest partial submission is better than a broken full one.

Should take-home coding assignments be paid?

Short ones usually aren't, and that is normal. Some remote companies, such as Doist and Automattic, publicly describe paid tasks or paid trials (as of October 2026). If an unpaid test looks like 15 hours or more, or like real product work, it's reasonable to ask politely about a shorter alternative.

Do I need to write tests for a take-home assignment?

Yes, unless the brief says otherwise. Basic unit tests for the main rules and a few edge cases are enough. Reviewers notice when tests are missing, even if the brief doesn't mention them.

Can I put my take-home project on my public GitHub?

Only if the company says it's fine. Many reuse the same test for every candidate and prefer it to stay private. Submit through a private repo with the reviewer as a collaborator, and if you want it in your portfolio, ask permission or rebuild a similar project of your own.

Key takeaways

• A take-home coding test is a work sample. Reviewers want working, readable, tested code they can run from your README, not cleverness.
• Send one clarifying email first: deadline (converted to WAT), expected hours, submission format, AI policy and priorities.
• Finish every must-have before any extra, and stay close to the stated time.
• Protect the work in Nigerian conditions: push often, install dependencies early, keep a backup connection and submit hours ahead.
• Treat the README as your voice: setup, decisions, assumptions, trade-offs, time spent and AI use.
• Expect a follow-up call on your code, and only submit what you can explain.
• Short unpaid tests are normal. Requests for money or to run suspicious scripts are not.

Next steps

When you're ready to put this into practice, browse remote tech jobs open to applicants in Nigeria. Each listing shows where applicants may live, so check that before you spend days on a test. After you search, use "Get email updates" to save it and get a free daily digest of new matching roles. To strengthen the skills a take-home tests, read our guide to becoming a remote software engineer from Nigeria. If you want someone to practise the follow-up code review with you, WorkRemote Premium includes one-on-one interview prep sessions as part of a membership.

Sources

• How to prepare for a technical assessment, OfferZen
• Take Home Tests, Code Your Future
• How we hire, Automattic
• Hiring - Frequently asked questions, Doist handbook
• Hiring Without Whiteboards, GitHub (poteto)
• About the repository README file, GitHub Docs
• Inviting collaborators to a personal repository, GitHub Docs