Content Manager interview questions

I run the calendar as one operational source of truth, not a static spreadsheet.

• One shared Airtable or Notion base with a row per asset and columns for channel, owner, status, publish date, funnel stage, and target keyword.
• A filtered view per channel so the blog and social leads see only their lane without losing the cross-channel picture.
• A pre-lock check each week that email and social pushes amplify the pillar piece rather than compete with it the same morning.

I set cadence from real throughput, then spend it where it moves goals rather than spreading thin.

• I start from what two writers actually ship per month in quality long-form, not an aspirational number.
• I would rather run one strong pillar plus three repurposed social cuts a week than five forgettable posts.
• Every quarter I rebalance the mix against engagement and conversion data and cut the channel that keeps underperforming.

I manage the risk before publish day rather than scrambling at the last minute.

• Interim checkpoints, an outline date and a first-draft date, surface a slip early.
• If a piece is truly at risk I pull a ready evergreen from my buffer or swap the slot with a lower-priority piece and reschedule.
• Then I talk to the writer about the cause, an unclear brief or overload, and adjust the next assignments.

I anchor the calendar with evergreen pillars and treat timely pieces as a smaller reactive layer.

• Evergreen pillars keep pulling organic traffic for months, so they carry roughly seventy percent of the plan.
• I leave headroom for news, launches, and trend pieces that must ship in days.
• That way a slow news week never empties the calendar and a big moment does not force me to drop everything.

I turn the strategy's priorities into a sequenced, executable plan with slack built in.

• I pull priority topics and funnel goals and break each into concrete assets with a keyword or job-to-be-done attached.
• I sequence pillar pages before the supporting cluster posts that link to them, each mapped to a channel and owner.
• I leave about twenty percent of capacity unbooked for reactive work and reviews so the plan survives contact with reality.

I make the calendar boring and visible rather than a black box, because surprises are the enemy.

• A single shared calendar view anyone can read, plus a short weekly note on what ships, what is at risk, and what I need.
• A monthly planning sync where sales, product, and demand gen see the roadmap and flag conflicts early.
• Clear ownership so people know which lane is theirs and stop stepping on each other.

I keep a deliberate buffer so opportunities do not derail planned work.

• Fifteen to twenty percent of capacity stays unbooked for a competitor move, a trending topic, or a product update.
• If the buffer goes unused I fill it with content refreshes, which are low-risk and always valuable.
• When reactive work repeatedly blows past the buffer, that is my signal the base plan is too ambitious and I rebalance.

I make the trade-off a transparent priority call rather than quietly disappointing two teams.

• I score requests on expected impact on the current goal, effort, and whether there is a hard external deadline like a launch.
• A launch-tied piece usually wins over an open-ended request.
• I say no or later to the rest with a clear reason and a slot on the roadmap.

I keep the meeting tight and tied to the board so it unblocks work instead of reading status.

• The agenda is what shipped, what is stuck and why, and what needs a decision this week.
• I come with blockers already identified so we spend the time unblocking, not narrating.
• Every action leaves with an owner and a date, and pure updates go in the written note instead.

I run production as clear stages with a gate and an owner at each one.

• Stages: intake and prioritization, brief, outline approval, draft, edit, SEO and design pass, review, then schedule and publish.
• Each stage has a definition of done, so half-baked drafts cannot clog the pipeline.
• It all lives on a kanban board so anyone can see where a piece sits without asking me.

Most rework comes from weak briefs and late reviewers, so I fix both at the source.

• A tight brief with the angle, audience, outline, and examples of good removes guesswork before drafting.
• Outline sign-off catches structural problems early, when they are cheap to fix.
• I lock reviewers and a review deadline up front so feedback does not trickle in after the piece is basically done.

I impose structure so intake is prioritized and defensible, not first-come by whoever shouts loudest.

• A single intake form forces requesters to state the goal, audience, deadline, and success metric before I accept anything.
• Vague requests get sent back for detail rather than absorbed.
• I triage weekly against priorities so requests enter a visible queue instead of landing in my DMs.

I use a short repeatable pre-publish list so quality does not depend on whoever publishes.

• The piece matches the brief and target intent, links and CTAs work, title and meta are optimized and unique.
• Images have alt text and are compressed, and the on-page SEO fields are filled.
• Internal links to and from the cluster are in place and tracking or UTM parameters are correct.

I control approval scope so review does not become a bottleneck.

• I define who is a required approver versus who is just informed, because if everyone can block, nothing ships.
• Legal or compliance-sensitive pieces get a named reviewer and a set turnaround.
• I collect feedback in one place, usually inline comments, so I am not reconciling five email threads.

I rely on lightweight visibility rather than chasing people for updates.

• A kanban view keyed to workflow stages shows owner, due date, and where each piece is stuck.
• A weekly scan flags anything aging too long in one column, my early warning for a bottleneck.
• The board is the status report, so status meetings stay short.

I diagnose the bottleneck by evidence and treat the cause, not the symptom.

• If pieces pile up in edit while drafting flows fine, editing is the constraint.
• The cause is usually too few editors, weak incoming drafts, or the editor doing rewrites the brief should have prevented.
• Depending on which, I redistribute review load, tighten briefs to raise draft quality, or add a peer-edit step so the senior editor only sees near-final work.

I give a structured ramp so quality scales rather than trial and error.

• Style guide, two or three exemplar pieces, and a real but low-stakes first brief so they learn by doing.
• Closer editing on the first few pieces, with the why behind edits, so they internalize the standard.
• A walkthrough of the CMS, calendar, and how briefs and reviews flow, so they are self-sufficient fast.

A written playbook keeps quality from walking out the door when a person leaves.

• It documents the workflow stages and gates, the brief and QA templates, the style guide, and naming and tagging conventions.
• New hires ramp in days, not weeks, because the standard is written down.
• I keep it living in Notion and update it whenever a process changes, or it rots and people stop trusting it.

A strong brief removes guesswork so a competent writer can produce a solid first draft without booking a call.

• Goal and funnel stage, target audience and search intent, primary keyword and related entities.
• A suggested outline, word count, internal links to include, and examples of the tone we want.
• What the piece is not about, to keep it focused.

I work backward from the objective to the reader action that supports it.

• If the goal is more trial signups from mid-funnel traffic, I brief a comparison or use-case piece that answers a buying question.
• I attach the CTA to trial and internal links to the pricing page.
• I make the connection explicit so the writer knows the piece has a job, not just a keyword.