GEO Take-Home Assignments: How to Ace Them

#01What are hiring managers actually testing?

A take-home for a GEO role usually asks you to look at how a brand shows up in AI answers and suggest improvements. Behind that brief sit four questions. Can you design a fair test? Can you read messy, variable results without overclaiming? Can you connect findings to actions a team could take next week? And can you explain it clearly to someone busy?

Most weak submissions fail on the second question. They run a few prompts once, find the brand missing and declare a crisis. AI answers vary from run to run, so a single run proves little. Showing that you know this, and designing around it, puts you ahead of most candidates immediately.

Our view: treat the assignment as a sample of your working style, not a test of how many hours you'll give away. A tight, well-reasoned four-hour piece beats a sprawling twenty-hour one.

#02How should you scope the assignment?

Read the brief twice and write down the decision the hiring manager would make with your work. "Should we invest in GEO for our pricing pages?" leads to a different assignment from "Why don't we appear for comparison questions?" If the brief is vague, email one or two clarifying questions. Asking is a signal of seniority, not weakness.

Then set your own limits and state them at the top of your submission: which engines you tested, how many prompts, how many runs each, the date and whether you were signed in. Limits make your work credible. A reviewer who sees "12 prompts, 3 runs each, 3 engines, tested signed out on one day" knows exactly how far to trust your findings.

If the company sets a time limit, respect it and say how long you spent. If there isn't one, pick a reasonable one yourself. Overrunning by a few hours is fine; doing a week of unpaid work isn't, and good employers don't expect it.

#03How do you build a prompt set that holds up?

Write prompts the way buyers ask, not the way marketers describe products. Mix intents: questions that name the brand, comparisons against alternatives, "best tool for" recommendations and problem questions that don't name any brand. Brands tend to be named often on their own brand questions and far less often on problem questions, so a mix shows the full picture.

Keep the set small enough to run properly. Ten to fifteen prompts across those intents, each run three times, is plenty for a take-home. Write each prompt down exactly as you ran it so the reviewer could repeat your test. Include two or three prompts you'd expect the brand to win, as a sanity check. If the brand loses those, check your method before drawing conclusions.

#04How should you record and read results?

Use a simple sheet with one row per run: prompt, intent, engine, run number, whether the brand was named, its position in any list, whether the description was accurate, and which sources were cited. Note anything surprising in a comments column.

When you summarise, report ranges and counts, not just percentages. "Named in 7 of 9 runs on comparison prompts in one engine" is clearer and more honest than "78% visibility." Flag inaccuracies separately from absence. An assistant that describes a product wrongly is often a more urgent problem than one that leaves it out, and reviewers notice candidates who spot this.

Look at citations closely. Which pages are cited when competitors are named? Are they review sites, comparison articles, documentation or forum threads? That's where your recommendations will come from.

#05How do you turn findings into recommendations?

Give three recommendations, ranked, each tied to evidence from your test. For each one, say what to do, why your findings support it, roughly how much effort it takes, and how the team would know it worked. "Publish a comparison page answering the five questions where competitors are cited" is a recommendation. "Improve content quality" isn't.

Separate what you know from what you suspect. Label assumptions plainly. If you think a missing integration page explains a gap but couldn't confirm it, say so and suggest how to check. Reviewers trust candidates who mark uncertainty far more than those who sound certain about everything.

#06How should you present the work?

Lead with a one-page summary: the question, your method in three lines, the three findings that matter and your three recommendations. Put the detail in an appendix or a linked sheet. Busy reviewers read the first page closely and skim the rest.

If you present live, rehearse a ten-minute version. Expect questions about your method, especially why you chose those prompts and how you handled variation. Have a clear answer for "What would you do with more time?" A good answer names the next test you'd run, not just "more prompts."

#07What should you avoid?

Don't invent numbers or present guesses as data. Don't name tools you didn't use or claim access you don't have. Don't copy a template audit that ignores the brief. And don't criticise the company's current team; describe what you found and what you'd do.

