If you’re a small to medium-size business (SMB) that has or will have a Drupal website, you’re probably planning to hire a Drupal site admin who can also do a bit of development – a good combination of skills for an SMB to have on the team.   

Before interviewing your candidates, get familiar with some of the areas in Drupal where the unskilled typically come to grief. Everyone’s requirements are different, but take a look at these questions, the reasons behind them, and what would be good responses. These will give you a sense of how the candidate handles technical, procedural, and user issues.
 

1. How do you handle security updates? Explain your process step by step

   Why ask this:  A big part of the reason for asking this question is to determine whether the candidate believes in following process.  How seriously does he/she regard system security and reliability? Thanks to an active Drupal community of contributors, Drupal security patches turn around quickly and frequently. Therefore an efficient and reliable upgrade process is essential to the security of your website. Security patches are generally minor version upgrades and straightforward to apply. However a site admin does need to take precautions, especially if someone else built the site. There could be glitches in modules or undocumented custom changes that are incompatible with the update. 
   
   Good answer:  
   A. Preparation: so, so important! 
   • Read the release notes to find out what’s different, what’s being fixed, and what new features to test after updating. Identify the modules to be updated and document.
   • Review changelog.txt to identify any changes that may affect functionality such as new dependencies, custom patches, API changes, or anything that will require manual steps in the update. Document. 
   • Download the new files and read the README.txt or UPGRADE.txt for known issues. 
   • Read the issue queue to see whether other users have experienced problems when applying the update – saves a lot of pain if the answer is to wait for a fix.
   
   B. Back up. Back up. Back up: Even if there is a non-production development or staging site, make a full back up of Drupal files and database. Also back up the non-production site.
   
   C. Apply updates to a local non-production site. This is a trial update, with the opportunity to catch and fix errors in the update process, and document them along with any manual steps or custom configuration changes. This is the safest and most conservative procedure. If you don’t have a development or staging site, take it as a good sign if the candidate blanches and tells you that getting a non-production site is mandatory.
   D. Test the updated non-production site: Test against the release documentation to ensure that critical new features are working, then test the site overall. 
   E. Take the live (production) site offline: Put the site into maintenance mode to keep users off the system. 
   F. Back up. Back up. Back up: Just in case users have made changes to the live site since Step B, take another full backup of the live site.
   G. Apply updates to the production site: follow the documentation gathered in Step C and go through the steps, making any custom configuration changes required. Document anything new or different than when updating the non-production site.
   H. Test the updated production site: Test against the release documentation to ensure critical new features are working, then test the site overall. Test as much as possible because if the production server has a slightly different configuration than the non-production site, the updates could still create issues.
   I. Bring the production site back online.

    

2. If our Drupal site slows down, what steps would you take to improve performance?

   Why ask this: This question probes for problem-solving skills as well as technical experience. How does the candidate approach troubleshooting for problems that involve multiple issues? Although Drupal is designed for scalability and high traffic volumes, when performance lags it could be due to Drupal settings, server architecture, or bad code. A good site admin will examine the problem from multiple angles. This is also where some development knowledge really helps because some of the solutions may involve the site admin looking into code and/or working with a developer.
   
   A good answer will mention multiple approaches, such as:
   Look at system performance for the server environment: Why assume that it’s a Drupal problem? Your Drupal site is part of a server infrastructure that includes web server, database server, and network connections. There are monitoring tools that help identify performance bottlenecks at the resource level. It’s more productive to start with infrastructure and then drill down to specifics.  
   
   Check into caching: one of the first things to check is whether page caching is turned on. Sometimes a site will use modules that only work when caching is turned off. Depending on site usage (both traffic and what gets accessed a lot), different types of caching modules are available. For more complex or granular caching, there are tools such as: Memcache, APC, and Boost.  
   
   Identify problem modules: One big advantage of Drupal is that there are so many contributed modules that developers are generally able to find the functionality they need instead of developing from scratch. Unfortunately, some modules are poorly-written when it comes to performance.
   
   • Delete, not just disable, unused modules. Every installed module has a performance impact because some of its files will be processed on every page load even if it isn’t used. This goes for disabled as well as enabled modules. 
   • Fix, find a replacement, or disable the culprits (if possible). Just a few badly-designed modules amongst dozens of good ones can cause most of the issues on a poorly-performing page. 
   • Disable. There are some modules that work just fine, but the nature of their functionality makes them resource hogs. So unless they’re necessary, they should be disabled. Statistics, Overlay, and Database Logging are a few that come to mind. 
   
   Check number of queries and files per page load: Every time a page loads up on Drupal, a bunch of queries run. With each query, Drupal hits the database. Every page load calls up files to render the page. A high number of queries and files suck down CPU, RAM, and database server.  The cause is usually a badly-written module, too many modules, or a high number of theme/template files. Fix, replace, or disable (if possible). 
   
   Identify problem views: Views is the Drupal module for building queries and displaying the results. Searches, reports, dashboards all depend on views. Depending on how the view was coded, it could be a specific view that’s making users complain, not a system-wide performance issue. Many performance issues in Views come down to lazy or inexperienced coding which can be fixed: 
   
   • Large views and query results with multiple joins, groupings, sorts, and fields
   • Repeatedly using APIs that load complete objects instead of single item returns; 
   • Bloating table size, index size, and scanning time by requesting all fields (“*”) instead of defining only the specific fields needed; 
   • Doing Joins on different column types, therefore making indexes unavailable to the query; this could point to a deeper issue with the database schema
   
   Caching can also help performance. Modules such as Block cache and Views content cache are designed to address specific caching situations; some Drupal experts maintain that caching should be enabled for most views.
    

