
Ask HN: How to vet dev candidates to make sure they can code at desired level? - etothet
The following seem to be popular methods used to determine if developer candidates can perform the coding aspects of the job you&#x27;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&#x27;m missing? Are there any good online resources&#x2F;services that help make this part of the hiring process easier and better for all involved?
======
photawe
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.

~~~
inertiatic
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.

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

~~~
rafiki6
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.

~~~
photawe
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".

------
rafiki6
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.

------
muzani
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...](https://www.joelonsoftware.com/2006/10/25/the-guerrilla-
guide-to-interviewing-version-30/)

------
taway555
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.

~~~
muzani
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.

