Content Writer interview questions and answers

I'd write: "Orders were delayed because the system was overloaded." Or, to say who it affects: "So many people ordered at once that your order took longer than usual."

The changes: "due to the fact that" becomes "because", the hidden verbs come back ("there was a delay in the processing of" becomes "were delayed"), and the main point moves to the front. The sentence drops from 23 words to 8 without losing meaning. In an edit test, explain each change briefly like this, so the interviewer sees you know the principles and didn't just shorten it by instinct.

Active voice is the default because it's shorter and clearer about who did what: "Our team fixed the bug" rather than "The bug was fixed by our team".

Passive voice is right when the doer is unknown, unimportant or obvious, and the reader cares about what happened: "Your account has been verified" or "The bridge was built in 1960." It's also used in formal and scientific writing. What to avoid is passive used to hide responsibility, like "Mistakes were made" in an apology, which readers notice. A quick test: if you can add "by zombies" after the verb and it still makes sense, it's passive.

I'd start with the reader: who they are, what they already know and what they need to do after reading. Then I'd talk to the engineer for twenty minutes to understand the note, asking "What does this change for the customer?" and "Can you give me an example?" That usually gives me the one main message.

I'd structure the post around the customer: the problem, what changed, how it helps them and how to use it. I'd replace jargon with plain words, or explain it once, and use an example or comparison from daily life. Finally, I'd ask the engineer to check it for accuracy, so the simple version is still correct.

Give the answer early and make the rest easy to scan. The introduction should say what the reader will get, in two or three sentences, not a long warm-up. Headings should say something useful ("Check your PF balance on the EPFO portal" rather than "Step 2"), so a skimmer can find their part. Keep one idea per paragraph and paragraphs short, especially on mobile. Use numbered steps, tables and examples where they help, and end with a clear next step.

Then check it: read it aloud for flow and, after publishing, look at engagement time and scroll depth to see where readers stop.

A blog post is usually found through search or social media by someone who doesn't know the brand yet. It needs to answer their question fully, be easy to scan with headings, stay useful for a long time and be optimised for search.

A newsletter goes to people who chose to subscribe, so it can be more personal and conversational. The subject line and preview text decide whether it's opened at all. It should focus on one main message, be short enough to read on a phone, and have one clear call to action. Writing a newsletter like a blog post, long and with several links of equal weight, is a common mistake.

Three options: "7 Money Habits That Help You Save From Your First Salary"; "Where Does Your Salary Go by the 20th? A Simple Plan to Fix It"; "First Job, First Salary: How to Start Saving Without Feeling Broke".

A headline works when it's specific about the benefit, speaks to a clear reader (here, a fresher), and makes an honest promise the article keeps. Numbers, questions and the reader's own words help. For search, include the phrase people type; for social, curiosity can matter more. Avoid clickbait: a headline the article doesn't deliver on damages trust. Writing ten options and choosing the best is normal practice.

Write for the ear, not the eye. A natural speaking pace is around 130-150 words a minute, so a 60-second script has about that many words, and fewer if there are pauses or on-screen demonstrations. Open with a hook in the first two or three seconds that names the viewer's problem, cover one idea only, and end with a single call to action.

I write in two columns, what's said and what's shown, and add on-screen text, because many people watch without sound. Sentences should be short and easy to say. Then I read it aloud with a timer and cut anything that sounds written rather than spoken.

I'd first write a short core message document: what's launching, who it's for, the main benefit, proof and the call to action, so the facts stay the same everywhere.

The blog post gives the full story: the problem, how the product solves it, details, examples and screenshots, structured for search. The LinkedIn post leads with a strong first line, since only the first two or three lines show before "see more", then shares one insight or story in short paragraphs. The email has a clear subject line and preview text, a few short paragraphs for people who already know the brand, and one button. Each piece is written fresh, not cut and pasted.

I prefer primary sources: the government department, regulator, company filing or research paper where the information first appeared, such as RBI or a ministry's website for official figures. For any source, I check who wrote it and their expertise, when it was published or updated, whether it shows evidence or cites its own sources, and whether it has a reason to be biased, such as a company praising its own product.

Important facts should be confirmed by two independent sources. Forwarded WhatsApp messages and unsourced blogs aren't sources. Wikipedia is a useful starting point, but follow its references to the original instead of citing it.

I'd try to trace it to its origin: search the exact figure with words like "survey" or "report", check the earliest articles that used it, and look on the websites of the organisations it's credited to. If I find the original, I'd read what it actually measured: the year, the sample size, the country and the exact question. Statistics often get changed as they're repeated, for example a survey of 500 users in one city becoming "most Indians".

If I can't find the original, I don't use the number, or I replace it with a figure I can verify. I'd link the original source and note it in my fact-check notes.

Prepare first, so you don't waste their time on basics: read their published work and the topic, decide what the article needs from them, and write open questions that ask for experience and examples, such as "What mistake do you see most often?" Share the topic and the time needed in advance.

During the call, record it only with permission, ask follow-ups when an answer is vague, and ask them to explain any jargon as they would to a beginner. Afterwards, check names, titles and numbers with them, and if needed share quotes for factual accuracy, while keeping editorial control. Credit them correctly in the article.

