[oceanplexian]

> All things equal, if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one.

They are stronger in the specific problem space you’re testing for. If your business has a lot of novel coding problems that need to be solved in under 9 minutes, then sure, this is a great measurement.

On the other hand, if your business has a lot of hard problems that take days, weeks, or quarters to solve, measuring someone’s ability to solve a 9 minute problem is a terrible metric. If anything it’s a counter signal, since it tends to select for candidates that optimize short term thinking over long term planning and problem solving.

[hnfong]

> if your business has a lot of hard problems that take days, weeks, or quarters to solve

I suppose your ideal interview as an interviewer would be to give the candidate a take home task and ask them to spend 2 weeks to work on it?

> If anything it’s a counter signal

Or perhaps give the candidate a task that normally takes 30 minutes, and hire the candidate if they take 60 mins to finish it?

I mean, you do you, but I hope you (and everyone else) can see why I'm not convinced otherwise.

[frumper]

No, the ideal interview is to ask them questions about what type of problems they've solved before and ask them to walk through what they did. Also, have a conversation with the person to get to know a little bit about what they're looking for in a job/company. It's an interview, not a tryout.

Metrics like a 10 minute task, or a 30 minute task is all relative. Do they know they language, the IDE, the operating system, the documentation, any experience in whatever abstract problem topic you choose, and personal comfort levels will all come into play.

If you want to filter someone to do a very specific thing then post to hire a contractor with the specifics of what you need. If you want a developer that can grow within your organization then pop quizzes area good way to dismiss good candidates.

[edanm]

> No, the ideal interview is to ask them questions about what type of problems they've solved before and ask them to walk through what they did.

This just doesn't work. Lots of people can bullshit very convincingly, and even if they can't produce novel solutions, can very well explain them in a matter that makes you think they for-sure know how to do it.

Hell, I can probably still prove lots of interesting things about set theory in math, as can many other people who studied math - doesn't make me the equivalent of the world-class mathematicians who actually came up with the proof.

Empirically, "talk to someone about what they did" doesn't give me hires that actually know what they're doing.

[spacemanspiff01]

If they pay me at contract rates double my current salary, and in my particular case my current IP assignment clause/the problem/ law makes it ok. Sure, pay me money to do something like what you guys need done.

Probably most useful if it's a contribution to open source.

[gymbeaux]

I don’t get why I have to prove to some strangers I can write code when I’ve been doing it for the last decade. It’s a ludicrous and broken system.

[zamnos]

Because those strangers don't know you.

Any idiot can write things on a resume and say they did things they didn't do (aka lying). You would never do such a thing, of course, but as crazy as it sounds, there are people out there who would do just that! So because there's no professional license to write code, the only way to prove to these strangers that you actually can write code is some sort of exercise where you prove it to them.

I really don't get why this is so hard to understand, either. I get that live coding in front of someone else is a crazy stressful situation - I've failed multiple interviews because I couldn't perform on demand and answer the interview question in the interview setting, when I could easily have done so after taking a proverbial shower to have a think, so I'd love to get rid of them too. But unless we all band together and start a software developers guild or something, the live coding interview is here to stay. (Though, Triplebyte, now Karat, and others did take a run at improving the process, so there's that.)

I know what I know, but you don't know what I know. It's only by communicating, in a sufficiently unfakeable way, like a 45-minute in-person interview, that one can pass or fail the unwritten "can program" shibboleth.

[gymbeaux]

My issue is that these coding interviews tend to turn up a lot of false-negatives and sometimes even false-positives. And of course they do. There’s so much more to what we do than being able to implement A* in 45 minutes without a real IDE could demonstrate.

[dragonwriter]

You don’t get why you have to prove your ability to do a job when you want them to pay you to do that job?

[gymbeaux]

Yep. I realize that’s not going to resonate with many or even most people, but that doesn’t mean I don’t believe it and that doesn’t mean it doesn’t have merit.

Law firms don’t ask lawyers to litigate in a mock courtroom setting before hiring them. Hospitals don’t ask surgeons to perform a little test surgery on a person before hiring them. Engineers aren’t asked to build a bridge to prove they know how.

I think the reason we are so unique is because we CAN demonstrate our ability to quickly and easily, and without risking human life. CAN of course does not equal SHOULD.

[bennyelv]

Law is a protected profession - you have to pass exams to be able to call yourself a Lawyer, and a law firm will verify that you have passed the relevant exams.

Same for medicine, engineering...

Any chump can call themselves a software engineer. That's the real problem here.