[rockbruno]

Everyone complains about the state of SWE interviews yet nobody seems to be able to come up with a legit better alternative. Even the author recognises this in the article.

This format is popular because it's the best time/effort trade-off for both the company and the candidate. It's massively flawed, but everything else attempted so far turned out to be even worse.

[ye-olde-sysrq]

How do other industries do this?

Is programming weird because you can just ask someone to prove they know how to use a hammer? And so other industries just have to hire based on work history and/or bias "culture fit" during the interview? And they suffer terribly from people who can talk the talk but not walk the walk?

Or is programming weird because there's so much propensity for people to be able to talk but not walk? We rely on nerdspeak and jargon so much that just being able to prattle on in a dilbert-esque way would otherwise convince someone to hire you?

[michaelt]

> How do other industries do this?

There's lots of other ways, but some of them suck.

Some fields attach a lot of weight to your alma mater, maybe they only hire people who studied law at Yale or Harvard.

Some fields require not just a degree, but also years of study under an industry veteran. Sometimes that also involves hazing like working 70-hour weeks, for some reason.

Some fields require work-sample tests where you show up at a given location and demonstrate your abilities on demand.

Some fields require not only a degree, but also years of working for free in order to break into paid work. And the paid work is far from guaranteed, that free work only pays off for 10% of people.

Some fields don't offer permanent employment, instead hiring people for much shorter periods - so bad hires can just not be rehired for the next project.

[zamnos]

Some fields have a literal test you have to pass to get a license which allows you to practice that field, and some even have laws that criminalize practicing in the field without said license.

Given surgeons don't have to do live pancreatectomies as part of the interview process, I'm not convinced that's such a bad thing.

[rockbruno]

I am not sure. I think part of the reason is that programming lives completely on the digital plane, while other fields tend to have physical components that can't be faked and allow you to grasp someone's knowledge in a much more straightforward way (e.g cooks produce physical food that you can see and taste)

[emodendroket]

Probably a little of both. A staggering number of candidates are just completely unable to solve simple problems.

[chihuahua]

Many years ago, I interviewed a candidate at Amazon for an SDE3 job (aka Senior SDE.) I asked him to write a function that takes 2 sorted arrays of integers and merges them into a single sorted array of integers. He just couldn't do it.

This is very simple problem to solve, and I think anyone who can't do that is not suitable for SDE3 (or 2 or 1, in my opinion)

One could argue about very difficult problems - can a candidate really be expected to invent the solution on the spot, or is it just because they saw it on LeetCode? Is it luck or ability?

But for simple problems, they are a strong negative signal and a very weak positive signal: just because you can merge sorted arrays, doesn't mean you're qualified, but if you can't even do that, you're most likely not qualified.

[zamnos]

Triplebyte and a few others in that space were able to do pre-screening for companies that chose to go though them, which skipped the recruiter call and pre-screen and got you on site faster. Worked pretty well, but they failed to figure out a business model and we sold to Karet which just shut down Triplebyte's candidate vetting process.

[lytefm]

I've had good experiences as an interviewer doing code review style interviews.

The candidate gets some code and a ticket description of what the code should do.

If he spots an issue, he can fix it right in the code or simply explain it.

I'd that testing the ability to read and understand code is both less stressful for the interviewee (no "judging every key stroke" stress) and more helpful for the interviewer.

[ncr100]

Spend 4 hours coding, while being paid by the interviewer, watched by a peer, working on a bug fix or new feature.

Works great.