We discard something like 50% of applicants based solely on the contents of their CV which generally shows that they are not suitable for the role in question. Without a CV we'd have to interview all those too which sounds like a massive waste of everyone's time.

There are other ways to evaluate potential candidates.

Most people have a LinkedIn profile these days which usually duplicates the majority of things on a CV. GitHub repositories of personal projects and StackOverflow comments/answers/etc can give an indication of practical knowledge. Depending on the industry, word of mouth and discreet questions to mutual friends goes a long way before you get to formal references and the like.

And before you even get to an interview you can always set a programming task beforehand to be discussed during the interview. (We do that for our follow up tech interviews, but there's nothing to prevent you from using it as part of the screening process.)

That is, those who don't mind being bombarded with bogus contact requests and having their details farmed out by strangers without their knowledge to all and sundry including impersonation fraudsters.

I suspect a key reason recruiters like to post on and trawl linkedin rather than dealing with individual candidates is just that it's less effort for the same return. There are entire agencies that only exist on linkedin, providing no other means of contact despite this being in breach of more than on current law. The reality remains that candidates (however expert) are merely commission fodder.

Bullshit if that's a reason to get rid of half....

Problem with using CVs is that there is a mountain of talent out there that undersell themselves, because the CV is NOT the right vehicle. I'm guilty of underselling myself in my CV.

Equally though, I'm a big hater of coding IN an interview. That isn't a good indicator either.

There is a good reason, a substantial amount of people cannot code with someone watching them. I include myself in that group.

It isn't because of incapability. I know I'm damn good at my job. How many times I mytself have been at someones desk, when their coding/typing skill falls apart while I'm watching. Itr's the same reason that pair programming is a curse to many.

Screening call, just a quick chat to talk through current gig, and previous + any thing on cv - light tech filter.

In person, set a couple of basic problems, leave you in peace to work on them.

Some people just don't get that being good at being interviewed is separate from being good at delivering quality work.

Pair programming is about the banter, once you are locked in, I find it effortless, with a good pair.

But you need to have the right setup, I'm on my machine, you are on yours and we are both dialed into a shared screen, so you don't inflict your editor on me, and I can use Vim.

I've been in the situation of going through ~100 CV's interviewing 7 or 8 and hiring 2 of them. I've also been in the situation of being one of the two people recruited from 400 applicants, and joining the initial four selected from another 600 applicants. For some jobs CV's can be a very time efficient tool for the employer.

"We discard something like 50% of applicants based solely on the contents of their CV"

I wonder how many of those CVs may have been rewritten by agencies or had originally been sent to the agency for some other job, emphasising a different part of the candidate's skill set.

Coding interviews miss the point. How does the candidate work with the team? Do they demonstrate an awareness of process? Can they demonstrate an understanding of ways to juggle competing requirements for the code? I used to say that the job was at most one third technical skills. The other two thirds were general problem solving and people skills.

Who knew, hiring is hard.

Other interesting statistics in the survey include the finding that less than half of developers who responded did not learn programming at university or an engineering school and that nearly a third were self-taught.

Nowt wrong with being self taught. It's given me a 30 year career. I remember once being asked to interview candidates for a role below mine with required qualifications that I didn't have. I don't have a single computing related qualification to my name and I'm (somewhat) proud of it :)

Right on the nail. I taught myself assembler and C and worked as an embedded systems programmer for quite some time before going to Uni where the programming modules imparted bugger all. They primarily consisted of abstract discussion of obscure mathematical algorithms (the hobby horse of the lecturer, who was a pure mathematician), but, surprisingly, not how to implement them in code, plus some quite elementary assignments that took for granted that you could already program. Project planning, secure coding, and even optimisation were simply not mentioned. As I'd previously designed instrumentation systems for aerospace research, I learned nothing new.

Competence is vital. How you become competent is rather secondary as long as it works.

And even if the candidate has learned programming at University any expertise with technology released since graduation (and some earlier than that) is likely to have been acquired via self-tuition.

Indeed, the measure of a software engineer is not the source of their knowledge, it's their ability to work with a team to deliver working software.

Computer science graduates I've worked with have never distinguished themselves in development roles from people with any other background. The curve of awful to brilliant doesn't care one way or the other.