contentful Software Engineer Interview: Questions & Prep (2026)

Contentful is a headless CMS platform used by large enterprises to deliver content across websites, mobile apps, and digital channels through APIs. Their engineering team builds the Content Management API, Content Delivery API, SDKs, and the web app that content editors use every day. As of July 2026, knok jobradar tracks 36 open Software Engineer roles at Contentful.

Candidates typically report a process spanning 3-4 rounds: a recruiter call, a technical phone screen, a coding exercise (take-home or live), and a final virtual panel covering system design and behavioural questions. The full cycle typically takes 2-4 weeks. Contentful's stack is TypeScript, React, and Node.js, and their interview questions reflect this, with heavy emphasis on API design, content modelling, and product thinking.

Expected salary ranges for Software Engineers in India:

Ranges are from knok jobradar. Actual offers vary by team, specialisation, and negotiation.

These questions are drawn from Contentful's public engineering blog, Glassdoor interview reports, and the nature of their product. Expect a mix of technical depth and product thinking.

1. How would you design a versioning system for content entries in a CMS? Walk through the data model and the trade-offs between approaches.
2. Contentful's Delivery API and Management API are central to the product. Describe a time you designed or took ownership of a public-facing REST or GraphQL API.
3. How would you build a webhook delivery system that guarantees at-least-once delivery without causing duplicate processing on the consumer side?
4. Walk us through how you would help a large enterprise customer migrate thousands of content entries from a legacy CMS to Contentful's data model.
5. Contentful uses TypeScript throughout its codebase. Describe a situation where strict typing caught or prevented a class of bug in a shared codebase.
6. How would you diagnose and fix performance issues in a React application that fetches content from a headless CMS at runtime?
7. Design a caching layer for a read-heavy content delivery API. How do you handle cache invalidation when an editor publishes new content?
8. How do you balance shipping features quickly with maintaining backward compatibility in a public API that thousands of developers depend on?
9. Tell me about a time you disagreed with a product or technical decision. What did you do, and what was the outcome?
10. How would you model a multi-tenant content structure that supports different locales, roles, and permissions per customer account?
11. Contentful's web app is used by non-technical content editors every day. How have you built interfaces or internal tooling for non-developer end users?
12. Walk me through how you approach reviewing a pull request that proposes a significant architectural change to a shared service.

Q: Contentful's APIs are central to the product. Describe a time you designed or took ownership of a public-facing REST or GraphQL API.

*Situation:* At my previous company, three client teams (web, iOS, and Android) all called the same REST endpoints. Each team pulled full content objects even when they only needed a handful of fields, which caused slow page loads on mobile.

*Task:* I was asked to lead a migration to a GraphQL API so each client could request exactly the fields it needed, while keeping the existing REST endpoints live for teams that had not yet migrated.

*Action:* I set up Apollo Server alongside the existing API, collaborated with each team to draft the initial schema, added persisted queries to avoid sending large query strings in production, and wrote a migration guide per client team. I kept the REST endpoints running for several months while teams moved across at their own pace.

*Result:* All three client teams completed the migration within the window. The mobile teams reported noticeably smaller payloads, and two features that had been blocked on data availability shipped in the same sprint after the switch.

---

Q: Tell me about a time you disagreed with a product or technical decision. What did you do?

*Situation:* Our product manager wanted to ship a bulk-publish feature in a single release because a key customer had requested it urgently. I believed the design allowed users to accidentally publish hundreds of draft entries at once with no confirmation step.

*Task:* I needed to raise the concern clearly without derailing the sprint or appearing obstructive.

*Action:* I wrote a short document outlining the risk with a concrete user scenario, proposed two alternatives (a confirmation modal showing an entry count, or a phased rollout to a beta group first), and scheduled a focused review with the PM and design lead before sprint planning.

*Result:* We shipped the phased rollout approach. The beta group flagged two edge cases we had not caught in review, and we resolved them before general availability. The PM later mentioned the document made the risk easy to explain to stakeholders.

---

Q: How would you design a caching layer for a read-heavy content delivery API?

*Situation:* A previous employer ran a content platform that experienced heavy traffic spikes during product launches. The origin database could not absorb direct read traffic during those peaks.

*Task:* I needed to design a caching strategy that kept content fresh for editors while shielding the database from spike loads.

*Action:* I introduced a CDN layer with short TTLs for frequently updated content and longer TTLs for static pages. Behind the CDN I added an in-process cache with a write-through invalidation hook triggered by our CMS publish events. I also built a cache warming job that pre-fetched high-traffic pages after each publish event.

*Result:* Database read load during peak events dropped significantly. Editors saw published changes appear on the live site within the TTL window we had agreed with the business, which resolved a long-standing complaint about stale content.

