Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Invention vs re-use. Unless the candidate is willing to take an honest, logical approach to this decision (involving defendable reasoning), I'd be wary.

Is it a solved problem? No? Invent it.

Is the solution available to you within your constraints? No? Make your own implementation (unless there's a way to acceptably compromise in the design).

Is the solution cost-effective to use (performance, ease-of-use, bugginess, support, etc)? No? Make a better implementation.

Otherwise just re-use an existing solution.



  Is it a solved problem? No? Invent it.
Something to consider: Sometimes we can change the rules. If given requirements A, B, and C, and we discover that “A” is not a solved probloem, we could go ahead and invent a solution. Then again, perhaps we can push back and ask if some lesser requirement A’ (which is a solved problem) is sufficient for success.

The converse is possible as well. Given requirements X, Y, and Z, all of which are solved problems, sometimes we can raise our hands and say “Will we really be successful implementing another Me-Too thingummy? If we take a chance and try to add feature W—which is not a solved problem—we will have a competitive advantage.”

I agree with your basic premise, but want to point out that given a certain bias, we can sometimes fark around with the requirements to suit ourselves. So a candidate in an interview could easily convince you that he had to invent a way to synchronize documents while supporting offline editing, but aother candidate in the same situation might have avoided the requirement necessitating invention in the first place. Or the reverse!




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: