
Ask HN: How to interpret this coding take home interview reject - takehomereject
I recently submitted a take home coding test and got the following reject. Question was to build a simplified tetris game.<p>&quot;
The code works and it&#x27;s fine as adequate Python, although it doesn&#x27;t follow Python&#x27;s style guideline of using underscores in function and variable names. But there&#x27;s nothing particularly impressive or that stands out as unusually well done, and a long list of things that are messy, awkward, or should be refactored. And there is very little documentation and no high-level explanation of the approach.
&quot;<p>for the first line, This is not a python position(clojure programmer), i used camelcase instead of snakecase.<p>Wondering if there is anything I can learn from the rest of the feedback.<p>Trying to see where i am falling short. I double checked my code ( ~ 150 lines) and I don&#x27;t see anything blatantly wrong&#x2F;ugly with it.
======
kentrado
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.

------
gus_massa
For the last line, it probably means "write more comments".

Python code has usually """docstrings""" at the beginning of each function,
that have some special format and support from the IDE. (I'm not sure if they
are common in Clojure.)

Perhaps the takeaway is that if they assign you a Python project for a Clojure
position, it will be evaluated as a Python project by a Python expert.

(Another takeaway is that a Python project for a Clojure position is a red
flag.)

(Another possibility is that your code really need more comments.)

(It is weird that they expect more refactoring. I expect Clojure code to be
more refactored than Python code, but perhaps the problem is that my Python
code is too bad.)