For system design questions: Open with requirements (read vs. write ratio, scale, latency expectations), then walk through the data model, then cover individual components. For a CMS platform like Contentful, always address how content publishing events propagate through the system, since that is the core of what they build.

For API design questions: Start from the consumer perspective (what does the client need?), then define the contract (endpoints or GraphQL schema), then cover error handling, rate limiting, and versioning. Mention backward compatibility explicitly, since Contentful maintains public APIs that thousands of developers depend on.

For behavioural questions: Use STAR: Situation (brief context), Task (your specific responsibility), Action (what you personally did, not the team), Result (an observable or measurable outcome). Contentful interviewers typically want to hear about cross-functional collaboration, so highlight moments where you worked across engineering, product, and design.

For TypeScript or language-depth questions: Go beyond 'I use interfaces and generics.' Name a specific TypeScript feature (discriminated unions, conditional types, mapped types) and the real problem it solved in your codebase.

For 'disagreement' questions: Structure your answer as: what you believed and why, how you raised it (document, meeting, or prototype), what decision was made, and what you learned. Show that you can advocate clearly and then commit once a decision is reached.

Contentful's engineering culture, based on their public engineering blog and Glassdoor interview feedback, centres on a few consistent themes.

Product empathy. Contentful serves both developers (via APIs and SDKs) and non-technical content editors (via the web app). Interviewers want to see that you think about the end user and the editor experience, not just the technical implementation.

API-first thinking. The product is fundamentally a set of APIs. Candidates who can reason about contracts, versioning, and backward compatibility stand out. If you have owned or maintained a public API, lead with that experience.

Ownership and clear communication. Candidates report that Contentful values engineers who can spot a problem, articulate it clearly, and drive it to resolution without waiting to be told. Your behavioural answers should demonstrate this.

Collaboration across functions. The process typically includes questions about working with product managers, designers, and other engineering teams. Show that building great software, for you, includes aligning with non-engineering stakeholders.

Honest trade-off reasoning. When you answer a design question, name the trade-offs rather than presenting one solution as obviously correct. Saying 'this approach works well for high read volume but adds operational complexity' signals maturity that interviewers consistently look for.

Week 1: Learn the product and the stack. Sign up for a free Contentful account and explore the Content Management API, the Delivery API, and the web app editor. Read a few posts on the Contentful engineering blog to understand how they approach distributed systems and API design. Note the core tech: TypeScript, React, Node.js, GraphQL.

Week 2: System design practice. Prepare to walk through at least three systems relevant to Contentful's domain: a content versioning system, a webhook delivery pipeline with at-least-once guarantees, and a caching layer for a read-heavy API. For each, know your data model, failure modes, and the key trade-offs.

Week 3: Coding depth. Practice TypeScript-specific patterns such as generics, discriminated unions, and mapped types. Review React performance patterns including memoisation, lazy loading, and code splitting. If you receive a take-home exercise, prioritise clean types, clear naming, and at least a few tests.

Week 4: Behavioural preparation. Write out STAR stories covering: a technical disagreement, a project you owned end to end, a process you improved, and a time you supported a non-technical stakeholder. Practice delivering each story in under three minutes.

Day before the interview: Review recent posts from the Contentful engineering blog and prepare two genuine questions per round. Good questions show you have engaged with their engineering material, for example asking how they handle cache invalidation at scale or how they approach API versioning internally. If you are still in the job hunt, knok checks 150+ job sites nightly, applies to matching Software Engineer roles on your behalf, and messages HR for you so you stay active even during busy preparation weeks.

Treating Contentful like a generic backend company. Their core product is a content API. Answers that ignore content modelling, publishing workflows, or the editor experience miss what the team actually cares about. Tie your examples to this domain wherever you can.

Thin trade-off reasoning in design questions. Saying 'I would use Redis for caching' without discussing TTL strategy, invalidation timing, or consistency trade-offs signals shallow thinking. Contentful's systems are complex and interviewers want to explore that complexity with you.

Underestimating TypeScript depth. If TypeScript is on your resume, be ready to go beyond 'I use interfaces.' Interviewers may probe generics, type narrowing, or how you handle third-party type definitions in a shared codebase.

STAR answers that say 'we' throughout. Interviewers want to understand your specific contribution. Replace 'we built the API' with 'I designed the schema and then paired with the backend engineer on the resolver layer.'

Arriving with no questions. Candidates report that Contentful's interview process is conversational. Coming with no questions for the interviewer reads as low interest. Prepare at least two genuine questions per round based on what you have read about their engineering challenges.

Ignoring the editor side of the product. Engineers who only discuss APIs and ignore the web app used by content editors are missing half of what Contentful builds. Show that you have thought about building tools for non-technical end users.