I’ve talked in the past about some of the common pitfalls I’ve seen as a manager doing technical interviews, but in that post I was really focused on code quality in code samples. This article is about the actual conversation.
This article is about two different candidates that I interviewed for a similar position. This has been anonymized as my intention here is not to provide commentary on a specific candidate. Rather, I want to highlight a similar scenario and how two different individuals handled that scenario in vastly different ways. Spoiler alert! One got hired. One didn’t get past the technical interview.
The Scenario
I am regularly a hiring manager for Acquia’s Professional Services team. As a rule, we hire two types of technical folks: Drupal developers and Drupal architects. At the time of my writing, Drupal 9 is the most current version of Drupal (although, Drupal 7 and Drupal 8 are still actively / widely used in the community).
I expect technical resources to be able to learn on the job. It’s an important part of a consulting role! You’ll never, ever know 100% of the things you’ll run up against when working with customers. It’s just not possible. Having said that though… an important part of our screening process is to try and understand if our candidates have a baseline understanding of Drupal and some common Drupal conventions such as (but not limited to):
Drupal standards and norms
etc.
I’m not saying we won’t hire you if you aren’t an expert in dependency injection or configuration management. BUT I will say, especially as an architect, you had better understand a bit about these topics and be able to talk to them intelligently.
I want to specifically mention here that these topics are, as a general rule, not a thing for “older” versions of Drupal. In D7 there wasn’t a configuration management system, there was no dependency manager, and object oriented PHP wasn’t the convention. So you absolutely could be successful using D7 without any skills in these arenas. However, in D8 / D9 (as the Drupal community has driven more towards “enterprise” grade software) these more common software conventions have come onto the scene. Necessarily, that means that many of us in the community that are more “hobbyist” developers and not computer scientists have some work to do. If you’re new to my blog… my degrees are in English and UX Design. Yet, I’ve spent most of my 15 years in the industry as a developer and architect. Degrees don’t equal success in this field (but if you don’t have some of the foundational skills, you have a bit more work to do).
And this is where our candidates start to diverge.
The Candidates
Both candidates came to the role with a background in Drupal. They both had experience with Drupal 7 and had a long, technical career. At first glance, these are good things. It is a little bit of a red flag in 2020 that a candidate doesn’t have Drupal 8 or 9 experience, but it’s not perhaps a deal breaker (as we will see as the story unfolds).
My style for interviewing is to ask fairly open ended questions on very big, technical topics. Why? Well… mostly because I want to hear the candidate talk about the topic in a general sense. I don’t really care if someone has memorized a bunch of hyper-specific use cases or situations. I want to know if someone (especially a candidate for the role of architect) can explain dependency management to me, why it’s important, how to integrate it into my workflow, etc. Why? Because many of our customers need this type of explanation. This is why I say I don’t necessarily need you to be an “expert” with composer to get a job. But I do need you to be able to talk about it intelligently.
Both candidates were asked a question about the Drupal configuration management system. The answers here really illustrate the difference between what I’m looking for (and what I’m not).
The first candidate didn’t have any idea what I was talking about. I asked what the preferred configuration management strategy was and the candidate just… didn’t have an answer. As an interviewer, I hate when a candidate hits this scenario. NOT “hate” in the sense that I’m mad at the candidate, but hate in the sense that I want every candidate to have the opportunity to shine and show their knowledge. So when I end up with a candidate who just whiffs, I try to give them the benefit of the double and give some hints / clues to move the discussion along. In this case, I prodded and talked about the D7 solution for this. That at least spurred the discussion forward… but the candidate still had no idea about configuration management and didn’t:
give any indication that they had researched the topic
didn’t ask leading questions about why I cared or what I was talking about
talk about how they had handled the situation in earlier versions of Drupal once I explained what I was talking about.
In essence, this candidate left a critical answer on the “test” blank.
The second candidate also didn’t have any hands on experience with what I was talking about. However there was a really critical difference. The second candidate immediately perked up when I asked about a configuration management strategy and said “oh, hey, I read about that. I don’t really understand it but I think it’s…” and then jumped into a quick summary of what configuration is and why it’s important. They were able to draw from experience (both with Drupal and other technologies) to explain why such a strategy is important and why it might be integrated into a development workflow. They asked me leading questions and was able to take my information to build on their answers.
At the end of the day, we did hire the second candidate (although, in a more junior role than originally planned based on lack of experience).
Understanding The Difference
I can’t stress enough that NEITHER of these candidates had the requisite experience for the position. But the way they approached the question gave me some really valuable insight into how each candidate approached their work. One candidate shut down and just “didn’t know.” The other candidate leaned into the fact that they didn’t know and demonstrated that they had done preparation prior to the interview and used prior experience to talk about how it might work.
I also want to be super clear that the second candidate was cautious to not just take a stab in the dark and guess about something that they didn’t understand. They talked about other situations, admitted what they knew and didn’t, and was super straight forward in their analysis. Exactly like I would want an architect to handle the situation with a customer when the consultant didn’t know the answer to a topic.
So, the candidate that “didn’t know” and whiffed? Got shut down in the interview process and didn’t move forward. The candidate the “didn’t know” and still had a great conversation moved on in the process and ultimately got a job.
Interviews are full of questions that are nearly impossible to answer because the interviewing team / interviewer wants to hear how the candidate approaches the problem. No, I don’t ask my candidates to talk about how to weigh a 747. No, I don’t care about reordering an array on a white board in a certain number of steps. I want to know if I can give you a broad topic that is hyper-relevant to our area of focus (Drupal) and have you talk about it in a way that demonstrates your ability to work with the technology and deliver software. And I think you’ll find that a lot of interviewers are similar. It’s about your ability to get the work done, fit into a team, and align with the culture of the company. And if you don’t know an answer… don’t just shut down or bullshit your way through. Prepare for the interview
I interview a fair number of folks for technical roles. This is a story about two candidates going for the same position. One got hired (and one didn’t). Let’s look at what they did differently when both had a lack of knowledge on a really important topic.