Managed by Q’s engineering interview process
Interview processes are in some ways like engineering problems. Both operate in imperfect environments where failures happen, and our job is to design a system that can withstand those failures. There are different variables that we can optimize, and there are tradeoffs for optimizing each.
It’s easy to get dogmatic about this stuff. (You must ask about pointers and recursion. Whiteboard interviews are evil.) We aren’t. We’ve optimized for what we think leads to success at Q.
What we’re looking for
Non-technical interviews
We’re excited about using technology to create good jobs. We do that by making it easy to run an office, by handling the logistical details that distract our customers from running their businesses. Our problems aren’t just virtual. They’re physical and tangible, and that excites us.
We hire engineers who
- Like what we’re doing
- Earn trust and operate with minimal management
- Get things done under ambiguous circumstances
- Exhibit humility, a love of learning, and empathy
Technical design interviews
In our phone-based and on-site interviews, we look for the ability to think like an engineer. The right candidates can have a fun, productive conversation on a deep technical topic. They can also reason about the tradeoffs that are inherent in any hard problems.
In general, we look more for the why more than the what. A candidate doesn’t need to know about every trendy database or every last MVC framework to do well. That said, there are some roles for which specific knowledge matters a lot.
Coding interviews
We use our coding interviews to assess both whether candidates can solve hard problems and whether they can express their ideas in code.
Though we do an online coding interview before candidates visit our office, we prefer to do our onsite interviews on whiteboards. In comparison with computer-based interviews, whiteboard interviews allow us to cover harder questions in less time, because they spare us from waiting through run/test/debug cycles.
Whiteboard interviews have flaws, as do all coding interviews. Here’s what we do to address them:
- Give information on how to prepare for our interviews (this post)
- Require multiple coding interviews. We tend to favor a candidate’s best performance when we evaluate them.
- Avoid questions that require tricks or intuitive leaps
- Forgive unimportant mistakes (e.g., minor syntax errors)
- Coach candidates when they make mistakes in interview tactics (e.g., rushing to code without understanding a problem)
Our interview lineup
Pre-screens
- A conversation with a recruiter
- A non-coding technical interview with an engineer.
- An online coding screen
On site (day 1)
- Product demo
- Technical design interview
- Two whiteboard coding interviews
On site (day 2)
- (For experienced candidates) Detailed career history
- Behavioral interviews
What candidates need to know
We expect candidates to be comfortable with the following technical concepts:
- Usage of basic data structures (trees, graphs, arrays, lists, hash tables/dictionaries)
- Recursion
- The time/space complexity of fundamental algorithms (linear and binary search, sorting)
- The basic structure of HTTP, including requests, responses, headers vs body, and the most common return codes. (We won’t ask people to recall what an HTTP 422 is on the spot.)
- Usage of HTTP-based APIs and JSON
- The Single Responsibility Principle
- (For candidates who work mostly on the backend) Databases (SQL or not — doesn’t matter)
- (For candidates who work mostly on the frontend) At least one pattern of UI application architecture. E.g., MV* or Flux.
A computer science degree is not a requirement for joining our engineering team. Some of the strongest engineers in our field do not have computer science degrees. But we find that we can ask more challenging questions if we presume that candidates know a couple of basic concepts that are taught in computer science programs.
How we make decisions
We define scorecards before we interview candidates for a position, and we aim to apply them consistently to candidates.
This may seem counterintuitive. A lot of people prefer to rely on gut instinct when they assess candidates. We were swayed by the arguments in Thinking, Fast and Slow, which cites decades of research arguing that structured, consistent interviews are more predictive of on-the-job performance than interviews based on gut feeling.
Based on the information we’ve gathered from our interviews, we then decide whether or not to make an offer.
Parting thoughts
We have a good track record, but we aren’t perfect. We know that we will make some mistakes. We also know that some people we reject will do outstanding work in other environments. We hope, though, that all of our candidates will believe that we treated them as we’d want to be treated ourselves.
Acknowledgements
We borrowed and adapted ideas from several sources, including
- Thinking, Fast and Slow
- Who: The A Method for Hiring
- An online interviewing class with Gayle Laakmann McDowell
