Technical Assessments and Take Home Tasks: A Senior Engineer's Guide to the Tech Challenge

The brief arrives at about five on a Thursday. Nine hundred words of PDF, and somewhere in the third paragraph it says “this should take around four hours.” Then you read the requirements. An API, a data store, authentication, a small front end, tests, a Docker setup, and a section headed “bonus points” listing four more things. You have done this work for fifteen years, and it is not four hours.

So you sit there doing the arithmetic every senior engineer in Australia has done at some point. Two evenings and most of Saturday, for a repository a stranger will read for twenty minutes against a rubric you have never seen. And you are doing it around a job you still have, on the four weeks notice most Australian contracts carry, which is the wait this employer faces anyway.

The advice online is either “just do the task” or “never do unpaid work,” and both come from people with no mortgage and no notice period to think about. Some tech challenges are the fastest route into a good team. Some are a scoping failure. A surprising number are negotiable if you ask properly, which almost nobody does. This article is about that stage: the take home task, the pairing session, the systems design round, and what happens after you submit.

One note before we start. Every timing, number and template below shows the shape of a thing rather than a claim about any employer or about the market. Swap in your own facts before you send anything.

Why are senior engineers still asked to do a tech challenge?

Because a panel cannot tell someone who has led three platform rebuilds from someone who has watched three, and a conversation does not reliably separate them. The task is a cheap way to see real work. It is also, less flatteringly, a way for a hiring manager to dodge a judgement call they do not feel qualified to make.

The third reason matters more. Teams hiring at senior level are often hiring one person into a small group, so a bad call is expensive and there is no bench to absorb it. A tech challenge feels like insurance. It rarely is, but the feeling keeps the format alive even at teams who complain about it.

Who you are talking to changes what you can do about it. Large Australian employers tend to run structured loops where every round has an owner and a scoring sheet, so the task is fixed by the process rather than by the person interviewing you. Smaller product teams have far more room to swap it. If the panel genuinely cannot assess you another way, do the task. If it is step four in a document nobody has revisited in years, you can often replace it.

What does the reviewing engineer actually look at?

They open the README first. Then they run the tests, or try to. Then they skim the directory structure, open two or three files, and form a view. In most processes a reviewer spends between fifteen minutes and an hour on a submission, not the eight hours you spent building it. That asymmetry is the most important fact about the exercise, and almost every over engineered submission ignores it.

Here is roughly how that time gets spent.

What they open	Time on it	What it is testing
README	Two to five minutes	Can you frame a problem, state assumptions, name trade offs
Setup and run instructions	Two minutes	Does it start on a clean machine. One that does not run is usually dead
Test suite	Five to ten minutes	Behaviour or getters. Is there one test proving the hard case
Commit history	One minute, if there is one	Slices, or one commit called “solution”
Two or three source files	Ten to twenty minutes	Naming, boundaries, error handling, whether it reads like a person wrote it
Bonus features	Often not at all	Whether you knew what to leave out

Nobody is grading the cleverness of your algorithm. The thing assessed is judgement under a constraint, and the README is where judgement lives, because it is the only place you get to say why.

The reviewer’s unspoken question: “would I merge this if it arrived as a pull request from someone on my team on a Tuesday?” Not “is this impressive.” Not “is this complete.”

A plain solution with a README naming three trade offs and one known weakness out scores a beautiful solution with no explanation, because the second leaves the reviewer guessing whether you chose that design or fell into it.

How do I scope a take home task so it does not eat my weekend?

Take the number in the brief and treat it as the actual budget, not a suggestion. Set a timer. Build the smallest thing that shows the core skill they asked for, make it run cleanly, write the tests that prove the hard case, then stop. Everything you did not build goes in the README as deliberate decisions with reasons. That list is a deliverable, not an apology.

Settle two things by reply before the clock starts. Ask when they want it back, because a brief with no return date quietly becomes an assumption that it is Monday morning. If you have a live process elsewhere, ask to start the following week rather than that night.

Hi Priya, happy to take this on. When do you need it back, and would your team mind if I start it on Monday? I have a final stage elsewhere on Friday and would rather give this proper attention.

On a four hour budget, the structure that works looks like this.

