The following seem to be popular methods used to determine if developer candidates can perform the coding aspects of the job you're interviewing them for:<p>* Public source code profiles (Github, etc.)
* At-home coding assignments
* Code katas
* Live coding
* References<p>I know at-home assignments, while commonplace, and even live coding are sometimes looked upon badly, but which of these methods above are best? What about other methods that I'm missing? Are there any good online resources/services that help make this part of the hiring process easier and better for all involved?
You can never be sure. If you do know coding (and I mean, are in the "senior-to-expert" category), there's a chance you'll be able to get a feel of what a guy can do by asking a lot of questions and by looking at public source code (such as github). That won't actually guarantee the candidate will perform as you wish, since in real life, there are so many things that you missed/can go wrong. Case in point: a few years ago, I had an project that I simply didn't have time to handle, so I sub-contracted it to a former boss of mine (a guy I deeply respect to this day). I would have never guessed he would not be able to handle it -- I wanted him to work on it 15-20 hours/week, and be up to speed in 2-3 days. This is far from what happened, so I ended up doing the project myself (I have no idea how I found the time). But long story short, even though he's a very very good programmer, he still couldn't handle the pressure. That says a lot about "regular joes" that can say all the right things, answer questions right, and still not perform well in the long term.<p>Having said that, the best bet (assuming you are in this category -- senior-to-expert), I would recommend hiring someone as a 3-6 months trial, and then see how it goes.<p>If you don't know coding, my take is you'll NEVER be able to know how a candidate can actually code -- don't even attempt hiring in this case.
First and foremost, have you asked yourself and your team the ever important question:<p>What is the REAL "level" of programming required to be successful at this job? Please don't keep the trend going of asking whiteboard questions to a person who will be coding CRUD apps all day.<p>A junior developer is a person who's looking to learn and make an impact in what it means to develop a system. I find it best to interview for potential. Ask them to solve the same problems you'd ask a senior to solve, but with a different bar and more focused on seeing how they think through them.<p>A senior developer should be a person who's technically competent, experienced, knows how to make technical decisions, and understands the basic idea of value proposition. They get why they're building what they're buidling. Sure you can sit there and ask them a crap ton of coding trivia, but that's not what you actually need from them. A senior should be able to tell you the differences between languages they've used, the challenges they've faced and how they over came them, and clearly highlight key aspects of their technical decision making capabilities.<p>A lead and manager should be more people oriented.<p>Asking someone to do coding tests is fun, but it's a really bad signal. Asking someone to work with you on a problem is a lot more interesting and can help you gather much more valuable information. Do your best to setup a test environment that is as close as possible to your real environment. Respect candidates, allow them to highlight their strengths, make them comfortable enough to admit their short comings honestly, and think carefully through what "level" you need.
I think all of those processes work fine for different people.<p>I love days long coding assignments and hate live coding. I especially hate giving my code samples - most of the code I've written are proprietary, and everything public is some kind of messy experiment. Code samples also feel like some violation, like stripping down while applying for a modelling job; I understand why it's there, but there are probably better options, and it feels creepy and judgemental.<p>But other people also have strong opinions on this, and they're not wrong. Everyone values different things and the filters are often right for them. Interview is a part of company culture.<p>I still think that the best thing to interview for is to find someone who is smart and gets things done: <a href="https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/" rel="nofollow">https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...</a>
Easiest way to cut through the noise is to give candidates some whiteboard questions. This will invariably filter out some good candidates that aren't good at these problems, but you'll be left with a bunch that have some baseline competency.