Over the last 5 years I've interviewed more than 100 candidates for Drupal/PHP developer positions in everything from 15 minute phone screens to 4 hour on-site interviews that include technical exercises. In 10 minutes I can gauge a candidate's skills and experience as a Drupal developer and if s/he is a good fit for a position. In this post I discuss my philosophy and methodology around hiring a *good* Drupal developer.
First things first, you need to have a job description and a solid (yet fluid) understanding of the role that needs to be filled. Is the ideal candidate a front-end developer (HTML, CSS, JS, jQuery, etc), a back-end developer (OO PHP, API integration, Bash scripting, etc), or a site builder/webmaster/Drupal Subject Matter Expert (SME)? This usually depends on business requirements but always influences the direction of the interview. The point is you need to know the types of projects the developer will work on and the strenghts and interests of the ideal candidate.
Before the interview I check a couple things: their Drupal.org profile, their github profile, and a basic search for their name on Google. What projects have they contributed to? Do they maintain a project? Do they know someone who I know? Can I find examples of their code?
My interviews always start off with a brief one-minute description of my role, the organization I represent, and ends with a simple question: "tell me about what you do and your role in some of the projects you've worked on?". I let the candidate talk for a couple minutes and try to determine the answer to the next question I ask, "do you consider yourself a front-end developer or a back-end developer?". Frequently I cut the person off to ask this question, not because I'm being rude but because I'm still trying to figure out: Are you a good fit? If a candidate talks about creating project plans and what I need is someone who can create a custom theme, then already I know this person may not be a good fit. I may have missed something, though, so I have a follow-up question, "What is the ideal role you would like to play on your next project?". I limit this first part of the interview to 5 minutes and cut it off from there. My goal is to learn about his/her interests and if they fit with the position for which I'm hiring.
Note: If, in the first 5 minutes a candidate blathers on and on about their technical prowess and what s/he did on XYZ project, then s/he is probably not a good fit.
Next, I move into a series of technical questions. Here are my questions, mostly in order:
- When building a site, tell me about the typical modules you use?
- How would you describe the views module?
- What is an argument in views? What is a relationship? How do these map to MySQL queries? How would you pass an argument to a block view?
- Blocks are passé, how else would you implement a block?
- Have you worked with features? What do they do? How do you use features to manage the dev->stage->prod process?
- What do you use for version control? Why?
- Tell me about some hooks that you regularly use?
- Are you a context, panels or display suite type of person? Why?
- Tell me how the form API works?
- What are entities? What's an EFQ?
- What are some of the major changes happening between Drupal 7 and Drupal 8?
The goal of the entire pre-screen interview is to understand the candidates technical knowledge and if s/he can explain it to me. I want to know details, see projects, and view code; how did you pass that argument into a view? Why did you use that module? What PHP functions did you use to manipulate an array? Can you walk me through the code for a module you wrote? For this reason, I don't expect people from marketing or sales to sit in on an interview at this point; their perspective doesn't matter. They may like the candidate but this doesn't impact the candidate's ability to perform the job.
In a first interview, I want to know first and foremost: Can the candidate hit the ground running?