Use the main keyword where it naturally signals the topic: the title, the H1, early in the first paragraph, at least one subheading, the URL and the meta description. Then write naturally, using synonyms and related terms, because search engines understand meaning, not just exact matches.

The better way to cover a topic is to answer the questions people ask about it: look at Google's "People also ask" box and related searches, and turn the useful ones into headings. Repeating a phrase unnaturally makes the text worse to read, and keyword stuffing is against Google's spam policies. Read it aloud: if a sentence sounds odd, rewrite it.

A meta description is the short summary of a page that search engines may show under its title in the results. It doesn't directly affect rankings, but a clear, specific one persuades people to click. Keep it to roughly 150-160 characters, include the main phrase, and say what the reader gets.

Example: "A step-by-step guide to filing your income tax return online: the documents you need, how to pick the right ITR form, and mistakes to avoid." Google sometimes rewrites descriptions to match the search, but a good one is still used often. Every page needs its own, never a copied one.

First check Google Search Console: which queries it used to rank for, and what's ranking above it now. Usually the competing pages are more current, more complete or a better match for what searchers want.

Then update it properly: correct outdated facts, figures, screenshots and rules; add sections answering the questions it now misses; tighten the introduction; improve headings; and add internal links from newer related articles. If two thin posts cover the same topic, merge them into one and redirect the old URL. Keep the same URL, and change the "last updated" date only when the update is real. Then request indexing with URL Inspection.

I'd use AI for the parts around the writing: brainstorming angles, drafting an outline to improve on, suggesting ten headline options, summarising long research material, and checking grammar and clarity. The actual article I'd write myself or rework heavily, adding what AI can't: real examples, expert quotes, first-hand experience and the brand's voice.

I'd check every fact it gives, since AI tools invent statistics and sources. I'd follow the client's policy on AI use. Google ranks content by how helpful it is, not by how it was made, but publishing large amounts of low-value AI text breaks its spam policies, so quality has to come first.

I'd treat both as unverified until I find them. For the study, I'd search its title, authors or organisation, find the original paper or report, and check that it says what the draft claims: the figure, the year, who was studied. AI often gets these slightly wrong, or invents a study that sounds real.

For the quote, I'd search the exact words. If I can't find where the person said it, I remove it: putting invented words in a real person's mouth is a serious error. I'd also check that every link works and leads to the right page, and replace anything unverifiable with sources I've read myself.

The same things I'd put in a brief for a junior writer. The audience and their level, the goal of the post, the target keyword and the search intent, the brand's voice with a short sample, the sections it must cover, the length, and what to avoid, such as competitor names or claims we can't prove. I'd ask it to suggest headings with one line on each, and to list questions it thinks the reader will have.

Then I'd improve the outline myself. I wouldn't paste the client's unpublished product details or internal documents into a tool the client or company hasn't approved.

Lead with your writing, and point to work they can read. "I'm a [degree] graduate from [college], and I've been writing seriously for [two years]. I write [a blog on personal finance / articles for my college magazine], and I've done freelance work for [type of clients], mostly [blogs and social posts]. One article I wrote on [topic] ranks on the first page for [phrase] and brings [number] visits a month. I enjoy turning complicated topics into simple guides, which is why this role, writing for [their audience], interests me."

Have your portfolio link ready, with three of your best and most relevant pieces at the top.

Show that you see feedback as the fastest way to improve. "I'd first read the edited version carefully to understand what changed and why. If it isn't clear, I'd ask the editor, not to argue but to learn: was it the structure, the tone, accuracy? Then I'd note the pattern so the next draft needs fewer changes. During my internship, my editor kept cutting my introductions, so I learned to start with the main point; by the end, my drafts needed far fewer edits."

If you disagree with a change on a factual point, say so politely, with your source.

Say yes, and explain your method so it sounds credible. "Yes. Most writers work across topics. I'd start with reliable sources to learn the basics, read the best-ranking articles to see what readers expect, and, where possible, talk to someone who works in the field, such as the client's product team. I keep a list of questions as I research, and I don't write anything I can't verify. For example, I wrote [articles on topic] for [client] with no background in it, and [result or feedback]."

Mention any niches you already know well too: finance, tech, health, education.

Give an honest range and explain what it depends on, rather than a big number. "For a researched blog post, about [1,500-2,500] polished words a day; for a simpler topic or social posts, more; for technical or expert-interview pieces, less, because research and fact-checking take time." Then show how you meet deadlines: outline first, research before writing, write the draft in one block, and edit separately.

Add that if a deadline is at risk, you tell the editor early. Interviewers are wary of candidates who promise very high word counts, because quality usually suffers.

Choose one piece and talk about results, not just the writing. Structure: the goal, what you did, and what happened. "[Client] wanted more sign-ups from organic search. I wrote a guide on [topic] after interviewing two of their [experts] and studying what the top results were missing. Within [three months] it reached the first page for [phrase], brought around [number] visits a month and became their top page for sign-ups."

If you don't have numbers, use feedback: the client's reaction, shares or comments. End with what you'd do differently, which shows you keep learning.