[remote_phone]

That’s because the interview is basically memorizing algorithms.

A real on-site interview should be:

1) give vague instructions on a fixing/modifying a moderately complex piece of software

2) have them ask good questions until they get to the heart of what they are supposed to do.

3) work with someone to accomplish this task. Use google or whatever else you need to finish it.

This interview should be 5 hours long including lunch. This is your best indicator of success.

[wyclif]

When did 5 hour interviews become the new normal? That seems sadistic to me.

[cableshaft]

Seriously.

My wife just interviewed and got a new job in the past week, for a proposal writing job at a decent-sized tech consulting firm (300 employees) where she'll be making six figures.

To get this job, she spent about two hours of preparation learning about the company and hunting down samples of past proposals (this is her standard process for preparing for an interview, by the way), then had one 30 minute interview with her would-be boss, and one 30 minute interview with three would-be coworkers (at the same time). She had a job offer a few hours after the second interview.

Now she's had several years of prior experience for some pretty large companies and worked on very large proposals in the past, but the difference seems to be in her industry they trust past experience, whereas in tech it has almost zero value, they just care about whether you can past their coding exercises.

The programmer/software engineer interview process is just so broken. I have to grind toy algorithm coding problems and rewatch algorithm lectures for weeks just to psyche myself up to go through the interview gauntlet again.

I've even neglected getting back to pings from recruiters just because I wasn't feeling up for going through the whole process at that point in my life and/or I knew I wouldn't have enough time to prepare myself for the interview to even have a chance to make it through it and I'd be wasting my time.

I get that employers are getting inundated with people that they at least feel they couldn't code (I bet they'd think that about me as well if they brought me in to interview today, even though I've been basically a one man dev team for startups before and currently developing and supporting software that services millions of customers) so they feel the need to verify the skills.

I just find verifying skills in the midst of the interview very difficult, especially if it's testing knowledge I haven't used very recently, since my brain is constantly context switching out technical details and platforms and apis based on my current work needs.

There needs to be a good way I can prove "Hey, I really can code" outside of an interview, once, that's somehow trusted. I thought that's what a degree in Computer Science was supposed to prove, but apparently that was a waste of money.

[wyclif]

There needs to be a good way I can prove "Hey, I really can code" outside of an interview, once, that's somehow trusted.

Some people say this is what fizzbuzz is supposed to do. Others, particularly people outside the USA, say the solution is engineering licensure. A lot of people in hiring think that's not enough. But what is definitely lacking is institutional trust between companies outside the FAANG bubble, and perhaps blue chip companies like IBM.

The problem of low institutional trust means that working for Company A as a programmer for years means nothing to Company B, and you have to prove yourself all over again if you have to interview for Company B even if your GitHub is loaded with open source side projects. So the problem is not proprietary code or not being able to show your work to a new employer, it's trust.

Anyway, the developer interview culture is severely broken, and it's been discussed a lot elsewhere on HN, yet nobody has been able to solve the problem. We have smart thermostats, can order books with our voice from the couch, and 3D print a house, but we can't solve hiring and just have to accept the status quo if we work in tech.

[specialist]

> the difference seems to be in her industry they trust past experience, whereas in tech it has almost zero value, they just care about whether you can past their coding exercises.

I'm of two thoughts.

One, the hazing ritual (reversion to mean) is because we forgot how to interview properly and can't think of any other strategies. For this, I mostly blame corporate HR wankery and failings.

Two, some Mensa style geeks do a weird bully flex, probably out of insecurity. And per our common negative attribution bias, these few "bad apples" are the ones we remember.

[unishark]

Well in academia, and generally in research, interviews are about 1.5 days of solid interviews, plus an hour presentation. In normal times, add a good dose of jetlag.

I once interviewed at a place that was almost two solid days of 30 minute interviews, one after another. By the end of the second day I completely didn't care about anything they wanted to ask about or what they thought about my responses. I think this stamina crushing test was actually part of the evaluation. Not kidding about that.

[wyclif]

Right, I can understand that's normal in academia, but I thought the context here is software development interviews.

[unishark]

Yeah was just a comment about how widespread sadism is.

[remote_phone]

Microsoft had all day interviews back in the 90s. It’s more efficient for both parties and has been for decades.