WordPress powers over 40% of all websites, so WordPress developer interviews are common for agencies, startups and freelancers. These WordPress interview questions cover the dashboard, themes and plugins for beginners, then hooks, custom post types, performance, security and custom development for experienced developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
WordPress is a free, open-source content management system written in PHP that uses a MySQL or MariaDB database.
WordPress.org is the self-hosted software: you download it, install it on your own hosting and have full control over themes, plugins and code.
WordPress.com is a hosted service run by Automattic that handles hosting for you but restricts plugins and custom code on lower plans.
Posts are time-based content, such as blog articles or news, shown in reverse date order, with categories, tags, authors and RSS feeds.
Pages are static content such as Home, About or Contact, which can be arranged in a parent-child hierarchy and use page templates.
Both are stored in the wp_posts table with a different post_type.
A theme controls the design and templates; a plugin adds functionality.
I choose ones that are actively maintained, compatible with the current WordPress version, well reviewed and from reputable developers, and I avoid installing many plugins that do similar jobs.
Every plugin adds code that can slow the site or introduce security holes, so fewer, high-quality plugins are better.
Most hosts offer one-click installs.
Manually, you create a MySQL or MariaDB database and user, upload the WordPress files, and run the installer in the browser, which writes wp-config.php with the database details and creates the admin account.
Afterwards I set the site title, permalinks and time zone, remove default content and install only the plugins needed.
Administrator (full control), Editor (publishes and manages everyone's posts and pages), Author (publishes their own posts), Contributor (writes posts but cannot publish), and Subscriber (manages their profile only).
Multisite adds Super Admin.
Each role is a set of capabilities, and plugins such as WooCommerce add roles like Shop Manager.
Users should get the lowest role they need.
Permalinks are the permanent URLs of posts and pages.
The setting in Settings > Permalinks controls their structure, and "Post name" (/sample-post/) is the most readable and SEO-friendly.
Changing the structure on an established site breaks old links unless redirects are added, so it should be decided before launch.
Menus are built in Appearance > Menus, or the Site Editor's Navigation block in block themes, and assigned to locations defined by the theme, such as the header or footer. Widgets are content blocks in sidebars and footers, such as recent posts or a search box; in block themes they are replaced by blocks placed in template parts.
Uploaded files go into wp-content/uploads, organised by year and month.
For each image WordPress generates several sizes (thumbnail, medium, large and theme-defined sizes) and outputs responsive srcset markup and lazy loading.
Images should be resized and compressed before upload or with an optimisation plugin, served as WebP or AVIF, and given alt text.
Categories are hierarchical (they can have sub-categories) and broadly group posts by topic, and every post must have at least one.
Tags are flat and describe specific details of a post.
Both are built-in taxonomies and create archive pages.
Too many thin tag pages can hurt SEO, so tags should be used consistently or set to noindex.
Take a full backup of files and the database, test updates on a staging copy first, especially major WordPress versions and important plugins, then update core, plugins and themes, and check key pages, forms and checkout afterwards.
Minor security releases update automatically by default.
Keeping a changelog and the ability to roll back makes updates low-risk.
wp-config.php holds the site's core configuration: database name, user, password and host, the table prefix, authentication keys and salts, and constants such as WP_DEBUG, WP_DEBUG_LOG, WP_MEMORY_LIMIT, DISALLOW_FILE_EDIT (disables the theme and plugin editor) and WP_ENVIRONMENT_TYPE. It should be protected from public access and never committed with real credentials.
Applied problems, trade-offs and questions about your own projects.
Hooks let you change WordPress behaviour without editing core files.
An action runs your function at a specific point, for example add_action('wp_enqueue_scripts', 'my_scripts') to load CSS and JavaScript, or on save_post.
A filter receives a value, lets you modify it and must return it, for example add_filter('the_content', 'add_disclaimer').
Actions do something; filters change something.
It is the order in which WordPress looks for a template file to display a request.
For a single post it tries single-{post-type}-{slug}.php, then single-{post-type}.php, single.php, singular.php and finally index.php.
Pages, categories, archives and search have similar chains.
Knowing it lets you create the most specific template you need instead of adding conditions to one big file.
Block themes use HTML templates with the same hierarchy.
Custom post types let you store content other than posts and pages, such as Products, Properties or Courses, registered with register_post_type and given their own admin menu and templates.
Custom fields (post meta) store extra data about each item, such as price or location, using the Advanced Custom Fields plugin or register_post_meta.
Custom taxonomies like Property Type group them.
Gutenberg is the block-based editor introduced in WordPress 5.0, where every paragraph, image or layout element is a block.
To create a custom block I scaffold it with @wordpress/create-block, describe it in block.json, write the editor interface in React with the edit function, and define the saved output with save, or use render_callback in PHP for dynamic blocks.
Block themes extend the same idea to whole-site editing.
The Loop is the code in theme templates that goes through the posts for the current page and displays each one with template tags such as the_title() and the_content(). WP_Query creates custom queries, for example the latest three posts from a category or products with a certain meta value, with arguments for post type, taxonomy, meta queries, ordering and pagination. wp_reset_postdata() restores the main query afterwards.
Use wp_enqueue_style and wp_enqueue_script inside a function hooked to wp_enqueue_scripts (or admin_enqueue_scripts), with dependencies, a version number for cache busting, and strategy => "defer" or loading in the footer for scripts.
Never hard-code script tags in templates.
Assets should be loaded only on pages that need them, and wp_add_inline_script or wp_localize_script passes data to JavaScript.
Shortcodes are tags in square brackets, such as [contact_form id="3"], that plugins and themes replace with dynamic content.
They are registered with add_shortcode and a callback that returns (not echoes) the output, with attributes handled through shortcode_atts.
In the block editor, custom blocks are the modern replacement, but shortcodes remain common in older sites and plugins.
The Options API (get_option, update_option) stores site-wide settings in the wp_options table.
Transients (set_transient, get_transient) store cached data with an expiry time, such as the result of a slow external API call, and use a persistent object cache such as Redis when available.
Options with autoload set to yes load on every request, so large ones slow the site.
WP-Cron schedules tasks such as publishing scheduled posts and sending emails, registered with wp_schedule_event.
It is not a real cron: it runs when someone visits the site, so on low-traffic sites tasks run late and on busy sites it adds overhead.
For reliability, disable it with DISABLE_WP_CRON and trigger wp-cron.php from a real server cron job every few minutes.
wp_posts stores posts, pages, attachments, menu items and custom post types; wp_postmeta stores custom fields; wp_users and wp_usermeta store users; wp_options stores settings; wp_terms, wp_term_taxonomy and wp_term_relationships store categories, tags and custom taxonomies; and wp_comments and wp_commentmeta store comments. Plugins add their own tables.
Block themes use HTML templates made of blocks and are edited visually in the Site Editor (full site editing), including headers, footers and templates. theme.json centrally defines global settings and styles: colour palettes, typography, spacing, layout widths and which design options users can change. Classic themes use PHP templates and the Customizer.
System design, deep internals, leadership and tough follow-ups.
I use good hosting with PHP 8+, page caching (a plugin or server-level cache like Nginx FastCGI or Varnish) and a persistent object cache such as Redis.
Static assets go on a CDN, images are compressed and lazy-loaded, and unused plugins and scripts are removed.
I find slow database queries with Query Monitor, add indexes or cache results with transients, and clean bloated wp_options autoload data and post revisions.
I validate and sanitise all input (sanitize_text_field, absint), escape all output for its context (esc_html, esc_attr, esc_url, wp_kses), use nonces to protect forms and AJAX requests from CSRF, and check permissions with current_user_can before any action.
Database queries use $wpdb->prepare to prevent SQL injection.
I never trust data from users, URLs or the database without these checks.
WordPress exposes content as JSON at /wp-json/wp/v2/, for example /wp-json/wp/v2/posts, which mobile apps and headless frontends such as Next.js can read.
I add custom endpoints with register_rest_route, always with a permission_callback, and expose custom fields with register_rest_field or show_in_rest.
Writes need authentication, such as application passwords, cookies with a nonce, or JWT.
Multisite runs many sites from one WordPress installation, sharing the same core files, plugins and themes, with sites on subdomains or subdirectories, managed by a Super Admin.
It suits universities, franchises and agencies managing many similar sites.
Drawbacks are that one problem can affect every site, some plugins are incompatible, and moving a single site out is harder.
WP-CLI is the command-line tool for WordPress.
It installs and updates core, plugins and themes, creates users, exports and imports databases, runs search-replace on URLs during migrations (handling serialised data correctly), regenerates thumbnails, flushes caches and runs cron events.
It makes maintenance scriptable and is essential for managing many sites.
Headless WordPress uses WordPress only as a content management backend, with editors working in the familiar admin, while a separate frontend built with Next.js, Astro or similar fetches content through the REST API or WPGraphQL. It gives fast, secure, modern frontends, but loses theme features and some plugins, and preview and SEO need extra work.
Keep themes and custom plugins in Git and deploy them through a pipeline, while content lives in the database and uploads.
For migrations, copy files and the database, then update URLs with WP-CLI search-replace or a migration plugin that handles serialised data, and test on staging.
Avoid overwriting a live database that has new orders or comments; sync content carefully.
Use a unique prefix or PHP namespaces and Composer autoloading, organise code into classes, register activation, deactivation and uninstall hooks to create and clean up data, follow coding standards, sanitise input, escape output, check capabilities and nonces, make text translatable with __() and a text domain, load assets only where needed, and keep settings in the Options API or custom tables for large data.
See all WordPress & Shopify Developer interview questions, covering WordPress, WooCommerce, Shopify, Shopify Liquid, Wix and more.