Skip to main content
If you’re observant, you’ll notice we gave this its own section in our hiring documentation. Asking us questions is a big deal. We are paying attention to the questions you ask us. We have a lot to say about questions. But first, two crucial things to know about questions and our hiring process:
  1. You can’t ask us too many questions.
  2. If you have to ask whether to ask a question, ask it. We’re not going to ding you for asking us an imperfect question.
That said, there are effective ways to ask us questions, and there are ineffective ways. If you’re struggling with our process, it might help to change the approach you’re taking. Here are several classes of questions that are unlikely to help you much, and how to write them more effectively:

​
“Yes/No” questions, and questions with only one possible answer.

Example: “Is a region a required field on a Machine create?”. You’ll usually get the answer you were looking for with a question like this. But you won’t get anything else. You haven’t left space for people on our team to contribute, or to tell you things you haven’t thought about. Here’s a better version of that question: “What happens if a user tries to create a Machine without specifying region?”

​
Questions that offload decision-making.

Example: “What do you think about creating a new Machine when a user pushes a button?” We want you to make decisions. We won’t ding you for asking questions like this, but our answers won’t be helpful. Look for words like “should”, or “too slow”, or “acceptable”, or “suitable” in your question. Sometimes they’re OK, and sometimes they’re a sign that you’re asking us to do your thinking for you. There isn’t a better version of this question, but there’s a better approach: ask questions that probe us about how things work here, so you can arm yourself with enough details to make these decisions yourself.

​
Questions that assume there’s a spec.

Example: “What do users want from the Machine create button?” We don’t have product managers. You won’t get a spec, because there isn’t one. Customers are unreliable narrators and can’t usually verbalize their needs. We hire team members who speak the same developer language as our customers, and rely on them to engage with those customers directly. That’s a thing we’re evaluating you on. Here’s a better version of that question: “How often does the Machine create function get called in a day?”