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!
Trait 1: Attitude
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.
Trait 2: Passion
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.
Trait 3: Communication
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.
Trait 4: Honesty
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!
Top comments (15)
Hey I totally agree and look for very similar things when I conduct interviews for our company.
However I do like for the passion part when I see applicants that like to work on few personal, open source projects. But like you said yeah not looking to have someone doing commits everyday.
I also look for someone who is a team player and doesn't shut themselves out. We like to go (the whole team) drink and play darts on Fridays and I wouldn't want to hire someone who Friday night leaves everyday to go home and play some games for instance. (don't get me wrong I love gaming)
As much as I'm not a fan of whiteboard interviews, I still like to ask a few tech questions to see that I'm not with someone who has just wiggled their way through. I usually ask simple things such as: What is a recursive function? Do you know what the MVC model is ? How would you explain inheritance? etc.
For me it's really not about just finding someone who will code what we tell them to and do the job well and that's it. But really a discussion on finding what the person can bring to the team and how they will fit in.
I totally agree with this, and yeah, there definitely still needs to be some technical elements to the interview. I've tried both take home assignments and having a list of questions I ask during the interview, but I'm still trying to find a good balance. Team outings are also definitely a great way to build a stronger and more trusting team, and it's great to find a candidate who wants to participate.
that Trait 4: Honesty did the trick for me....I always ask a candidate to tell me the scale of their technical skills (eg JavaScript, PHP etc) between 1 to 5...
when they write 1 or 2, I know they not so skilled but they are likely to be honest..when its 3, I'll find out if its a "safe" zone where they tend to lie about their capabilities...when its 4 or 5..I'll give them a lil test
I would likely end up not hiring anyone who ranked themselves at the top of any skill scale I provide. I asked (at a presentation) Bjarn Stroustrop how he would rate his C++ skills on a scale of 1 to 10. He said 6 and he invented the language.
If any good programmer is being honest with themselves, they'll likely always rank themselves slightly above average I find.
That's the problem with this sort of question.
If you ask me to rank myself.. I'll say something and you'll interpret all sorts of things.. but who knows if your ranking system is the same as mine.
So I find this sort of question meaningless.
Best ask the person what they are best at and then measure that somehow. Like asking them what they did in the past or asking them to show you something or you showing them something and see if they can follow.
But trick questions can be tricked, and rarely are reflective of anything.
People have wide backgrounds.. so there's a wide range of skillsets.
Y'know, I've never thought about asking candidates to rate themselves on a skill scale, but that's a great point!
Once I was interviewing a candidate with a couple of years of experience. The conversation went like this:
Me: "What was the most challenging task/project that you have ever done?"
Her: "No challenging tasks!😒"
Me: "Wow, really? What if you are assigned to a challenging project?"
Her: "I will take it as a challenge"
Me: 🙄🙄🙄
Hi. Interesting stuff.
I was wondering what's your take, as an interviewer, on coding challenges.
I've written a couple of posts about coding challenge - this is the first, which is kind of a research attempt:
How would you design an interview coding challenge? What could you learn about a candidate from it?
Zohar Peled ・ Sep 26 ・ 1 min read
and this is the second - which is how I think it should be:
What if your interview coding challenge would look like this?
Zohar Peled ・ Sep 26 ・ 1 min read
However, these are from my perspective, which is more often the candidate's perspective and less the interviewer perspective (I have conducted some interviews, but that was never actually a part of my day-to-day job, so I lack experience from that side of the table).
Definitely sharing this one on twitter
Thanks for the share!
Great read, thank you!
I'm glad you enjoyed it!
I remember a interviewer was constantly asking questions that even himself, did not know anything about them at all!
Thanks for sharing. Definitely very useful.
Thanks, I'm glad you liked it!