I’ve only been a hiring manager for a year and a half, but I’ve been doing technical interviews for most of my career. One of the things I learned early on is that not everyone interviews well. SPOILER ALERT that isn’t the thing that annoys me. It’s perfectly fine if you’re nervous as a candidate, I expect it. It’s perfectly fine if you can’t remember something when you’re put on the spot, I expect this too. The whole point of an interview is to give us a chance to get to know you and see how you handle different scenarios and situations (and, let’s be honest, an interview is a pretty stressful situation)!
Here’s the problem. When you send in a code sample nearly all of my good will goes out the window. Why? A few things (and it’s not me being a jerk, I promise).
I am fairly meticulous in my code prompts of what I want to see and I expect you to read the requirements.
I recognize that some of your existing work may not be appropriate to send me.
I recognize you have a job, and you may not be able to spend a “significant” amount of time writing that code sample.
I expect that if you want the job, you’re going to put in “some” amount of effort to get the job.
For example, here are the three (that’s all, three) things I ask for a developer interviewing for my team at Acquia to provide in a code sample:
Properly manage dependencies
Demonstrate an understanding of
Object oriented PHP by extending or implementing a Drupal core or contrib class
Dependency injection
Coding standards and best practices
Enable without errors
The most simple instance of this could be a “Hello World” block plugin in a module. Overall that would be perhaps 150 lines of code spread across 4 files (a composer.json, the module’s .info file, a theme function in the .module file, and a Block Plugin Class).
A big part of my role in the hiring process is to talk about the code sample you’ve provided. In fact, I’ve conducted nearly every code review interview for Acquia’s Professional Services team (in North America) for the last year and a half! By no means have we hired everyone that I’ve interviewed. A lot of people don’t make it past this part of the interview process. (So, it’s pretty important to get it right if you want a job.) Let’s talk about what that means and how you can ace that part of the interview.
Code Quality
You know how everyone tells you to dress nice for an interview because showing up in jeans and a t-shirt make a bad first impression? I’m here to tell you that code quality makes an equally bad first impression. Have I hired people with “bad” code samples? You betcha, because they killed their interviews. Does a bad code sample immediately make me leery of a candidate and make me more likely to pass them over? Absolutely.
As an architect, I am heavily invested in the quality of the work my teams generate. It needs to work, it needs to be commented / documented, it needs to follow best practices. I will not, in good conscience, hand over a codebase to a customer who has paid hundreds of thousands or millions of dollars, that is poor quality.
I cannot tell you the number of times I get a code sample from someone that has really, really, clearly, really obviously never been looked at for code quality.
The very first thing I always always do is run PHP Code Sniffer on the code sample. PHPCS will tell me all kinds of fun things about spacing, line length, variable / function / class naming, unused variables and use statements, etc. My record for an interview was something like 1500 PHPCS warnings / errors in a ~150 lines of code. So, roughly 10 errors per line. Again, all of this requires 0% of my brain power to find because PHPCS does it all for me.
After running a sniffer, I open up the code (all the files) and just sort of scroll through what you provided to get a sense of whats there, how big it is, what it’s supposed to do, etc.
A few things that immediately jump out at me are:
unused use statements (because hey, they are at the top of the file and my IDE tells me this immediately upon opening)
improper array syntax (the word array is incredibly easy to spot)
unused variables (because again, my IDE tells me this as I scroll through the page)
bad spacing (because it’s super visible as I scroll through the page)
lack of comments (same).
The five bullets above require very little brain power to identify because they stick out like a sore thumb as I scroll through the code. My IDE tattles on you in each of those cases.
Now you might be wondering, “Well, Mike, don’t you turn on the code and make sure it works?" Yes, I do! Once I’ve skimmed and run my automated testing tools, this is where I start actually reading the code, comments, and reviewing what was done and how it was done. But! By that time, you’ve already made your first impression on me.
There are three grades here:
Pristine Code: this person has very obviously used both their brain (to manually review) and code sniffing tools (e.g. GrumPHP or PHPCS) to review their code
Clean Code: this person has obviously done “something” to follow standards, but missed a few silly things (like line spacing, etc.)
Terrible Code: this person has obviously done nothing to follow standards
I believe it’s important to talk to all candidates, so even if I walk away from a code sample feeling it is legitimately terrible, I still usually will take some time to talk to that person and get to know them. Why? Because I’m fifteen years into a career that started from a largely self-taught technical background. People gave me chances, early in my career. I did some really stupid stuff on early projects. I interviewed really poorly. Those people that took a chance on me made my career. So I take the responsibility to heart and still chat with people. I have been pleasantly surprised more than once!
So, let’s imagine that you’ve submitted a code sample and you make it to the interview. I’m going to spend at least 15-20 minutes talking to you about what you wrote, how you wrote it, why you wrote it, etc. If there are code quality issues you can 100% bet that I am going to challenge you on them. “Hey, so I noticed that you did _____________ in your code,” <insert example from my bulleted list above>. “Why didn’t you catch that?”
The most common responses I get?
“My current company doesn’t really care about that.”
“I just kind of look at the code and fix stuff that I see.”
“That’s not something I focus on.”
None of these amuse me. I get it! I’ve worked at places where I didn’t care nearly as much about these things as I do today. I’ve grown up a lot over the last four years. I care deeply about this today (it wasn’t a huge deal a few years ago). So why does this annoy me so much?
Returning to my code review prompt:
Demonstrate an understanding of
Coding standards and best practices
It’s right there. It’s in the prompt.
When I work with a developer in a remote organization, it is critical to me that the individual in question can read implementation details on a ticket and execute them without me looming over their shoulder and demanding things. Following instructions is so important.
We don’t explicitly say “which” coding standards and best practices to follow (although, PHP / Drupal should be inferred). It’s just important that you can articulate which standards you followed and why!
Why are Coding Standards so Important?
I get this question a lot. I ASK this question a lot during interviews.
When you have a big team—let’s say 15 developers—there’s a lot of code getting slung around on the project. It’s challenging to keep up with all the feature development, bug fixes, etc. at the best of times because 15 devs all doing full time work is legit a lot of code. Imagine if every one of those devs had slightly different coding standards. Worse, imagine if those devs all had slightly different editor configurations. Every time someone opened a file, all the line indents would change, slightly. The git diff would be impossible.
Code standards are there to make sure that everyone is doing things the same way, all the time. By aligning your approach you ensure that you are all working the same way, looking for the same things, etc. Honestly, I’ll let you Google this one for yourself and read up on it if you aren’t on board.
TLDR: coding standards are important and there should be at least one automated tool for each language you are using on a project to test the quality of the code being written in that tool. Period!
In Conclusion
I know how scary it is to put yourself out there for a new job. I know that if you’re in the Drupal community talking to someone with Acquia in their title can be really intimidating (I know, because I was super intimidated when I interviewed for my job). I know that you may not personally agree that coding standards are important. But at the end of the day, if a company takes the time to ask you for a code sample, please carefully review what they’re asking for. If they want you to follow standards and best practices you better do it! If you already have something on hand? Great! Feel free to send it. But maybe, just maybe, it’s worth ten minutes to re-read the code from a year ago to make sure it’s really your best work.
If you’re currently seeking a role in the Drupal world, check out Acquia’s open listing for a Technical Architect, Remote, in North America! I’d love to see your code (just make sure you check the quality first).