[ornornor]

In my experience, the number of hours the company suggests is always BS. It takes 2–3x as much time to experiment and then polish your solution. It might take the states amount of time if you’re the person who came up with the problem and knows how to solve it right away because you’ve put much thought into it and have seen dozens or hundreds of solutions already.

[bruce511]

The context is also radically different.

Let's say I come up with an assignment and I pass it to a junior to see how long it takes. The junior does the work, likely reports the time rounded down, but also with no stakes. Jim job is secure.

As an interviewee you're gonna spend time polishing the code. Every variable well named, lots of comments, good functions, well considered parameter order etc. It's gonna take longer because , for you, the stakes are higher. You'll likely build some code to test it, and so on.

This is before we discuss domain knowledge that the junior had, and also that the company implemented the task in the first place and didn't just spitball the time expected.

[sgerenser]

Yeah I’d be very surprised if even half of take home assignments were “tested” on juniors vs just having time estimates spitballed. You know, like every dev does when asked “so how long do you think this ticket will take to implement?”

[deredede]

With the unfortunate difference that when estimating a ticket you will have to complete, most people have learned to give safe over-estimates, but they don't want to look bad when a prospective hire complete the job in 1/4 the time estimate...

[autarch]

When I've created these sorts of take homes I always do them myself and have at least 1 other person on the team do them. My thinking was that we should be able to do them in 1.5 hours if we tell the candidate it will take then up to 3 hours. I would give my own time to complete it as the expected time for a candidate.

[seriousman123]

You can't create the take home yourself because you're drawing on your own personal domain experience.

For example I'm an expert on real time video streaming in embedded systems. It's trivial to me to program a real time system that will stream video at a lower resolution in real time from scratch. I pass that problem to your average backend web developer they're going to take 100x longer then me.

The issue is, while it may seem obvious to you that the domain is too specialized, when you yourself spend to much time in a specific domain you become biased and you start to think such knowledge is basic because you get too good at it. It's invisible to you.

Time shouldn't be the factor measured here because people have such varied backgrounds.

[autarch]

The take homes I created in the past were not so extremely domain specific. They were relatively common problems like "read these JSON files and generate a tree of dependencies between them based on references, where file1.json might contain an item like 'file2.json'".

[maest]

If I'm hiring for a real time video streaming platform, I probably don't want to hire a backend dev who has 0 experience in the field and takes 100x thr time, so this seems fine.

The point of the assignment isn't to make it "fair" (in some loose sense), but to filter out candidates.

[sgerenser]

True to some extent, but you usually don’t want to filter out all candidates who don’t have extensive experience in the exact domain you’re working in, otherwise you’d never hire anyone.

[robryan]

It is also going to be very hard to stand out on them without taking extra time because like it or not for a top company the competition is going to be spending that 2-3x time. At least in a technical interview the problem is time boxed so that the other solutions you are being compared against also only got 45 minutes.

[mrkurt]

We design these so people with relevant experience can bang them out in about two hours. They're not trick challenges, though, they're very straightforward. Getting people to believe they should only spend two hours on them is the challenge.

[seriousman123]

It's not BS in the sense they are lying. It's BS because they're wrong.

The reason they end up getting it wrong is usually because they pick something domain related to what the company does. So these guys literally work in that domain every single day of course they know it in and out.

When they throw it at someone completely foreign to the domain it's going to take a longer time to figure it out. Most interviewers just lack the ability to see this.