Since joining the hiring team at Automattic in the fall of 2019, I’ve noticed different patterns and preferences on text-based interviews. Some of these are also general interviewing tips.

Send shorter messages

The pacing of the conversation is improved when you send multiple shorter messages instead of one multi-paragraph message. Answer as you go along. This gives more opportunity for your interviewer to drop pertinent emoji reactions and give feedback/redirect along the way.

Shorter messages = more engagement and faster feedback.

If someone starts down the wrong path on a question and answers once every five minutes in a wall of text, then the interviewer isn’t given an opportunity to redirect early on. The interviewee may unintentionally be cutting their interview short since they spent so long answering the wrong question. Also, it’s not a very engaging conversation if you only see a message once every five minutes.

Tip: It’s OK to type fast and correct typos/edit for clarity as you go.

Avoid Threads if possible

This is something I prefer. I watch that “_ is typing,” alert like a hawk. This is your cue to know if you’ll be interrupting someone or not.

It’s really helpful to know if you should wait for them to finish sending a message or if you should jump in with another message. In Slack, this alert only shows up if you’re typing in the main channel. The threads don’t show it, so you’re not sure if someone is typing.

Of course, there are some small comments that are better in threads. That’s fine. Keep threaded messages short if you need to use them. If you need to go back and discuss something, instead of using a thread, you can use a block quote for context:

In async conversations where you don’t need to know if someone is typing (most everything except interviews), then I 100% prefer threads. It’s all about context.

Show your thought process

So much of our interview and hiring process is about how you approach a problem rather than the final answer. Do you need more context to make a good decision or provide a good answer? Ask for it! Don’t make an assumption about it.

In the end, a lucky right answer without showing your thought process isn’t worth as much as a solid thought process that arrives at a different answer.

Don’t bother name dropping

We don’t have a checklist of frameworks or languages we want you to mention. It’s about how you solve and approach problems. If you demonstrate a strong learning ability, then we’re not worried about if you’ve worked with x, y, or z, since we know you can learn whatever you need to in order to get the job done.

Tell the story

If we ask a question like, “Tell me about a time when…,” act like you’re telling someone a story about it, because you are! Give context:

• What was the project?
• Who worked on it? What was your role?
• Why did you solve the problem the way you solved it? Did you consider alternatives?
• How did you know you were successful? Specific metrics are 🔥

In the end, it should sound like a concise story. This allows the interviewer to understand the issue and context so much more than if you only focus on the “What.”

Also, be prepared to answer follow-up questions related to your story. For example, that specific metric you mentioned earlier — how did you measure that?

It’s not that different

A few little etiquettes are different, but, in the end, the same rules apply to in-person interviews as text-only interviews. Most people have never been interviewed over text, and most people do great with it. If you practice telling your stories and can demonstrate a pattern of success, you’ll be fine, text-based or in-person. 

Thanks to Thuy Copeland, Josh Betz, and Enej Bajgoric, my fellow interviewers at Automattic, for reviewing this post 🙌🏻