Interview Tasks That Have Nothing to Do With the Job

When what an interview tests and what a job actually requires are two different things, the interview stops being a selection tool and becomes an obstacle course — one that rewards prep time, test-taking skill, and tolerance for absurd tasks over real professional ability.

This problem is most visible in tech — where algorithmic puzzle rounds are standard for roles that will never require writing an algorithm — but it exists across industries wherever interview design has drifted from evidence toward tradition, convenience, or the interviewers' own preferences.

The research on this is not ambiguous. The disconnect between what most interviews test and what predicts job performance is well-documented. The problem is that organisations rarely feel the cost — candidates do.

The most common forms of this problem

These are not edge cases. They are standard practice at a significant portion of employers across size and industry.

LeetCode-style algorithms for roles that don't write algorithms

Frontend engineers, product engineers, and most senior individual contributors are evaluated on system design, communication, and delivery — not on whether they can implement a red-black tree under time pressure. Yet algorithmic puzzle rounds remain standard at large tech companies for roles where the skill will never be used. The result is a filter for people who have spent weeks grinding interview prep, not for people who can do the job.

Unpaid take-home projects that could have been a work sample conversation

A three-to-five-hour take-home assessment for a junior or mid-level role extracts significant unpaid labour from candidates, many of whom are working full-time jobs while applying. The same signal — does this person understand the problem space? — can be assessed in a 30-minute portfolio review or a short paid exercise. When companies default to unpaid take-homes, they disproportionately screen out employed candidates who cannot spare the hours, while collecting real work product for free.

Brain teasers and estimation puzzles for execution roles

"How many golf balls fit in a Boeing 747?" was popularised by consulting interviews in the 1980s. Research published by Google's own HR team in 2013 found that brainteaser results had zero correlation with job performance. They remain in use not because they predict anything, but because interviewers find them intellectually interesting and candidates do not yet refuse them en masse.

Multiple rounds testing the same dimension

A five-round process where rounds two, three, and four are structurally identical — all behavioural, all asking the same "tell me about a time you..." questions — adds attrition without adding signal. Each round costs the candidate preparation time, often a half-day of leave, and emotional energy. The information gain per additional round drops sharply after the second or third interview; what follows is usually anxiety management for the hiring team rather than genuine evaluation.

Industry-specific technical tests for cross-functional roles

A designer applying for a B2B SaaS company who is asked to design a healthcare product for a 48-hour take-home. A data analyst asked to write production-grade ETL pipelines. A marketing hire asked to complete a full competitor analysis with deliverables. When the task requires deep domain knowledge the role does not require, the test measures either luck (the candidate happens to know the domain) or willingness to perform unpaid specialist work.

Why this persists despite the evidence

The companies running these processes are rarely doing so because the evidence supports it. They persist for a different set of reasons: inertia (we have always done it this way), social proof (prestigious companies do it), risk aversion (harder to be blamed for a rigorous process than for a quick one), and the simple fact that poorly-designed interviews rarely produce visible feedback.

When a candidate is screened out by an irrelevant test, they do not usually tell the company. They move on. The company never learns that it passed on a strong candidate because the algorithm puzzle was not representative of the role. The interview looks like it worked — someone was hired — even if the signal was noise.

The candidates who refuse or fail these tasks are not tracked. The counterfactual — how the hire would have performed versus the candidate who dropped out at round three — is never measured. So the feedback loop that would correct the behaviour never closes.

What the research actually says

Interview validity has been studied for decades. The findings are consistent and largely ignored.

Google's own data on brainteasers ↗

Laszlo Bock (then SVP People Operations at Google) confirmed that brainteaser interview questions are 'a complete waste of time' — they 'don't predict anything.'

New York Times, 2013

Structured interviews outperform unstructured ones ↗

A meta-analysis of 85 years of hiring research found structured interviews — consistent questions evaluated against defined criteria — are substantially more predictive of job performance than unstructured ones.

Schmidt & Hunter, Psychological Bulletin, 1998

Work sample tests are among the strongest predictors ↗

The same meta-analysis ranked work sample tests — giving candidates a realistic preview of the job and asking them to do it — as one of the highest-validity selection methods available.

Schmidt & Hunter, 1998

The LeetCode interview problem ↗

Engineering blog posts from practitioners at companies including Netflix, Basecamp, and others have documented that algorithmic interview performance does not correlate with engineering output once hired.

Thomas Ptacek, 2015

What good interview design looks like

The highest-validity selection methods, per decades of research: work sample tests (asking candidates to do a representative sample of the actual job), structured behavioural interviews (consistent questions, scored against defined criteria), and cognitive ability assessments when relevant to the role.

A work sample for a frontend developer is a small, realistic, scoped task — not an algorithm puzzle, not a five-hour rebuild of an existing feature. A work sample for a copywriter is editing a piece of real company content with a brief. For a data analyst, it is a short dataset with a defined question, reviewed in conversation.

The common thread: the task resembles the job, is scoped to require hours rather than days, and is reviewed in a structured way. This is not complex. It is mostly not done because designing it requires more effort from the employer than issuing a generic LeetCode link.

Share this with your network

If you have spent days prepping for an interview task that had nothing to do with the role, you are not alone. Sharing this helps make the problem more visible — and puts pressure on employers to design better processes.

Share on LinkedIn Share on X Share on Reddit

Read the related issue

Sometimes the process is not just poorly designed — it was never open to you in the first place.

Nepotism in Hiring: How Rigged Processes Ghost Real Candidates →Next: When Recruiters Build Pipelines to Sell →