How to Hire Software Engineers Without a Four-Hour Take-Home Test

Ask any engineering manager why a role has been open for four months and you will usually hear the same two things: not enough good candidates, and no time to screen the ones who apply. Both are real. Neither is usually the actual problem.

The actual problem is that most engineering funnels are built to reject, and the rejection happens before anyone has looked at a line of code. A keyword scan on the CV, then a four-hour take-home task sent by email. The first step cannot tell a senior engineer from someone who once read the documentation. The second step quietly removes almost everyone worth hiring, because the people you want already have a job, a life, and no reason to spend a Saturday on your assignment.

Why the take-home task backfires

Take-home tasks were invented to be fairer than whiteboard interviews, and in principle they are. In practice they load the entire cost of screening onto the candidate at the exact moment they owe you nothing.

The people who complete a four-hour task are, disproportionately, the people with four hours to spare: junior candidates, people between jobs, and people applying to twenty companies at once. The senior engineer with two children and a current employer who is happy with them will read the email, think "not for this", and close it. You did not screen them out. They screened you out.

There is a second cost that rarely gets counted. Somebody on your team has to review each submission properly, and the review is slow, subjective and inconsistent between reviewers. A task that takes the candidate four hours takes your team forty minutes per candidate. At thirty candidates that is a working week of engineering time spent on people you will mostly not hire.

What actually predicts a good engineer

The signal you are looking for is not whether someone can produce working code given unlimited time and an internet connection. Given enough time, most applicants can. The signal is judgement under constraint: what they choose, what they rule out, and what they notice is missing.

That is testable in minutes rather than hours, because judgement shows up in the first decision, not the fortieth. A handful of well-built questions will separate the field:

• A data model call. Given this requirement, which of these four schemas would you ship, and what breaks first in the one you rejected?
• A failure scenario. The deploy went out, error rates are up, the dashboard is flat. What do you look at first?
• A trade-off with no clean answer. Ship the feature with a known race condition behind a flag, or hold the release for a week? Both are defensible. The reasoning is the answer.
• A code-reading question. Not "write a function" - "here is a function, what is wrong with it". Reading is most of the job; writing from scratch is not.
• A scope question. The ticket says one thing, the requirement implies three more. Which do you raise before starting?

Notice that none of these have a single correct answer that can be looked up, and none of them take more than a minute to think through if you actually know the work. That is exactly what makes them good screening questions and bad interview trivia.

The stack is the least useful filter you have

Almost every job ad opens with a technology list, and almost every CV answers with the same list back. It is the least informative exchange in hiring. A competent backend engineer moves between Go, Java and Node in a few weeks. What does not transfer in a few weeks is knowing how to debug a production incident, how to size a database index, or when to say no to a requirement.

Filter hard on the things that genuinely do not transfer - a licence, a security clearance, a specific domain like payments or medical devices, real experience at your scale - and filter loosely on syntax. Every role you screen this way widens the pool without lowering the bar.

This applies across the whole spread of IT roles, not just backend. A frontend developer is judged on how they think about state and accessibility, not on which framework version they last touched. A DevOps or cloud engineer is judged on what they do when a rollback fails at 2am. A data engineer is judged on how they handle the pipeline that silently produced wrong numbers for a week. A QA engineer is judged on what they think to test that nobody wrote a ticket for. The stack changes; the judgement is the job.

Where the candidates actually are

The engineers you most want to hire are employed and are not reading job boards. They are, however, on Instagram and Facebook at lunch and on the sofa in the evening, like everyone else. That is not a marketing claim - it is simply where the population is.

An ad in that feed has to earn two seconds of attention from someone who was not looking for a job. A wall of requirements will not do it. A concrete, slightly provocative technical hook will: a question they cannot help answering, a bug they want to spot, a trade-off they have an opinion about. Engineers are competitive about being right, and a good technical question is close to irresistible.

The application then has to be short enough to finish on a phone, standing up, without a CV to hand. If the next step after the hook is "upload your CV and cover letter", you have converted curiosity back into work, and most people will stop.

What a two-minute screen looks like in practice

The shape that works is simple. The ad asks one real technical question. Tapping it opens a short quiz - six to ten questions, mixed difficulty, no login. Each answer scores against criteria you set in advance, and the time taken is part of the picture: an engineer who works through a trade-off question in forty seconds is telling you something different from one who takes four minutes on the same question.

At the end, the candidate leaves a name and a way to reach them, and that is the entire application. Nobody uploads a PDF. Nobody writes a cover letter. On your side, a ranked list arrives with every answer attached, so the first conversation starts at the architecture rather than at "so, tell me about yourself".

For senior roles you can extend this without breaking it: send a short timed skills test to the top of the list only. The people who reach that stage have already shown they can think, and they are far more likely to complete a real task once a human has told them they are a serious candidate. That is the same take-home task, moved to the point in the funnel where it costs you nothing.

Scoring fairly, and staying on the right side of the rules

Structured scoring is fairer than a CV read, but only if the criteria are set before the applications arrive and applied identically to everyone. Decide in advance what a strong answer looks like on each question, weight the questions that matter most, and leave the ranking alone once candidates start coming in.

Two things to keep out of it. First, anything that is not the work: employment gaps, university brand, and the shape of someone's career are poor predictors and reliable sources of bias. Second, targeting by age or gender. Employment advertising sits in a special category on Meta's platforms, and narrowing an engineering ad to "men, 25-34" is both against the rules and against your own interest - you have just removed most of the pool.

The takeaway

You do not need a longer test. You need an earlier, shorter one that measures judgement instead of stamina, placed where the candidates already are rather than where you wish they were. Keep the deep technical conversation for people who have already shown they can think - and stop losing the best engineers at the first email.

Qwiza turns an engineering job description into exactly this: an ad written in language engineers respond to, a scored technical quiz behind it, and a ranked shortlist with the reasoning attached - across frontend, backend, mobile, data, cloud and QA.