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?

Comments

I only ask guys: How much time do you take to finish a site ? And post me a few examples (If okay, send me the backend password). In exploring their works, I know their real front-end / back-end skins.

If any candidate gave me a backend password for a client site that they had done I'd dismiss their application straight away!

I like to see actual code they've written, then I can see stuff like how they write comments, how they handle exceptions, what the coder module has to say about their work, etc.

Asking about time it took to build a site/module is a great question too.

" How much time do you take to finish a site ?"

if i get asked that during an interview, that's usually a sign that the interviewer doesn't have a clue about Drupal.

In response I would advise the interviewer to use Dreamweaver, and I politely make my excuses and leave.

What kind of technical exercises do you do? Are they exercises you have setup yourself or do you use any online resources?

Great set of questions though, particularly like the panels / display suite one.

As for the previous comment, I'm intrigued as to what kind of answers you get from "How much time do you take to finish a site?", and more importantly, what information you are looking for in their answer?!

I do a couple things for technical exercises. First I have the candidate show me their dev environment; what's their IDE, show me how to use Drush, run a couple git commands, show me a local site you have setup, etc. For actual work, I have a document I've written with three exercises from which they can choose: a site building exercise (create a content type/view/fields, etc), a theming exercise (create a theme/SASS/responsive/etc), and a back-end developer exercise (create a module that does XYZ).

Bullshit and egoistic approach, thats why small company like yours takes 100s of interview in 5 years but only have 10 employees. Good companies takes 100s interviews in 5 years and have 50 developers.

Its not all about interview and skills how interviewee present themselves at first, its more about finding the in-depth gem inside developer and let them develop it for better development of company. Which Big-Time-Charlie like you would never understand.

Hello AC, nice troll. ;)

Frequently a project needs a short-term staff augmentation so it can be delivered on-time and on-budget. In this case you need developers who can hit the ground running, sprint for a couple weeks/months, and then they move on to the next project/client. These developers are well-paid, as they should be, as they are experts at the technology for which they are hired. If you need a Drupal developer who can hit the ground running and meet deadlines, then you have no time to train and mentor and wait for the developer's inner flower to bloom.

On the other hand, and what I think you're getting at, is there's a difference between hiring for a short-term staff aug position vs. a full-time permanent employee. Placing a permanent employee is more about personality and group dynamics and life experience then it is about technical chops and how quickly s/he can develop a website or write a module.

Disclaimer: I help my clients interview and hire developers, I very rarely interview developers for my business.

So why don't you write it clearly in your blog saying the interview is for your CLIENT companies? and for SHORT term.

Your post is misleading and scary for developers getting into Drupal world.

BR
Anonymous Coward and Jerk + (add whatever you like to call)

Some years ago I could see myself writing this out of frustration of paying hell up front. Other recruiters (the kind the bug you on LinkedIn) seem to not appreciate the vastness of what they're asking in their job descriptions.

For years I wouldn't reply, apply, or move forward with actual positions because I never new what par was. So I thought the standard would be, "If you're not totally proficient in every technology in the description, don't bother." It's still kind of an issue personally because I'm still fighting some perfectionist standard in my head to want to cover everything IA to AJAX to Drupal backend code. So something like "Experience: Flash Development" drives me nuts (as an example of something I kinda get) and just drives me away from that job and back to obsessive study.

I understand the frustration because when you're new that seems to be the impression and it doesn't help that many recruiter job posting reinforce this.

When I was starting out trapped in one peasants dilemma after the other I know the feeling of being trapped by not even knowing what you don't know and not having the luxury of a linear path.

But it gets better ACJ+, I'm writing this comment from Argentina to skip Minnesota winter because I have a contract that allows me to work remotely. Too me this sort of freedom, opportunity, is amazing. Especially when those frustrations become options and Drupal to you becomes digital arts and crafts.

Not to say there isn't frustration with glue and popsicle sticks, but it's borne of the challenge instead of the abyss.

I think you totally miss the point that *all* companies look for a mix of talent, skills and experience. This post is absolutely not *only* for "CLIENT companies", as you put it - it's useful advice for any company needing to hire Drupal developers who will hit the ground running, and it's a fallacy to suggest that's only organisations looking for short-term contractors. That, I say, is nonsense. R.J. says:

"On the other hand, and what I think you're getting at, is there's a difference between hiring for a short-term staff aug position vs. a full-time permanent employee."

