We’re hiring for the Data team at Bevy. One of our core values is “communicate like a legend,” and it’s about communicating with respect, candor, clarity, courage, and empathy. We are building for the long term at Bevy, so it’s also about communicating to our future selves and future colleagues.
Of all the attributes we are looking for in Bevy data team members, I’ve been thinking a lot about communication lately. I’m trying to learn a lot about a candidate during relatively few interactions, and the nature of our communication during the hiring process is different from how we’d communicate if the person is hired to the team. An interview is different from a team meeting because the objective is different and there is more at stake. A take-home challenge is different from a team project because there is less discussion and there is more at stake. And there is a lot more talking than writing during the hiring process, with about 6 hours of live interviews. So how do you “get signal” on communication?
It starts with the resume
Call me shallow, but if I’m reviewing 100 resumes and I come across one that consists of two pages of lists of languages and frameworks, and each past job is a list of 35 bullets about how they “re-architected and implemented data services while meeting business deadlines and using software development lifecycle methodologies”, I’m going to skip that one. Being able to lift out your important contributions and explain them concisely to a technical audience (the hiring manager) is an important communication skill.
Communicating remotely, or remotely communicating?
During the first interview, in addition to (I hope) getting some positive signal on their technical attributes, I learn whether they can concisely and clearly explain why we are here: Did they do some research on Bevy? Can they articulate how they can contribute to Bevy and how we can contribute to their goals for growth and impact as a data professional? And, as importantly, do they actively listen and confirm their understanding of a question?
If they do well in the interview, we invite them to do a take-home challenge and we start to communicate more in writing. Bevy is a remote company and most of our communication is written, so this part is very revealing. My unscientific estimate of how much time an individual contributor spends writing software or writing and speaking English looks roughly like this:
To communicate well in a remote team, writing is not optional. Writing is the foundation for sharing knowledge, enabling others to be productive asynchronously, and documenting your work for the future. Writing happens in Confluence, GitHub, Jira, and Slack. Meetings are the smallest part. Each requires different skills, see for example tip #3, the “quick chat protocol” in Thomas Limoncelli’s excellent collection of pro tips for remote working.
During the take-home challenge, we exchange emails, ask and answer clarifying questions, and eventually review a PR with the candidate’s answer to the challenge. This is where we learn the most about their ability to communicate like a legend. Did they update the README? Do they explain their approach? Did they add some diagrams? Can they spell? Or, if not, can they install Grammarly? If writing is the foundation of how we collaborate in a remote company, then this part of the interview process is where we learn the most, even if it doesn’t perfectly simulate working in our team.
One of the things I appreciate in written communication is a sentence or two at the top that summarizes the page. This helps me and every other audience get the gist and decide whether/when I need to read the whole document (can I read it quickly between meetings or should I make a cup of tea and find a quiet 45 minutes so that I can really digest it?).
The same goes for Slack. Starting a conversation with “Hi!” and waiting for a response before revealing the riveting details of some non-urgent question you have is not great. I prefer a short “I have a question about usage reporting for a customer, not urgent”, which lets me decide whether I need to leave a meeting to deal with this or not.
The Slack Ack
And while I’m on Slack pet peeves, if I send someone a message like “working on that report, will have it to you as soon as the Airflow job finishes, ETA 2 hours” or “here is a candidate that came through for one of the data roles, but they might be a fit for your team.” then you might not have time to look at the resume for another day or two, but it’s nice to acknowledge it with a 👍 or a ✔️. It’s the equivalent of a simple “OK” and keeps the social contract alive. We don’t use Slack during the interview process, but you can get an idea of whether a candidate is a thoughtful summarizer versus a meandering narrator from their emails.
Keeping it in perspective
As much as we try to turn the interview loop into a hyper-rational process with question banks and rubrics, it is still a few humans making decisions about other humans based on sparse, noisy data. If I find myself excited or critical after an interview, I have to remind myself of that. It helps me to zoom out and reflect on the whole range of conversations and emails I’ve had with this candidate and with others, where the skills they are demonstrating fall into the communication donut, and whether the full circle of their communication has the potential to be legendary.