Note that this was written about interviewing for development positions. I have a slightly different take when interviewing for “devops” positions that I write about in the breathlessly anticipated follow-up to this article.
I’ve been interviewing again for a little while. Since my job is finding a job, I’ve been studying at least several hours a day, learning new things and brushing up on the old.
I really enjoy it. Whether it be algorithms, programming languages, Linux systems administration, networking, infrastructure, etc., they’re all subjects that appeal to me and in which I have an interest to get better. The only area that has been a constant for me over the years is my disinterest in Microsoft products.
Usually, I get petrified at even the mere thought of interviewing. This has been going on for years, ever since I first froze in an interview at Netflix headquarters in Los Gatos, CA (I didn’t get the job, but I did get a case of the yips). I think I’m a strong coder, but I can panic in coding interviews better than anyone. However, I also perversely look forward to them, because I do enjoy things that are difficult.
I expected that I would eventually overcome my fears and insecurities around interviewing, but like many of my expectations, I was wrong. However, there are worse things in life, like cleaning up dog poo from five dogs in a big yard after a New England winter.
As I’ve been navigating the choppy waters of interviewing, I can neatly divide the mindsets of those who’ve been interviewing me into two camps:
- Tool knowledge is everything.
- Tool knowledge isn’t as important as knowing the underlying technologies.
In almost every case, those that fell into the second category were either a startup or small company.
Predictably, the larger companies would reject me for not having experience with a particular tool. A tool! I normally don’t apply to large companies, but sometimes startups fall prey to this peculiar mindset, so I would appreciate when they would out themselves1 by confessing that not having experience with Terraform was a dealbreaker. I got to the point where I would say it up front to spare everyone involved every possible embarrassment.
Conversely, when dealing with a company that I think might be a good fit for me, they’re usually saying that not having experience with Terraform (even though they use it) isn’t an issue before I’m even finished saying it. With that out of the way, we then get onto things that are important, such as evaluating my experience and knowledge over the course of my career.
A Digression
When I was doing mostly frontend development, it seemed that companies would look for React developers or Angular developers rather than JavaScript developers2.
Unfortunately, most of these candidates couldn’t explain closures or know the difference between prototypal inheritance and classical inheritance and how to code examples of the two. It only got worse with the arrival and increasing reliance on libraries like jQuery and later Angular and React and [insert superfluous JavaScript tool here]. For instance, many solutions to common JavaScript problems on StackOverflow were solved (and upvoted) using jQuery, not JavaScript.
Also, why hire for an abstraction? None of those libraries are so difficult to learn that one can’t come up to speed very quickly.
So, what would happen? In my experience, it would amount to massive amounts of difficult to read and understand code with many indirections and redirections that sometimes would lead to a complete rewrite. You get what you pay for!
If it were up to me, I hire the candidate that understands the fundamentals of the JavaScript language and its strengths and weaknesses every time, even if they had never heard of any of the particular tools du jour.
Anyway, what the hell was I talking about. It probably doesn’t matter. Companies hire for what they think they need, and in so doing they reveal who they are and what they think is important. I can then avoid them if I want. And most times, I want to run like hell. They’re really doing me a favor.
Weeeeeeeeeeee
What do I think is important to know? I tend to favor open-ended questions like the following (some are oldies but goodies):
-
What happens when you enter an address or search query in the address bar of a browser and hit Enter?
-
A company wants to move from on-premise to the cloud. What questions do you ask and what recommendations do you offer?
-
Here’s an example Python script (or whatever language they’ve marked as strong on a CV) and a Bash script. What would you do to refactor or otherwise improve them?
-
You just installed a base Linux distribution. Tell me what you do to make it more secure.
In addition, coding questions are good. I believe this is a particularly difficult way to determine the effectiveness of a candidate, though, so I usually gauge the individual’s experience level from their CV and the initial discussion and then ask a question that is challenging but not humiliating.
Knowledge of commonly-used algorithms and Big O notation is important, and I like to ask questions that can help suss out their level of familiarity of data structures and particular tradeoffs when it comes to solving a problem. How do they approach the problem? What level of detail do they communicate? This is sometimes more important to me than if they actually solve the problem.
Most companies don’t care about what particular language is chosen for a coding challenge (even one that isn’t used at the company), so why do they then care about knowledge in a particular tool versus lack of knowledge in another?
I’ve had plenty of interviews where the inteviewer(s) are complete assholes (like the aforementioned Netflix interview), and so I place a high priority on make the candidate feel as comfortable as possible. If the interviewer is obnoxious, then that is great information to have, no matter how well you do. After all, you’re there to evaluate if you want to work there, bearing in mind that you’ll sometimes spend more time with these ninjas than with your significant other.
Conclusion
The end. What more do you want from me?
References
-
This is similar to when I’m informed that a company doesn’t hire remote workers. But the context is important. For example, if it’s the same tired reasons that I used to hear years ago (and sometimes still do), I wonder if they realize that what they’re telling me has everything to do with themselves and nothing to do with me. It’s particularly egregious when it comes from a fellow programmer and not a manager. In essence, “I’m a child who is so easily distracted that I cannot be trusted to do what I say, and further I cannot comprehend that anyone is different from me.” That’s right, I said it.
-
Perhaps this is the fault of hiring managers and recruiters.