[jakebasile]

> Even seasoned developers have to go onsite and spend 1-2 days doing interview.

No, they don't. Like most people that champion these types of nonsense "code challenge" interviews you present a false dichotomy of "you have to either torture someone in person for multiple days, or torture them with a bullshit made up test for hours!"

You can talk to them for a while over the phone (or video chat), split up over a few days, and get to know them just fine.

[tptacek]

Yes, this much is true: in weak hiring cultures, which are very common, people get their friends (or people with dazzling resumes) hired without any real rigor. What's more, in that culture, it's straightforward to generate a dazzling resume: you "fail up", because it takes longer to get fired (or for it to become clear that it's time to get a new job) than it does to get enough time on the job to look good on a resume.

[jakebasile]

I really don't think this issue is as widespread as commonly held, and I think it is used to perpetuate the horrible hiring culture that is common in our industry.

I think it's perfectly reasonable to hire people based on resume, references, and conversation. If they can't handle the job once hired then they should be let go.

I do not think that the idea that all candidates are complete idiots unless they can be "proven" to be good engineers (by faked tests that rarely cover the actual job requirements but do have a way of discriminating against those who don't enjoy brainteasers, didn't go to college, or are older) is good or healthy.

[shantly]

I wanna know who the people are who can talk confidently and intelligently about the details, decisions, and purposes in the systems, technologies, and workflows they've worked with or built, to essentially arbitrary depth, but can't actually do the job, and also actually manage to hold down jobs without huge gaps in their work history. I find it hard to believe there are so many of them that it's worth defending against. Smooth talkers exist, sure, but c'mon, they can handle a friendly but detailed discussion about stuff on their résumé but can't write code? God, learning to write code would be easier than prepping for that kind of thing without actually knowing how to do the work, surely.

[jjav]

Precisely. It can't be done.

This does assume that the interviewer is an expert in the area and can take that friendly conversation to the necessary depths.

[tptacek]

Serious question: have you done much hiring? Because this was a huge component of my lived experience as a hiring manager since the late 1990s, and every hiring manager I've talked with directly since has had similar experiences. If you do a lot of hiring, and you're honestly surprised that there are people who do really well in interviews and turn out not to be good hires, I'm curious to hear more about your experience.

[shantly]

Yeah, both as just another part of larger hiring panels and in tech lead roles with the biggest say in who gets in. Maybe I've been rejecting people who'd be fine and am committing the same sin but it seems pretty easy to get a sense of "this person has been working 5 years but is incredibly junior and barely understands the stuff they're working with" or "this person has been working 5 years and really knows their shit" from like 20 minutes of conversation, and I've not seen a true bullshitter get through hiring despite a lack of heavy, time-intensive tech-challenge-based interviews anywhere I've worked. Closest we had one place was a really easy screening project, which we didn't make anyone not-obviously-junior bother with, and I bet a few minutes on the phone with the right person could have replaced that with no real harm to the process.

I have, however, on two occasions probably personally convinced someone they had dodged a bullet by passing on me when I bombed that sort of quizzy interview—they were, I am entirely confident given the job descriptions, my work history, and actual feedback I've received from managers and peers, quite wrong, but I bet they were very sure I was useless and nowhere near being fit for the job.

[EDIT] I guess I should add that I have a history of not realizing that something I'm good at is not actually easy or obvious to others, so possibly I'm just unusually awesome at assessing developer suitability through conversation—I really doubt it, but maybe that's what's going on. I've also not found a way to make this fit with any sort of "we ask everyone the same set of questions because we want spreadsheets at the end" process, as you've got to tailor the interview to both the position and to the candidate, as presented on their résumé and related material. So if you want spreadsheets and quantifiable-everything then I'm not sure how you match that up with my preferred style.

[alexk]

Makes, sense, however video conference interviews usually take up full day from a candidate, as you have to free up your day (and your mind), stay at home and be ready to answer a rapid succession of questions/perform live coding acts.

At least that what my experience when I was a job candidate.

[jakebasile]

Who says video/phone interviews need to take up an entire day or have "live coding" (which will be super high stress and don't indicate in any way if someone is a good candidate)?

[alexk]

What would happen on those interview calls then?

[jakebasile]

Talk with the person, get to know them. Ask about previous projects, get into details about what went wrong and what went right and how they'd change things. Get into technology details.