In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers. We asked participants questions about how they saw their careers and next opportunities, as well as specifically asking about their reactions to our job postings. It’s easy to find advice on this topic, but the volume is overwhelming and the information is often conflicting. We wanted to cut through the vast quantity of Think Pieces On The Internet to make some changes based on actual data. Our goal, unsurprisingly, is to identify ways to increase gender representation on Automattic’s engineering teams.
This was a fascinating process, and we are truly grateful to the 71 people who responded to our request for feedback. Given that we had this level of interest within just five days speaks to the relevance of the topic, as attracting contributors to a research project can often be far more of a challenge. While much of what we learned (discussed below) lines up with research you can find online, listening to people share their individual stories was profoundly impactful on our interviewers. It also revealed further insights that we are eager to apply. Automattic’s hiring team has been able to make some immediate changes, but have much more to think about, and expect this to influence our ongoing efforts.
I have done a lot of technical interviews. And mainly I think that interviewers have to change, but I do have some suggestions for interviewees. Ages ago I wrote up my prep list for interviewing at The Conglomerate, which is comprehensive, and frankly excessive. This is the short version with the benefit of spending more time on the other side of it. It’s targeted somewhat more at algorithms and data-structures interviews which are the ones that I think people are most afraid of.
1. Be Calm
I can’t tell you what to do here – you need a degree of self-awareness to figure out what will make you stressed and what will make you feel in control. For me, I need to know what to expect and feel like I have prepared enough to do it.
As an interviewer, I’m always working to make someone feel calm and in control. But you can’t necessarily tell if someone is freaking out (especially if that freaking out ends up coming across as arrogance). And this is a lot of work, that sometimes results in the interview going over time, or me concluding some fraction of it was not a good signal. It’s much easier for everyone if you don’t freak out in the first place. So determine what you need: information? Time? And ask for it. Most places want you to be successful and will be happy to give it to you.
2. Choose Your Language Carefully
Worry less about what will “impress” your interviewer and more about what you feel comfortable in. Then modulo that with the kindness of the language. E.g. if you love C, but are pretty happy in Python, I would suggest choosing Python, because there is a bunch of useful stuff in Python, and you just need to write fewer lines of code to achieve the same thing.
If you are interviewing for a platform specific job, at some point in the process you should expect to demonstrate you can be effective on that platform. And obviously many interviewers are bad, and some are setting secret tests (such as programming language) by which they judge people. However, when I say “code in whatever language you like”, I mean it.
One note on languages that have a lot of magic in them – like Ruby – you can easily end up writing code that you can’t reason about the efficiency of because it’s doing a bunch of things for you and you don’t know what. Anything you write with magic, you should be able to write without magic, and so understand the magic enough to know how you might do that – and when you might want to.
3. Know Your Foundation Blocks
The algorithms and data-structures covered in interviews is essentially second year Computer Science curriculum. Data-structures at least, are building blocks for everything we use – it’s worth understanding what their properties are and when to use them. I think array / list / hashtable / binary tree are probably sufficient.
Algorithms are like… the history of how we learned to solve problems and manipulate data efficiently. As computers become more powerful, it might seem less pressing but it’s still relevant, and still worth knowing. I don’t think you need to be able to re-implement them on demand, but knowing which is which and understanding trade-offs is good. Aside from sorting, binary search, and the basics of runtime analysis (basically: how long will it take proportional to the input?) are useful.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
