Tech sector job interviews assess anxiety, not software skills: study

> it would be worth it to talk to a tech recruiter

IMO this is very good advice. Having been on both sides of the equation, I think a good tech recruiter (emphasis on good) brings a huge value to the process. As a hiring manager, I had one guy I knew I could rely on to bring me really qualified candidates every time. His own filter was excellent, and he only brought me people that were a good fit. I almost didn't need to interview them. Other recruiters were terrible, one even sent me a candidate who had faked their first phone screen so they weren't even remotely qualified for the job.

That is the guy you want to know. He has earned his reputation. And it cuts both ways, too -- his success isn't just when the company is happy with him, but when candidates are too -- all the best ones are his clients, after all.

>But what's the content they should be interviewed on? You say no to quicksort. How about date parsing? That shows you have to handle messy cases.

But why? The vast majority of programmers don't ever need to write code to parse a date. It's just another test completely irrelevant to the job.

>Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.

Both are pretty bad interview questions. Is this a Javascript position? If they don't know how it handles equality do you really think that is the end of the the world for the interviewee, does that make them a bad programmer? It's something you could explain to them during the interview in under 5 minutes (and you should, it eases the pressure on the interviewee). So really what's the worth of asking it?

Likewise, "implement a hash table". Pointless. Ask them "Do you know how a hash table works under the hood?", chances are they might not know exactly how to implement one but they do understand roughly how it works. If they don't know then describe a simple implementation and quiz them on why it's built this way, do they understand the "why" even if they don't understand the "how". Most competent programmers can implement a hash table given an explanation of how it works which is why I don't think it's a good question to ask someone during an interview. It's just a memory test, not a test of how good they are as a programmer, how good they'd fit into a team, how good they would be at designing a large system, how good they'd be at weighing up the pros and cons of different solutions.

This is why interviews should be discussions, not tests.

HBO's Silicon Valley is dramatized, but I can't be the only one who's coded from the the convention hall floor/hotel, or had to setup servers "live". Every time a site gets unexpectedly popular (/. effect; HN hug of death) and dies, and comes back, there's someone at the other end who's probably close to tears trying to get their site back up ASAP.

That doesn't indict the fact that's the exception and that software programming almost never looks like that.

The real problem is that take home problems are trivially gameable - it's obvious to someone unscrupulous who's not a well-seasoned coder, that it would be well worth paying someone else to do their take-home-interview-homework. (Sure, that would come out eventually, but that's only one of the problems I have with take-home assignments.)

Some places have "open book" interviews, where it's like "here's a laptop, do this thing, and google/stack overflow/devdocs" your way to victory, which is at least better than the older "how much trivia do you remember about this API"-style questions. But I have no idea how to go further and make that unbound by time when an employee is on the other end of the table listening to the interviewee's thought process, if only because it makes it very hard on the interviewer to plan their own time. (Especially considering maker vs manager time.)

> Couldn't tell an average from a median

Without meaning to attack you personally (especially in the context of the rest of your comment), a comment like this annoys me a bit.

I presume by "average" you mean arithmetic mean, but the median is also an average, and depending on the context the median might be a far more useful statistic than the mean. Confusing the mean and the median is one thing, and perhaps you actually used this terminology in the interview; "confusing" "the average" and the median isn't really worthy of comment, and sounds more like a breakdown in communication between interviewer and candidate rather than a lack of technical knowledge. It just seems vaguely hypocritical to me to be expecting a certain level of ability from the candidate and then using imprecise/informal terminology.

> no one knows what to replace it with that isn't enormously expensive

That's the crazy thing about this. FAANG has near-infinite resources, relatively speaking. Google could be A/B testing their interviewing process, experimenting new approaches, experimenting (as the OP study did) with eye-trackers and other tech to try to gain insights on candidate behavior. They have the "engineering for the sake of engineering" and "innovation for the sake of innovation" culture that allows for moonshots and boondoggles. I don't think they're exactly known for following "if it ain't broke, don't fix it", given how many times they kill off products only to recreate them later on, especially their chat apps.

Yet they stick to the traditional whiteboarding method because-- why?