Ask HN: How to vet dev candidates to make sure they can code at desired level? | Hacker News Reader

Ask HN: How to vet dev candidates to make sure they can code at desired level?

6 pointsetothet13 comments

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:

* Public source code profiles (Github, etc.) * At-home coding assignments * Code katas * Live coding * References

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?

View on HN

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.

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.

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.

Who wants to get hired on a 3-6 month trial basis?

Not established competent programmers is the answer, unless you're paying at least FAANG salaries.

I end up taking those.

The problem is that the interview process in tech is frustrating. It's not just the anxiety, whiteboards, being judged for having a beard. It's also that applications can go on for weeks before having a response, and due to the volume of applications, just writing applications take hours. The higher the pay grade, the more loops you have to jump through, the more people have to approve you.

If I can skip 2 weeks of interviewing for 2 weeks of trial work, I take it.

The downside is that employers rarely have the balls to let go of someone who was trialed this way. And sometimes even if someone does poorly, many companies don't have the luxury of trying to find someone else. It seems to benefit the applicant much more.

It is common in Europe that when you accept an offer there will be a probation-period; say you'll sign a job offer and it'll say something like

"During the first six months either side can terminate the agreement with XX-days/weeks notice."

I suspect this is because it is a little harder to fire people here than it might be in America with the whole "at will" employment approach you tend to have.

I would say - if you're truly competent, you won't be afraid. If you're incompentent, that's a different story

There's a subjective term if I've ever heard one. Who decided I'm truly competent? What happens if I'm truly competent but I outshine someone who's influential enough that doesn't want me around? What if I'm truly competent, but I wasn't setup for success? What if I'm truly competent but...you get the idea.

If you want a contract resource, hire a contract resource and if they perform well ask them to stay after. These are people who've decided for whatever reason they are happy to contract. Don't offer a person looking for a full time gig a 3 month contract in the hopes of being hired.

Be upfront and honest with people.

i never said to be dishonest - maybe I wasn't clear enough. What I meant was this "You specify from the get-go you want to hire the guy, but he'll start on a 3-6 month trial basis. If all goes well, you'll continue and give him a full contract".

Why would you apply for a job where you are "truly competent"? Don't most engineers want to be challenged when they are looking for a new job? Shouldn't people who are looking for this sort of thing have a sense that they may fall short?

Yes, because no competent person has ever failed in a hiring process.

First and foremost, have you asked yourself and your team the ever important question:

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.

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.

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.

A lead and manager should be more people oriented.

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.

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.

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.

I still think that the best thing to interview for is to find someone who is smart and gets things done: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

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.

Downside of this is that you still might not get, say, someone who can hack a security watermark feature into a react native camera app. Being able to solve hardest questions might not necessarily mean they can solve easier ones, or that they can get work done.

Reply on news.ycombinator.com