How To Hire Awesome Developers Without The Stressful Interviews

I was thinking about how different LeadingAgile’s pair-programming (more simply, pairing) interview is from other interviews, like many interviews at the big tech-giant companies we all know about. Interviews at these massive tech companies are known for being difficult ordeals. There are even courses designed to help you pass them! Common challenges include multiple rounds of tech interviews and white-board programming exercises, where a candidate is expected to solve a problem writing correct code on a whiteboard with no reference material.

Why doesn’t LeadingAgile interview developers the way these other tech giant companies do? We believe that we can find and hire awesome developers while making the process compassionate and without undue stress on candidates. That kind of compassion is an aspect of Studios that we want to project. It brings candidates that are good teammates and good consultants. That compassion in an interview, along with a follow-up email describing what they need to learn/improve, also encourages “not yet” candidates to come back and interview again when they have more experience. Not only are white boarding interviews unnecessarily stressful, they do not represent what we do every day at Studios, namely pair program and find answers to things we do not know.

Our pairing interview is intended to be a reasonable simulation of real working conditions at LA Studios. We are looking to answer:

• Can they do the work we do?
• Do we think they will succeed as a developer who primarily pairs or works in an ensemble (some folks call it a mob)?
• Can they “develop out loud” while someone is helping?
• Is their preferred craft in alignment with what we have found to work? (TDD, CI, legacy rescue…)?
• If they do things differently than we do, can they speak to the pros/cons?

Our pairing interview does differ a bit from an actual working situation. Unlike on the job, the interviewer:

• Knows what they are looking for the candidate to demonstrate
• Will only help as much as needed to keep the candidate moving – the two are not trying to solve the exercise together

But we have found our pairing interview a good predictor of whether a candidate will be successful on one of our teams, because it does share so many aspects of our “real work.” Here are some things we look for as signs that a candidate will succeed in day-to-day development at Studios:

• Is there at least one programming language that they can be effective with? (Candidates may work in whatever language and tool set they are comfortable with.)
• What is their skill level with their language of choice? Do they write it idiomatically?
• Can they explain the what and why of the code they are writing?
• Are they careful?
• Are they skilled with TDD and generally test-first, and is that their default instinct?
• If they do not demonstrate the use of version control during the interview, are they able to talk about how they would use it in real work?
• Do they value small, single-concept commits with useful messages?
• Do they bring at least a little humor or fun to their work?
• Are they able to gracefully recover from setbacks?
• Do they accept instruction/redirection well?
• Are they curious if they are introduced to something new?
• Are they comfortable “not knowing the answer” in front of someone?
• If they do not know a specific detail, can they quickly find an answer online?

A “no” to any specific question above does not fail a candidate. Certainly, holding opposing views to some of the above will prevent a candidate from receiving an offer. For instance, believing that TDD is a waste of time or having a strong preference to wait until a feature is complete before they commit to version control are strong indicators that they will not be successful at LeadingAgile Studios.

But a “miss” on many of the things above that we are looking for is only likely to affect the level that we might place the candidate at. For instance, our most senior positions require strong TDD, refactoring, CI, version control skills. For them, we expect idiomatic use of the best parts of their selected language. Our least-senior position, Associate, requires some ability to code, curiosity, and an interest in learning. If we are considering someone for Associate, being able to demonstrate use of basic data types and control flow is sufficient.

There are things that we specifically do not look for by using pairing interviews, generally because they do not reproduce what we experience day-to-day:

• Whiteboard coding – as mentioned above, it is not what we do day-to-day and may create undue stress for the candidate.
• Ability to list the names of, for example, data structures or patterns. While we want candidates to be aware of and be able to show use of some patterns (based on career level), there is no mark against someone who can implement a particular pattern but doesn’t specifically state its name.
• Willingness or ability to do unpaid development work outside an interview. We recognize that not everyone has a life that allows them time to code outside of work. For instance, a person might be caring for a sick parent or be responsible for small children. If we were to screen out candidates who cannot do coding exercises at home, we would be reducing the diversity of the pool of people capable of succeeding at Studios.

LeadingAgile Studios is growing. We are looking for very skilled developers to lead efforts or very new developers who we can help grow. If you are not interested in interviews as performed at giant tech companies, either because you have experienced them or because you are not looking for an interview that requires weeks of preparation, contact us.