The defining characteristic of software developers is how little we know, and how useless the information we do have is. The skills we can be most confident of are often obsolete. Once upon a time, the fact that I knew how to use jQuery and Firebug put me at the cutting edge. Most of what I know is about as useful as jQuery, and the problem that I need to solve today will most likely involve me copying and pasting code from stack overflow, trying to make sense of it as I go.
We don’t really care if you’ve been able to memorize API details in the past, or if you have mastered the art of sounding smart in an interview. Instead, we’d like to really focus on the two skills that we think are fundamental: coding and communication.
Most developer interviews begin with a technical screen. The goal here is to figure out if you are likely to be able to pass a technical interview, and answer any questions that you might have about the role. The next step will often be a technical interview, to explore the skills that will be most relevant to your role as a developer. For example, your job will often be:
- Understand business priorities enough to pull a story from “Ready to Start” into “In Progress.”
- Think through the story, and double check if it still makes sense. This will take anywhere from 5 minutes to 5 hours. If it turns out that I wrote a half-baked story that will actually end up being five stories, you may have to explain something that is completely freaking obvious to me several times. Communication!
- Create a branch in your local, get something working, write tests for it, convince yourself your branch is ready for someone else to review, and eventually create a pull request (possibly a draft PR). Code!
- Most PRs get a certain amount of review, and it’s not uncommon to iterate a couple of times. We’ll try hard to provide gracious and useful feedback, and to appreciate the fact that you’re willing to incorporate changes into code that you thought was already good enough. Code and communication!
- If all tests are passing and review and edits are complete, we’ll merge and deploy the PR, and you get to go back to step 1. Moar code and communication!
So what do the steps above mean in terms of coding and communication skills?
- You can set up a local environment with Node, your favorite editor, use Git, and contribute to the test and CI automation necessary to maintain reasonable velocity and quality.
- You can participate in design conversations and help to choose tools and libraries that will prevent us re-inventing the wheel. If there are several good options for a form library, you will help us do the hard work of evaluating different libraries and facilitate the team conversation that will be required to make sure that everyone understands that a technical design decision was made, and have some sense that there was an effort to understand the trade-offs involved and to make a “good enough” choice.
- You take the time not only to write code that fulfills the acceptance criteria of the story, but you also ensure that you’ve written code you or a colleague will be able to make sense of in six months when it needs to be refactored. You’ll write enough tests that if the components you build stop working we have a good chance of finding issues before they get to production. Generally speaking, this will mean writing Cypress integration tests that will demonstrate not only that your components work, but that they work in the context of the overall application. For complex stories, it will often be necessary to refactor your code a few times until the components fit together in a way that makes sense both to you and reviewers.
- Often as you work on a story you’ll find that there are a number of decisions that need to be made that were completely missed by the optimist who wrote the story: new fields that need to be added to APIs, UX complexities that turn a two day effort into a two week effort, etc. You’ll need to explain to the team that once again the devil is hiding in the details, and ideally you’ll be able to help drive conversations about possible approaches. Sometimes, the best way to drive this conversation is to present a working prototype, and then go off and refactor it a few times until we come up with something that doesn’t feel like we’re tormenting our users.
- When you have to learn how to use a new component, you’ll need to figure out the right balance of reading the source code, discussing it with a colleague, and asking stack overflow to give you code that you can copy and paste and will magically work.
Obviously, all of the above is a great deal more than we can hope to accomplish in technical interview that we’d like to keep under an hour. We share it because it is the context for the technical interview, where you will dial into a Zoom (even if we’re all in the same room), share your desktop, open an editor to the agreed-upon starting point, and start working on the problem that we assign you. We can provide a computer if you don’t have one, but technical interviews are hard so having a laptop or web IDE setup in a way that is comfortable for you is necessary.
In some cases, the starting point will be a code sample you’ve shared with us ahead of time. For example, suppose you’ve done nothing but Angular for the last two years, and the code sample you shared with us was an Angular todo app that you’d hacked on a bit because the code you’ve been working on isn’t something that you can share (and although it probably doesn’t need to be said, we really, really, really never want you to share any non-public code with us!). So even though we all pretty much suck at Angular cause it’s been a long time, if ever, the important thing is that you’re working with code that you’re familiar with and can explain to us, so that we can get a sense of how you think about code that you’re familiar with, what it feels like to pair with you, and how you think through a problem, and how you use Google and your colleagues when you’re stumped.
Ideally, we’ll start with a softball problem and you’ll get some working code added to the starting sample quickly. Then we’ll ask you something harder, and you’ll start solving it, and talk out loud about how to solve it. With luck, you’ll start on an approach that makes sense, we’ll think of a different approach, and you’ll switch gears and do that. Switching gears and coding in an interview is super hard, so we’re much more interested in the quality of the process than in achieving specific results. At the end of an hour or so our hope is to have had a good conversation while watching you type some working code. Sometimes the softball turns out to be hard, and that’s okay too. As long as you’re writing code and talking to us about how you think about the problem, we’re going to learn something, and we hope you do too.
What if all you’ve been doing recently is Java or PHP and the whole reason you’re excited to interview with us is that you want to start playing with React and building sick web apps? (and Redux, and Lambda, and GraphQL, and all the other goodness!) We have real reservations about submitting a code sample that uses languages and technologies you’re unfamiliar with. Technical interviews are hard, and if you do it with a stack you’re in the process of learning, it’s that much harder. That being said, a create-React-app that manages state with Redux and has Cypress tests isn’t a bad place to start, and if you can share your IDE and solve some problems in a language you’re still learning while having a conversation about what you like and don’t like about this new language, we’d be up for that too. Specifically, we’ll be interested in:
- Are you able to iterate with the stack you’re using? For example, can you add a test for a new feature, and then iterate on the code until the test is passing?
- Is your code idiomatic? Can you compose components that break down a complex operation into smaller functions that are easy to understand? Do you think fluently about the relationship between state and the resulting user experience?
We’re always looking to make our technical interviews better, and would be very grateful for any thoughts, feedback, or links you have on how to think about technical interviews for developers.