Skip to content
tezvyn:
Menu

Justify static site generator vs CMS for a portfolio site

Source: developer.okta.comMediumHow cards are made

Matching tool complexity to static publishing needs. Choose Hugo or Jekyll with Git and a CDN; removing runtime databases eliminates per-request latency and PHP exploit surfaces.

What's really being asked

This question tests whether you can match infrastructure choices to actual workload characteristics rather than defaulting to familiar tools. The interviewer wants to see that you understand the trade-offs between static site generators and traditional content management systems, specifically around performance, security, maintenance overhead, and developer workflow. A portfolio of technical writing samples is inherently static, read-mostly content with a single author, so the ideal answer demonstrates cost-aware thinking and operational discipline.

The full answer

First, name a specific static site generator such as Hugo or Jekyll and pair it with a Git-based workflow for version control. Second, describe deployment through a static host or CDN so that content is served from edge locations with no server-side processing, following the eighty-twenty rule by getting most of the benefit with minimal operational work. Third, justify the rejection of a traditional CMS by citing the absence of runtime PHP, database queries, and plugin patching, which together remove per-request latency and eliminate entire classes of exploits. Fourth, acknowledge the limited scenarios where a CMS makes sense, such as multi-author workflows with non-technical editors or complex dynamic features, but clearly state those do not apply here. Fifth, mention concrete performance outcomes like faster time-to-first-byte and better search ranking potential due to speed.

The mistakes people make

A major red flag is defaulting to WordPress or Drupal without acknowledging the maintenance tax. Another is claiming that static sites are only for developers and ignoring that modern Git-based workflows with markdown are accessible to most technical writers. Some candidates over-engineer by proposing containerized CMS instances or serverless databases for what is fundamentally a collection of HTML files. Others forget to mention security entirely or incorrectly assume that caching plugins make a dynamic CMS as fast as a static file served from a CDN.

What usually comes next

The interviewer may ask how you would handle search functionality without a database, so be ready to discuss client-side search libraries or hosted search services like Algolia. They might also ask how a non-technical stakeholder could update content, which is an opportunity to mention headless CMS options or Git-based content editors. Another follow-up could involve scaling costs, where you should note that static hosting on platforms like Netlify or Cloudflare Pages is often free for low traffic, whereas a CMS requires ongoing compute and database spend.

A concrete example

For a personal technical writing portfolio, I would use Hugo with the PaperMod theme, store markdown files in a GitHub repository, and deploy to Cloudflare Pages. New articles would be committed and pushed to main, triggering an automated build that generates HTML, CSS, and JavaScript. The resulting site would have no PHP runtime, no MySQL database, and no plugin ecosystem to patch, reducing the attack surface to zero while keeping time-to-first-byte under fifty milliseconds globally.

Interview question

When evaluating infrastructure for a single-author technical portfolio, why is a static site generator strongly preferred over a traditional CMS?

  • a.It provides built-in WYSIWYG editing and multi-author workflows for non-technical stakeholders
  • b.It removes runtime PHP and databases, eliminating per-request latency and exploit surfacesCorrect
  • c.It achieves equivalent performance through simpler caching plugins without giving up dynamic features
  • d.It requires containerized hosting and serverless databases to minimize operational overhead
Why?

A static portfolio is read-mostly content with no need for runtime processing, so removing PHP and databases directly cuts latency and attack surfaces. The caching-plugin argument is a common misconception because cached dynamic CMSs still carry maintenance and security overhead that static files avoid.

Just read this? Test yourself on what you have been reading.

Read the original → developer.okta.com

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles