I've had the opportunity to do this fornat twice and I think it works well.
Here's how it works:
They ask you to pick a 3 hour time window to work on the project.
You pick the time.
They send you the project prompt in an email right at the beginning of your time interval.
You have 3 hours to read the prompt, design, implement, test a solution.
If you miss the deadline, project counts for nothing.
Both the times I did this the prompts were absolutely doable in 3 hours.
They were the kind thing you could do in about 2 hours if you had the ability to read the project prompt ahead of time and think about it for a few days.
Personally, I work well with time constraints. This format feels closer to a workday where mid-afternoon you might challenge yourself to finish a task before 5pm. Its a lot less pressure than having to juggle a conversation and having your code scrutinized in real time.
It forces a real time constraint that keeps you from piling time into something you just don't know.
Its hard to cheat, and it also forces the company to make the task achievable in the time frame. This format forces them to realize when the task is too big for anyone to finish in the time.
I hate time constraints. That is why I hate whiteboarding as well.
My brain just not work that way. If I have to modify something in a project I already worked on. That's fine. But interviews always ask tho build something from the ground up.
Once I got the requirements I need a few hours to think about it, before I write any actual code. I usually do something else while I do this. On a job, it's when I home and do some chores and my mind can wander around freely. But I can't make this process much faster. If I'm on the clock I have to sit down and start spitting out code. Also, there is no time for any major refactoring if you went in a wrong direction. This adds a lot of unnecessary stress.
I like it when you have a day or an afternoon to finish a 3 hours long task. I work faster if there's no time pressure.
The real world has time constraints, so I don't see this as unreasonable expectation in an interview.
> I need a few hours to think...before I write any actual code...I work faster if there's no time pressure.
It sounds like you work better but not faster. If something absolutely must be done in 3 hours, you usually will not have 2 hours to do the dishes while you let it marinate.
To be clear, I prefer to let a problem sit in my head for a bit, too. I think the end result is better in most cases, for most people. But the real world has problems with hard and fast time constraints, or huge financial incentives to get something working in ASAP and clean it up later if necessary.
But how many of those involve building a brand new thing you've never thought about from scratch? As the person you responded to said, if they're modifying something they've already worked on, that's different.
If something /brand new/ needs to be built in HOURS with huge financial incentives, that is a failure on so many levels of business that blaming the engineer for their inability to actually get it out the door in 3 hours is ridiculous
Yes, I completely fine with actual hard time pressure, when I know the codebase. When I'm on call and something goes wrong I can fix the code very fast and reliably.
When I presented with a completely new problem I have to think about what is the best tool for the job, how I want to structure my code, how can I test it, what are the edge cases, etc.
Yes. Though in practice I'd give people some grace period after the three hours: the three hour time limit is to help the candidate not commit endless hours to the project, it's not meant as a punishment.
I agree here - given the pressures of an interview are much higher than on the job, enforcing a time limit should only prevent extremes rather than add yet more pressure.
I think I’d be fine if someone gave me 3 hours to complete a typical take home exercise, but I worry that some exceptional engineers I know might not be. Applying excessive time pressure could lead to cultural homogeneity.
Yup I've done a couple interviews like that. They send the email at the time of your choosing and you have to submit the finished challenge at whatever deadline. Works for me! I can do things how I want to, just as if I had been given such a task on the job.
> They send you the project prompt in an email right at the beginning of your time interval
Whoops, your home internet has gone down. Or Gmail has decided it's not having any mail from their domain. Or your mail provider think they're spam. Or your mail client doesn't pick up the email for half an hour. There's a whole raft of problems coming from "email delivery is reliable enough to be a timer."
Take homes can & ought to be timed.
I've had the opportunity to do this fornat twice and I think it works well.
Here's how it works: They ask you to pick a 3 hour time window to work on the project. You pick the time. They send you the project prompt in an email right at the beginning of your time interval. You have 3 hours to read the prompt, design, implement, test a solution. If you miss the deadline, project counts for nothing.
Both the times I did this the prompts were absolutely doable in 3 hours. They were the kind thing you could do in about 2 hours if you had the ability to read the project prompt ahead of time and think about it for a few days.
Personally, I work well with time constraints. This format feels closer to a workday where mid-afternoon you might challenge yourself to finish a task before 5pm. Its a lot less pressure than having to juggle a conversation and having your code scrutinized in real time.
It forces a real time constraint that keeps you from piling time into something you just don't know.
Its hard to cheat, and it also forces the company to make the task achievable in the time frame. This format forces them to realize when the task is too big for anyone to finish in the time.