Keep the company's data private. Don't publish the assignment or post findings online without permission, even in your portfolio. If you want to reuse the work, ask, or rebuild it on a fictional or public example.

#08From MentionX data: why intent mix mattersOriginal data

Method. Read-only aggregate queries over MentionX scans from 22 August to 29 October 2026 (UTC): 2,217 engine runs (2,154 completed) across 18 anonymised projects and six engines.

MentionX's anonymised aggregates show how much brand mentions depend on the type of question:

Our view: a take-home that only tests brand-name prompts will look rosy. Include problem and recommendation prompts, where brands are named far less often, to show you understand where the real gaps are.

Limits. A convenience sample of mostly B2B software projects, run through engine APIs, which can behave differently from the consumer apps. Perplexity, Copilot and DeepSeek figures come from a single day (26 October 2026), so treat them as a snapshot, not a trend.

#09Worked example: Ledgerline's take-home, seen from the hiring side

Ledgerline is a fictional accounts-payable tool. Figures are illustrative.

Ledgerline, a fictional accounts-payable tool, asks GEO candidates to spend about four hours on one question: "Why aren't we recommended when people ask how to automate invoice approvals?"

One candidate sends a 30-slide deck built on single runs of 40 prompts. Another sends two pages. She ran 12 prompts three times each in three engines, signed out, on one stated date. She found Ledgerline named often on brand questions and rarely on problem questions, and noticed that answers which named competitors cited comparison articles and integration docs that Ledgerline lacked. Her three recommendations each named an evidence row in her sheet. Ledgerline hires her.

#10What can you do before your next take-home?

Build a reusable test sheet with the columns above, practise on a public brand you know, and time yourself. Write a one-page summary of that practice run. When a real assignment arrives you'll spend your hours on thinking, not on setting up a spreadsheet. For more on interviews, see GEO interview questions.

#11How do you handle questions about your method?

Expect a reviewer to push on three points: why these prompts, why this many runs, and why these engines. Prepare a one-sentence answer for each. For prompts, explain that you mirrored the questions real buyers ask at different stages, and point to where they came from, such as the company's own help centre, reviews or sales pages. For runs, explain that answers vary, so repeated runs show whether a result is stable. For engines, explain that you chose the ones the company's buyers are most likely to use, and that you'd confirm this with customer data.

If a reviewer points out a flaw, agree where it's fair and say how you'd fix it. "You're right, I tested signed out only, so I can't speak to personalised answers. I'd add a signed-in run next" lands far better than defending a weak choice. Interviewers often care more about how you take criticism than about the original work.

#12How do you stand out without overworking?

Add one small extra that shows depth. A short note on how the company's structured data or crawler access could affect AI answers is useful. So is a quick check of whether its key facts, such as pricing, integrations or locations, appear consistently across its site and major listings. Keep each extra to a paragraph. The aim is to show range, not to deliver a free consulting project.

Finish with a short "next 30 days" plan: what you'd test first if hired, who you'd need to work with, and how you'd report progress. That turns your submission from a piece of homework into a preview of working with you.

#13What should a good submission look like at a glance?

Picture the reviewer opening your file. On page one they should see the question, your method in a few lines, three findings and three ranked actions. On page two, a short table of results by intent and engine. After that, an appendix with the full prompt list and a link to your raw sheet. If someone can understand your conclusion in two minutes and check your evidence in ten, you've done the job well. Name the file clearly, include your name and the date, and send it as a format the company can open without special software.

#14Common questions

How long should a GEO take-home take? Follow the company's limit. If none is set, choose a reasonable one, such as a few hours, and state it.

How many prompts should I test? Ten to fifteen across several intents, each run about three times, is usually enough.

Can I put the assignment in my portfolio? Only with permission. Otherwise rebuild it on a fictional or public example.

What tools should I use? A spreadsheet and the engines themselves are enough. Only mention tools you actually used.