3 ms·
My key point every time my team discusses hiring: If you think your take-home project takes N hours, add 1-1.5. You already know the context, and are underestim
by digb 7y ago
My key point every time my team discusses hiring: If you think your take-home project takes N hours, add 1-1.5. You already know the context, and are underestimating the difficulty even if you've run through it before.
- jagged-chisel 7y ago> ... especially if you've run through it before [edits mine] We're doing a hackathon-style interview session this Friday, and I've already had to remind the team that one of our coding challenges is "easy" because we know the answer. You need to think back to the first time you saw it. Also, we're not actually interested in the solution, but how you arrived at it. Once you grok the problem, most software people hit on the solution pretty soon, and can begin coding - we want to see how you come to the realization, and then how you work to create the solution.
- realthing 7y agoThis sounds silly
- dver 7y agoThis can be added to the bigger pile that is software project estimation.
- commandlinefan 7y agoHofstatder’s law: it always takes longer than you expect, even after accounting for Hofstatder’s law.
- Ididntdothis 7y agoAnd you never know what the company wants. Fully tested, nicely formatted code or just a proof of concept? Agnonizing over this also costs time.
- chris11 7y agoA lot of this is dependent on how reasonable the take home project is. But I've always assumed that my work needs to be professional. That means it needs to be readable, well-designed, and nicely formatted. Of course take-home projects should be short, and are basically a POC. But shortcuts should probably be discussed with the interviewer and should be well documented.