[e4e78a06]

Strongly disagree if we are talking a complex problem like coding a distributed system. It is very possible for an implementation to be 90% correct but it won't compile or it's wrong for very subtle reasons. And maybe if there was another 30 minutes it would be debugged correctly but it didn't work out in the 45 minute interview period. There is signal contained in the 90% right attempt that can show a lot of knowledge and skill which you'd be missing out using autorejects.

We are not talking some CRUD app where it is trivial to make each component work or a Leetcode problem that you can spit out in 20 minutes.

[ytpete]

I'd still argue it's a bad sign if the candidate is stuck with nothing even compiling after 45 minutes. That's not a sign of the problem being complicated, that's a sign of the developer either (a) struggling to figure out dev environment basics, or (b) having a tendency to go way down one solution path without pausing for any simple gut checks / sanity tests of their work in progress.

In the latter case, is it possible for a developer to operate that way and still produce a great solution given more time? I suppose so - but in my experience, the people who are not in the habit of incrementally checking their work are virtually never strong developers.

There's also a time management question here. If a person knows they only have 45 minutes, that should create extra pressure to start testing earlier. Someone who still waits until time's almost up before checking anything is probably a fairly extreme case of this antipattern.

[garyjlin]

Yeah this is actually why we recommend liberally-timed take homes instead of a sit down 45 minute block. It's super frustrating to get 95% of the way there just to be cut out by time.