@naomarik: Over time, unfortunately.

Give me a month working closely with someone and I'll have formed a reasonable impression of their competence, I hope.

That's unfortunately rather late in the hiring process.

I tend to look for good judgment and conscientiousness above all else though.

@tagore what about looking what they’ve already accomplished? is that not a strong indicator?

@naomarik: That's a hard thing to discover though...

i mean if someone made a webapplication or game by themselves, that’s pretty apparent 😉

but i have met people who can’t show me a thing they’ve done due to it all being backend work, is this kind of the context you had in mind when answering?

@naomarik: That, and...

Most serious work is done in teams.

Even if someone worked on something impressive it's possible that they weren't exactly an asset.

And, beyond that, even people I'd consider less than competent sometimes accomplish things through sheer grit.

(though that's worth at least noting about them.)

Hiring programmers is ridiculously difficult, and I'm inclined to think that short trial-periods should be more common.

I wasnt joking when I said "over time." But it's more than competence that can be assessed given time- fit is important too.

I think we'd all be better off if the last round of interviewing consisted of a well-paid week to month-long trial, no shame attached to being rejected at the end of it.

My approach is to simply have a guided conversation with candidates (using a mind map to remind me of the structure of questions). The whole "technical test" thing is a waste of time -- it's so unlike how developers operate in the real world. But get them talking about projects they've worked on, what excites them, what annoys them, types of projects they like and don't... you can tell a lot about a developer's competence by getting them talking about the right topics.

I've never had to fire anyone I've hired.

I start in the top right... if we get stuck, I switch to the top left... If any topic doesn't seem to generate a conversation, that speaks volumes 🙂

Thats what has been going through my mind too. The first requirement to figure out competence in somebody else is to be competent in the field yourself. This might seem obvious, but its really important to highlight. Because then you can talk to your applicant about the field and while talking you are at least able to spot really fast if he is incompetent. And there is a high chance you start to recognize which books he read for instance or which problems he solved because you went through a similar process. This works even better if you have one or two people with you that have a slightly different field of competence that is relevant to your work or a very different field, like someone from HR.

For instance, if someone has a personal project he worked on, let him explain a problem he encountered and how he solved it, this is something you will do all the time in your job and it shows a lot. Code can always be copied / pasted but understanding the problem / solution can not.

Also in germany we have a probation period of max. 6 months which usually is enough to figure out if someone fits or not.

That said, if you have a good mentor / teacher in your team and enough resources it is also worth to take the time and teach somebody that shows enough interest and endurance. Although I have to admit that this even harder to figure out. Thats btw. one of the advantages of university. Somebody who is willing to go through the grind of a comp. sci. study for 4 - 8 years most probably will be able to be productive at your place.

And dont forget, as the hiring process is done by humans and humans make mistakes, you will also make mistakes in your hiring process. That is inevitable sooner or later. As always, the question is how to handle mistakes. Never having to fire someone you hired (like @seancorfield) is the exception, I would say, at least over a lifetime.

@seancorfield Thats a very nice chart btw. I hope you dont mind I grab that?

Sure! I post it far and wide hoping it'll help people change how they interview 😈 to get us away from those dreadful "technical tests" and "whiteboard challenges".

And, yes, maybe I am the exception with my record but I wish that wasn't the case -- if the interview process was better, everyone should have that record!

Thanks 🙂 +1 for getting away from technical tests. They will for sure not be able to simulate your working conditions and are therefore a waste of time. Although I do think its nice to have someone explain an algorithm to something very simple and talk to him about that whereas it is important to have a discussion like you would have in your team when you approach a problem together. I want to highlight that this should be very short and it should be not to figure out his technical skills, but his team / communication skills.

Or her, sorry for that, unluckily I only worked with male colleagues so far.

The only type of technical test I've ever found at all useful is to give someone a short, fairly simple function, with a couple of bugs in it, and then pair with them as they write tests and debug it...

@seancorfield Yeah, I largely agree about technical tests. Something really simple is a good way to weed out people who can't program at all, and it always surprises me how many people who look like senior developers on paper, and even have credentials, can't. But ideally you do that before committing to a face-to-face interview.

The last time I got hired the process mainly revolved around a technical test, but...

It actually seemed much more like a screening than anything else. First they asked me to write factorial, and then they asked me to write a function that determined, essentially, whether or not two intervals on the number line overlapped.

Which was fine- I figured they were starting with easy stuff. And then that was it.

Apparently though they had been interviewing a lot of people who failed that test completely.

I like your graph. While I'm not as organized about it as that there are definitely things in there that I try to talk about with people. Getting an idea of how they approach things is important.

I'll also say that I am a firm believer in nepotism.

I don't mean hiring my cousin, but... if I can find someone that someone I've worked with and respect has worked with and thinks is really good I take that very seriously.

And I've been pretty lucky in that a lot of the time when I've needed to hire someone (and I've never been in a position where I was hiring lots of people at a time, which made this easier) there was a nepotism hire available.

I've never had one be incompetent. I did have one who was a tricky fit... very technically competent, but very difficult to communicate with.

And I think that sort of thing matters a lot- people can be quite competent but still be bad hires if they are a bad fit with you. In this guy's case... well it's hard for me to see him being good at communicating anywhere, tbh.

But I know, looking back on my career, that how good a fit I was for the culture I was in had a lot to do with how useful I was.

Which is why I kind of like the idea of trial-periods. If you accept a job, or hire a candidate, and after a month you realize that it wasn't a terrible mistake, but that if you knew then what you know now you might have kept looking...

Well then you have to either quit or fire, and there are good reasons not to quit jobs after a month, or fire for no very articulable reason after a month.