Block	Time	What happens
Read and decide	20 minutes	Read the brief twice. Write down the one thing being tested. Choose your cuts first
Skeleton that runs	30 minutes	Empty project, one endpoint, one passing test, committed. Now you have something submittable
Core path	90 minutes	The actual feature. Commit in slices with real messages
Tests that matter	45 minutes	One happy path, two for the edge cases you would worry about in production
README	35 minutes	Assumptions, trade offs, omissions, how to run it, what you would do next
Tidy and submit	20 minutes	Clean clone, fresh install, follow your own instructions

For the README itself, this shape does the work.

What I built. A single service that does X, with Y left as an in memory store. Three commands to run it from a clean clone.

Assumptions. The brief did not say whether Z was required, so I assumed not and designed so it can be added at the boundary.

Trade offs. I chose a simple queue over an event stream because the stated volume does not justify the operational cost. At ten times the volume I would revisit this first.

What I left out, and why. Authentication, because the brief named it as a bonus and I prioritised test coverage on the core path inside the budget.

What I would do next, with another day. Property based tests on the parser. A migration story for the schema.

That last section changes outcomes. It tells the reviewer you can see past the toy, which is the exact quality they are hiring for.

When should I do the take home task, and when should I decline?

Do it when the role is one you would actually accept, you have already spoken to a human from the team, and the scope is reasonable or negotiable. Negotiate when any of those is missing. The strongest signal is order: a task sent before any conversation is a filter, and filters at senior level usually mean the process was not designed for you.

Situation	What it usually means	Reasonable response
Task arrives after a good talk with the hiring manager	They want evidence	Do it, capped at the stated time
Task arrives before any call, with the first reply	You are one of forty in a funnel	Ask for a short call first. It is a normal ask
Brief says four hours, scope is clearly eight	Nobody has timed it recently	Do four hours and say so in the README
You are already at final stage elsewhere	Sequencing, not judgement	Give them the deadline, ask for a pairing session
They want work off their real backlog	Unpaid work, not an assessment	Decline the format. Offer your own code
Third assessment in the same process	The process has no owner	Ask what this round decides that the last two did not

If nobody can tell you what a round decides, it does not decide anything. The reasons candidates get cut are usually structural rather than technical, a pattern we pulled apart in the gates where candidates actually get rejected.

How do I ask for a different format without sounding difficult?

Never decline in the abstract. Decline the format and offer two specific substitutes in the same message, with a time you are willing to commit. “I cannot do eight hours but I will give you ninety minutes live, this week” reads as someone with a full life and clear boundaries. “I do not do take home tasks” reads as hard to work with.

Send it to the recruiter, not the hiring manager.

Hi Priya,

Thanks for sending the challenge through, and I want to be straight about the scope. Realistically it is a full day of work, and with my notice period and a live process elsewhere I cannot commit that this week.

I am still very interested, so two alternatives I can do:

1. A ninety minute pairing session with one of your engineers, on a problem of their choosing. Happy for it to be unseen.
2. A walkthrough of a service I built and own, covering the design decisions, the parts I would change, and what broke in production.

Either gives your team a better read on how I work than a weekend project would. I can do Tuesday or Thursday afternoon. Which suits?

Nikhil

Three things make that land. It names the real constraint rather than inventing a principle. It offers your time in a different shape rather than less of it. And it ends with two dates, which turns a negotiation into a scheduling question.

The Australian tech market is also small. Hiring managers move between employers and talk to each other, so the way you decline travels further than the role does. A specific, warm no is remembered as well as a yes.

If they say the task is mandatory, do a time boxed version and say so in your reply.

Understood, happy to proceed. I will time box it to the four hours the brief suggests and document what I would have added with more time.

Can I use AI tools on a take home task?

Ask first. One line to the recruiter settles it: what is your policy on AI assistance for this task? Policies now vary round by round inside the same company, and asking is never held against you. If they say yes, use the tools as you would at work and disclose it in one line. Never use AI on a task that explicitly bans it.

