The thing about take home interviews is that the code can always be better. No matter how experienced you are, a sufficiently anal retentive person will nitpick

The thing about take home interviews is that the code can always be better. No matter how experienced you are, a sufficiently anal retentive person will nitpick it apart. If you want to play their game, your only choice is to dedicate more and more hours to the project until it is damn near perfect. Tips: 1-) Always run the code against a linter on strict settings before submitting. PyLint would have helped you. 2-) Always make sure everything is tested, even if it is trivial. 3-) Better to err in the side of too many comments than too few. 4-) Always include a README file with in depth explanation on how to build it, run it and what it does and how to use it. 5-) Set your project up for distribution, this means if you are doing python, include a requirements.txt if you are using external dependencies (Protip: avoid using external dependencies whenever possible) 6-) Use design patterns, whenever possible. Call attention to it in the comments: "Using decorator pattern to blalbalblas" 7-) Include a TODO file with a wishlist of features you would have done but didn't have time to implement (heh). 8-) If possible, get one of your mates to do a code review for you. Make sure your mate is an expert on the language of the project and also make sure you tell him to be as anal retentive as possible. Does this sound insane to you? Good. Alternatively, you could do what I started doing. Just refuse these kind of interviews. The state of interviewing is partly our fault for putting up with stuff like this.