I've had to interview a number of developers throughout my last couple of jobs, and I've been slowly refining a list of common traits I've found that successful candidates have all shared. I wanted to talk about what I've found to be the largest indicators of a top candidate, and also some of the red flags. I find that most posts about interviews are from a candidates perspective—how to prepare for an interview, common interview questions—but I wanted to highlight some of the non-technical traits I'm looking out for. I should also preface this article by saying I'm not representative of all interviewers; everyone is going to have their own styles of interviewing, and what's appealing to me doesn't necessarily mean it's important to other employers. I'm just providing my perspective on what I've found to be the most important qualities. Alright, now that the preamble is out of the way, let's jump into it!
I think attitude is one of (if not the most) important traits of a candidate. Especially in my current workplace that practices pair programming—I want a candidate that I could see myself working with for 8 hours at a time. We do code/PR reviews, so a successful candidate needs to be open to feedback and collaborating on problems with other team members. Now, not every workplace practices pair programming, but I feel this characteristic is still applicable across almost any circumstance. You don't want someone who's going to stir up a ton of conflict amongst the team.
In my experience, the more ego that's in a workplace, the more toxic the culture becomes. I believe the most positive environment is one that values inclusivity and mentorship. You could be an excellent developer, but if you're not willing to share that knowledge with your team to help build everyone up, then a lot of that value is immediately lost. We're all constituents of the same goal, so if we're putting up barriers between developers, we'll never be able to work as a cohesive unit. People often conflate high skill with success, but a focused team will always outperform an individual.
This one is tricky for me. I think a positive work/life balance is incredibly important to maintain, and I know not everyone has the time to pursue a bunch of side-projects. That being said, having a body of work or an online presence (whether it be contributions to OSS or involvement in a development community) makes it a lot easier to understand the capabilities & skillset of the candidate. Also, self-learning is incredibly important—especially in web development where things move so rapidly—so having an idea of where a candidate goes to keep up to date on emerging technologies is a huge benefit.
I don't need a candidate to have hundreds of green squares on their GitHub contribution chart. If they've made the effort to participate in development outside of work experience, it helps me understand the kind of developer they are before the interview. This assists me in refining the questions that I prepare, which usually results in a better interview. So yes, when you include links to your socials on your resume, interviewers absolutely check them out. I understand this may be a touchy area, but again, it's not a dealbreaker for me. I don't need you to eat, sleep, and breathe code.
I'm not a fan of whiteboard interviews. I feel like it's not a good representation of a candidates ability to solve the types of challenges we deal with on a daily basis. I'm not saying that there's no value in these types of interviews—it's just not my style. I prefer learning about a candidate through asking questions about the projects they've worked on.
Keeping questions open-ended and having a candidate talk about their technical background has (in my experience) been a better indicator of a candidates ability, moreso than whether they can throw together a function that takes in two binary trees as arguments, and return whether or not they're perfect mirrors of each other. I'm much more interested in whether they can communicate technical concepts to me vs if they've memorized the common interview algorithms. You can tell a lot about someone's work ethic just by listening to how they talk about development.
I've met brilliant developers with terrible work ethic, which is kind of like mixing 16 year scotch with Coke Zero. There's certainly a lot of potential but it's been lost underneath a layer of disappointment, and if you drink too much you'll end up with a massive headache.
If I'm asking you technical questions and something comes up that you're not familiar with, I don't want you to try and lie or talk your way around it. Be honest and tell me that it's not a concept that you're familiar with, and we can work it through it together. If a candidate seems genuinely interested in understanding a concept, then it demonstrates that they have a curiosity and willingness to learn. I never expect a candidate to fully understand every facet of the tools we work with, but if they're able to show they're strong, capable learners, then I'm less concerned about practical experience (this, of course, has limitations. I need the candidate to at least be familiar with the stack we work with).
I've had interviews where a candidate was clearly unfamiliar with a topic, but tried to talk their way around it. I understand the pressure of an interview scenario, and admitting you don't understand something might seem like a sign of weakness and hurt your chances at the position. But I can tell you that getting caught in a lie is 10 times worse than being not knowing something. This is an immediate red flag for me. It's also an indicator that a candidate might have trouble keeping open communication in a workplace setting when they're running into blocks, or struggling with a task. Don't do it!
These are just the things that I've noticed in my experiences thus far. Maybe they're obvious, but I'm still learning something new with every interview and constantly refining my practice. If you're in the position where you're performing interviews, I think it's important to take a moment of introspection after each one to review your process. Remember, this is going to be the candidate's first impression of the company, so it's important to maintain a balance of being able to assess a candidate's technical ability while still providing an authentic representation of the company's values.
Here's an interview tip: never project yourself onto the candidate. I've met too many people whose expectations for a candidate come from looking in a mirror. Don't expect the people you're interviewing to share your experience or exact skillset. A diverse workforce is a strong workforce.
I hope this provides some clarity on what we're observing from the other side of the table. Other interviewers, what are some of the traits of a candidate that are the most important to you? Let me know!
Thanks for reading, and feel free to say hi on Twitter!