That is not fence sitting. In 2026 this is a genuine split rather than settled permission. Some large employers warn in their candidate instructions that using generative AI during an assessment may be grounds for disqualification, and at least one well known AI company tells candidates to complete take home assessments without AI unless the company indicates otherwise. Other teams assume you will use the tools and would think less of you if you had not. You cannot tell which from the brief, and asking costs nothing.

If you could not reach anyone before the clock started and the brief is silent, the safe reading is restraint. Scaffolding, boilerplate and test fixtures are defensible. Anything touching the design or the domain logic should be yours, and you disclose whatever you did use.

The line in your README can be one sentence.

I used an AI assistant for scaffolding, boilerplate and test fixtures, the same way I would in my day to day work. The design decisions, the domain modelling and the trade offs described above are mine, and I am happy to walk through any part of the code.

What damages you is the gap between what you submitted and what you can explain. Reviewers increasingly follow the take home task with a short walkthrough call for exactly this reason, and that call is now the real assessment. If you generated something you do not fully understand, the conversation will expose it in minutes, and it reads as dishonesty rather than as a tooling choice.

So: ask, match what you do to the answer, read everything the tools produce, delete anything you would not defend. And if the brief bans AI assistance, honour it. Ignoring a written instruction during an assessment tells the employer something they will remember.

What is different about live coding and pairing sessions?

Almost everything. In a take home task the artefact is judged. In a pairing session you are, specifically your behaviour when you do not immediately know the answer. They watch how you narrate your thinking, whether you ask clarifying questions before writing code, how you react to a curveball, and whether you are pleasant to sit next to for an hour.

The failure mode for senior people is silence. You go quiet because you are thinking, as you would at your desk, and the interviewer reads it as stuck. Narrate instead.

“Right, before I write anything: is this batch or is it going to be called per request? Because that changes whether I care about the allocation in the loop. I will assume per request and call it out if that is wrong.”

Four practical habits carry a pairing session.

• Restate the problem in your own words before you touch the keyboard. Twenty seconds, and it catches the misread requirement that would cost you the round.
• Write the ugly version first, out loud, saying you will clean it up. A stated intent to refactor is rarely penalised.
• When you are stuck, say so and say what you would look up. “I would check the exact signature, I always do” is a normal thing for a senior person to say.
• If the shared editor has no autocomplete or types, name it once, calmly, then get on with it.

How should I approach a systems design interview?

Treat it as a requirements conversation that happens to involve a whiteboard. The common senior failure is jumping to an architecture in the first two minutes. The interviewer wants to see whether you find the real constraints before committing to a shape, because that is the expensive mistake in real projects.

A sequence that holds up under pressure:

1. Clarify scope for five minutes. Who uses this, how many, how often, the read to write ratio, the tolerance for staleness, what is out of scope.
2. State the non functional requirements as numbers. Invented and agreed out loud is fine. “Let us say five thousand writes a minute at peak and a hundred millisecond budget at the edge.” Design without numbers is decoration.
3. Draw the boring version. Client, API, store, queue, worker. Say it is the boring version deliberately.
4. Break it on purpose. Name where it fails first as load grows, and fix only that. This is the part being marked.
5. Name the trade off you are accepting. Consistency for availability, cost for latency, simplicity for throughput. Which one, and why.
6. Close with operations. How you would know it is broken at three in the morning, and what you would look at first. Few candidates get here, and it separates people who have run systems from those who have only drawn them.

Employers hiring platform people often fold this round into a delivery conversation, so expect deployment, rollback and on call questions too. The ground those interviews cover is mapped out in our guide to DevOps interviews.

What should I do after I submit the task?

Send one short message confirming the submission with a line about what you chose to focus on, then leave it alone for a week. Do not send follow up commits, and do not email improvements you thought of on Sunday night. The submission is a snapshot of your judgement under a time limit, and adding to it afterwards undoes the constraint you were tested on.

Hi Priya, submitted just now, repository link below. I time boxed it to four hours and put the trade offs and the “what I would do next” list in the README, so the thinking is visible even where the code stops. Happy to walk through any of it live.

The exception is a defect that stops it running. If your setup instructions are wrong, fix them and say so. Anything else waits for the conversation.

