Hiring Developers the Fun and Easy Way!
This is the internet and people have opinions here, right? Cool, because I do too. And man, do I have opinions on Silicon Valley and the "culture" perpetuated by Valley-inhabited and -esque companies. So let's start with the way they hire people, and why I like doing things my way instead.
Too many times I see people talking about bad software engineer interview experiences. Just recently, I saw a tweet in passing about someone who didn't get a job because they couldn't articulate the difference between a linked list and a binary tree. This is exactly the kind of thing that irritates me, because if you dig into a lot of these kinds of questions, it boils down to this:
Do you need me to figure either/both of them out for a specific purpose? Great! What's that purpose and how often do you ACTUALLY run into that particular problem? Oh, you don't actually see that concept used much in what you are/I will be doing? Then why is this a relevant interview question or exercise?
So now you ask, "Fine, smartass, how would you go about hiring someone?" Fair enough. Here are the three things I look for when determining if someone is worth hiring:
Do they know how to code? Of course, this is the most obvious qualification for a software engineering position - someone who can actually do the job. But I don't like to go through the bullshit of having someone determine the difference between two data structures. I can't fucking articulate the difference between a binary tree and a linked list, either. I know how each is structured, sure, but just being able to spit out textbook-level answers usually means jack shit in real-world application.
Let's be clear: I am absolutely NOT discounting knowledge of any kind (you'll see what I mean in point #2 below). But a question like that should not make or break a candidate's chances when it's not actually relevant to the job at hand. For example: Knowing how to build a React front-end on top of a Node backend is a great skill to have. When your goal is working on a monolithic Windows Forms application, though, React and Node probably aren't very relevant. The relevant skills in this case would most likely be .NET Framework (with C# or VB.NET language syntax) and obviously, WinForms.
Another thing that I like to do from the outset of an interview is ask a wide range of technical questions, both about coding topics/syntax and more general questions that are related to the product(s)/project(s) my team is working on. The last team I was on fixed bugs in a pretty comprehensive IT management tool, so my general knowledge questions would include items relating to the Windows registry, services, and the occasional Active Directory curveball (you can take the sysadmin out of the datacenter…). Something I always stress to interviewees is that the technical question section is not a pass or fail situation. Rather, it gives me an idea of where their current skillset is and the areas in which they'll need enrichment.
Finally, I'm gonna be that jerk: I like giving junior developers whiteboard exercises (the key word here being junior). This is not simply to see if they CAN code, since many junior devs come in with links to their Github repos and personal portfolios that showcase what they know and are capable of doing. Instead, I like whiteboard exercises because I can watch HOW someone goes about solving an issue. I always encourage people to verbally talk out the problem as they work on it and ask any questions they want. I'm not going to answer all of them since this is their time to think through a problem, but I'll offer up advice or maybe the one little nudge forward they need to get back on track. Ultimately, this shows me how they think - what really goes on when their gears are turning - and that helps tremendously to know if they have the underlying logic skills I'm looking for. Again, however, failing a whiteboard exercise should not necessarily be what makes or breaks the interview.
Do they have the capacity AND desire to learn? There are few fields that change and evolve as quickly as software engineering, thanks to the evolution of technology in general. Because of this rapid pace, people who work in the field need to be able to adapt quickly as well. This doesn't just make them a better asset to the company/team, but it also helps to foster their growth into a better developer and human being. Which, as a good leader, should be one of your primary goals with every person that joins your team.
Additionally, I love asking candidates what they do in their spare time. It gives me a real glimpse into how they think on a large scale. Sure, I get the usual answers like gaming, coding (hey, it started as a hobby for me), and other activities you'd expect from programmers. But one that struck me a while back was simply: reading. This person just loved to read and absorb knowledge. They liked to read about all kinds of subjects, too, not just tech-related ones. Yeah, they had a passion for tech, but they also cultivated passions for all kinds of other things (especially food). Having that desire to "broaden your horizons" is exactly the kind of mindset that makes for a good and well-rounded candidate.
Will they be a positive addition to the team? So they have the technical chops. They have the ability to grow and adapt. That means you should hire them, right? Not necessarily. Many times, I've been forced to choose between two candidates: One who has a slightly better technical skillset but lacks in positive attitude or interpersonal skills, and another who may not be quite as strong technically but is willing to go the extra mile to help both themselves and their teammates grow and learn. Every time, I'll take the one who needs more technical growth. Why? Because that person can DO the job but they can also make a positive impact to the team as a whole. As a leader you must ALWAYS think about the best interests of your team when making personnel decisions (later, ask me why firing people can absolutely be a good thing). After all, a team of people should be more than just the sum of its parts.
A few years ago, someone was hired onto one of my teams who had a pretty good technical background, both coding and otherwise, but had a terrible attitude. This person essentially thought that the work they were hired to do was boring and "beneath" them, and they ended up doing basically nothing. And you better believe everybody on the team took notice, so much so that it started dragging people down. Eventually, most of the team approached our manager as a group and asked for action to be taken, and before you know it, the poisonous colleage was gone. Once again, they definitely had the skills to do the job, but because they had a garbage attitude, it caused discord with the rest of the team and morale suffered. As soon as they were gone, however, things went back to normal and the team was once again happy and productive.
So there ya have it. Yes, I know my methods aren't perfect, but I'd like to think that I've had a pretty good success rate in the folks that I've hired in the past. Having said that, if you have any feedback/words of wisdom/anecdotes of your own, you know where to find me.