If that is what you're getting at, and your follow-up implies it is, I say you're wrong. Hiring senior Drupal people is hiring senior Drupal people, regardless of the purpose. This post is categorically not only for the former. While companies wanting to build something fast with limited resource will probably seek to source a team 100% made up of experienced people - that would only be sensible - EVERY Drupal team needs experienced people on board, and this post is about hiring them.

For example, the make-up of our team is a real mix of experienced people and those who are learning. You need both, but the mix needs to be right. If we set about, as a hiring policy, to only look for people who might (or might not) have an "in-depth gem inside", then I would fear for our ability to deliver projects!! No, that would be madness. Instead, we have a number of people we hired because they ARE Drupal experts, we - as a business - DO need to hit the ground running, and someone needs to polish the "in-depth gems" inside the others. On the other hand, we also take on graduates, people from entirely different industries, etc. For example, one of our junior - now senior - developers was a professional musician who had never written a line of code in his life before he joined us, and is now an experienced and valued Drupal developer. But the point is you CANNOT run a delivery business by only gem-polishing. You need a proper balance of experienced staff vs. people coming through.

So the idea that R.J.s post only belongs to the world of contract hiring is, frankly, plain wrong.

From both ends of the interview... I wish I'd been this discerning in the past when hiring developers, it would have proven very fruitful. This has come at a perfect time for me as an interviewee!

I noticed that you divided developers up into three groups, generally - backend, frontend, and Drupal SMEs (subject management experts). As someone who got their start as in SME/frontend roles, but who in recent years has dove deeply into backend development (being an SME made it much easier), I'm confused as to which I should concentrate on. Would you consider it a weakness or strength if someone was focused in all three areas? It makes applying for jobs kind of confusing - especially since they are written with the assumption that the applicant has a specific concentration.

I keep hearing nobody is an expert every aspect of Drupal - but most I get on LinkedIn want you to be everything. Fortunately I'm out of the whole peasant's dilemma phase of getting started, but that being... not an uncommon way to start, being everything for clients and getting enough experience to know what's what... it seems like the next logical thing. Be able to do everything.

Then I got a steady role as a developer for a publishing company where we would split up the work based on where we were more inclined. Things outside that realm, learning experience and breadth. In practice, as a Drupaler I found I was much more inclined as a themer because I enjoyed keeping pace with front end tech. It's just what shines to me.

So I guess in a way it seems like someone who is everything just won't become as exceptional at the thing they take to joyously. I think it's also a tell to the interviewer what level of maturity you have with Drupal. When I was relentlessly studying up on everything Drupal it lasted for years, but quality of life and the enjoyment of it all eventually resulted in burnout. From a hiring manager point of view it doesn't seem like a risk with taking. They won't get as much out of you and there's that wild card chance you totally fizzle out part way through.

Personally, I would recommend paying hell up front, but to get the lay of the blue land. Then I would recommend picking a number one based on what you could see yourself doing if you were simply retired and had to pass the time somehow. Let that number one marginalize the other if you want to maximize your potential one way or the other.

If I was a hiring manager I would go with people who know and pursue what they're good at. Isn't that what a team is for? Being savvy as to what all is entailed but being bringing to the table what you truly excel at?

Also look at it this way, we're upping the ante with a whole bunch of new tech with Drupal 8 like symfony and twig. Maybe there's a case "oh, if you focus maybe you'll become set in your ways" but I would argue "you can understand the changes because you actually appreciate the new tech and take to it."

Hey Richard, sorry for the delay in response. About your question - backend, frontend, and SME, I would recommend selling yourself as a Drupal "nuts and bolts" guy. That is, someone who knows Drupal in-and-out, can jump in on a project where necessary, and knows how to write both a custom theme or a custom module.

When I think of a backend developer, I think of @mattedlefsen, a developer with whom I've worked on multiple projects over the past couple years. On one project, he taught a vendor's dev team how to use objective C to use OAUTH to sign HTTP requests. The kicker is he had never written a line of objective C before the project. If you can jump into languages you don't know and do stuff like this, then by all means, go this route.

But to answer your question, being a "nuts and bolts" developer is a strength, not a weakness.

"Are you a context, panels or display suite type of person? Why?"

that's a seriously good question, and deep question , which goes right to the heart of the matter with regards to the different approaches and methodologies to building a Drupal site.

me , i'm a context person, and i wouldn't touch Panels with a bargepole. then again, you do get drupal devs who swear by Panels and wouldnt use anything else..

great question.. if the candidate is good you should get a very interesting answer.

Add new comment

The content of this field is kept private and will not be shown publicly.