3. The back end of our site is out-of-the-box. How would you make life easier for content editors?

   Why ask this: You want a candidate who is sympathetic to non-technical users and familiar with ways of making their jobs easier and more efficient. Drupal is developer-friendly, not content editor or admin-friendly. Friendliness and convenience are available in a Drupal environment, but they need to be built in. Quite often web development requirements focus on customer-facing functionality and forget about the back-end features that content editors need every day to maintain the site. If this is the case, you want a site admin who can correct the situation.
   
   Good answers include:
   Modules for editing: Anything that makes editing and handling files friendlier. There are different options, but this set of modules is pretty popular:
   
   • WYSIWYG - this module is the pre-requisite for CKEditor and IMCE 
   • IMCE WYSIWYG Bridge - this makes IMCE work with CKEditor through the WYSIWYG module.
   • CKEditor – the most popular editor HTML text editor. Anyone who has used a word processor will find this easy to use. Some nice to haves to add on:
   • CKEditor Link – the best feature of this module is that it allows users to insert links to internal content in a way that updates automatically even if the path changes.
   • CodeMirror – formats, colors, indents HTML source code for easier reading and troubleshooting.
   • IMCE - file browser and uploader with s image and file-handling features.
   • IMCE Crop - image cropping tool that works with IMCE
   • WYSIWYG Media Embed - insert media file embed codes into WYSIWYG text areas
   • IMCE for FileField – select files via IMCE File Browser outside WYSIWYG environment (standalone). 
   • IMCE Mkdir - create and delete sub-directories under directories assigned by IMCE.
   • Better Formats –allows pre-setting the allowed input formats for various fields and content types – essentially making input formats context sensitive and far less confusing.
   
   Simpler themes: There’s a lot that can be done in Drupal, which means non-technical users get disoriented by all the options facing them when all they really need is access to a few simple admin tasks. Drupal 7 ships with a theme called Seven which is much simpler. There’s also a popular new theme called Rubik. There’s also the Administration theme module which allows defining a different theme for admin pages. This makes it possible to specify paths that should use the admin theme even when located in other sections of the site.
   
   Customize for easier navigation: Drop-down menus, toolbars, tabs, and quick access to top-level administration links all help make life easier for non-technical users. Once the site admin understands what content editors need to manage, Admin, Admin Menu, and Toolbar are modules that can be installed to make navigation simpler and more intuitive.
   
   Customize views: It’s easier (and safer) for users to see only the content and functions they’re authorized to manage. The Panels tool combines multiple Views into custom dashboards. 
   
   When you include there three questions during an interview, you will get a sense of the candidate’s technical competence. You’ll also get a sense of non-tangible qualities such as:
   
   • Appreciation for documented procedures
   • Approach to problem-solving 
   • Attitude toward non-technical users
   
   If you’re having trouble hiring a Drupal site administrator, Smartt can bridge the gap temporarily. From IT infrastructure audits that identify performance bottlenecks to web services that make sure you’re current with the latest security updates, our team of experts lets you spend more time doing your job and less time worrying about website maintenance.