The cadence then matches any other stage, and the rules for following up after an interview without sounding desperate apply here too. One addition: when feedback arrives, ask for the rubric. Not defensively, just “is there a scoring guide you can share the headings of, so I know what I under weighted?” Some send it, and it is worth a lot next time. If a recruiter is carrying your submission, ask them to chase it, which is part of what our delivery team handles for candidates.

Common mistakes senior candidates make

• Over building. Bonus features, a caching layer and a CI pipeline on a four hour task. It reads as an inability to prioritise.
• Submitting with no README. The most expensive omission available. Your thinking stays invisible and the code is scored alone.
• Apologising in the README. “Sorry, I ran out of time” is weaker than “I stopped at four hours as agreed, and here is what came next.” Same facts, different read.
• Going silent when the scope is impossible. Employers often do not know their brief is oversized, because candidates worry that saying so counts against them.

The senior candidate’s tips

• Keep a reference project ready. One service you built, can talk about for forty minutes, and can share publicly. It turns a decline into a counter offer.
• Check the licence and confidentiality of anything you share. Never walk a panel through code you have no right to show.
• If it reaches an offer, the effort you put in here is leverage in the conversation that follows, covered in how to negotiate a salary offer.
• Experienced engineers do not need a course for this. Campus4tech offers standalone job support for people already in the market, which here means scoping the brief with you and reviewing the submission before it goes.

Checklist before you submit

Check	Done
Fresh clone, my own setup instructions followed, tests pass
README states assumptions, trade offs, omissions and next steps
Time spent is stated honestly, and AI assistance disclosed if used
No dead code, no commented out experiments, no TODOs
Commit history reads as a sequence of decisions
I can explain every file out loud

Frequently asked questions

Should I do an unpaid eight hour take home task?

Only if the role is one you would genuinely accept, you have met a human from the team first, and the scope is capped at something you can finish in about four hours. If all three hold, do it and cap the time yourself. If any one is missing, ask for a smaller brief or a pairing session before you commit a weekend.

What do reviewers actually look at in a take home task?

Reviewers read the README first, then the tests, then the shape of the code, usually in well under an hour. They are looking for judgement under a constraint: what you chose to build, what you deliberately left out, and whether you can explain both. Clever code with no explanation scores worse than plain code with a clear rationale.

Can I use AI tools on a take home task?

Ask first. One line to the recruiter settles it: what is your policy on AI assistance for this task? Policies now vary round by round inside the same company, and asking is never held against you. If they say yes, use the tools as you would at work and disclose it in one line. Never use AI on a task that explicitly bans it.

How do I decline a take home task without losing the role?

Decline the format, not the assessment. Say plainly that you are not able to commit a full weekend at this stage, then offer two concrete alternatives on the same message: a ninety minute pairing session, or a walkthrough of production code you already own. Some employers will take one of them, and the ones who refuse any substitute have told you something useful.

How long should a senior take home task take?

Briefs commonly say four hours and describe a scope closer to eight. Treat the stated number as the budget you actually spend, and use the README to list what you would have done with more time. A task that needs more than a working day is a scoping failure, and it is fair to say so politely before you start.

Can experienced engineers get help with assessments without enrolling in a course?

Yes. Campus4tech offers standalone job support with no training attached, which is usually what people already in the market need. At the assessment stage that means scoping a brief before you start, reviewing your README and tests before you submit, and rehearsing the walkthrough. We continue working with candidates until they are successfully placed.

Summary

The tech challenge is not a test of how much you can build in a weekend. It is a test of what you choose to build, what you leave, and whether you can say why. That is why the README carries more weight than the code, and why the walkthrough afterwards is where the decision is increasingly made.

Treat the stated time as a hard budget. Put the thinking where the reviewer will find it. Ask about AI before you decide anything, then be straight about what you used. Offer a pairing session when the brief is oversized, with two dates attached. And when a process asks for a third assessment nobody can justify, walking away is a senior decision rather than a failure of nerve.

Campus4tech works with experienced technology professionals across Australia on the parts of a search that decide the outcome: positioning, submissions, interview rehearsal and the assessment stage itself. If you keep stalling at the same round, book a free consultation and we will look at where it is actually going wrong. We continue working with candidates until they are successfully placed.