Show structure: "Main file bootstraps with Composer autoload. Classes are namespaced and split by concern. Activation creates tables with dbDelta. I use register_deactivation_hook to clean up cron events and uninstall.php to remove all data."
Good plugin architecture: a main plugin file that bootstraps the plugin, PSR-4 autoloading via Composer, classes organised by responsibility (Admin, Public, API, Models), and clear separation between WordPress hook registration and business logic. Activation hooks (register_activation_hook) handle database table creation and default options. Deactivation hooks clean up scheduled events. Uninstall hooks or uninstall.php remove all plugin data. For database changes: use dbDelta() for table creation/updates with proper charset and collation. Strong candidates discuss: using the singleton pattern sparingly, dependency injection where practical, and the WordPress coding standards.
Senior plugin development question. Candidates who dump everything in functions.php or a single plugin file will produce unmaintainable code. Those who use namespaces, autoloading, and proper activation/deactivation lifecycle management build professional plugins.